Betrouwbaarheid in Azure Notification Hubs

Azure Notification Hubs helpt u bij het beheren van pushmeldingen in meerdere platformmeldingssystemen (PNS), zoals Apple Push Notification Service (APNs), Firebase Cloud Messaging (FCM) en Windows Push Notification Service (WNS).

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Notification Hubs bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiobrede fouten en serviceonderhoud. Ook worden opties voor back-up en herstel en belangrijke informatie over de Service Level Agreement (SLA) van Notification Hubs beschreven.

Aanbevelingen voor productie-implementatie

Volg deze aanbevelingen voor productieworkloads:

Overzicht van betrouwbaarheidsarchitectuur

Azure Notification Hubs is georganiseerd rond naamruimten en Notification Hubs. Een naamruimte is een beheergrens die een of meer hubs bevat. Hubs vertegenwoordigen eindpunten voor een toepassing. Apparaten registreren zich bij deze eindpunten met behulp van registraties of installaties, waardoor de service pushmeldingen naar de apparaten kan verzenden. Zie Registratiebeheer voor meer informatie.

Notification Hubs verzendt pushmeldingen naar platformmeldingssystemen (PNS), zoals Apple Push Notification Service (APNs) en Firebase Cloud Messaging (FCM). De levering van end-to-endmeldingen is afhankelijk van de beschikbaarheid van Notification Hubs en het gedrag van downstream PNS-providers.

Voor het plannen van betrouwbaarheid is het belangrijk om onderscheid te maken tussen de volgende typen gegevens die Door Notification Hubs worden beheerd:

• Metagegevens: Naamruimte- en hubconfiguratie, inclusief verbindingsgegevens en configuratie voor herstel na noodgevallen.
• Registratiegegevens: Apparaatregistraties en installaties waarmee gebruikers en apparaten worden toegewezen aan tags en sjablonen.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke fouten voor meer informatie.

Notification Hubs verwerkt automatisch tijdelijke fouten die optreden bij het maken van verbinding met een PNS. U bent echter verantwoordelijk voor het afhandelen van tijdelijke fouten wanneer uw services of apparaten van gebruikers communiceren met Notification Hubs. Tijdelijke fouten kunnen optreden tijdens registratiebewerkingen, verzendbewerkingen voor meldingen en beheerbewerkingen. Volg deze richtlijnen:

• Registraties en installaties: Uw toepassingen op apparaten moeten registratie- en installatiebewerkingen die mislukken, opnieuw proberen vanwege tijdelijke fouten. Door Microsoft geleverde SDK's verwerken nieuwe pogingen automatisch. Als u de beschikbaar gestelde SDK's niet kunt gebruiken, implementeer dan herhalingslogica met exponentiële backoff en jitter, en maak registratiebewerkingen waar mogelijk idempotent.

  Het maken of bijwerken van een installatie is idempotent, dus u kunt de bewerking zonder risico opnieuw proberen. Gebruik indien mogelijk installaties in plaats van registraties.

• Melding verzendt en beheerbewerkingen: Gebruik een door Microsoft geleverde SDK om pushmeldingen te verzenden en beheerbewerkingen uit te voeren. Deze SDK's proberen het automatisch opnieuw wanneer tijdelijke fouten optreden.

  Als u de aangeboden SDK's niet kunt gebruiken, implementeer dan herhalingslogica met exponentiële back-off en jitter, en maak bewerkingen voor het verzenden van meldingen waar mogelijk idempotent.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

In regio's die beschikbaarheidszones ondersteunen, ondersteunen Notification Hubs-naamruimten een zone-redundante configuratie. Notification Hubs schakelt automatisch zoneredundantie in voor alle naamruimten in sommige regio's. Wanneer zoneredundantie is ingeschakeld, repliceert Microsoft zowel metagegevens als registratiegegevens in alle beschikbaarheidszones in de regio.

Requirements

• Regioondersteuning:

  Notification Hubs schakelt automatisch zoneredundantie in voor alle naamruimten in de volgende regio's. U kunt zoneredundantie in deze regio's niet uitschakelen:

  Europa	Midden-Oosten	Africa	Asia Pacific
  Centraal Frankrijk	Qatar Central	Zuid-Afrika - noord	China - noord 3
  Italy North			Korea Central
  Norway East
  Centraal Polen
  Sweden Central
  Switzerland North

  In andere regio's die Notification Hubs ondersteunen en beschikbaarheidszones hebben, is zoneredundantie optioneel. U kunt deze alleen inschakelen wanneer u een naamruimte maakt.

• Ondersteuning voor lagen: U kunt beschikbaarheidszones gebruiken met alle lagen van Notification Hubs.

Cost

Voor zoneredundantie worden extra kosten in rekening gebracht buiten de prijscategorie. Zie prijzen voor Notification Hubs voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

