Tillförlitlighet i Azure Notification Hubs

Azure Notification Hubs hjälper dig att hantera push-meddelanden i flera plattformsmeddelandesystem (PNS), till exempel Apple Push Notification Service (APN), Firebase Cloud Messaging (FCM) och Windows Push Notification Service (WNS).

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur du gör Notification Hubs motståndskraftigt mot olika potentiella avbrott och problem, inklusive tillfälliga fel, fel i tillgänglighetszonen, regionomfattande fel och serviceunderhåll. Den beskriver även alternativ för säkerhetskopiering och återställning samt viktig information om serviceavtalet för Notification Hubs (SLA).

Rekommendationer för produktionsdistribution

Följ dessa rekommendationer för produktionsarbetsbelastningar:

Översikt över tillförlitlighetsarkitektur

Azure Notification Hubs ordnas runt namnrymder och meddelandehubbar. Ett namnområde är en hanteringsgräns som innehåller en eller flera hubbar. Hubbar representerar slutpunkter för ett program. Enheter registreras med dessa slutpunkter med hjälp av antingen registreringar eller installationer, vilket gör att tjänsten kan skicka push-meddelanden till enheterna. Mer information finns i Registreringshantering.

Notification Hubs skickar push-meddelanden till plattformsmeddelandesystem (PNS), till exempel Apple Push Notification Service (APN) och Firebase Cloud Messaging (FCM). Leverans av meddelanden från slutpunkt till slutpunkt beror på tillgängligheten för Notification Hubs och beteendet hos underordnade PNS-leverantörer.

För tillförlitlighetsplanering är det viktigt att skilja mellan följande typer av data som Notification Hubs hanterar:

• Metadata: Namnområdes- och hubbkonfiguration, inklusive anslutningsinformation och konfiguration av haveriberedskap.
• Registreringsdata: Enhetsregistreringar och installationer som mappar användare och enheter till taggar och mallar.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av övergående fel.

Notification Hubs hanterar automatiskt tillfälliga fel som uppstår vid anslutning till ett PNS. Du ansvarar dock för att hantera tillfälliga fel när dina tjänster eller användares enheter interagerar med Notification Hubs. Tillfälliga fel kan inträffa under registreringsåtgärder, meddelandesändningsåtgärder och hanteringsåtgärder. Följ den här vägledningen:

• Registreringar och installationer: Dina program på enheter bör försöka registrera igen och installera åtgärder som misslyckas på grund av tillfälliga fel. Microsoft tillhandahållna SDK:er hanterar återförsök automatiskt. Om du inte kan använda de tillhandahållna SDK:erna, bör du implementera logik för återförsök med exponentiellt ökande väntetid och jitter samt göra registreringsåtgärderna idempotenta där det är möjligt.

  Att skapa eller uppdatera en installation är idempotent, så du kan försöka utföra åtgärden igen på ett säkert sätt. Använd installationer i stället för registreringar när det är möjligt.

• Skicka aviseringar och utför hanteringsåtgärder: Använd ett SDK från Microsoft för att skicka push-meddelanden och utföra hanteringsåtgärder. Dessa SDK:er försöker automatiskt igen när tillfälliga fel inträffar.

  Om du inte kan använda de angivna SDK:erna implementerar du omprövningslogik med exponentiell backoff och jitter och gör aviseringssändningsåtgärderna idempotent där det är möjligt.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

I regioner som stöder tillgänglighetszoner stöder Notification Hubs-namnområden en zonredundant konfiguration. Notification Hubs aktiverar automatiskt zonredundans för alla namnområden i vissa regioner. När zonredundans är aktiverat replikerar Microsoft både metadata och registreringsdata i alla tillgänglighetszoner i regionen.

Requirements

• Regionstöd:

  Notification Hubs aktiverar automatiskt zonredundans för alla namnområden i följande regioner. Du kan inte inaktivera zonredundans i dessa regioner:

  Europa	Mellanöstern	Africa	Asia Pacific
  Frankrike Centrala	Qatar Central	Sydafrika Nord	Norra Kina 3
  Norra Italien			Korea Central
  Norway East
  Centrala Polen
  Centrala Sverige
  Schweiz Nord

  I andra regioner som stöder Notification Hubs och har tillgänglighetszoner är zonredundans valfritt. Du kan bara aktivera det när du skapar ett namnområde.

• Stöd för nivå: Du kan använda tillgänglighetszoner med alla nivåer i Notification Hubs.

