Wat zijn beschikbaarheidszones?
Veel Azure-regio's bieden beschikbaarheidszones, die gescheiden groepen datacenters binnen een regio zijn. Elke beschikbaarheidszone heeft een onafhankelijke energie-, koelings- en netwerkinfrastructuur, zodat als één zone een storing ondervindt, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende zones.
Beschikbaarheidszones worden verbonden door een netwerk met hoge prestaties met een retourlatentie van minder dan ongeveer 2 ms. Ze zijn dicht genoeg om verbindingen met lage latentie met andere beschikbaarheidszones te hebben, maar zijn ver genoeg uit elkaar om de mogelijkheid te verminderen dat meer dan één wordt beïnvloed door een gelokaliseerde storing, zoals een stroomstoring of storm.
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.
Typen ondersteuning voor beschikbaarheidszones
Azure-services kunnen twee soorten ondersteuning voor beschikbaarheidszones bieden: zone-redundant en zonegebonden. Elke service ondersteunt mogelijk een of beide typen. Zorg er bij het ontwerpen van uw betrouwbaarheidsstrategie voor dat u begrijpt hoe elke service in uw workload beschikbaarheidszones ondersteunt.
Zone-redundante implementaties: zone-redundante resources worden automatisch gerepliceerd of gedistribueerd over meerdere beschikbaarheidszones. Zone-redundante gegevensservices repliceren bijvoorbeeld de gegevens over meerdere zones, zodat een fout in één zone geen invloed heeft op de beschikbaarheid van de gegevens. Voor sommige services kunt u de set zones selecteren die door uw resource worden gebruikt, terwijl microsoft in andere services de zones selecteert.
Met zone-redundante implementaties beheert Microsoft het spreiden van aanvragen over zones en de replicatie van gegevens tussen zones. Als er een storing optreedt in een beschikbaarheidszone, beheert Microsoft automatisch failover naar een andere zone.
Zonegebonden implementaties: een zonegebonden resource wordt geïmplementeerd in één zelf-geselecteerde beschikbaarheidszone. Deze benadering biedt geen tolerantievoordeel, maar helpt u om strengere latentie- of prestatievereisten te bereiken. Virtuele machines, beheerde schijven en standaard-IP-adressen kunnen bijvoorbeeld zonegebonden worden geïmplementeerd in dezelfde zone.
Als u de tolerantie van zonegebonden resources wilt verbeteren, moet u een architectuur ontwerpen met afzonderlijke resources in meerdere beschikbaarheidszones binnen de regio, maar Microsoft beheert het proces niet voor u. Als er een storing optreedt in een beschikbaarheidszone, bent u verantwoordelijk voor failover naar een andere zone.
Sommige services gebruiken geen beschikbaarheidszones totdat u ze zo configureert. Als u geen service expliciet configureert voor ondersteuning voor beschikbaarheidszones, wordt deze een niet-zone- 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.
Belangrijk
Sommige services hebben mogelijk extra vereisten om te voldoen aan ondersteuning voor beschikbaarheidszones. Sommige bieden bijvoorbeeld alleen ondersteuning voor beschikbaarheidszones voor bepaalde lagen of SKU's, of in een subset van Azure-regio's.
Resources configureren voor ondersteuning voor beschikbaarheidszones
Elke service heeft een eigen methode voor het configureren van ondersteuning voor beschikbaarheidszones. Voor meer informatie over hoe elke service beschikbaarheidszones ondersteunt en hoe u deze ondersteuning configureert, raadpleegt u Azure-betrouwbaarheidshandleidingen per service.
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.
Abonnement A kan bijvoorbeeld fysieke zone 1 hebben toegewezen aan logische zone 2, terwijl abonnement B fysieke zone 1 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 kunnen hebben op een actieve workload, zodat de workload in andere zones kan blijven worden uitgevoerd terwijl de update wordt uitgevoerd. Als u wilt profiteren van gesequentieerde zone-updates, moet uw workload al zijn geconfigureerd voor uitvoering in meerdere zones. Zie Geavanceerde veilige implementatieprocedures voor meer informatie over hoe Azure updates implementeert.
Richtlijnen voor architectuur voor beschikbaarheidszones
Betrouwbare workloads 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.