Delen via

Zonetolerantie inschakelen voor Azure-workloads

Om uw toepassingen toleranter te maken voor zonegerelateerde hardwarefouten, netwerkonderbrekingen en natuurrampen, is het belangrijk dat u uw Azure-workloads ontwerpt voor zonetolerantie. Wanneer u resources distribueert over meerdere beschikbaarheidszones binnen een regio, vermindert u het risico dat één zonestoring van invloed is op kritieke services.

Hoewel het een best practice is om zonetolerantie aan te pakken tijdens de eerste planning en implementatie van workloads, is het gebruikelijk om bestaande niet-tolerante workloads te converteren naar zonetolerantieconfiguraties. Over het algemeen is de verwerking van het inschakelen van zonetolerantie voor bestaande workloads eenvoudig en blijft Microsoft het proces vereenvoudigen. Elke wijziging in uw workload kan echter een risico veroorzaken. Zodra u de betrokken risico's begrijpt, kunt u vervolgens beoordelen en prioriteren welke workloads en services binnen deze workloads het belangrijkst zijn voor uw bedrijf en vervolgens zonetolerantie toepassen op de meest impactvolle resources.

In dit artikel vindt u een overzicht van de belangrijkste overwegingen voor het inschakelen van zonetolerantie in uw Azure-workloads. Het helpt u ook bij het plannen en implementeren van een succesvollere overgang naar een tolerantere architectuur.

Aanbeveling

Als u momenteel bezig bent met het ontwerpen van uw workloads of van plan bent om een ontwerpbeoordeling van uw huidige workloads uit te voeren, is het belangrijk dat u de aanbevelingen voor het ontwerpen van redundantie in het Azure Well-Architected Framework (WAF) volgt. De WAF-aanbevelingenhandleiding helpt u bij het ontwerpen van workloadredundantie op meerdere niveaus, met een focus op kritieke werkstromen. Ter ondersteuning van acceptatie van beschikbaarheidszones worden ook strategieën beschreven, zoals implementaties in meerdere regio's en implementatiestempels.

Wat is zonetolerantie?

Azure-services kunnen op twee primaire manieren tolerant worden gemaakt voor storingen in de beschikbaarheidszone:

  • Zone-redundante services: Veel Azure-services ondersteunen zoneredundantie. Deze services repliceren automatisch gegevens tussen beschikbaarheidszones, distribueren binnenkomende aanvragen en failover naar verschillende zones tijdens een zonefout. Elke service ondersteunt deze mogelijkheden op een manier die zinvol is voor die specifieke service. Sommige services zijn standaard zone-redundant, terwijl andere services mogelijk zoneredundantie moeten configureren.

  • Zonegebonden services: Sommige Azure-services zijn zonegebonden, wat betekent dat ze kunnen worden vastgemaakt aan een specifieke beschikbaarheidszone. Als u zonetolerantie wilt bereiken met behulp van een zonegebonden service, implementeert u afzonderlijke exemplaren van de service in meerdere beschikbaarheidszones. Mogelijk moet u ook de distributie van verkeer, replicatie van gegevens en failover tussen de exemplaren beheren.

Sommige services kunnen worden geïmplementeerd in een zone-redundante of zonegebonden configuratie. In de meeste gevallen is het raadzaam zone-redundante services te implementeren wanneer u dat kunt.

Zie Typen ondersteuning voor beschikbaarheidszones voor meer informatie.

Procedure voor zone-inschakeling

Gebruik de volgende stappen om uw Azure-workloads systematisch te controleren, prioriteit te geven aan zonetolerantie en zonetolerantie in te schakelen voor elk onderdeel.

Vereiste voorwaarden