Cost

Zonredundans medför en extra kostnad utöver nivåpriset. Mer information finns i Priser för Notification Hubs.

Konfigurera stöd för tillgänglighetszoner

• Skapa ett nytt zonredundant namnområde: Processen för att skapa ett nytt zonredundant namnområde beror på vilken region du använder:

  • I regioner där Notification Hubs automatiskt aktiverar zonredundans behöver du inte konfigurera den.

    Important

    I dessa regioner skapar Notification Hubs alltid namnområden med zonredundans aktiverat, även om en kodbaserad distribution, till exempel en Bicep fil eller Azure Resource Manager mall, anger att zonredundans är inaktiverad.

    Om du inte vill ha ett zonredundant namnområde skapar du det i en region som stöder valfri zonredundans.

  • I regioner där zonredundans är valfritt kan du bara aktivera den när du skapar ett namnområde. Information om hur du konfigurerar ett nytt namnområde med zonredundans finns i Skapa en Azure meddelandehubb i Azure-portalen.

• Gör en befintlig namnområdeszon redundant: Notification Hubs stöder inte migrering på plats av ett befintligt namnområde till stöd för tillgänglighetszoner. Du måste distribuera ett nytt namnområde och flytta dina registreringar till det namnområdet. Följ riktlinjerna i Flytta resurser mellan Azure regioner, vilket även gäller om du distribuerar det nya namnområdet i samma region.

Beteende när alla zoner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Notification Hubs-namnområde för zonredundans och alla zoner är i drift.

• Åtgärd mellan zoner: Notification Hubs distribuerar och hanterar begäranden automatiskt med hjälp av infrastruktur i valfri zon i regionen.

• Datareplikering mellan zoner: Både registreringsdata och metadata replikeras synkront över alla zoner i den angivna regionen.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Notification Hubs-namnområde för zonredundans och det uppstår ett avbrott i någon av zonerna.

• Identifiering och svar: Microsoft identifierar zonfel och hanterar redundans i regionen. Du behöver inte starta failover.

• Anmälan: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktiva begäranden: Hanteringsåtgärder under flygning, enhetsregistreringar och nya begäranden om att skicka meddelanden kan misslyckas under redundansväxlingen. Dina program bör försöka utföra misslyckade åtgärder igen genom att följa vägledningen för tillfällig felhantering.

• Förväntad dataförlust: Dataförlust förväntas inte under ett avbrott i en zon eftersom Notification Hubs synkront replikerar namnområdes- och hubbkonfigurations- och registreringsdata mellan tillgänglighetszoner.

  Den här replikeringen är inte en säkerhetskopia. Under modellen med delat ansvar ansvarar du för att säkerhetskopiera registrerings- och installationsdata. Mer information finns i Säkerhetskopiering och återställning.

• Förväntad stilleståndstid: Ett kort avbrott i tjänsten är möjligt när Microsoft omdirigerar trafik. Följ vägledningen för tillfällig felhantering för att förbereda dina program för dessa avbrott.

• Omdistribution: Tjänsten omdirigerar automatiskt begäranden till felfria zoner.

Zonåterställning

När den berörda zonen återställs behöver du inte vidta några åtgärder. Microsoft återställer och balanserar om Notification Hubs-infrastrukturen för att använda den återställda zonen.

Test för zonfel

Du kan inte utlösa redundansväxling för Notification Hubs-zoner direkt. Testa ditt arbetsbelastningsbeteende genom att köra motståndskraftstester för återförsök, idempotens och beroendefel i icke-produktionsmiljöer. Du kan också använda Azure Chaos Studio för att testa omgivande programkomponenter.

Motståndskraft mot regionomfattande fel

Notification Hubs tillhandahåller haveriberedskap för metadata genom att replikera namnområdesmetadata mellan regioner, men de replikerar inte enhetsregistreringsdata. Den här funktionen kräver manuella åtgärder under ett regionavbrott och innebär viss stilleståndstid för din meddelandehubb.

Om du behöver minska stilleståndstiden och manuella åtgärder under redundansväxlingen bör du överväga att använda en anpassad lösning för flera regioner.

Microsoft-hanterad geografisk haveriåterställning för metadata

Notification Hubs stöder Microsoft-hanterad haveriåterställning för metadata i en sekundär Azure-region. Om din primära region har en parkopplad region kan du välja den parkopplade regionen. Oavsett parkopplingsstatus för din primära region kan du också välja en sekundär region från en lista över flexibla återställningsregioner. Notification Hubs replikerar sedan namnområdesmetadata, till exempel namnområdesnamn, anslutningssträngar och annan viktig information.

