Replicatie tussen regio's in Azure
Veel Azure-regio's bieden beschikbaarheidszones, die gescheiden groepen datacenters zijn. Binnen een regio zijn beschikbaarheidszones dicht genoeg om verbindingen met lage latentie met andere beschikbaarheidszones te hebben, maar ze zijn ver genoeg van elkaar om de kans te verkleinen dat meer dan één wordt beïnvloed door lokale storingen of het weer. Beschikbaarheidszones hebben onafhankelijke energie-, koelings- en netwerkinfrastructuur. Ze zijn zodanig ontworpen dat als één zone een storing ondervindt, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende zones.
Hoewel Azure-regio's zijn ontworpen om bescherming te bieden tegen lokale rampen met beschikbaarheidszones, kunnen ze ook bescherming bieden tegen regionale of grote geografische rampen met herstel na noodgevallen door gebruik te maken van een andere secundaire regio die gebruikmaakt van replicatie tussen regio's. Zowel de primaire als de secundaire regio's vormen samen een regiopaar.
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 één of meerdere Azure-regio's.
Replicatie tussen regio's is een van de belangrijkste pijlers in de strategie voor bedrijfscontinuïteit en herstel na noodgevallen van Azure. Replicatie tussen regio's bouwt voort op de synchrone replicatie van uw toepassingen en gegevens die bestaan met behulp van beschikbaarheidszones in uw primaire Azure-regio voor hoge beschikbaarheid. Replicatie tussen regio's replicatie repliceert asynchroon dezelfde toepassingen en gegevens in andere Azure-regio's voor herstel na noodgevallen.
Sommige Azure-services maken gebruik 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. Met azure geografisch redundante opslag (GRS) 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 kruislings te repliceren naar een andere ingeschakelde regio. In deze scenario's moet 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 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. Azure vereist niet dat u replicatie tussen regio's gebruikt en u kunt services gebruiken om tolerantie te bouwen zonder dat u meerdere replicaties naar een andere ingeschakelde regio hoeft te repliceren. Maar we raden u ten zeerste aan om uw essentiële services in verschillende regio's te configureren om te profiteren van isolatie en de beschikbaarheid te verbeteren.
Voor toepassingen die ondersteuning bieden voor meerdere actieve regio's, raden we u aan om meerdere ingeschakelde regio's te gebruiken. Deze procedure zorgt voor optimale beschikbaarheid voor toepassingen en een geminimaliseerde hersteltijd als een gebeurtenis van invloed is op de beschikbaarheid. Ontwerp waar mogelijk uw toepassing voor maximale tolerantie en gemak van herstel na noodgevallen.
Voordelen van replicatie tussen regio's
De architectuur voor serviceoverschrijdende replicatie en gegevens kan per service worden bepaald. U moet een kosten-batenanalysebenadering uitvoeren 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 uitwerken. Dit zijn enkele voordelen:
- Regioherstelvolgorde: Als er een geografiebrede storing optreedt, krijgt herstel van één regio prioriteit uit 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 is ingeschakeld voor replicatie tussen regio's, kan herstel worden vertraagd.
- Sequentiële updates: geplande Azure-systeemupdates voor uw ingeschakelde regio's worden chronologisch gefaseerd om downtime, impact van bugs en eventuele logische fouten in het zeldzame geval van een defecte update te minimaliseren.
- Fysieke isolatie: Azure streeft ernaar om een minimale afstand van 300 mijl (483 kilometer) tussen datacenters in ingeschakelde regio's te garanderen, hoewel het niet mogelijk is in alle geografische gebieden. De scheiding van datacenters vermindert de kans dat natuurrampen, burgerlijke onrust, stroomstoringen of fysieke netwerkstoringen van invloed kunnen zijn op meerdere regio's. Isolatie is onderhevig aan de beperkingen binnen een geografie, zoals geografiegrootte, beschikbaarheid van energie- of netwerkinfrastructuur en voorschriften.
- Gegevenslocatie: 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 gegevenslocatie voor fiscale en rechtshandhavingsbevoegdheidsdoeleinden.
Hoewel het niet mogelijk is om uw eigen regionale koppeling te maken, kunt u toch uw eigen oplossing voor herstel na noodgevallen maken door uw services te bouwen in een aantal regio's 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 flexibele architectuur ontwerpen voor uw toepassingen die het verlies van de primaire regio overleven.
Azure beheert gepland onderhoud en prioriteit voor herstel voor regionale paren. Sommige Azure-services zijn standaard afhankelijk van regionale paren, zoals redundante Azure-opslag.
U bent niet beperkt tot het gebruik van services binnen uw regionale paren. Hoewel een Azure-service kan vertrouwen op een specifiek regionaal paar, kunt u uw andere services hosten in elke regio die aan uw bedrijfsbehoeften voldoet. Een Azure GRS-opslagoplossing kan bijvoorbeeld gegevens in Canada - centraal koppelen aan een peer in Canada - oost terwijl u Azure Compute-resources gebruikt die zich in VS - oost bevinden.
Gekoppelde Azure-regio's
Veel regio's hebben ook een gekoppelde regio ter ondersteuning van replicatie tussen regio's op basis van nabijheid en andere factoren.
Belangrijk
Neem contact op met uw Microsoft-verkoop- of klantvertegenwoordiger voor meer informatie over de architectuur en beschikbare koppelingen van uw regio.
Regionale Azure-paren
| Geografie | Regionaal paar A | Regionaal paar B |
|---|---|---|
| Azië en Stille Oceaan | Azië - oost (Hong Kong Special Beheer istrative Region) | Azië - zuidoost (Singapore) |
| Australië | Australië - oost | Australië - zuidoost |
| Australië - centraal | Australië - centraal 2* | |
| Brazilië | Brazilië - zuid | VS - zuid-centraal |
| Brazilië - zuidoost* | Brazilië - zuid | |
| Canada | Canada - midden | Canada - oost |
| China | China - noord | China - oost |
| China - noord 2 | China - oost 2 | |
| China - noord 3 | China - oost 3* | |
| Europa | Noord-Europa (Ierland) | West-Europa (Nederland) |
| Frankrijk | Frankrijk - centraal | Frankrijk - zuid* |
| Duitsland | Duitsland - west-centraal | Duitsland - noord* |
| India | India - centraal | India - zuid |
| India - centraal | India - west | |
| India - west | India - zuid | |
| Japan | Japan - oost | Japan - west |
| Korea | Korea - centraal | Korea - zuid* |
| Noorwegen | Noorwegen - oost | Noorwegen - west* |
| Zuid-Afrika | Zuid-Afrika - noord | Zuid-Afrika - west* |
| Zweden | Zweden - centraal | Zweden - zuid* |
| Zwitserland | Zwitserland - noord | Zwitserland - west* |
| Verenigd Koninkrijk | Verenigd Koninkrijk West | VK - zuid |
| Verenigde Staten | VS - oost | VS - west |
| VS - oost 2 | Central US | |
| VS - noord-centraal | VS - zuid-centraal | |
| VS - west 2 | VS - west-centraal | |
| US - west 3 | VS - oost | |
| Verenigde Arabische Emiraten | VAE - noord | UAE Central* |
| het Ministerie van Defensie in de VS | US DoD - oost* | US DoD Central* |
| Amerikaanse overheid | US Gov Arizona* | US Gov Texas* |
| US Gov Virginia* | US Gov Texas* |
(*) Bepaalde regio's hebben toegang tot specifieke klantscenario's, zoals herstel na noodgevallen in land/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 India - west is India - zuid, maar de secundaire regio india - zuid is India - centraal.
- VS - west 3 is gekoppeld in één richting met VS - oost. Vs - oost is ook bidirectioneel gekoppeld aan VS - west.
- Brazilië - zuid is uniek omdat het is gekoppeld aan een regio buiten de geografie. De secundaire regio van Brazilië - zuid is VS - zuid-centraal. De secundaire regio vs - zuid-centraal is niet Brazilië - zuid.
Regio's met beschikbaarheidszones en geen regiopaar
Azure blijft wereldwijd uitbreiden in regio's zonder een regionaal paar en bereikt hoge beschikbaarheid door gebruik te maken van beschikbaarheidszones en lokaal redundante of zone-redundante opslag (LRS/ZRS). Regio's zonder paar hebben geen geografisch redundante opslag (GRS). Dergelijke regio's volgen richtlijnen voor gegevenslocatie om ervoor te zorgen dat gegevens in dezelfde regio blijven wonen. Klanten zijn verantwoordelijk voor gegevenstolerantie op basis van hun RTO/RPO-behoeften (Recovery Point Objective of Recovery Time Objective) 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 plannen voor hun herstel na noodgevallen in meerdere regio's per richtlijnen van Azure-services die ondersteuning bieden voor hoge beschikbaarheid en Azure-tolerantie: bedrijfscontinuïteit en herstel na noodgevallen.
De onderstaande tabel bevat Azure-regio's zonder regiopaar:
| Geografie | Region |
|---|---|
| Qatar | Qatar - centraal |
| Polen | Polen - centraal |
| Israël | Israël - centraal |
| Italië | Italië - noord |
| Oostenrijk | Oostenrijk - oost (binnenkort beschikbaar) |
| Spanje | Spanje - centraal (binnenkort beschikbaar) |