Replicatie tussen regio's in Azure: Bedrijfscontinuïteit en herstel na noodherstel

Veel organisaties vereisen zowel hoge beschikbaarheid als beschikbaarheidszones die ook worden ondersteund met bescherming tegen grootschalige verschijnselen en regionale rampen. Zoals besproken in het overzicht van tolerantie voor regio's en beschikbaarheidszones, zijn Azure-regio's ontworpen om bescherming te bieden tegen lokale rampen met beschikbaarheidszones. Maar ze kunnen ook bescherming bieden tegen regionale of grote geografierampen na noodherstel door gebruik te maken van een andere regio die gebruikmaakt van replicatie tussen regio's.

Replicatie in meerdere regio's

Om ervoor te zorgen dat klanten over de hele wereld worden ondersteund, onderhoudt Azure meerdere geografische gebieden. Deze afzonderlijke afbakeningen definiëren een grens voor herstel na noodherstel en gegevenslocatie in een of meer Azure-regio's.

Replicatie tussen regio's is een van de belangrijke pijlers in de strategie voor bedrijfscontinuïteit en herstel na noodherstel van Azure. Replicatie tussen regio's is gebaseerd op de synchrone replicatie van uw toepassingen en gegevens die bestaan door gebruik te maken van beschikbaarheidszones binnen uw primaire Azure-regio voor hoge beschikbaarheid. Replicatie tussen regio's repliceert asynchroon dezelfde toepassingen en gegevens in andere Azure-regio's voor bescherming tegen noodherstel.

Sommige Azure-services profiteren van replicatie tussen regio's om bedrijfscontinuïteit te garanderen en bescherming te bieden tegen gegevensverlies. Azure biedt verschillende opslagoplossingen die gebruikmaken van replicatie tussen regio's om de beschikbaarheid van gegevens te garanderen. Met geografisch redundante opslag (GRS) van Azure worden gegevens bijvoorbeeld automatisch gerepliceerd naar een secundaire regio. Deze aanpak zorgt ervoor dat gegevens duurzaam zijn, zelfs als de primaire regio niet kan worden hersteld.

Niet alle Azure-services repliceren automatisch gegevens of vallen automatisch terug van een mislukte regio om kruisgepliceerd naar een andere ingeschakelde regio te repliceren. In deze scenario's moeten herstel en replicatie worden geconfigureerd door de klant. Deze voorbeelden zijn illustraties van het model voor gedeelde verantwoordelijkheid. Het is een fundamentele pijler in uw strategie voor herstel na noodherstel. Zie Bedrijfscontinuïteitsbeheer in Azure voor meer informatie over het model voor gedeelde verantwoordelijkheid en voor meer informatie over bedrijfscontinuïteit en herstel na noodherstel in Azure.

Gedeelde verantwoordelijkheid wordt de kern van uw strategische besluitvorming als het gaat om herstel na noodherstel. Voor Azure hoeft u geen replicatie tussen regio's te gebruiken en u kunt services gebruiken om tolerantie te bouwen zonder kruislings repliceren naar een andere ingeschakelde regio. Maar we raden u ten zeerste aan om uw essentiële services tussen regio's te configureren om te profiteren van isolatie en beschikbaarheid te verbeteren.

Voor toepassingen die ondersteuning bieden voor meerdere actieve regio's, raden we u aan om beschikbare meerdere ingeschakelde regio's te gebruiken. Deze praktijk zorgt voor optimale beschikbaarheid voor toepassingen en minimale hersteltijd als een gebeurtenis van invloed is op de beschikbaarheid. Ontwerp, indien mogelijk, uw toepassing voor maximale tolerantie en gemak van herstel na noodherstel.

Voordelen van replicatie tussen regio's

Het ontwerpen van cross-regionale replicatie voor uw services en gegevens kan per service worden bepaald. U moet per se een kosten-batenanalysebenadering uitvoeren op basis van de strategische en zakelijke vereisten van uw organisatie. Primaire en belangrijkste voordelen van replicatie in kostenregio's zijn complex, uitgebreid en intensig. Dit zijn enkele voordelen:

• Herstelreeks voor regio's: als er een storing optreedt in de hele geografie, krijgt het herstel van één regio prioriteit van elke ingeschakelde set regio's. Toepassingen die zijn geïmplementeerd in ingeschakelde regiosets hebben gegarandeerd een van de regio's met prioriteit voor herstel. Als een toepassing wordt geïmplementeerd in verschillende regio's, die niet zijn ingeschakeld voor replicatie tussen regio's, kan het herstel worden vertraagd.
• Sequentieel bijwerken: geplande Azure-systeemupdates voor uw ingeschakelde regio's worden chronologische chronologische volgorde uitgevoerd om downtime, impact van fouten en eventuele logische fouten in het zeldzame geval van een mislukte update te minimaliseren.
• Fysieke isolatie: Azure streeft ernaar om een minimale afstand van 483 kilometer (483 kilometer) tussen datacenters in ingeschakelde regio's te garanderen, hoewel dit niet in alle geografische gebieden mogelijk is. Datacenterscheiding vermindert de kans dat natuurrampen, rampen, stroomuitval of fysieke netwerkuitval van invloed kunnen zijn op meerdere regio's. Isolatie is onderhevig aan de beperkingen binnen een geografie, zoals de grootte van de geografie, de beschikbaarheid van de stroom- of netwerkinfrastructuur en regelgeving.
• Gegevensstatus: regio's bevinden zich binnen dezelfde geografie als hun ingeschakelde set (met uitzondering van Brazilië - zuid en Singapore) om te voldoen aan de vereisten voor gegevenssleedheid voor belasting- en afdwingingsdoeleinden in de jurisdictie.

Azure-replicatieparen tussen regio's voor alle geografische gebieden

Regio's worden gekoppeld voor replicatie tussen regio's op basis van nabijheid en andere factoren.

Azure-regioparen

() * Bepaalde regio's hebben alleen toegang ter ondersteuning van specifieke klantscenario's, zoals herstel na noodherstel in het land. Deze regio's zijn alleen beschikbaar op aanvraag door een nieuwe ondersteuningsaanvraag te maken in de Azure Portal.

Volgende stappen

• Regio's weergeven die beschikbaarheidszones in Azure ondersteunen
• Snelstartsjablonen