Microsoft ansvarar för att utlysa katastrofläge och initiera redundansväxling. När det händer skapar Microsoft ett nytt namnområde i den sekundära regionen. Eftersom den använder metadata från den primära regionen kan program ansluta till det namnområdet med hjälp av det befintliga namnområdesnamnet, reťazec pripojenia och hubbnamnen.

Requirements

• Regionstöd: I parkopplade Azure regioner kan ditt namnområde använda den Azure parkopplade regionen som sekundär region.

  Om ditt namnområde finns i en icke-komprimerad region, eller om du vill replikera data till en annan region, kan du välja någon av följande flexibla återställningsregioner som den sekundära regionen:

  Americas	Europa	Africa	Asia Pacific
  Syd-Brasilien	North Europe	Sydafrika Nord	Australia East
  Västra USA 2			Southeast Asia

• Nivåstöd: Alternativ för haveriåterställning av metadata är tillgängliga i alla Notification Hubs-nivåer.

Cost

Notification Hubs tar inte ut någon extra avgift för att konfigurera eller använda metadatarelaterad geohaveriberedskap. Du betalar dock för bandbredden mellan regioner som används för att replikera metadata. Prisinformation finns i Priser för bandbredd och Priser för Notification Hubs.

Konfigurera stöd för flera regioner

• Aktivera geografisk haveriberedskap av metadata för ett nytt namnområde: Följ anvisningarna i Skapa en Azure-meddelandehubb i Azure-portalen. Välj konfigurationen för haveriåterställning när du skapar namnområdet.

• Aktivera eller inaktivera geo-haveriåterställning för metadata för ett befintligt namnområde: Följ anvisningarna i Aktivera haveriåterställning för ett befintligt namnområde i Azure Notification Hubs.

• Säkerhetskopiera dina enhetsregistreringsdata: Se Exportera och importera Azure Notification Hubs registreringar i bulk.

Beteende när alla regioner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Notification Hubs-namnområde för geohaveriåterställning för metadata och både dina primära och sekundära regioner är i drift.

• Åtgärd mellan regioner: Den primära regionen hanterar alla begäranden. Den sekundära regionen hanterar inte begäranden om inte redundansväxling sker.

• Datareplikering mellan regioner: Metadata, till exempel namnområdesnamn, hubbkonfiguration, anslutningssträngar och annan viktig information, replikeras asynkront mellan regioner. Registreringsdata replikeras inte. Du ansvarar för att exportera den regelbundet för att underhålla en säkerhetskopia.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Notification Hubs-namnområde för metadata-geo-haveriåterställning, om det uppstår ett avbrott i den primära regionen.

• Identifiering och svar: Microsoft ansvarar för att identifiera regionfelet och bestämma om redundans ska utlösas till den konfigurerade sekundära regionen.

• Anmälan: Microsoft meddelar dig inte automatiskt när en region är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktuella begäranden: Pågående begäranden till namnområdet i den primära regionen kan misslyckas när regionen blir offline. Klienter bör försöka utföra åtgärder igen när redundansväxlingen har slutförts.

• Förväntad dataförlust: Metadata bevaras. Registreringsdata säkerhetskopieras inte automatiskt, men du kan säkerhetskopiera dem själv. Mer information finns i Exportera och importera Azure Notification Hubs registreringar i bulk. Om du inte gör det är registreringsdata inte tillgängliga förrän den primära regionen återställs.

• Förväntad stilleståndstid: Det tar lite tid för Microsoft att utlösa redundansväxling av metadata och sedan slutföra redundansväxlingen. Tiden kan variera, men det tar vanligtvis flera timmar.

  När redundansväxlingen är klar ansvarar du för att återställa eventuella säkerhetskopior av registreringsdata.

• Omfördelning: Efter redundansväxling dirigeras förfrågningar till ett namnområde i den sekundära regionen som använder replikerade data från den primära regionen. När redundansväxlingen är klar ansluter klienterna automatiskt till namnområdet i den sekundära regionen.

Regionåterställning

Om den primära regionen återhämtar sig kan det vara möjligt att växla tillbaka till det primära namnområdet i den primära regionen. Det primära namnområdet skulle behålla registreringsdata från före driftstoppet. Detta skulle vara en manuell process och Microsoft skulle kommunicera med dig för att förklara hur detta fungerar.

