Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 meestal gescheiden door enkele kilometers en zijn meestal binnen 100 kilometer. Deze afstand betekent dat ze dicht genoeg zijn om verbindingen met lage latentie met andere beschikbaarheidszones te hebben via een netwerk met hoge prestaties. Ze zijn echter ver genoeg uit elkaar om de kans te verminderen dat meer dan één wordt beïnvloed door lokale storingen of het weer.
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.
Azure brengt geen kosten in rekening voor gegevensoverdracht tussen beschikbaarheidszones in dezelfde regio, ongeacht of u privé- of openbare IP-adressen gebruikt.
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.
Aanbeveling
Zie Lijst met Azure-regio's om te zien welke regio's beschikbaarheidszones ondersteunen.
Datacenters en beschikbaarheidszones
Een beschikbaarheidszone is een logische groepering van een of meer fysiek afzonderlijke datacenters binnen een regio. Elke beschikbaarheidszone is gebouwd op een manier die als er iets misgaat (zoals een stroomstoring of netwerkprobleem), de anderen blijven werken. Eén datacenter biedt dit beveiligingsniveau niet zelf.
Typen ondersteuning voor beschikbaarheidszones
Azure-services kunnen drie typen ondersteuning voor beschikbaarheidszones bieden voor hun resources: zone-redundant en zonegebonden. Elke service ondersteunt mogelijk een of meer van deze typen. Zorg er bij het ontwerpen van uw betrouwbaarheidsstrategie voor dat u begrijpt hoe elke service in uw workload beschikbaarheidszones ondersteunt door te verwijzen naar de betrouwbaarheidshandleiding van elke service.
Elke service kan ondersteuning voor beschikbaarheidszones op verschillende manieren implementeren. In de volgende secties worden de twee typen ondersteuningsservices voor beschikbaarheidszones beschreven:
Zone-redundante bronnen: Zone-redundante bronnen worden door de service 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. Sommige services zijn automatisch zone-redundant in ondersteunde regio's, terwijl andere services vereisen dat u uw resource zo configureert dat deze zone-redundant is. Voor de meeste services selecteert Microsoft de zones die uw resources gebruiken. Soms kunt u de reeks zones selecteren.
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 resources: een zonegebonden resource wordt geïmplementeerd in één zelf-geselecteerde beschikbaarheidszone.
Zonegebonden implementaties bieden niet automatisch tolerantie voor storingen in de beschikbaarheidszone. Zonegebonden resources zijn echter geïsoleerd van fouten in andere zones. Ze kunnen u ook helpen bij het bereiken van ongebruikelijk strenge latentie- of prestatievereisten. Voor een chatty workload die is gebouwd met behulp van virtuele machines, kunt u er bijvoorbeeld voor kiezen om meerdere virtuele machines in dezelfde zone te implementeren om de latentie ertussen te verminderen.
Als u zonegebonden resources tolerant wilt maken voor storingen in de beschikbaarheidszone, moet u een architectuur ontwerpen met afzonderlijke resources in meerdere beschikbaarheidszones binnen de regio. 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 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. Betrouwbaarheidshandleidingen bevatten details van de vereisten waaraan u moet voldoen om beschikbaarheidszones in te schakelen voor uw services.
Wanneer u een resource configureert als zone-redundant, of als u meerdere exemplaren van een zonegebonden resource in verschillende beschikbaarheidszones gebruikt, wordt uw resource beschouwd als zonebestendig: dat wil gezegd, is deze bestand tegen de storing van één beschikbaarheidszone.
Zie Zoneresources en zonetolerantie voor meer informatie over hoe u zone-implementaties kunt gebruiken en zonetolerantie kunt behouden.
Als een resource niet is geconfigureerd voor het gebruik van beschikbaarheidszones, hetzij vanwege de regio die geen zones ondersteunt, of vanwege uw configuratiekeuzes, wordt deze een niet-zonegebonden of regionale implementatie genoemd. Azure kan niet-zonegebonden resources plaatsen in alle zones in de regio. U kiest niet welke resources naar welke zones gaan. Als een beschikbaarheidszone in de regio een storing ondervindt, kunnen niet-zonegebonden resources zich in de betrokken zone bevinden en downtime kunnen ondervinden.
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 krijgen automatisch 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 ARM-API (List Locations Azure Resource Manager) 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.
Als u zonetoewijzing wilt vergelijken voor flexibele oplossingen die meerdere abonnementen omvatten, gebruikt u de toegewezen ARM API checkZonePeers. Als u de checkZonePeers API wilt gebruiken, moet de functie Microsoft.Resources/AvailabilityZonePeering zijn ingeschakeld. Zie Functies registreren in een Azure-abonnement voor meer informatie over het inschakelen van functies.
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.
Latentie tussen zones
Binnen elke regio zijn beschikbaarheidszones verbonden via een netwerk met hoge prestaties. Microsoft streeft ernaar om een communicatie tussen zones te realiseren met een retourlatentie van minder dan ongeveer 2 milliseconden. Lage latentie zorgt voor communicatie met hoge prestaties binnen een regio en voor synchrone replicatie van gegevens in meerdere beschikbaarheidszones.
Notitie
De doellatentie verwijst naar de latentie van de netwerkkoppelingen. Afhankelijk van het communicatieprotocol dat u gebruikt en de netwerkhops die vereist zijn voor een specifieke netwerkstroom, kan de latentie die u ziet afwijken.
In de meeste workloads kunt u onderdelen van uw oplossing verdelen over beschikbaarheidszones zonder merkbaar effect op uw prestaties. Als u een workload hebt met een hoge mate van gevoeligheid voor latentie tussen zones, is het belangrijk om de latentie tussen de geselecteerde beschikbaarheidszones te testen met uw werkelijke protocollen en configuratie. Om het verkeer tussen zones te verminderen, is het mogelijk om zonegebonden implementaties te gebruiken, maar u moet optimaal meerdere beschikbaarheidszones gebruiken in uw plan voor betrouwbaarheidsstrategie. Zie Zonale resources en zonetolerantie voor meer informatie over het gebruik van zonale implementaties en het behouden van zonetolerantie.
Richtlijnen voor architectuur voor beschikbaarheidszones
Om betrouwbare 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.