Migratiebasislijn voor Azure-beschikbaarheidszone

Artikel
04/14/2023

In dit artikel wordt beschreven hoe u de gereedheid van de beschikbaarheidszone van uw toepassing kunt beoordelen voor migratie van niet-beschikbaarheidszone naar ondersteuning voor beschikbaarheidszones. We doorlopen de stappen die u nodig hebt om te bepalen hoe u kunt profiteren van ondersteuning voor beschikbaarheidszones in overeenstemming met uw toepassing en regionale vereisten. Zie Wat zijn Azure-regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones en de regio's die deze ondersteunen.

Bij het maken van betrouwbare workloads kunt u ten minste een van de volgende configuraties voor beschikbaarheidszones kiezen:

Zonegebonden. Een zonegebonden configuratie biedt een specifieke, zelf geselecteerde beschikbaarheidszone.
Zone-redundant. Een zone-redundante configuratie biedt resources die automatisch worden gerepliceerd of gedistribueerd over zones.

Naast de twee opties voor beschikbaarheidszones, zonegebonden en zone-redundant, biedt Azure Wereldwijde services, wat betekent dat ze wereldwijd beschikbaar zijn, ongeacht de regio. Omdat deze services altijd beschikbaar zijn in verschillende regio's, zijn ze bestand tegen zowel regionale als zonegebonden storingen.

Zie Beschikbaarheidszoneservice en regionale ondersteuning om te zien welke Azure-services ondersteuning bieden voor beschikbaarheidszones.

Notitie

Wanneer u geen zoneconfiguratie voor uw resource selecteert, zonegebonden of zone-redundant, zijn de resource en de subonderdelen niet zonebestendig en kunnen ze uitvallen tijdens een zonegebonden storing in die regio.

Overwegingen voor het migreren naar ondersteuning voor beschikbaarheidszones

Er zijn een aantal mogelijke manieren om een betrouwbare Azure-toepassing te maken met beschikbaarheidszones die voldoen aan zowel SLA's als betrouwbaarheidsdoelen. Volg de onderstaande stappen om de juiste aanpak voor uw behoeften te kiezen op basis van technische en wettelijke overwegingen, servicemogelijkheden, gegevenslocatie, nalevingsvereisten en latentie.

Stap 1: controleren of de Azure-regio beschikbaarheidszones ondersteunt

In deze eerste stap moet u valideren dat uw geselecteerde Azure-regio beschikbaarheidszones ondersteunt, evenals de vereiste Azure-services voor uw toepassing.

Als uw regio beschikbaarheidszones ondersteunt, raden we u ten zeerste aan om uw workload te configureren voor beschikbaarheidszones. Als uw regio geen ondersteuning biedt voor beschikbaarheidszones, moet u azure Resource Mover-richtlijnen gebruiken om te migreren naar een regio die ondersteuning voor beschikbaarheidszones biedt.

Notitie

Voor sommige services kunnen beschikbaarheidszones alleen worden geconfigureerd tijdens de implementatie. Als u beschikbaarheidszones voor bestaande services wilt opnemen, moet u mogelijk opnieuw implementeren. Raadpleeg de servicespecifieke documentatie in Overzicht van richtlijnen voor migratie van beschikbaarheidszones voor Microsoft Azure-producten en -services.

Stap 2: Controleren op beschikbaarheid van producten en SKU's in de Azure-regio

In deze stap valideert u dat de vereiste Azure-services en -SKU's beschikbaar zijn in de beschikbaarheidszones van uw geselecteerde Azure-regio.

Als u wilt controleren op regionale ondersteuning van services, raadpleegt u Beschikbare producten per regio.

Zie Beschikbaarheid van VM-SKU's controleren om de beschikbare VM-SKU's per Azure-regio en -zone weer te geven.

Als uw regio geen ondersteuning biedt voor de services en SKU's die uw toepassing vereist, gaat u terug naar Stap 1: Controleer de product beschikbaarheid in de Azure-regio om een nieuwe regio te vinden die ondersteuning biedt voor de services en SKU's die uw toepassing vereist. We raden u ten zeerste aan uw workload te configureren met zoneredundantie.

Voor zonegebonden hoge beschikbaarheid van Azure IaaS-Virtual Machines gebruikt u Virtual Machine Scale Sets (VMSS) Flex om VM's over meerdere beschikbaarheidszones te spreiden.

Stap 3: houd rekening met de vereisten van uw toepassing

In deze laatste stap bepaalt u op basis van toepassingsvereisten welk type ondersteuning voor beschikbaarheidszones het meest geschikt is voor uw toepassing.

Hieronder vindt u drie belangrijke vragen die u helpen bij het kiezen van de juiste implementatie van de beschikbaarheidszone:

Bevat uw toepassing latentiegevoelige onderdelen?

Azure-beschikbaarheidszones binnen dezelfde Azure-regio zijn verbonden via een netwerk met hoge prestaties met een retourlatentie van minder dan 2 ms.

