Replicatie tussen regio's in Azure: bedrijfscontinuïteit en herstel na noodgevallen
Veel organisaties vereisen zowel hoge beschikbaarheid die wordt geleverd door beschikbaarheidszones die ook worden ondersteund met bescherming tegen grootschalige verschijnselen en regionale rampen. Azure-regio's zijn ontworpen om bescherming te bieden tegen lokale rampen met beschikbaarheidszones. Maar ze kunnen ook bescherming bieden tegen regionale of grote geografische rampen met herstel na noodgevallen 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 noodgevallen 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 noodgevallen in Azure. Replicatie tussen regio's bouwt voort op de synchrone replicatie van uw toepassingen en gegevens die bestaan met behulp van beschikbaarheidszones binnen uw primaire Azure-regio voor hoge beschikbaarheid. Replicatie tussen regio's repliceert dezelfde toepassingen en gegevens asynchroon in andere Azure-regio's voor bescherming tegen herstel na noodgevallen.
Sommige Azure-services profiteren van replicatie tussen regio's om bedrijfscontinuïteit te garanderen en te beschermen tegen gegevensverlies. Azure biedt verschillende opslagoplossingen die gebruikmaken van replicatie tussen regio's om de beschikbaarheid van gegevens te garanderen. Azure GEOGRAFISCH redundante opslag (GRS) repliceert bijvoorbeeld gegevens automatisch 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 kruislings te repliceren naar een andere ingeschakelde regio. 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 noodgevallen. Zie Bedrijfscontinuïteitsbeheer in Azure voor meer informatie over het model voor gedeelde verantwoordelijkheid en voor meer informatie over bedrijfscontinuïteit en herstel na noodgevallen in Azure.
Gedeelde verantwoordelijkheid wordt de kern van uw strategische besluitvorming als het gaat om herstel na noodgevallen. Voor Azure hoeft u geen replicatie tussen regio's te gebruiken en u kunt services gebruiken om tolerantie op te bouwen zonder kruislings te repliceren naar een andere ingeschakelde regio. Maar we raden u ten zeerste aan uw essentiële services in verschillende regio's te configureren om te profiteren van isolatie en om de beschikbaarheid te verbeteren.
Voor toepassingen die ondersteuning bieden voor meerdere actieve regio's, raden we u aan om beschikbare regio's met meerdere ingeschakelde regio's te gebruiken. Deze procedure zorgt voor optimale beschikbaarheid voor toepassingen en minimale hersteltijd als een gebeurtenis van invloed is op de beschikbaarheid. Ontwerp waar mogelijk uw toepassing voor maximale tolerantie en het gemak van herstel na noodgevallen.
Voordelen van replicatie tussen regio's
Het ontwerpen van replicatie tussen regio's voor uw services en gegevens kan per service worden bepaald. U zult noodzakelijkerwijs een kosten-batenanalysebenadering gebruiken op basis van de strategische en zakelijke vereisten van uw organisatie. Primaire en rimpelende voordelen van replicatie tussen regio's zijn complex, uitgebreid en verdienen uitwerking. Dit zijn enkele voordelen:
- Regioherstelvolgorde: als er een geografische uitval optreedt, krijgt herstel van één regio prioriteit buiten elke ingeschakelde set regio's. Toepassingen die zijn geïmplementeerd in ingeschakelde regiosets, hebben gegarandeerd een van de regio's die prioriteit hebben 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.
- Sequentiële updates: geplande Azure-systeemupdates voor uw ingeschakelde regio's worden chronologisch gespreid om downtime, impact van fouten en logische fouten te minimaliseren in het zeldzame geval van een defecte update.
- Fysieke isolatie: Azure streeft naar een minimale afstand van 483 kilometer (300 mijl) tussen datacenters in ingeschakelde regio's, hoewel dit niet mogelijk is in alle geografische gebieden. Scheiding van datacenters vermindert de kans dat natuurrampen, burgerlijke onrust, stroomuitval of fysieke netwerkstoringen meerdere regio's kunnen beïnvloeden. Isolatie is onderhevig aan de beperkingen binnen een geografie, zoals de grootte van de geografie, de beschikbaarheid van de energie- of netwerkinfrastructuur en de regelgeving.
- Gegevenslocatie: regio's bevinden zich in dezelfde geografie als hun ingeschakelde set (met uitzondering van Brazilië - zuid en Singapore) om te voldoen aan vereisten voor gegevenslocatie voor belasting- en wetshandhavingsbevoegdheidsdoeleinden.
Hoewel het niet mogelijk is om uw eigen regionale koppeling te maken, kunt u toch uw eigen noodhersteloplossing maken door uw services in een willekeurig aantal regio's te bouwen en vervolgens Azure-services te gebruiken om ze te koppelen. U kunt bijvoorbeeld Azure-services zoals AzCopy gebruiken om back-ups van gegevens te plannen naar een Azure Storage-account in een andere regio. Met Behulp van Azure DNS en Azure Traffic Manager kunt u een tolerante architectuur ontwerpen voor uw toepassingen die het verlies van de primaire regio overleven.
Azure beheert de prioriteitstelling van gepland onderhoud en herstel voor regionale paren. Sommige Azure-services zijn standaard afhankelijk van regionale paren, zoals Azure redundante opslag.
U bent niet beperkt tot het gebruik van services binnen uw regioparen. Hoewel een Azure-service afhankelijk kan zijn van een specifiek regionaal paar, kunt u uw andere services hosten in elke regio die voldoet aan de behoeften van uw bedrijf. Een Azure GRS-opslagoplossing kan bijvoorbeeld gegevens in Canada - centraal koppelen met een peer in Canada - oost tijdens het gebruik van Azure Compute-resources in VS - oost.
Azure-replicatiekoppelingen tussen regio's voor alle geografische gebieden
Regio's worden gekoppeld voor replicatie tussen regio's op basis van nabijheid en andere factoren.
Belangrijk
Neem contact op met de verkoop- of klantvertegenwoordiger van Microsoft voor meer informatie over de architectuur van uw regio.
Regionale Azure-paren
| Geografie | Regionaal paar A | Regionaal paar B |
|---|---|---|
| Asia-Pacific | Azië - oost (Hongkong) | Azië - zuidoost (Singapore) |
| Australië | Australië - oost | Australië - zuidoost |
| Australië | Australië - centraal | Australië - centraal 2* |
| Brazilië | Brazilië - zuid | VS - zuid-centraal |
| Brazilië | Brazilië - zuidoost* | Brazilië - zuid |
| Canada | Canada - midden | Canada - oost |
| China | China - noord | China East |
| China | China - noord 2 | China - oost 2 |
| China | China - noord 3 | China - oost 3* |
| Europa | Europa - noord (Ierland) | Europa - west (Nederland) |
| Frankrijk | Frankrijk - centraal | Frankrijk - zuid* |
| Duitsland | Duitsland - west-centraal | Duitsland - noord* |
| India | India - centraal | India - zuid |
| India | India - west | India - zuid |
| Japan | Japan - oost | Japan - west |
| Korea | Korea - centraal | Korea - zuid* |
| Noord-Amerika | VS - oost | VS - west |
| Noord-Amerika | VS - oost 2 | Central US |
| Noord-Amerika | VS - noord-centraal | VS - zuid-centraal |
| Noord-Amerika | VS - west 2 | VS - west-centraal |
| Noord-Amerika | US - west 3 | VS - oost |
| Noorwegen | Noorwegen - oost | Noorwegen - west* |
| Zuid-Afrika | Zuid-Afrika - noord | Zuid-Afrika - west* |
| Zweden | Zweden - centraal | Zweden - zuid* |
| Zwitserland | Zwitserland - noord | Zwitserland - west* |
| VK | Verenigd Koninkrijk West | Verenigd Koninkrijk Zuid |
| Verenigde Arabische Emiraten | VAE - noord | UAE - centraal* |
| US Department of Defense | US DoD East* | US DoD Central* |
| Amerikaanse overheid | US Gov Arizona* | US Gov Texas* |
| Amerikaanse overheid | US Gov Virginia* | US Gov Texas* |
(*) Bepaalde regio's hebben beperkte toegang ter ondersteuning van specifieke klantscenario's, zoals herstel na noodgevallen in het land/de regio. Deze regio's zijn alleen beschikbaar op aanvraag door een nieuwe ondersteuningsaanvraag te maken.
Belangrijk
- India - west is slechts in één richting gekoppeld. De secundaire regio van India - west is India - zuid, maar de secundaire regio van India voor Zuid-India is India - centraal.
- Brazilië - zuid is uniek omdat het is gekoppeld aan een regio buiten het geografische gebied. De secundaire regio van Brazilië - zuid-centraal is VS - zuid-centraal. De secundaire regio van VS - zuid-centraal is niet Brazilië - zuid.
Regio's met beschikbaarheidszones en geen regiopaar
Azure blijft wereldwijd uitbreiden met Qatar als de eerste regio zonder regiopaar en bereikt hoge beschikbaarheid door gebruik te maken van beschikbaarheidszones en lokaal redundante of zone-redundante opslag (LRS/ZRS). Regio's zonder een paar hebben geen geografisch redundante opslag (GRS). Dergelijke regio's volgen de richtlijnen voor gegevenslocatie die de mogelijkheid bieden om gegevens binnen dezelfde regio te houden. Klanten zijn verantwoordelijk voor gegevenstolerantie op basis van hun behoeften op basis van hun Recovery Point Objective of Recovery Time Objective (RTO/RPO) en kunnen hun gegevens verplaatsen, kopiëren of openen vanaf elke locatie wereldwijd. In het zeldzame geval dat een hele Azure-regio niet beschikbaar is, moeten klanten hun herstel na noodgeval voor meerdere regio's plannen volgens richtlijnen van Azure-services die ondersteuning bieden voor hoge beschikbaarheid en Azure-tolerantie – Bedrijfscontinuïteit en herstel na noodgevallen