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.
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.
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.
Wanneer u een resource zo configureert dat deze zone-redundant is 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.
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.
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.
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.
Notitie
Zoals gerapporteerd op Azure Updates Blog , worden er geen kosten in rekening gebracht voor de gegevensoverdracht tussen beschikbaarheidszones, ongeacht het gebruik van privé- of openbare IP-adressen op uw Azure-resources. Met deze wijziging zal Azure klanten verder aanmoedigen en ondersteunen bij het bouwen van tolerantere en efficiëntere toepassingen en oplossingen in Azure
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.
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.
In deze module leert u hoe u maximaal beschikbare oplossingen kunt implementeren met Azure SQL. U bekijkt ook architecturen en bepaalt de invloed ervan op de beschikbaarheid.
Beheer een SQL Server-databaseinfrastructuur voor cloud-, on-premises en hybride relationele databases met behulp van de relationele Microsoft PaaS-databaseaanbiedingen.
