Herstel in regio's met behulp van beschikbaarheidszones en herstel na noodgevallen tussen regio's (Azure Event Grid)

In dit artikel wordt beschreven hoe Azure Event Grid ondersteuning biedt voor automatisch herstel in de regio van uw Event Grid-resourcedefinities en -gegevens wanneer er een fout optreedt in een regio met beschikbaarheidszones. Ook wordt beschreven hoe Event Grid ondersteuning biedt voor automatisch herstel van Event Grid-resourcedefinities (geen gegevens) naar een andere regio wanneer er een fout optreedt in een regio met een gekoppelde regio.

Herstel in regio's met behulp van beschikbaarheidszones

Azure-beschikbaarheidszones zijn fysiek gescheiden locaties binnen elke Azure-regio die tolerant zijn voor lokale fouten. Ze worden verbonden door een netwerk met hoge prestaties met een retourlatentie van minder dan 2 milliseconden. Elke beschikbaarheidszone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. Als één zone wordt beïnvloed, worden regionale services, capaciteit en hoge beschikbaarheid ondersteund door de resterende twee zones. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones. In dit artikel ziet u ook de lijst met regio's met beschikbaarheidszones.

Event Grid-resourcedefinities voor onderwerpen, systeemonderwerpen, domeinen en gebeurtenisabonnementen en gebeurtenisgegevens worden automatisch gerepliceerd in drie beschikbaarheidszones (indien beschikbaar) in de regio. Wanneer er een fout opgetreden is in een van de beschikbaarheidszones, failover van Event Grid-resources naar een andere beschikbaarheidszone zonder menselijke tussenkomst. Op dit moment is het niet mogelijk om deze functie te beheren (in- of uitschakelen). Wanneer een bestaande regio beschikbaarheidszones gaat ondersteunen, wordt er automatisch een failover uitgevoerd voor bestaande Event Grid-resources om te profiteren van deze functie. De gebruiker hoeft verder niets te doen.

Herstel na noodgevallen tussen regio's

Wanneer een Azure-regio een langdurige storing ondervindt, bent u mogelijk geïnteresseerd in failoveropties voor een alternatieve regio voor bedrijfscontinuïteit. Veel Azure-regio's hebben geografische paren en sommige niet. Zie Replicatiekoppelingen tussen Azure-regio's voor alle geografische gebieden voor een lijst met regio's met gekoppelde regio's.

Voor regio's met een geopaar biedt Event Grid een mogelijkheid om een failover van het publicatieverkeer naar de gekoppelde regio uit te geven voor aangepaste onderwerpen, systeemonderwerpen en domeinen. Achter de schermen synchroniseert Event Grid automatisch resourcedefinities van onderwerpen, systeemonderwerpen, domeinen en gebeurtenisabonnementen naar de gekoppelde regio. Gebeurtenisgegevens worden echter niet gerepliceerd naar de gekoppelde regio. In de normale status worden gebeurtenissen opgeslagen in de regio die u voor die resource hebt geselecteerd. Wanneer er een regiostoring is en Microsoft de failover initieert, beginnen nieuwe gebeurtenissen naar de geografisch gekoppelde regio te stromen en worden ze vanaf daar verzonden zonder tussenkomst van u. Gebeurtenissen die zijn gepubliceerd en geaccepteerd in de oorspronkelijke regio, worden daar verzonden nadat de storing is verzacht.

Door Microsoft geïnitieerde failover wordt in zeldzame gevallen uitgevoerd door Microsoft om een failover uit te voeren van Event Grid-resources van een betrokken regio naar de bijbehorende geografisch gekoppelde regio. Microsoft behoudt zich het recht voor om te bepalen wanneer deze optie wordt uitgeoefend. Dit mechanisme omvat geen gebruikerstoestemming voordat het verkeer van de gebruiker wordt overgeschakeld.

U kunt deze functionaliteit in- of uitschakelen door de configuratie voor uw onderwerp of domein bij te werken. Selecteer de optie Cross-Geo (standaard) om door Microsoft geïnitieerde failover en Regionaal in te schakelen. Zie Gegevenslocatie configureren voor gedetailleerde stappen voor het configureren van deze instelling. Als u voor een regio kiest, worden er geen gegevens van welke aard dan ook gerepliceerd naar een andere regio door Microsoft en kunt u uw eigen plan voor herstel na noodgevallen definiëren. Zie Uw eigen plan voor herstel na noodgevallen bouwen voor Azure Event Grid-onderwerpen en -domeinen voor meer informatie.

