Betrouwbaarheid in Azure-app Service

2025-06-22

In dit artikel wordt de betrouwbaarheidsondersteuning in Azure App Service beschreven, met informatie over tolerantie binnen regio's via beschikbaarheidszones en implementaties in meerdere regio's.

Betrouwbaarheid is een gedeelde verantwoordelijkheid tussen u en Microsoft. U kunt deze handleiding gebruiken om te bepalen welke betrouwbaarheidsopties voldoen aan uw specifieke bedrijfsdoelstellingen en uptimedoelstellingen.

App Service is een HTTP-service voor het hosten van webtoepassingen, REST API's en mobiele back-ends. App Service kan worden geïntegreerd met Microsoft Azure om beveiliging, taakverdeling, automatisch schalen en geautomatiseerd beheer voor toepassingen te bieden. Zie het App Service-overzicht om te ontdekken hoe App Service de betrouwbaarheid en tolerantie van uw toepassingsworkload kan versterken.

Wanneer u App Service implementeert, kunt u meerdere exemplaren inrichten in een App Service-plan. Dit plan vertegenwoordigt de rekenwerkers die uw toepassingscode uitvoeren. Het platform doet er alles aan om de exemplaren in verschillende foutdomeinen te implementeren, maar het distribueert de exemplaren niet automatisch over beschikbaarheidszones.

Aanbevelingen voor productie-implementatie

Gebruik Premium v3/v4 App Service-abonnementen.
Schakel zoneredundantie in. Zie de sectie Beschikbaarheidszoneondersteuning voor meer informatie over de vereisten voor zoneredundantie en hoe u deze inschakelt

Schakel zoneredundantie in. Hiervoor moet uw App Service-plan minimaal twee exemplaren gebruiken.

Tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Door Microsoft geleverde SDK's verwerken meestal tijdelijke fouten. Omdat u uw eigen toepassingen op App Service host, kunt u overwegen om tijdelijke fouten te voorkomen:

Implementeer meerdere exemplaren in uw plan. App Service voert geautomatiseerde updates en andere vormen van onderhoud uit op exemplaren in uw plan. Als een exemplaar beschadigd raakt, kan de service dit exemplaar automatisch vervangen door een nieuwe, gezonde instantie. Tijdens het vervangingsproces kan er een korte periode zijn wanneer het vorige exemplaar niet beschikbaar is en een nieuw exemplaar niet gereed is om verkeer te verwerken. U kunt deze effecten beperken door meerdere exemplaren van uw App Service-plan te implementeren.
Gebruik deploymentslots. App Service-deploymentslots maken implementaties van uw toepassingen zonder uitvaltijd mogelijk. Gebruik implementatieslots om het effect van implementaties en configuratiewijzigingen voor uw gebruikers te minimaliseren. Implementatiesites verminderen ook de kans dat uw toepassing opnieuw wordt opgestart. Het opnieuw opstarten van de toepassing veroorzaakt een tijdelijke fout.
Vermijd het vergroten of verkleinen. Om op te schalen of af te schalen moet u de CPU, het geheugen en andere middelen wijzigen die aan elk exemplaar worden toegewezen. Bewerkingen voor omhoog en omlaag schalen kunnen het opnieuw opstarten van een toepassing activeren. In plaats van omhoog of omlaag te schalen, selecteert u een laag en instantiegrootte die voldoet aan uw prestatievereisten onder normale belasting. U kunt uitschalen en inschalen door exemplaren dynamisch toe te voegen en te verwijderen om wijzigingen in het verkeersvolume af te handelen.

Ondersteuning voor beschikbaarheidszone

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

App Service kan worden geconfigureerd als zone-redundant, wat betekent dat uw resources worden verdeeld over meerdere beschikbaarheidszones. Distributie in meerdere zones helpt uw productieworkloads om tolerantie en betrouwbaarheid te bereiken. Wanneer u zoneredundantie configureert voor App Service-plannen, worden alle apps die gebruikmaken van het plan zone-redundant gemaakt.