Voer voordat u begint de volgende acties uit:

  • Identificeer elke workload. Een workload verwijst naar een verzameling toepassingsresources, gegevens en ondersteunende infrastructuur die samenwerken om gedefinieerde bedrijfsresultaten te bereiken. Zie Well-Architected Framework-workloads voor meer informatie over workloads en hoe u deze definieert.

  • Prioriteit geven aan de gebruikers- en systeemstromen van elke workload. Verkrijg inzicht in de kritieke paden en afhankelijkheden van uw workloads om te bepalen welke onderdelen als eerste zonebestendig moeten worden gemaakt. Voor meer informatie over hoe u kritische flowanalyse gebruikt om prioriteit te geven aan workloads, zie Prioriteren van workloads voor zonetolerantie.

  • Wijs een kritieke classificatie toe aan elke workload en stroom. Deze classificatie helpt u inzicht te krijgen in de impact van een mogelijke storing in uw bedrijf en begeleidt uw beslissingen over welke workloads prioriteit moeten krijgen voor zonetolerantie. Houd ook rekening met de hoeveelheid acceptabele downtime tijdens het opnieuw configureren van de workloads.

    U kunt een taxonomie gebruiken om uw workloads te classificeren op basis van hun criticiteit. Met deze aanpak kunt u uw inspanningen richten op de belangrijkste services.

    Bekijk de volgende voorbeeldtaxonomie om uw workloads te classificeren.

    Werkbelastingtype Description Effect van onderbreking
    Missiekritisch Kritieke stromen en workloads die zeer betrouwbaar, altijd beschikbaar moeten zijn, bestand tegen fouten en operationeel moeten zijn Elke onderbreking van essentiële functies loopt onmiddellijk risico's op onherstelbare bedrijfsschade of introduceert risico's voor het menselijk leven.
    Bedrijfskritiek Essentiële stromen en workloads die belangrijke bedrijfsfuncties gebruiken Verstoring riskeert financieel verlies of merkschade.
    Bedrijfsoperationeel Draagt bij aan de efficiëntie van bedrijfsactiviteiten, maar niet direct line-of-service aan klanten Kan enige onderbreking tolereren.
    Administratief Interne productiestromen en workloads die niet zijn afgestemd op bedrijfsactiviteiten Kan onderbrekingen verdragen.

    Zie Een classificatie van kritiek toewijzen aan elke stroom voor meer informatie over het classificeren van uw workloads op basis van de beoordeling van kritiek.

  • Controleer of de regio's waar uw Azure-resources zich bevinden ondersteuning bieden voor beschikbaarheidszones. Raadpleeg de lijst met Azure-regio's. Als een regio geen beschikbaarheidszones ondersteunt, kunt u overwegen om uw resources te verplaatsen naar een regio die dat wel doet. Zie Azure-resources verplaatsen tussen resourcegroepen, abonnementen of regio's voor meer informatie.

Stap 1: Prioriteit geven aan Azure-services voor zonetolerantie

Nadat u hebt bepaald welke workloadstromen het belangrijkst zijn voor uw bedrijf, kunt u zich richten op de Azure-services waarvan deze stromen afhankelijk zijn. Sommige Azure-services zijn belangrijker voor uw toepassingen dan andere. Geef prioriteit aan deze services om ervoor te zorgen dat uw toepassingen beschikbaar blijven en tolerant blijven als er een zonefout optreedt.

Gebruik de volgende richtlijnen om prioriteit te geven aan Azure-servicegroepen op basis van hun ernst voor uw workloads. Houd rekening met uw specifieke toepassingsarchitectuur en bedrijfsvereisten wanneer u de prioriteit van services voor zonetolerantie bepaalt.

  1. Begin met netwerkservices. Workloads delen meestal netwerkservices, dus een toename van de tolerantie van deze services kan de tolerantie van meerdere workloads in één keer verbeteren.

    Veel kernnetwerkservices zijn automatisch zone-redundant, maar u moet zich richten op onderdelen zoals Azure ExpressRoute-gateways, Azure VPN Gateway, Azure Application Gateway, Azure Load Balancer en Azure Firewall.

  2. Verbeter de tolerantie voor operationele gegevensopslag. Operationele gegevensarchieven bevatten waardevolle gegevens die vaak door meerdere workloads worden gebruikt, zodat het verbeteren van de beschikbaarheid van deze gegevensarchieven veel workloads kan helpen.

    Voor tolerantie voor operationele gegevensopslag richt u zich op services zoals Azure SQL Database, Azure SQL Managed Instance, Azure Storage, Azure Data Lake Storage, Azure Cosmos DB, Azure PostgreSQL Flexible Server, Azure MySQL Flexible Server en Azure Cache voor Redis.

  3. Prioriteit geven aan rekenservices. Deze services zijn vaak eenvoudig te repliceren en te distribueren tussen zones omdat ze staatloos zijn.

    Rekenservices omvatten Azure Virtual Machines, Azure Virtual Machine Scale Sets, Azure Kubernetes Service (AKS), Azure App Service, App Service Environment, Azure Functions, Azure Service Fabric en Azure Container Apps.

  4. Bekijk de resterende bedrijfskritieke resources die door uw kritieke stromen worden gebruikt. Deze resources zijn mogelijk niet zo kritiek als de eerder vermelde resources, maar ze spelen nog steeds een rol in de functionaliteit van uw toepassing en u moet ze overwegen voor zonetolerantie.

  5. Bekijk de rest van uw bedrijfsgerelateerde resources. Neem weloverwogen beslissingen over of ze zonebestendig moeten zijn. Deze beoordeling omvat services die mogelijk niet rechtstreeks betrekking hebben op uw kritieke workloads, maar toch bijdragen aan de algehele prestaties en betrouwbaarheid van toepassingen.