Hier volgen enkele redenen waarom u de door Microsoft geïnitieerde failoverfunctie wilt uitschakelen:

• Door Microsoft geïnitieerde failover wordt op basis van best effort uitgevoerd.
• Sommige geoparen voldoen niet aan de gegevenslocatievereisten van uw organisatie.

In dergelijke gevallen is de aanbevolen optie om uw eigen plan voor herstel na noodgevallen te maken voor Azure Event Grid-onderwerpen en -domeinen. Hoewel voor deze optie iets meer inspanning is vereist, kunt u sneller failover uitvoeren en hebt u de controle over het kiezen van secundaire regio's. Als u herstel na noodgevallen aan de clientzijde wilt implementeren voor Azure Event Grid-onderwerpen, raadpleegt u Uw eigen herstel na noodgevallen aan de clientzijde bouwen voor Azure Event Grid-onderwerpen.

Beoogde hersteltijd en beoogd herstelpunt

Herstel na noodgevallen wordt gemeten met twee metrische gegevens:

• Recovery Point Objective (RPO): de minuten of uren aan gegevens die verloren kunnen gaan.
• RTO (Recovery Time Objective): de minuten of uren waarop de service mogelijk niet beschikbaar is.

De automatische failover van Event Grid heeft verschillende RPO's en RTO's voor uw metagegevens (onderwerpen, domeinen, gebeurtenisabonnementen) en gegevens (gebeurtenissen). Als u een andere specificatie nodig hebt dan de volgende, kunt u nog steeds uw eigen failover aan de clientzijde implementeren met behulp van de onderwerpstatus-API's.

Recovery Point Objective (RPO)

• RPO voor metagegevens: nul minuten. Wanneer een resource wordt gemaakt/bijgewerkt/verwijderd, wordt de resourcedefinitie synchroon gerepliceerd naar het geo-paar wanneer een resource wordt gemaakt/bijgewerkt/verwijderd. Wanneer een failover optreedt, gaan er geen metagegevens verloren.

• Gegevens-RPO: wanneer er een failover plaatsvindt, worden nieuwe gegevens verwerkt vanuit de gekoppelde regio. Zodra de storing voor de getroffen regio wordt beperkt, worden de niet-verwerkte gebeurtenissen daar verzonden. Als het herstel van de regio langere tijd vereist dan de time-to-live-waarde die is ingesteld op gebeurtenissen, kunnen de gegevens worden verwijderd. Als u dit gegevensverlies wilt beperken, raden we u aan een dode letter voor een gebeurtenisabonnement in te stellen. Als de getroffen regio verloren gaat en niet kan worden hersteld, gaan er gegevens verloren. In het beste geval blijft de abonnee de publicatiesnelheid bij en gaat er slechts een paar seconden aan gegevens verloren. Het ergste scenario zou zijn wanneer de abonnee niet actief gebeurtenissen verwerkt en met een maximale duur van 24 uur, kan het gegevensverlies maximaal 24 uur duren.

Beoogde hersteltijd (RTO)

• RTO voor metagegevens: het nemen van failover-beslissingen is gebaseerd op factoren zoals beschikbare capaciteit in gekoppelde regio's en kan in het bereik van 60 minuten of langer duren. Zodra de failover is gestart, begint Event Grid binnen vijf minuten aanroepen voor het maken/bijwerken/verwijderen van onderwerpen en abonnementen te accepteren.

• Gegevens-RTO: Hetzelfde als de bovenstaande informatie.

Belangrijk

• In het geval van herstel na noodgevallen aan de serverzijde, als de gekoppelde regio geen extra capaciteit heeft om het extra verkeer op te nemen, kan Event Grid failover niet initiëren. Het herstel wordt op basis van best effort uitgevoerd.
• Er worden geen kosten in rekening gebracht voor het gebruik van deze functie.
• Herstel na geo-noodgeval wordt niet ondersteund voor partnernaamruimten en partneronderwerpen.

Volgende stappen

Zie Uw eigen herstel na noodgevallen aan de clientzijde bouwen voor Azure Event Grid-onderwerpen.