Exemplaardistributie in een zone-redundante implementatie volgt specifieke regels. Deze regels blijven van toepassing wanneer de app wordt ingeschaald en uitgeschaald. Zie Overwegingen voor meer informatie.

Ondersteuning voor regio

Zone-redundante App Service-plannen kunnen worden geïmplementeerd in elke regio die beschikbaarheidszones ondersteunt.

Zie Regio's voor meer informatie over welke regio's beschikbaarheidszones ondersteunen voor App Service Environment v3.

Vereisten

U moet de Premium v2-4-abonnementstypen gebruiken. Als u meer informatie wilt weergeven, moet u ervoor zorgen dat u de juiste laag boven aan deze pagina selecteert.

U moet de abonnementstypen Premium v2-4 of Isolated v2 gebruiken en minimaal twee exemplaren van het abonnement hebben.
Beschikbaarheidszones worden alleen ondersteund op nieuwere App Service-schaaleenheden. Zelfs als u een van de ondersteunde regio's gebruikt, krijgt u een foutmelding wanneer u een zone-redundant App Service-plan maakt als beschikbaarheidszones niet worden ondersteund voor de schaaleenheid die u gebruikt.

De schaaleenheid waaraan u bent toegewezen, is gebaseerd op de resourcegroep waarnaar u een App Service-plan implementeert. Om ervoor te zorgen dat uw workloads terechtkomen op een schaaleenheid die beschikbaarheidszones ondersteunt, moet u mogelijk een nieuwe resourcegroep maken en een nieuw App Service-plan en App Service-app maken binnen de nieuwe resourcegroep.

Als u wilt zien of uw App Service-plan een stempel heeft dat beschikbaarheidszones ondersteunt, controleert u de maximumNumberOfZones eigenschap voor het App Service-plan. Als de waarde groter is dan één, ondersteunt uw stempel zones en kunt u zoneredundantie inschakelen voor het plan. Als de waarde gelijk is aan één, biedt uw schaaleenheid geen ondersteuning voor beschikbaarheidszones en moet u een nieuw plan implementeren om zoneredundantie in te schakelen.
```
az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
```
U moet minimaal twee exemplaren in uw plan implementeren.

Overwegingen

Tijdens een storing in de beschikbaarheidszone kunnen sommige aspecten van Azure App Service worden beïnvloed, ook al blijft de toepassing verkeer bedienen. Dit gedrag omvat het schalen van Een App Service-plan, het maken van toepassingen, het configureren van toepassingen en het publiceren van toepassingen.

Wanneer u zoneredundantie inschakelt in uw App Service-plan, verbetert u ook uw tolerantie voor updates die het App Service-platform uitrolt. Zie Betrouwbaarheid tijdens serviceonderhoud voor meer informatie.

Exemplaardistributie in een zone-redundante implementatie volgt specifieke regels. Deze regels blijven van toepassing wanneer de app wordt ingeschaald en uitgeschaald:

Minimale exemplaren: Uw App Service-plan moet minimaal twee exemplaren hebben voor zoneredundantie.
Maximale beschikbaarheidszones die door uw abonnement worden ondersteund: Azure bepaalt het aantal beschikbaarheidszones dat uw abonnement kan gebruiken. Als u het aantal beschikbaarheidszones wilt weergeven dat uw abonnement kan gebruiken, raadpleegt u de eigenschap maximumNumberOfZones in het App Service-plan. Dit is een alleen-lezen eigenschap. Als deze waarde gelijk is aan 1, biedt uw App Service-plan geen ondersteuning voor zoneredundantie. Als de waarde maximumNumberOfZones groter is dan 1, kan uw App Service-plan worden geconfigureerd voor zoneredundantie.
```
az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
```
Exemplaardistributie: Wanneer zoneredundantie is ingeschakeld, worden planexemplaren automatisch verdeeld over meerdere beschikbaarheidszones. De distributie is gebaseerd op de volgende regels:
- De exemplaren worden gelijkmatig verdeeld als u een capaciteit (aantal exemplaren) opgeeft die groter is dan maximumNumberOfZones en het aantal exemplaren is deelbaar door maximumNumberOfZones.
- De resterende gevallen worden verdeeld over de resterende zones.
- Wanneer het App Service-platform instanties toewijst voor een zoneredundant App Service-plan, maakt het gebruik van beste moeite zoneverdeling die door de onderliggende virtuele machineschaalsets van Azure wordt geboden. Een App Service-plan is in balans als elke zone hetzelfde aantal VM's heeft, of verschilt van alle andere zones met één VM meer of één VM minder. Zie Zone balancing voor meer informatie.
Plaatsing van fysieke zones: U kunt de fysieke beschikbaarheidszone bekijken die wordt gebruikt voor elk van uw App Service-planexemplaren. Gebruik de REST API, die de physicalZone waarde voor elk exemplaar retourneert.
```
az rest --method get --url https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/instances?api-version=2024-04-01
```