Stap 2: Methoden voor zoneconfiguratie evalueren

Nadat u prioriteit hebt gegeven aan uw workloads en Azure-services, identificeert u de methode die nodig is om ondersteuning voor beschikbaarheidszones in te schakelen voor elke service en begrijpt u wat u moet doen om zonetolerantie te configureren.

Elke Azure-handleiding voor betrouwbaarheidsservices bevat een sectie waarin wordt beschreven hoe u zonetolerantie voor die service inschakelt. Deze sectie helpt u inzicht te hebben in de inspanningen die nodig zijn om elke servicezone tolerant te maken, zodat u uw strategie dienovereenkomstig kunt plannen. Zie azure-handleidingen voor betrouwbaarheidsservices voor meer informatie over een specifieke service.

Gebruik de zoneconfiguratietabel om snel inzicht te hebben in benaderingen voor algemene Azure-services.

Belangrijk

Als uw workload onderdelen bevat die zijn geïmplementeerd in een zonegebonden configuratie (of één zone), moet u van plan zijn om deze onderdelen tolerant te maken voor zonestoringen. Een veelvoorkomende aanpak is het implementeren van afzonderlijke exemplaren in een andere beschikbaarheidszone en zo nodig schakelen tussen deze exemplaren.

Stap 3: Testen op latentie

Wanneer u de werkbelastingzone tolerant maakt, kunt u latentie tussen beschikbaarheidszones overwegen. Soms kunnen sommige verouderde systemen de kleine hoeveelheid extra latentie die verkeer tussen zones introduceert niet tolereren, met name wanneer u synchrone replicatie inschakelt binnen de gegevenslaag. Als u vermoedt dat latentie tussen zones van invloed kan zijn op uw workload, voert u tests uit voor en na het inschakelen van zonetolerantie. Zie Zone-resources en zonetolerantie voor meer informatie over hoe latentie tussen zones van invloed kan zijn op uw toepassing en benaderingen om latentieproblemen tussen zones te beperken.

Zoneconfiguratiemethoden voor Azure-services

Elke Azure-service ondersteunt een specifiek type ondersteuning voor beschikbaarheidszones, dat is gebaseerd op het beoogde gebruik en de interne architectuur van de service. Als u een resource hebt die niet is geconfigureerd voor het gebruik van beschikbaarheidszones (of een niet-zonegebonden resource), wilt u deze mogelijk opnieuw configureren met ondersteuning voor beschikbaarheidszones. De betrouwbaarheidshandleiding voor die service biedt richtlijnen of koppelingen naar configuratie-instructies voor beschikbaarheidszones.

Deze sectie bevat een overzicht van de verschillende typen zoneconfiguratiemethoden en welke benadering elke service ondersteunt.

Belangrijk

