Wat zijn beschikbaarheidszones?
Veel Azure-regio's bieden beschikbaarheidszones, die gescheiden groepen datacenters binnen een regio zijn. Beschikbaarheidszones zijn dicht genoeg om verbindingen met lage latentie met andere beschikbaarheidszones te hebben. Ze worden verbonden door een netwerk met hoge prestaties met een retourlatentie van minder dan 2 ms. Beschikbaarheidszones zijn echter ver genoeg uit 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. Ze helpen uw gegevens gesynchroniseerd en toegankelijk te blijven wanneer er iets misgaat.
Datacenterlocaties worden geselecteerd met behulp van strenge criteria voor risicobeoordeling van beveiligingsproblemen. Dit proces identificeert alle belangrijke datacenterspecifieke risico's en houdt rekening met gedeelde risico's tussen beschikbaarheidszones.
In het volgende diagram ziet u verschillende azure-voorbeeldregio's. Regio's 1 en 2 ondersteunen beschikbaarheidszones.
Zie Azure-regio's met ondersteuning voor beschikbaarheidszones om te zien welke regio's beschikbaarheidszones ondersteunen.
Zonegebonden en zone-redundante services
Wanneer u implementeert in een Azure-regio die beschikbaarheidszones bevat, kunt u meerdere beschikbaarheidszones samen gebruiken. Door meerdere beschikbaarheidszones te gebruiken, kunt u afzonderlijke kopieën van uw toepassing en gegevens bewaren in afzonderlijke fysieke datacenters in een groot grootstedelijk gebied.
Er zijn twee manieren waarop Azure-services beschikbaarheidszones gebruiken:
Zonegebonden resources worden vastgemaakt aan een specifieke beschikbaarheidszone. U kunt meerdere zonegebonden implementaties in verschillende zones combineren om te voldoen aan hoge betrouwbaarheidsvereisten. U bent verantwoordelijk voor het beheren van gegevensreplicatie en het distribueren van aanvragen tussen zones. Als er een storing optreedt in één beschikbaarheidszone, bent u verantwoordelijk voor failover naar een andere beschikbaarheidszone.
Zone-redundante resources zijn verspreid over meerdere beschikbaarheidszones. Microsoft beheert het verspreiden van aanvragen tussen zones en de replicatie van gegevens in zones. Als er een storing optreedt in één beschikbaarheidszone, beheert Microsoft failover automatisch.
Azure-services ondersteunen een of beide van deze methoden. PaaS-services (Platform as a Service) ondersteunen doorgaans zone-redundante implementaties. IaaS-services (Infrastructure as a Service) ondersteunen doorgaans zonegebonden implementaties. Zie Azure-regio's met ondersteuning voor beschikbaarheidszones voor meer informatie over hoe Azure-services werken met beschikbaarheidszones.
Zie het overzicht van betrouwbaarheidsrichtlijnen voor meer informatie over servicespecifieke betrouwbaarheidsondersteuning met behulp van beschikbaarheidszones en aanbevolen richtlijnen voor herstel na noodgevallen.
Fysieke en logische beschikbaarheidszones
Elk datacenter wordt toegewezen aan een fysieke zone. Fysieke zones worden toegewezen aan logische zones in uw Azure-abonnement en verschillende abonnementen hebben mogelijk een andere toewijzingsvolgorde. Azure-abonnementen worden automatisch toegewezen aan hun toewijzing op het moment dat het abonnement wordt gemaakt. Daarom kan de zonetoewijzing voor één abonnement anders zijn voor andere abonnementen. Bijvoorbeeld: Abonnement A kan fysieke zone X hebben toegewezen aan logische zone 1, terwijl abonnement B in plaats daarvan fysieke zone X heeft toegewezen aan logische zone 3.
Gebruik de Azure Resource Manager-API voor lijstlocaties om inzicht te hebben in de toewijzing tussen logische en fysieke zones voor uw abonnement. U kunt de Azure CLI of Azure PowerShell gebruiken om de informatie op te halen uit de API.
az rest --method get --uri '/subscriptions/{subscriptionId}/locations?api-version=2022-12-01' --query 'value'
Beschikbaarheidszones en Azure-updates
Microsoft streeft ernaar om updates voor Azure-services in één beschikbaarheidszone tegelijk te implementeren. Deze aanpak vermindert de impact die updates mogelijk hebben op een actieve workload, omdat de werkbelasting in andere zones kan blijven worden uitgevoerd terwijl de update wordt uitgevoerd. U moet uw workload uitvoeren in meerdere zones om te profiteren van dit voordeel. Zie Geavanceerde veilige implementatieprocedures voor meer informatie over hoe Azure updates implementeert.
Gekoppelde en niet-gekoppelde regio's
Veel regio's hebben ook een gekoppelde regio. Gekoppelde regio's ondersteunen bepaalde typen implementatiemethoden voor meerdere regio's. Sommige nieuwere regio's hebben meerdere beschikbaarheidszones en hebben geen gekoppelde regio. U kunt nog steeds oplossingen voor meerdere regio's implementeren in deze regio's, maar de benaderingen die u gebruikt, kunnen afwijken.
Model van gedeelde verantwoordelijkheid
In het model voor gedeelde verantwoordelijkheid wordt beschreven hoe verantwoordelijkheden worden verdeeld tussen de cloudprovider (Microsoft) en u. Afhankelijk van het type services dat u gebruikt, neemt u mogelijk meer of minder verantwoordelijkheid voor het uitvoeren van de service.
Microsoft biedt beschikbaarheidszones en regio's om u flexibiliteit te bieden bij het ontwerpen van uw oplossing om te voldoen aan uw vereisten. Wanneer u beheerde services gebruikt, neemt Microsoft meer beheerverantwoordelijkheden voor uw resources over, waaronder mogelijk zelfs gegevensreplicatie, failover, failback en andere taken met betrekking tot het besturingssysteem.
Richtlijnen voor architectuur voor beschikbaarheidszones
Om betrouwbaardere workloads te bereiken:
- Productieworkloads moeten worden geconfigureerd voor het gebruik van beschikbaarheidszones als de regio waarin ze zich bevinden, beschikbaarheidszones ondersteunt.
- Voor bedrijfskritieke workloads moet u een oplossing overwegen die zowel uit meerdere regio's als uit meerdere zones bestaat.