Voor App Service-plannen die niet zijn geconfigureerd als zone-redundant, zijn de onderliggende VM-exemplaren niet bestand tegen fouten in de beschikbaarheidszone. Ze kunnen downtime ervaren tijdens een storing in elke zone in die regio.

Kosten

Wanneer u App Service Premium v2-v4-abonnementen gebruikt, zijn er geen extra kosten verbonden aan het inschakelen van beschikbaarheidszones zolang u twee of meer exemplaren in uw App Service-plan hebt. Er worden kosten in rekening gebracht op basis van de SKU van uw App Service-plan, de capaciteit die u opgeeft en eventuele instanties waarnaar u schaalt op basis van uw criteria voor automatische schaalaanpassing.

Als u beschikbaarheidszones inschakelt maar een capaciteit van minder dan twee opgeeft, dwingt het platform een minimumaantal exemplaren van twee af. Het platform brengt u kosten in rekening voor deze twee instanties.

Wanneer u het App Service Isolated v2-abonnement gebruikt, zijn er geen extra kosten verbonden aan het inschakelen van beschikbaarheidszones zolang u twee of meer exemplaren in uw App Service-plan hebt. Er worden kosten in rekening gebracht op basis van de SKU van uw App Service-plan, de capaciteit die u opgeeft en eventuele instanties waarnaar u schaalt op basis van uw criteria voor automatische schaalaanpassing.

Ondersteuning voor beschikbaarheidszones configureren

Als u een nieuw zone-redundant App Service-plan wilt implementeren, moet u de typen Premium v2-4-abonnementen gebruiken. Als u meer informatie wilt weergeven, moet u ervoor zorgen dat u de juiste laag boven aan deze pagina selecteert.

Maak een nieuw App Service-plan met zoneredundantie. Als u een nieuw zoneredundant App Service-plan wilt implementeren, selecteert u de optie Zoneredundant wanneer u het plan implementeert in Azure Portal of stelt u de eigenschap zoneRedundant App Service-plan true in op in de Azure CLI-opdracht, De Azure PowerShell-opdracht, het Bicep-bestand of de Azure Resource Manager-sjabloon:
- Azure CLI
- Biceps
```
az appservice plan create -g MyResourceGroup -n MyPlan --zone-redundant --number-of-workers 2 --sku P1V3
```
Notitie