Wanneer u zoneredundantie inschakelt voor een resource, wordt die resource automatisch bestand tegen zonefouten. Wanneer u een zonegebonden configuratie gebruikt om de resource vast te maken aan een specifieke beschikbaarheidszone, wordt de resource niet automatisch zoneredundant. U moet het bestand bestand maken tegen de uitval van een zone. Voor zonegebonden services weerspiegelt dit artikel de complexiteit en kosten van het vastmaken aan een zone. Zie de betrouwbaarheidshandleiding van de service voor meer informatie over extra stappen voor het bereiken van zonetolerantie.

De tabel zoneconfiguratie bevat de ondersteunde benadering voor zoneconfiguratie voor veel Azure-services en bevat een koppeling naar elke betrouwbaarheidshandleiding voor die service. De betrouwbaarheidshandleiding bevat informatie over het configureren van niet-zoneresources om ondersteuning voor beschikbaarheidszones mogelijk te maken.

In de volgende tabel wordt elke zoneconfiguratiebenadering beschreven, inclusief het niveau van inspanning en downtime dat nodig is om beschikbaarheidszones in te schakelen.

Methode Description Typisch inspanningsniveau Kan downtime vereisen
Altijd zone-veerkrachtig De service is standaard zonebestendig in regio's die beschikbaarheidszones ondersteunen. Er is geen actie vereist. Geen Nee.
Enablement Minimale configuratiewijzigingen vereist, zoals zoneredundantie inschakelen in instellingen. Het proces heeft geen invloed op de beschikbaarheid, maar houd rekening met kosten of prestaties. Low Nee.
Wijziging Er zijn waarschijnlijk enkele configuratiewijzigingen vereist, zoals het opnieuw implementeren van afhankelijke resources of het wijzigen van netwerkinstellingen. Gemiddeld Yes
Herschikking Belangrijke wijzigingen die nodig zijn, zoals het opnieuw implementeren van volledige resources, toepassingen of services, of het migreren van gegevens naar nieuwe services. High Yes

Meer informatie over de kosten voor het inschakelen van ondersteuning voor een beschikbaarheidszone voor een service. Voor veel services voegt het inschakelen van beschikbaarheidszones geen kosten toe. Voor sommige services is echter een specifieke laag, een specifiek aantal capaciteitseenheden of beide vereist. Voor andere services worden verschillende tarieven in rekening gebracht wanneer u beschikbaarheidszones gebruikt. De tabel in de volgende sectie bevat de typische kostenimpact voor elke service.

Opmerking

De informatie in dit artikel bevat een overzicht van de gebruikelijke benadering voor het inschakelen van ondersteuning voor beschikbaarheidszones en geeft een overzicht van de typische kostenimpact. Maar sommige factoren kunnen van invloed zijn op de werking van uw specifieke oplossing. Sommige services worden bijvoorbeeld vermeld als altijd zonetolerant, maar deze aanduiding is alleen van toepassing in specifieke regio's of voor specifieke lagen van de service. Gebruik deze tabellen als uitgangspunt, maar bekijk de andere resources die worden genoemd om de specifieke details te begrijpen.

Azure-services op zoneconfiguratiebenadering

De volgende tabel bevat een overzicht van de ondersteuning voor de beschikbaarheidszone voor veel Azure-services en biedt een benadering, inclusief kostenimpact, om ondersteuning voor beschikbaarheidszones in te schakelen voor elke service.