• Maak een nieuwe zone-redundante naamruimte: Het proces voor het maken van een nieuwe zone-redundante naamruimte is afhankelijk van de regio die u gebruikt:

  • In regio's waarin Notification Hubs zoneredundantie automatisch inschakelt, hoeft u deze niet te configureren.

    Important

    In deze regio's maakt Notification Hubs altijd naamruimten waarvoor zoneredundantie is ingeschakeld, zelfs als een op code gebaseerde implementatie, zoals een Bicep-bestand of Azure Resource Manager-sjabloon, aangeeft dat zoneredundantie is uitgeschakeld.

    Als u geen zone-redundante naamruimte wilt, maakt u deze in een regio die optionele zoneredundantie ondersteunt.

  • In regio's waar zoneredundantie optioneel is, kunt u deze alleen inschakelen wanneer u een naamruimte maakt. Zie Een Azure Notification Hub maken in de Azure-portal voor meer informatie over het instellen van een nieuwe naamruimte met zoneredundantie.

• Maak een bestaande naamruimtezone redundant: Notification Hubs biedt geen ondersteuning voor in-place migratie van een bestaande naamruimte naar ondersteuning voor beschikbaarheidszones. U moet een nieuwe naamruimte implementeren en uw registraties naar die naamruimte verplaatsen. Volg de richtlijnen in Resources verplaatsen tussen Azure regio's, die ook van toepassing zijn als u de nieuwe naamruimte in dezelfde regio implementeert.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Notification Hubs-naamruimte configureert voor zoneredundantie en alle zones operationeel zijn.

• Bewerking tussen zones: Notification Hubs distribueert en verwerkt aanvragen automatisch met behulp van infrastructuur in elke zone in de regio.

• Replicatie van gegevens in meerdere zones: Zowel registratiegegevens als metagegevens worden synchroon gerepliceerd in alle zones in de opgegeven regio.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Notification Hubs-naamruimte configureert voor zoneredundantie en er een storing is in een van de zones.

• Detectie en reactie: Microsoft detecteert zonefouten en beheert failover binnen de regio. U hoeft geen failover te initiëren.

• Notification: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: In-flight beheerbewerkingen, apparaatregistraties en nieuwe aanvragen voor het verzenden van meldingen kunnen mislukken tijdens een failover. Uw toepassingen moeten mislukte bewerkingen opnieuw proberen door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

• Verwachte gegevensverlies: Gegevensverlies wordt niet verwacht tijdens een storing in één zone, omdat Notification Hubs synchroon naamruimte en hubconfiguratie- en registratiegegevens repliceert in beschikbaarheidszones.

  Deze replicatie is geen back-up. Onder het model voor gedeelde verantwoordelijkheid bent u verantwoordelijk voor het maken van back-ups van registratie- en installatiegegevens. Zie Back-up en herstel voor meer informatie.

• Verwachte downtime: Een korte serviceonderbreking is mogelijk terwijl Microsoft verkeer omleidt. Volg de richtlijnen voor tijdelijke foutafhandeling om uw toepassingen voor te bereiden op deze onderbrekingen.

• Herdistributie: De service stuurt aanvragen automatisch om naar zones die in orde zijn.

Herstel van zone

Wanneer de getroffen zone wordt hersteld, hoeft u geen actie te ondernemen. Microsoft herstelt de infrastructuur van Notification Hubs en brengt deze opnieuw in balans om de herstelde zone te gebruiken.

Testen op zonefouten

U kunt failover van een Notification Hubs-zone niet rechtstreeks activeren. Als u het gedrag van uw workload wilt testen, voert u tolerantietests uit voor nieuwe pogingen, idempotentie en afhankelijkheidsfouten in niet-productieomgevingen. U kunt ook Azure Chaos Studio gebruiken om omringende toepassingsonderdelen te testen.

Tolerantie voor storingen in de hele regio

Notification Hubs biedt herstel na noodgevallen van metagegevens door metagegevens te repliceren tussen regio's, maar er worden geen apparaatregistratiegegevens gerepliceerd. Voor deze mogelijkheid is handmatige tussenkomst vereist tijdens een regiostoring en is er sprake van enige downtime voor uw Notification Hub.

Als u downtime en handmatige interventie tijdens de failover wilt verminderen, kunt u overwegen om een aangepaste multiregio-oplossing te gebruiken.

Microsoft beheerde geo-noodherstel van metagegevens

Notification Hubs ondersteunt herstel na noodgevallen van Microsoft beheerde metagegevens naar een secundaire Azure regio. Als uw primaire regio een gekoppelde regio heeft, kunt u die gekoppelde regio selecteren. Ongeacht de koppelingsstatus van uw primaire regio, kunt u ook een secundaire regio kiezen uit een lijst met flexibele herstelregio's. Notification Hubs repliceert vervolgens metagegevens van naamruimten, zoals de naamruimtenaam, verbindingsreeksen en andere kritieke informatie.