Als u de Azure CLI gebruikt om de zone-redundant eigenschap te wijzigen, moet u de --number-of-workers eigenschap opgeven. Dit is het aantal exemplaren en gebruikt een capaciteit die groter is dan of gelijk is aan 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Migreer een bestaand App Service-plan naar zoneredundantie. Als u een bestaand App Service-plan hebt dat zoneredundantie ondersteunt (de maximaal beschikbare zones groter zijn dan 1), kunt u zoneredundantie inschakelen door de eigenschap zoneRedundant van true het App Service-plan in te stellen op de Azure CLI, uw Bicep-bestand of uw Resource Manager-sjabloon:
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
```
Notitie

Als u de Azure CLI gebruikt om de zoneRedundant eigenschap te wijzigen, moet u de sku.capacity eigenschap opgeven. Dit is het aantal exemplaren en gebruikt een capaciteit die groter is dan of gelijk is aan 2.

Als u een plan of stempel hebt dat geen ondersteuning biedt voor beschikbaarheidszones, moet u een nieuw App Service-plan maken in een nieuwe resourcegroep, zodat u terechtkomt op de App Service-footprint die zones ondersteunt.

Notitie

Het wijzigen van de zoneredundantiestatus van een App Service-plan is bijna onmiddellijk. Tijdens het proces ondervindt u geen downtime of prestatieproblemen.
Zoneredundantie uitschakelen. Als u zoneredundantie wilt uitschakelen, stelt u de eigenschap zoneRedundant App Service-plan false in op of gebruikt u de Azure CLI:
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
```
Notitie

Als u azure CLI gebruikt om de zoneRedundant eigenschap uit te schakelen, moet u de sku.capacity eigenschap opgeven, anders wordt de standaardwaarde ingesteld op 1.

Maak een nieuw App Service-plan met zoneredundantie.
1. Als u nog geen zone-redundante App Service Environment hebt, implementeert u een nieuwe zone-redundante App Service Environment. Zie Een App Service-omgeving maken voor meer informatie over het maken van een App Service-omgeving.
2. Als u het App Service-plan in Azure Portal wilt maken, selecteert u Zone-redundant. Als u het plan wilt maken met behulp van de Azure CLI-opdracht, de Azure PowerShell-opdracht, het Bicep-bestand of de Resource Manager-sjabloon, stelt u de eigenschap App Service-plan zoneRedundant in op true, zoals in de volgende voorbeeldcode:
- Azure CLI
- Biceps
```
az appservice plan create -g MyResourceGroup -n MyPlan --app-service-environment MyAse --zone-redundant --number-of-workers 2 --sku I1V2
```
Notitie

Als u de Azure CLI gebruikt om de zoneRedundant eigenschap te wijzigen, moet u de number-of-workers eigenschap opgeven. Dit is het aantal exemplaren en gebruikt een capaciteit die groter is dan of gelijk is aan 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    hostingEnvironmentProfile: {
        id: '...'
    }
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Een bestaand App Service-plan migreren naar zoneredundantie Als u een bestaand App Service Environment- of Isolated v2 App Service-plan hebt dat zoneredundantie ondersteunt, kunt u zoneredundantie op elk gewenst moment inschakelen. Als u zoneredundantie voor de App Service Environment wilt inschakelen, stelt u de zoneRedundant eigenschap true in op of gebruikt u de Azure CLI:
- Azure CLI
- Biceps
```
az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=true
```
```
resource asev3 'Microsoft.Web/hostingEnvironments@2020-12-01' = {
    name: aseName
    location: location
    kind: 'ASEV3'
    dependsOn: [
        virtualnetwork
    ] 
    properties: {
        ...
        zoneRedundant: true
    }
}
```
Notitie

Wanneer u de zoneredundantiestatus van de App Service Environment wijzigt, start u een upgrade die 12-24 uur duurt. Tijdens het upgradeproces ondervindt u geen downtime of prestatieproblemen.

Voor Geïsoleerde v2 App Service-plannen, als de App Service-omgeving zone-redundant is, kunnen de App Service-plannen zone-redundant worden gemaakt. Elk App Service-plan heeft een eigen onafhankelijke zoneredundantieinstelling, wat betekent dat u een combinatie van zone-redundante en niet-zoneredundante plannen in een App Service-omgeving kunt hebben. Als u zoneredundantie wilt inschakelen voor een Geïsoleerd v2 App Service-plan, stelt u de eigenschap zoneRedundant van true het App Service-plan in op of gebruikt u de Azure CLI.
- Azure CLI
- Biceps
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
```
Notitie

Als u de Azure CLI gebruikt om de zoneRedundant eigenschap te wijzigen, moet u de sku.capacity eigenschap opgeven. Dit is het aantal exemplaren en gebruikt een capaciteit die groter is dan of gelijk is aan 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    hostingEnvironmentProfile: {
        id: '...'
    }
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Zoneredundantie uitschakelen. Als u zoneredundantie wilt uitschakelen, kunt u de eigenschap van het App Service-plan of App Service Environment zoneRedundant instellen op false of de Azure CLI gebruiken.
```
az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=false