Dienst Kan zone-redundant zijn Kan zonegebonden zijn Typische benadering van zoneconfiguratie Typische invloed van kosten
Azure AI Zoeken Ja Altijd zone-veerkrachtig N/A
Azure API Management Ja Ja Wijziging Minimale laag vereist
Azure App Configuration Ja Altijd zone-veerkrachtig N/A
Azure App Service Ja Enablement Minimale niveau en vereist aantal exemplaren
Azure App Service - App Service-omgeving Ja Enablement Minimaal aantal exemplaren vereist
Azure Application Gateway Ja Ja Altijd zone-veerkrachtig N/A
Azure Backup Ja Herschikking Gemiddelde kostenverhoging
Azure Bastion Ja Ja Herschikking Geen gevolgen voor kosten
Azure Batch Ja Herschikking Geen kostenimpact voor hetzelfde aantal virtuele machines (VM's)
Azure Blob-opslagruimte Ja Enablement Gemiddelde kostenverhoging
Azure Cache voor Redis - Enterprise Ja Herschikking Geen gevolgen voor kosten
Azure Cache voor Redis - Standard en Premium Ja Enablement Minimale laag vereist
Azure Container Apps Ja Herschikking Minimum aantal replica's vereist
Azure Container Instances Ja Herschikking Geen gevolgen voor kosten
Azure Container Registry- Ja Altijd zone-veerkrachtig N/A
Azure Cosmos DB voor NoSQL Ja Wijziging Geen als u automatische schaalaanpassing of schrijfbewerkingen voor meerdere regio's gebruikt
Azure Data Factory Ja Altijd zone-veerkrachtig N/A
Azure Data Lake Storage Ja Enablement Gemiddelde kostenverhoging
Azure Database for MySQL - Flexibele server Ja Herschikking Primaire en hoge beschikbaarheidsinstantie (HA) vereist
Azure Database for PostgreSQL - Flexibele server Ja Enablement Primaire en HOGE-instantie vereist
Azure Databricks Ja Enablement Geen kostenimpact voor hetzelfde aantal VM's; gemiddelde kostenverhoging voor opslag
Azure Disk Storage (beheerde schijven) Ja Ja Enablement Gemiddelde kostenverhoging
Elastische SAN van Azure Ja Herschikking Gemiddelde kostenverhoging
Azure Event Hubs: Toegewezen laag Ja Altijd zone-veerkrachtig Minimale capaciteitseenheden (CA's) vereist
Azure Event Hubs: alle andere niveaus Ja Altijd zone-veerkrachtig N/A
Azure ExpressRoute-gateway Ja Ja Wijziging Afhankelijk van de laag
Azure Files Ja Enablement Gemiddelde kostenverhoging
Azure Firewall Ja Ja Wijziging Geen gevolgen voor kosten
Azure Functions Ja Herschikking Minimale niveau en vereist aantal exemplaren
Azure HDInsight Ja Herschikking Geen kostenimpact voor hetzelfde aantal knooppunten
Azure IoT Hub Ja Altijd zone-veerkrachtig N/A
Azure Key Vault- Ja Altijd zone-veerkrachtig N/A
Azure Kubernetes Service (AKS) Ja Herschikking Geen gevolgen voor kosten
Azure Load Balancer Ja Ja Wijziging Geen gevolgen voor kosten
Azure Logic Apps - Verbruikslaag Ja Altijd zone-veerkrachtig N/A
Azure Logic Apps - Standard-laag Ja Herschikking Minimale niveau en vereist aantal exemplaren
Azure Managed Grafana Ja Opnieuw implementeren Gemiddelde kostenverhoging
Azure Monitor: Log Analytics Ja Altijd zone-veerkrachtig
Azure NetApp Files Ja Herschikking Afhankelijk van de replicatieconfiguratie
Azure Queue Storage Ja Enablement Gemiddelde kostenverhoging
Azure Service Bus Ja Altijd zonetolerant N/A
Azure Service Fabric Ja Ja Herschikking Geen kostenimpact voor hetzelfde aantal VM's
Azure Site Recovery Ja Herschikking Geen kostenimpact voor Site Recovery, gemiddelde kostenverhoging voor replicaopslag
Azure SQL Database: Bedrijfskritieke laag Ja Enablement Geen gevolgen voor kosten
Azure SQL Database: laag algemeen gebruik Ja Enablement Gemiddelde kostenverhoging
Azure SQL Database: Hyperscale-laag Ja Herschikking Minimum aantal replica's vereist
Azure SQL Database: Premium-laag Ja Enablement Geen gevolgen voor kosten
Azure SQL Managed Instance Ja Enablement Gemiddelde kostenverhoging
Azure Table Storage Ja Enablement Gemiddelde kostenverhoging
Azure-schaalvergrotingssets voor virtuele machines Ja Ja Herschikking Geen kostenimpact voor hetzelfde aantal VM's
Virtuele Azure-machines Ja Herschikking Geen kostenimpact voor hetzelfde aantal VM's
Azure Virtual Network Ja Altijd zone-veerkrachtig N/A
Openbaar IP-adres Ja Ja Altijd zone-veerkrachtig N/A
  • Last updated on