Migratiebasislijn voor azure-beschikbaarheidszone
In dit artikel leest u hoe u de gereedheid van de beschikbaarheidszone van uw toepassing kunt beoordelen voor het migreren van een niet-beschikbaarheidszone naar ondersteuning voor beschikbaarheidszones. Meer informatie over hoe u kunt profiteren van ondersteuning voor beschikbaarheidszones en hoe u kunt voldoen aan uw toepassings- en tolerantievereisten. Zie Wat zijn Azure-regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones en de regio's die deze ondersteunen.
Wanneer u betrouwbare workloads maakt, kunt u ten minste een van de volgende configuraties voor de beschikbaarheidszone 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, zone-redundant en zone-redundant, biedt Azure globale 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 regionale en zonegebonden storingen.
Als u wilt zien welke Azure-services beschikbaarheidszones ondersteunen, raadpleegt u de beschikbaarheidszoneservice en regionale ondersteuning.
Notitie
Wanneer u geen zoneconfiguratie voor uw resource selecteert, zone-redundant of zone-redundant, zijn de resource en de bijbehorende subonderdelen niet zonebestendig en kunnen ze uitvallen tijdens een zonestoring in die regio.
Overwegingen voor migratie 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 en de vereiste Azure-services voor uw toepassing ondersteunt.
Als uw regio beschikbaarheidszones ondersteunt, raden we u ten zeerste aan om uw workload voor beschikbaarheidszones te configureren. Als uw regio geen ondersteuning biedt voor beschikbaarheidszones, moet u Azure Resource Mover-richtlijnen gebruiken om te migreren naar een regio die ondersteuning biedt voor beschikbaarheidszones.
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 de 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 of 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 Producten die beschikbaar zijn 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 nodig heeft, moet u teruggaan naar stap 1: Controleer de beschikbaarheid van het product in de Azure-regio om een nieuwe regio te vinden die ondersteuning biedt voor de services en SKU's die uw toepassing nodig heeft. We raden u ten zeerste aan om uw workload te configureren met zoneredundantie.
Voor hoge beschikbaarheid met meerdere zones van Virtuele Azure IaaS-machines gebruikt u Virtual Machine Scale Sets Flex om VM's over meerdere beschikbaarheidszones te verdelen.
Stap 3: Houd rekening met uw toepassingsvereisten
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 waarmee u de juiste implementatie van de beschikbaarheidszone kunt kiezen:
Bevat uw toepassing latentiegevoelige onderdelen?
Azure-beschikbaarheidszones binnen dezelfde Azure-regio zijn verbonden door 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 het configureren van uw workload met een zone-redundante implementatie.
Voor essentiële toepassingsonderdelen die fysieke nabijheid en lage latentie vereisen, zoals gaming, engineeringsimulatie en high-frequency trading (HFT), raden we u aan om een zonegebonden implementatie te configureren. Virtual Machine Scale Sets Flex biedt zone-uitgelijnde rekenkracht samen met gekoppelde opslagschijven.
Heeft uw toepassingscode de gereedheid om een gedistribueerd model te verwerken?
Voor een gedistribueerd microservicesmodel en afhankelijk van uw toepassing is er de mogelijkheid om doorlopend gegevensuitwisseling tussen microservices tussen zones uit te wisselen. 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 zonegebonden implementatie kiezen.
Met 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.
Zoek de latentiegevoelige resources of services in dezelfde zone samen. Andere services in uw architectuur blijven mogelijk zone-redundant.
Repliceer de latentiegevoelige zonegebonden services over meerdere beschikbaarheidszones om zonetolerantie te garanderen.
Taakverdeling tussen de meerdere zonegebonden implementaties met een standaard of globale load balancers.
Als de Azure-service beschikbaarheidszones ondersteunt, raden we u ten zeerste aan zoneredundantie te gebruiken door knooppunten over de zones te spreiden om een SLA met een hogere uptime en bescherming tegen zonestoringen te krijgen.
Voor een toepassing met drie lagen is het belangrijk om inzicht te krijgen in de toepassings-, bedrijfs- en gegevenslagen; en hun status (stateful of stateless) om te ontwerpen in overeenstemming met de aanbevolen procedures en richtlijnen volgens het type workload.
Raadpleeg de richtlijnen en aanbevolen procedures voor de architectuur van de landingszone voor gespecialiseerde workloads in Azure, zoals hieronder.
SAP
Azure Virtual Desktop
Azure Kubernetes Service
Oracle
Wilt u bedrijfscontinuïteit en herstel na noodgevallen in dezelfde Azure-regio bereiken vanwege nalevings-, gegevenslocatie- of governancevereisten?
Om bedrijfscontinuïteit en herstel na noodgevallen binnen dezelfde regio te bereiken en wanneer er geen regionaal paar is, raden we u ten zeerste aan 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 van Azure-VM's inschakelen tussen beschikbaarheidszones voor meer informatie over repliceren, failover en failback van virtuele Azure-machines van de ene beschikbaarheidszone naar een andere in dezelfde Azure-regio.
Als u meerdere regio's nodig hebt of als uw Azure-regio geen beschikbaarheidszones ondersteunt, raden we u aan regionale paren te gebruiken. Regionale paren bevinden zich op een afstand van ongeveer 100 mijl van elkaar en bieden u straalbeveiliging tegen storingen op regionaal niveau, zoals brand, overstromingen, aardbeving en andere natuurlijke of onvoorziene rampen. 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, zoneredundante en wereldwijde services het beste werkt om te voldoen aan zakelijke en technische vereisten.
Andere punten om in overweging te nemen
Elk datacenter in een regio wordt toegewezen aan een fysieke zone. Fysieke zones worden toegewezen aan de logische zones in uw Azure-abonnement. Aan Azure-abonnementen wordt deze toewijzing automatisch toegewezen 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 toewijzing van de logische zone aan de fysieke zone voor uw abonnement weer te geven. Deze informatie is belangrijk voor essentiële toepassingsonderdelen waarvoor colocatie met Azure-resources is gecategoriseerd als strategische services die mogelijk niet beschikbaar zijn in alle fysieke zones.