Betrouwbaarheid in Azure Notification Hubs

In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Notification Hubs beschreven en wordt zowel regionale tolerantie behandeld als beschikbaarheidszones en herstel na noodgevallen en bedrijfscontinuïteit

Ondersteuning voor beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.

In een regio die beschikbaarheidszones ondersteunt, ondersteunt Notification Hubs standaard een zone-redundante implementatie. Wanneer u implementeert met beschikbaarheidszones, worden zowel registratiegegevens als metagegevens gerepliceerd in alle zones in de opgegeven regio.

Vereisten

• Azure Notification Hubs maakt gebruik van beschikbaarheidszones in regio's waar ze beschikbaar zijn. Zie Beschikbaarheidszoneservice en regionale ondersteuning voor een lijst met regio's die beschikbaarheidszones ondersteunen.

• Beschikbaarheidszones worden standaard alleen ondersteund in specifieke lagen. Zie [Prijzen voor Notification Hubs](https://azure.microsoft.com/pricing/details/notification-hubs voor meer informatie over welke lagen ondersteuning bieden voor implementaties van beschikbaarheidszones.

SLA-verbeteringen

Voor beschikbaarheidszones worden extra kosten in rekening gebracht boven op bestaande prijscategorieën. Zie de SLA voor Notification Hubs voor meer informatie over onze SLA.

Zone-down-ervaring

Tijdens een zonebrede storing is er geen actie vereist tijdens zoneherstel. Notification Hubs herstelt zichzelf en balanceert zichzelf opnieuw om automatisch te profiteren van de gezonde zone.

Beschikbaarheidszones inschakelen

U kunt alleen beschikbaarheidszones inschakelen voor nieuwe naamruimten. Omdat Notification Hubs geen ondersteuning biedt voor de migratie van bestaande naamruimten, kunt u zoneredundantie niet uitschakelen nadat u deze hebt ingeschakeld op uw naamruimte.

Zie Een Azure Notification Hub maken in Azure Portal voor meer informatie over het instellen van een nieuwe naamruimte met beschikbaarheidszones.

Migreren naar ondersteuning voor beschikbaarheidszones

Als u wilt weten hoe u een bestaande Notification Hubs-resource verplaatst naar een nieuwe regio met ondersteuning voor beschikbaarheidszones, volgt u de richtlijnen in Resources verplaatsen tussen Azure-regio's.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

Notification Hubs biedt dekking voor herstel na noodgevallen van metagegevens via regio's voor replicatie van metagegevens, zoals de naam van Notification Hubs, de verbindingsreeks en andere kritieke informatie.

U kunt de gekoppelde Azure-regio gebruiken of kiezen uit een lijst met regio's die flexibele herstelregio ondersteunen.

Wanneer een scenario voor herstel na noodgevallen wordt geactiveerd, zijn registratiegegevens het enige segment van de Notification Hubs-infrastructuur die verloren gaat. Zie de sectie Back-upregistratiegegevens voor opties voor het behouden van de registratiegegevens voor uw naamruimte en hoe u deze kunt herstellen.

Flexibele herstelregio

Flexibele herstelregio is een eenvoudige oplossing waarmee u een secundaire naamruimte kunt configureren als een failoverdoel voor uw primaire naamruimte. U kunt kiezen uit de lijst met ondersteunde regio's. In het geval van regio's met beschikbaarheidszones, maar geen gekoppelde regio, kunt u flexibel herstel gebruiken om een secundaire regio te selecteren. Wanneer de failover wordt geactiveerd, wordt de secundaire naamruimte de actieve naamruimte en wordt de primaire naamruimte de passieve naamruimte. Alle aanvragen en berichten die naar de primaire naamruimte worden verzonden, worden omgeleid naar de secundaire naamruimte en de pushmeldingen worden bezorgd vanuit de secundaire naamruimte.

De volgende regio's ondersteunen Flexibele herstelregio:

• VS - west 2
• Europa - noord
• Australië - oost
• Brazilië - zuid
• Azië - zuidoost
• Zuid-Afrika - noord

Een back-up maken van registratiegegevens

Gekoppelde en flexibele regioherstel maakt alleen een back-up van metagegevens. U moet een oplossing implementeren om de registratiegegevens opnieuw in te vullen in uw hub na herstel.

Azure Notification Hubs ondersteunt twee typen apparaatregistraties: installaties en registraties. U wordt aangeraden een back-up te maken van uw registraties naar:

• Een opslagoplossing van uw keuze: als er een DR-gebeurtenis optreedt, is er enige downtime voor herstelactiviteiten.
• Een andere hub die u in een andere regio maakt: gebruik deze optie om een back-up te maken van uw registraties. Als werkende hub kunt u code implementeren om over te schakelen naar deze kopie. Als u een secundaire Notification Hub synchroon wilt houden met de primaire Notification Hub, kunt u een van de volgende opties gebruiken om een back-up van uw registraties te maken:
  • 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, zodat deze beter geschikt is voor het replicatiescenario. Zie deze voorbeeldcode voor meer informatie.
  • Voor registraties: Gebruik een app-back-end die een reguliere dump van registraties van de primaire Notification Hub als back-up ontvangt. Vervolgens kan er een bulksgewijze invoeging worden uitgevoerd in de secundaire Notification Hub. Zie Azure Notification Hubs-registraties bulksgewijs exporteren en importeren.

De secundaire Notification Hub heeft mogelijk verlopen registraties. Wanneer de push naar een verlopen ingang wordt uitgevoerd, schoont Notification Hubs automatisch de bijbehorende registratierecord op de primaire Notification Hub op op basis van het antwoord dat is ontvangen van de PNS-server. U kunt verlopen records opschonen uit de back-upoplossing van uw keuze door aangepaste logica toe te voegen die feedback van elke verzendfunctie verwerkt en verlopen registraties verwijdert.

Als u geen back-end hebt en de app wordt gestart op doelapparaten, voeren de apparaten een nieuwe registratie uit in de secundaire Notification Hub. Uiteindelijk heeft de secundaire Notification Hub alle actieve apparaten geregistreerd.

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

Herstel na noodgevallen in meerdere regio's inschakelen

Als u herstel na noodgevallen voor een nieuwe naamruimte wilt inschakelen, volgt u de procedure in de Azure Notification Hub maken in Azure Portal.

Herstel na noodgevallen in- of uitschakelen voor een bestaande naamruimte:

1. Meld u aan bij het Azure-portaal.

2. Selecteer in het menu links Alle services.

3. Selecteer Notification Hub-naamruimten in de sectie Internet of Things.

4. Selecteer op de pagina Notification Hub-naamruimten de naamruimte waarvoor u de instellingen voor herstel na noodgevallen wilt wijzigen.

5. Op de pagina Notification Hub-naamruimte voor uw naamruimte ziet u de huidige instelling voor herstel na noodgevallen in de sectie Essentials .

6. In het volgende voorbeeld is een flexibele herstelregio ingeschakeld. Klik op de huidige selectie voor herstel na noodgevallen om het pop-upvenster voor bewerken weer te geven.

   

7. In het pop-upvenster Herstel na noodgevallen bewerken kunt u uw selecties wijzigen. Sla uw wijzigingen op.

   Notitie

   Met een gekoppelde herstelregio wordt de regio weergegeven, maar grijs weergegeven. U kunt de regio niet bewerken.

   

Volgende stappen

• Betrouwbaarheid in Azure