Microsoft is verantwoordelijk voor het declareren van een noodgeval en het initiëren van een failover. Als dat gebeurt, maakt Microsoft een nieuwe naamruimte in de secundaire regio. Omdat de metagegevens uit de primaire regio worden gebruikt, kunnen toepassingen verbinding maken met die naamruimte met behulp van de bestaande naamruimtenaam, verbindingsreeks en hubnamen.

Requirements

• Regioondersteuning: In gekoppelde Azure regio's kan uw naamruimte de gekoppelde Azure regio als secundaire regio gebruiken.

  Als uw naamruimte zich in een niet-gereairede regio bevindt of als u gegevens naar een andere regio wilt repliceren, kunt u een van de volgende flexibele herstelregio's selecteren als de secundaire regio:

  Americas	Europa	Africa	Asia Pacific
  Brazilië Zuid	Europa - noord	Zuid-Afrika - noord	Australia East
  Westelijke Verenigde Staten 2			Southeast Asia

• Ondersteuning voor lagen: Opties voor herstel na noodgevallen voor metagegevens zijn beschikbaar in alle Notification Hubs-lagen.

Cost

Notification Hubs brengt geen extra kosten in rekening voor het configureren of gebruiken van geografisch herstel na noodgevallen voor metagegevens. U betaalt echter voor de bandbreedte tussen regio's die wordt gebruikt om metagegevens te repliceren. Zie prijzen voor bandbreedte en Prijzen voor Notification Hubs voor meer informatie over prijzen.

Ondersteuning voor meerdere regio's configureren

• Geografisch noodherstel van metagegevens inschakelen voor een nieuwe naamruimte: Volg de procedure in Een Azure-meldingshub maken in Azure Portal. Selecteer de configuratie voor herstel na noodgevallen wanneer u de naamruimte maakt.

• Geografisch noodherstel van metagegevens in- of uitschakelen voor een bestaande namespace: Volg de procedure in Noodherstel inschakelen voor een bestaande Azure Notification Hubs-namespace.

• Maak een back-up van uw apparaatregistratiegegevens: Zie Azure Notification Hubs registraties bulksgewijs exporteren en importeren.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Notification Hubs-naamruimte configureert voor herstel na geo-noodgeval voor metagegevens en zowel uw primaire als secundaire regio's operationeel zijn.

• Bewerking tussen regio's: De primaire regio dient alle aanvragen. De secundaire regio verwerkt geen aanvragen, tenzij er een failover plaatsvindt.

• Replicatie van gegevens in meerdere regio's: Metagegevens, zoals de naamruimtenaam, hubconfiguratie, verbindingsreeksen en andere kritieke informatie, worden asynchroon gerepliceerd tussen regio's. Registratiegegevens worden niet gerepliceerd. U bent verantwoordelijk om het regelmatig te exporteren om een back-up te behouden.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten als u een Notification Hubs-naamruimte configureert voor geografisch noodherstel van metagegevens en er een storing optreedt in de primaire regio.

• Detectie en reactie: Microsoft is verantwoordelijk voor het detecteren van de regiofout en het bepalen of failover naar de geconfigureerde secundaire regio moet worden geactiveerd.

• Notification: Microsoft geeft u niet automatisch een melding wanneer een regio uitvalt. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Aanvragen tijdens de vlucht naar de naamruimte in de primaire regio kunnen mislukken wanneer de regio offline gaat. Clients moeten bewerkingen opnieuw proberen nadat de failover is voltooid.

• Verwachte gegevensverlies: Metagegevens blijven behouden. Er wordt niet automatisch een back-up van registratiegegevens gemaakt, maar u kunt er zelf een back-up van maken. Zie Azure Notification Hubs-registraties bulksgewijs exporteren en importeren voor meer informatie. Als u dat niet doet, zijn registratiegegevens pas beschikbaar als de primaire regio wordt hersteld.

• Verwachte downtime: Het duurt even voordat Microsoft failover van metagegevens activeert en vervolgens de failover is voltooid. Hoewel de tijd kan variëren, duurt het over het algemeen enkele uren.

  Nadat de failover is voltooid, bent u verantwoordelijk voor het herstellen van back-ups van registratiegegevens.

• Herdistributie: Na een failover worden aanvragen doorgestuurd naar een naamruimte in de secundaire regio die gebruikmaakt van de gerepliceerde gegevens uit de primaire regio. Nadat de failover is voltooid, maken clients automatisch verbinding met de naamruimte in de secundaire regio.

Herstel van de regio

Als de primaire regio wordt hersteld, is het mogelijk om een failback uit te voeren naar de primaire naamruimte in de primaire regio. De primaire naamruimte behoudt de registratiegegevens van vóór de storing. Dit zou een handmatig proces zijn en Microsoft zou met u communiceren om uit te leggen hoe dit werkt.