De aanbevolen aanpak voor het bereiken van hoge beschikbaarheid, als lage latentie geen strikte vereiste is, is om uw workload te configureren met een zone-redundante implementatie.

Voor kritieke toepassingsonderdelen waarvoor fysieke nabijheid en lage latentie zijn vereist, zoals gaming, technische simulatie en high-frequency trading (HFT), raden we u aan een zonegebonden implementatie te configureren. Virtual Machine Scale Sets Flex biedt zone-uitgelijnde rekenkracht samen met gekoppelde opslagschijven.

Is uw toepassingscode gereed voor het verwerken van een gedistribueerd model?

Voor een gedistribueerd microservicesmodel en afhankelijk van uw toepassing is er de mogelijkheid om doorlopend gegevens uit te wisselen tussen microservices in verschillende zones. Deze continue gegevensuitwisseling via API's kan van invloed zijn op de prestaties. Als u de prestaties wilt verbeteren en een betrouwbare architectuur wilt onderhouden, kunt u kiezen voor een zonegebonden implementatie.

Bij een zonegebonden implementatie moet u het volgende doen:

Identificeer latentiegevoelige resources of services in uw architectuur.
Controleer of de latentiegevoelige resources of services zonegebonden implementatie ondersteunen.
Plaats de latentiegevoelige resources of services in dezelfde zone. Andere services in uw architectuur blijven mogelijk zone-redundant.
Repliceer de latentiegevoelige zonegebonden services in meerdere beschikbaarheidszones om zonetolerantie te garanderen.
Taakverdeling tussen de meerdere zonegebonden implementaties met een standaard- of globale load balancer.

Als de Azure-service beschikbaarheidszones ondersteunt, raden we u ten zeerste aan zoneredundantie te gebruiken door knooppunten over de zones te spreiden voor een hogere sla voor uptime en bescherming tegen zonegebonden storingen.

Voor een toepassing met drie lagen is het belangrijk om de toepassings-, bedrijfs- en gegevenslagen te begrijpen; en hun status (stateful of stateless) om te ontwerpen in overeenstemming met de best practices en richtlijnen op basis van het type workload.

Raadpleeg voor gespecialiseerde workloads in Azure, zoals de onderstaande voorbeelden, de richtlijnen en best practices voor de architectuur van de landingszone.

Wilt u bedrijfscontinuïteit en herstel na noodgevallen bereiken in dezelfde Azure-regio vanwege naleving, gegevenslocatie of governancevereisten?

Als u bedrijfscontinuïteit en herstel na noodgevallen wilt bereiken binnen dezelfde regio en wanneer er geen regiopaar is, wordt u ten zeerste aangeraden uw workload te configureren met zoneredundantie. Een benadering met één regio is ook van toepassing op bepaalde branches met strikte vereisten voor gegevenslocatie en governance binnen dezelfde Azure-regio. Zie Herstel na noodgevallen voor Azure-VM's inschakelen tussen beschikbaarheidszones voor meer informatie over het repliceren, failover en failback van virtuele Azure-machines van de ene beschikbaarheidszone naar een andere binnen dezelfde Azure-regio.

Als u meerdere regio's nodig hebt of als uw Azure-regio geen ondersteuning biedt voor beschikbaarheidszones, raden we u aan regioparen te gebruiken. Regionale paren bevinden zich op grote afstand op ongeveer 100 mijl van elkaar en bieden u straalbescherming tegen storingen op regionaal niveau zoals brand, overstromingen, aardbevingen en andere natuurlijke of onvoorziene calamiteiten. Zie Replicatie tussen regio's in Azure: bedrijfscontinuïteit en herstel na noodgevallen voor meer informatie.

Notitie

Er kunnen scenario's zijn waarin een combinatie van zonegebonden, zone-redundante en globale services het beste voldoet aan zakelijke en technische vereisten.

Andere punten om in overweging te nemen

Zie Toepassingen testen op beschikbaarheid en tolerantie voor meer informatie over het testen van uw toepassingen op beschikbaarheid en tolerantie.
Elk datacenter in een regio wordt toegewezen aan een fysieke zone. Fysieke zones worden toegewezen aan de logische zones in uw Azure-abonnement. Deze toewijzing wordt automatisch toegewezen aan Azure-abonnementen op het moment dat een abonnement wordt gemaakt. U kunt de toegewezen ARM REST API, listLocations gebruiken en de API-versie instellen op 2022-12-01 om de logische zonetoewijzing aan fysieke zone voor uw abonnement weer te geven. Deze informatie is belangrijk voor kritieke toepassingsonderdelen waarvoor co-locatie met Azure-resources is vereist die zijn gecategoriseerd als Strategische services die mogelijk niet beschikbaar zijn in alle fysieke zones.
Kosten voor bandbreedte tussen zones zijn van toepassing wanneer verkeer tussen zones wordt verplaatst. Zie Bandbreedteprijzen voor meer informatie over bandbreedteprijzen.