az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
```
Notitie

Als u azure CLI gebruikt om de zoneRedundant eigenschap uit te schakelen, moet u de sku.capacity eigenschap opgeven, anders wordt de standaardwaarde ingesteld op 1.

Capaciteitsplanning en -beheer

Als u zich wilt voorbereiden op een fout in de beschikbaarheidszone, kunt u overwegen de capaciteit van uw App Service-plan te overprovisionen. Met overinrichting kan de oplossing enige mate van capaciteitsverlies tolereren en blijven werken zonder verslechterde prestaties. Zie Capaciteit beheren met overinrichting voor meer informatie.

Normale bewerkingen

In de volgende sectie wordt beschreven wat u kunt verwachten wanneer App Service-plannen zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn:

Verkeersroutering tussen zones: Tijdens normale bewerkingen wordt verkeer gerouteerd tussen al uw beschikbare App Service-planexemplaren in alle beschikbaarheidszones.
Gegevensreplicatie tussen zones: Tijdens normale bewerkingen wordt elke status die is opgeslagen in het bestandssysteem van uw toepassing, opgeslagen in zone-redundante opslag en synchroon gerepliceerd tussen beschikbaarheidszones.

Ontspanningservaring

In de volgende sectie wordt beschreven wat u kunt verwachten wanneer App Service-plannen zijn geconfigureerd voor zoneredundantie en een of meer beschikbaarheidszones niet beschikbaar zijn:

Detectie en reactie: Het App Service-platform detecteert automatisch fouten in een beschikbaarheidszone en initieert een antwoord. Er is geen handmatige tussenkomst vereist om een zonefailover te starten.
Actieve aanvragen: Wanneer een beschikbaarheidszone niet beschikbaar is, worden alle aanvragen die worden uitgevoerd die zijn verbonden met een Exemplaar van een App Service-plan in de defecte beschikbaarheidszone beëindigd. Ze moeten opnieuw worden geprobeerd.
Verkeer omleiden: Wanneer een zone niet beschikbaar is, detecteert App Service de verloren exemplaren uit die zone en probeert automatisch nieuwe vervangende exemplaren te vinden. Zodra er vervangingen zijn gevonden, wordt het verkeer over de nieuwe exemplaren verdeeld, indien nodig.

Als automatische schaalaanpassing is geconfigureerd en wordt bepaald dat er meer exemplaren nodig zijn, wordt er een aanvraag naar App Service verzonden om deze exemplaren toe te voegen. Gedrag voor automatisch schalen werkt onafhankelijk van het gedrag van het App Service-platform, wat betekent dat de specificatie van het aantal exemplaren geen veelvoud van twee hoeft te zijn. Zie Een app omhoog schalen in App Service en overzicht van automatische schaalaanpassing voor meer informatie.

Belangrijk

Er is geen garantie dat aanvragen voor meer exemplaren in een zone-down scenario slagen. De backfilling van verloren exemplaren vindt plaats op basis van best effort. Als u gegarandeerde capaciteit nodig hebt wanneer een beschikbaarheidszone verloren gaat, moet u uw App Service-plannen maken en configureren om rekening te houden met het verlies van een zone. U kunt dit bereiken door de capaciteit van uw App Service-plan te over-inrichten.
Niet-uitvoering gerelateerd gedrag: Toepassingen die zijn geïmplementeerd in een zoneredundant App Service-plan, blijven actief en verwerken verkeer, zelfs als een beschikbaarheidszone een storing ondervindt. Gedragingen buiten de runtime kunnen echter worden beïnvloed tijdens een storing in de beschikbaarheidszone. Dit gedrag omvat het schalen van Een App Service-plan, het maken van toepassingen, het configureren van toepassingen en het publiceren van toepassingen.

Terugvalproces

Wanneer de beschikbaarheidszone wordt hersteld, maakt App Service automatisch exemplaren in de herstelde beschikbaarheidszone, verwijdert u tijdelijke exemplaren die zijn gemaakt in de andere beschikbaarheidszones en routeert u verkeer tussen uw exemplaren zoals gebruikelijk.

Testen op zone-uitvallen

Het App Service-platform beheert verkeersroutering, failover en failback voor zone-redundante App Service-plannen. Omdat deze functie volledig wordt beheerd, hoeft u geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.

Ondersteuning voor meerdere regio's

App Service is een service met één regio. Als de regio niet meer beschikbaar is, is uw toepassing ook niet beschikbaar.

Alternatieve benaderingen voor meerdere regio's

Als u het risico wilt beperken dat een storing in één regio van invloed is op uw toepassing, implementeert u in meerdere regio's. De volgende stappen helpen de tolerantie te versterken:

Implementeer uw toepassing op de instances in elke regio.
Taakverdeling en failoverbeleid configureren.
Repliceer uw gegevens tussen regio's, zodat u de laatste toepassingsstatus kunt herstellen.

De volgende resources zijn gerelateerd aan deze aanpak:

Zie Enterprise-implementatie met hoge beschikbaarheid met behulp van App Service Environment voor een voorbeeldbenadering die deze architectuur illustreert.

Reservekopieën

Wanneer u de Basic-laag of hoger gebruikt, kunt u een back-up maken van uw App Service-app naar een bestand met behulp van de mogelijkheden voor back-up en herstel van App Service.

Deze functie is handig als het moeilijk is om uw code opnieuw te implementeren of als u de status op schijf opslaat. Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Een back-up maken van uw app en deze herstellen in App Service voor meer informatie.

Betrouwbaarheid tijdens serviceonderhoud

Azure App Service voert regelmatige service-upgrades uit, evenals andere vormen van onderhoud. Om ervoor te zorgen dat uw verwachte capaciteit beschikbaar is tijdens een upgrade, voegt het platform automatisch extra exemplaren van het App Service-plan toe tijdens het upgradeproces.

Schakel zoneredundantie in. Wanneer u zoneredundantie inschakelt in uw App Service-plan, verbetert u ook uw tolerantie voor updates die het App Service-platform uitrolt. Updatedomeinen bestaan uit verzamelingen virtuele machines (VM's) die offline worden gehaald op het moment van een update. Updatedomeinen zijn gekoppeld aan beschikbaarheidszones. Door meerdere instanties in uw App Service-plan te implementeren en zoneredundantie voor uw plan in te schakelen, wordt tijdens upgrades een extra resiliëntielaag toegevoegd als een instantie of zone ongezond wordt.

Zie Routine gepland onderhoud voor Azure App Service voor meer informatie.

Pas de upgradecyclus aan. U kunt de upgradecyclus voor een App Service-omgeving aanpassen. Als u het effect van upgrades op uw workload wilt valideren, kunt u handmatige upgrades inschakelen, zodat u validatie en tests kunt uitvoeren op een niet-productie-exemplaar voordat de wijziging wordt geïmplementeerd in uw productie-exemplaar.

Zie Upgradevoorkeur voor gepland onderhoud in App Service Environment voor meer informatie over onderhoudsvoorkeuren.

Dienstenniveauovereenkomst (SLA)

De SLA (Service Level Agreement) voor App Service beschrijft de verwachte beschikbaarheid van de service en de voorwaarden waaraan moet worden voldaan om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Wanneer u een zone-redundant App Service-plan implementeert, neemt het uptimepercentage dat is gedefinieerd in de SLA toe.

Betrouwbaarheid in Azure