Nadat de primaire regio is hersteld, moet u het volgende doen:

• Valideer de status van uw naamruimte en de bijbehorende gegevens.
• Bepaal of recente wijzigingen in de registratiegegevens van de secundaire regio naar de primaire regio moeten worden gesynchroniseerd.

Test voor regiofouten

U kunt geen geo-failover starten. U moet echter uw eigen procedures voor herstel na noodgevallen testen. Controleer of er een back-up van registraties wordt gemaakt en of u deze kunt herstellen naar een nieuwe naamruimte.

Aangepaste multiregionale oplossingen voor veerkracht

Door Microsoft beheerd geo-noodherstel repliceert alleen metagegevens. De functie kan die metagegevens herstellen naar een secundaire naamruimte, maar u bent verantwoordelijk voor het importeren van apparaatregistraties in die naamruimte, zodat uw toepassing kan blijven werken. Deze aanpak vereist handmatige interventie tijdens een noodgeval en omvat downtime.

Als uw hersteldoelstellingen minder uitvaltijd of handmatige interventie vereisen, kunt u een aangepaste actief-actief-multiregio-oplossing implementeren. Implementeer een tweede Notification Hubs-naamruimte naar een andere Azure regio van tevoren.

• Failover: Omdat de tweede naamruimte een werkende resource is, kunt u logica implementeren om een regiofout te detecteren en over te schakelen naar die naamruimte.

• Synchronisatie: Als u een tweede Notification Hub synchroon wilt houden met de primaire Notification Hub, gebruikt u een van de volgende opties:

  • Voor installaties: Gebruik een app-back-end die tegelijkertijd installaties maakt en bijwerken in beide Notification Hubs. Met installaties kunt u uw eigen unieke apparaat-id opgeven, die dit replicatiescenario ondersteunt. Zie het RedundantHub-voorbeeld voor meer informatie.

  • Voor registraties: Gebruik een app-back-end die regelmatig registraties van de primaire Notification Hub exporteert als back-up en deze bulksgewijs importeert in de secundaire Notification Hub. Zie Azure Notification Hubs-registraties bulksgewijs exporteren en importeren voor meer informatie.

  Als u geen back-end hebt, kunt u uw app ook configureren om installaties in beide hubs te maken wanneer de app op doelapparaten wordt gestart. De apparaten maken nieuwe registraties in beide Notification Hubs. Uiteindelijk heeft de secundaire Notification Hub alle actieve apparaten geregistreerd.

• Verlopen registraties en installaties: De secundaire Notification Hub heeft mogelijk verlopen registraties en installaties. Wanneer een pushmelding naar een verlopen handle wordt verzonden, verwijdert Notification Hubs automatisch de bijbehorende registratie- of installatierecord in de notification hub op basis van het antwoord dat van de PNS-server is ontvangen. U kunt verlopen records opschonen uit de back-upoplossing van uw keuze door aangepaste logica toe te voegen die feedback verwerkt van elke verzend- en verwijder verlopen registraties en installaties.

• Niet-geopende apps: Er is een periode waarin apparaten met niet-geopende apps geen meldingen ontvangen.

• Kosten: Als u uw eigen secundaire hub gebruikt om registratiegegevens te beveiligen, worden voor die hub normale servicekosten in rekening gebracht. Als u ook andere Azure resources implementeert in uw secundaire regio ter ondersteuning van uw herstel, betaalt u voor die met normale servicetarieven.

Back-up maken en terugzetten

Notification Hubs biedt geen enkele ingebouwde back-up- en herstelfunctie voor alle gegevens die zijn opgeslagen in uw naamruimte. U bent verantwoordelijk voor het combineren van de volgende benaderingen:

• Gebruik infrastructuur als code (IaC), zoals Bicep, om uw naamruimte, hub en beleidsconfiguratie te definiëren. Sla deze definities op in broncodebeheer, zodat u de resources indien nodig opnieuw kunt implementeren.
• Maak een back-up van uw apparaatregistratiegegevens door Azure Notification Hubs registraties bulksgewijs te exporteren.

Tolerantie voor serviceonderhoud

Microsoft past regelmatig service-updates toe en voert ander onderhoud uit. Het Azure platform verwerkt deze activiteiten automatisch en zorgt ervoor dat onderhoud naadloos en transparant voor u is. Er wordt geen downtime verwacht tijdens onderhoudsgebeurtenissen, tenzij u op de hoogte bent gesteld via Azure Service Health gepland onderhoud.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Voor Notification Hubs is de SLA voor beschikbaarheid van toepassing op naamruimten die gebruikmaken van de Basic- en Standard-lagen.

Verwante onderwerpen

• Betrouwbaarheid in Azure