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 ongeveer 1,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 en regio's 3 en 4 hebben geen 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.
Sommige services gebruiken geen beschikbaarheidszones totdat u ze zo configureert. Als u een service niet expliciet configureert voor ondersteuning voor beschikbaarheidszones, wordt deze een niet-zonegebonden of regionale implementatie genoemd. Resources die op deze manier zijn geconfigureerd, kunnen worden geplaatst in een beschikbaarheidszone in de regio en kunnen worden verplaatst. Als een beschikbaarheidszone in de regio een storing ondervindt, kunnen niet-zonegebonden resources zich in de getroffen zone bevinden en downtime kunnen ondervinden.
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: een abonnement met de naam 'financiën' kan fysieke zone X hebben toegewezen aan logische zone 1, terwijl een ander abonnement met de naam 'engineering' 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[?availabilityZoneMappings != `null`].{displayName: displayName, name: name, availabilityZoneMappings: availabilityZoneMappings}'
Beschikbaarheidszones en Azure-updates
Voor elke regio wil Microsoft updates implementeren voor Azure-services binnen één beschikbaarheidszone tegelijk. 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.
Richtlijnen voor architectuur voor beschikbaarheidszones
Om betrouwbaardere workloads te bereiken:
- Productieworkloads moeten worden geconfigureerd voor het gebruik van meerdere 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.