När den primära regionen har återställts måste du:

• Verifiera tillståndet för ditt namnområde och dess data.
• Avgör om de senaste ändringarna av registreringsdata ska synkroniseras från den sekundära regionen tillbaka till den primära regionen.

Test för regionfel

Du kan inte initiera en geografisk redundansväxling. Du bör dock testa dina egna haveriberedskapsprocedurer. Kontrollera att registreringar säkerhetskopieras och att du kan återställa dem till ett nytt namnområde.

Anpassade lösningar för flera regioner för återhämtning

Geo-haveriåterställning för Microsoft-hanterade metadata replikerar endast metadata. Funktionen kan återställa metadata till ett sekundärt namnområde, men du ansvarar för att importera enhetsregistreringar till det namnområdet så att ditt program kan fortsätta att fungera. Den här metoden kräver manuella åtgärder under en katastrof och innebär stilleståndstid.

Om återställningsmålen kräver mindre stilleståndstid eller manuella åtgärder kan du implementera en anpassad aktiv-aktiv multiregionlösning. Distribuera ett andra Notification Hubs-namnområde till en annan Azure region i förväg.

• Redundans: Eftersom det andra namnområdet är en fungerande resurs kan du implementera logik för att identifiera ett regionfel och växla till det namnområdet.

• Synkronisering: Om du vill hålla en andra meddelandehubb synkroniserad med den primära meddelandehubben använder du något av följande alternativ:

  • För installationer: Använd en appserverdel som samtidigt skapar och uppdaterar installationer i båda meddelandehubbarna. Med installationer kan du ange din egen unika enhetsidentifierare, som stöder det här replikeringsscenariot. Mer information finns i RedundantHub-exemplet.

  • För registreringar: Använd en appserverdel som regelbundet exporterar registreringar från den primära meddelandehubben som en säkerhetskopia och massimporter dem till den sekundära meddelandehubben. Mer information finns i Exportera och importera Azure Notification Hubs registreringar i bulk.

  Om du inte har någon serverdel kan du också konfigurera appen så att den skapar installationer i båda hubbarna när appen startar på målenheter. Enheterna skapar nya registreringar i båda meddelandehubbarna. Så småningom har den sekundära meddelandehubben alla aktiva enheter registrerade.

• Utgångna registreringar och installationer: Den sekundära meddelandehubben kan ha utgångna registreringar och installationer. När ett pushmeddelande skickas till ett handtag som har löpt ut rensar Notification Hubs automatiskt bort den associerade registrerings- eller installationsposten i meddelandehubben baserat på svaret från PNS-servern. Du kan rensa utgångna poster från valfri säkerhetskopieringslösning genom att lägga till anpassad logik som bearbetar feedback från varje sändning och tar bort förfallna registreringar och installationer.

• Oöppnade appar: Det finns en tidsperiod under vilken enheter med oöppnade appar inte tar emot meddelanden.

• Kostnad: Om du använder din egen sekundära hubb för att skydda registreringsdata medför den hubben normala tjänstavgifter. På samma sätt, om du distribuerar andra Azure resurser till din sekundära region för att stödja din återställning, betalar du för dem till normala servicepriser.

Säkerhetskopiering och återställning

Notification Hubs tillhandahåller inte en enda inbyggd säkerhetskopierings- och återställningsfunktion för alla data som lagras i ditt namnområde. Du ansvarar för att kombinera följande metoder:

• Använd infrastruktur som kod (IaC), till exempel Bicep, för att definiera din namnrymd, hubb och principkonfiguration. Lagra dessa definitioner i källkontrollen så att du kan distribuera om resurserna vid behov.
• Säkerhetskopiera dina enhetsregistreringsdata genom att exportera Azure Notification Hubs registreringar i grupp.

Motståndskraft mot serviceunderhåll

Microsoft tillämpar regelbundet tjänstuppdateringar och utför annat underhåll. Den Azure plattformen hanterar dessa aktiviteter automatiskt, vilket säkerställer att underhållet är sömlöst och transparent för dig. Ingen driftstopp förväntas under underhållshändelser om du inte har blivit informerad via Azure Service Health planerat underhåll.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

För Notification Hubs gäller serviceavtalet för tillgänglighet för namnområden som använder nivåerna Basic och Standard.

Relaterat innehåll

• Tillförlitlighet i Azure