Delen via

Betrouwbaarheid in Azure-app Service

Azure 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. Als Azure-service biedt App Service een scala aan mogelijkheden ter ondersteuning van uw betrouwbaarheidsvereisten.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u App Service tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. Het beschrijft ook hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen en benadrukt enkele belangrijke informatie over de App Service service level agreement (SLA).

Opmerking

Als u op zoek bent naar informatie over betrouwbaarheidsondersteuning in App Service Environment, raadpleegt u Betrouwbaarheid in App Service Environment.

Aanbevelingen voor productie-implementatie

Het Azure Well-Architected Framework biedt aanbevelingen voor betrouwbaarheid, prestaties, beveiliging, kosten en bewerkingen. Als u wilt weten hoe deze gebieden van invloed zijn op elkaar en bijdragen aan een betrouwbare App Service-oplossing, raadpleegt u best practices voor Architectuur voor App Service (Web Apps) in het Azure Well-Architected Framework.

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u een App Service-web-app maakt, geeft u het App Service-plan op waarmee de app wordt uitgevoerd.

Een App Service-plan definieert een set rekenresources die uw web-apps uitvoeren. Alle web-apps moeten worden uitgevoerd binnen een plan. U kunt een plan schalen voor uitvoering op meerdere VM-exemplaren, ook wel werkrollen genoemd. Deze exemplaren bieden de rekenresources die uw app-code uitvoeren. Eén App Service-plan kan meerdere apps hosten. Alle apps worden uitgevoerd op dezelfde gedeelde set VM-exemplaren.

App Service biedt de volgende redundantiefuncties:

  • Distributie tussen foutdomeinen: Op platformniveau distribueert Azure automatisch de VM-exemplaren van uw App Service-plan over foutdomeinen binnen de Azure-regio. Deze distributie minimaliseert het risico op gelokaliseerde hardwarefouten door VM's te groeperen die een gemeenschappelijke voedingsbron en netwerkswitch delen.

  • Distributie tussen beschikbaarheidszones: Als u zoneredundantie inschakelt voor een ondersteund App Service-plan, distribueert Azure uw exemplaren over beschikbaarheidszones binnen de regio. Deze configuratie biedt een hogere tolerantie als er een zonestoring optreedt. Zie Ondersteuning voor beschikbaarheidszones voor meer informatie over zoneredundantie.

  • App-schaalaanpassing: Wanneer u uw App Service-plan configureert voor het uitvoeren van meerdere VM-exemplaren, worden alle apps in het plan standaard uitgevoerd op alle exemplaren. Als u uw plan voor automatisch schalen configureert, worden alle apps samen geschaald op basis van de instellingen voor automatische schaalaanpassing. U kunt echter aanpassen hoeveel planinstanties een specifieke app uitvoeren met behulp van schaalaanpassing per app.

  • Schaaleenheden: Intern wordt App Service uitgevoerd op een platforminfrastructuur met de naam schaaleenheden, ook wel stempels of webruimten genoemd. Een schaaleenheid bevat alle onderdelen die nodig zijn voor het hosten en uitvoeren van App Service, waaronder rekenkracht, opslag, netwerken en taakverdeling. Azure beheert schaaleenheden om een evenwichtige workloaddistributie te garanderen, routineonderhoud uit te voeren en de algehele betrouwbaarheid van het platform te behouden.

    Sommige mogelijkheden kunnen alleen worden toegepast op specifieke schaaleenheden. Sommige App Service-schaaleenheden ondersteunen bijvoorbeeld zoneredundantie, terwijl andere schaaleenheden in dezelfde regio dat niet doen.

Tolerantie voor 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 kunnen 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, moet u stappen ondernemen om de kans op tijdelijke fouten te verminderen:

  • 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. Als u deze effecten wilt beperken, implementeert u meerdere exemplaren van uw App Service-plan.

  • 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. Deze bewerkingen wijzigen de CPU, het geheugen en andere resources die aan elk exemplaar zijn toegewezen, en ze kunnen het opnieuw opstarten van een toepassing activeren. Selecteer een niveau en instantiegrootte die voldoen aan uw prestatievereisten bij normale belasting. Als u wilt uitschalen en inschalen, voegt u exemplaren dynamisch toe en verwijdert u deze om wijzigingen in het verkeersvolume af te handelen.

Tolerantie voor fouten in beschikbaarheidszones

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

Voor Premium v2-v4-lagen kunt u App Service configureren 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.

Vereisten

Als u zoneredundantie wilt inschakelen, moet u voldoen aan de volgende vereisten:

Exemplaardistributie tussen zones

Wanneer u een zoneredundant App Service-plan maakt, distribueert Azure de exemplaren van het plan over beschikbaarheidszones in de regio. Deze distributie zorgt ervoor dat uw apps beschikbaar blijven, zelfs als één zone een storing ondervindt.

Exemplaardistributie in een zone-redundante implementatie volgt specifieke regels. Deze regels zijn ook van toepassing als 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, wat wordt aangeduid als maximumNumberOfZones. Zie De ondersteuning voor zoneredundantie voor een App Service-plan controleren om het aantal beschikbaarheidszones weer te geven dat door uw specifieke abonnement kan worden gebruikt.

  • Exemplaardistributie: Wanneer zoneredundantie is ingeschakeld, distribueert Azure planinstanties automatisch over meerdere beschikbaarheidszones. De distributie is gebaseerd op de volgende regels:

    • Als het aantal exemplaren groter is dan maximumNumberOfZones en gelijkmatig wordt verdeeld, distribueert Azure de exemplaren gelijkmatig over zones.

    • Als het aantal exemplaren niet gelijkmatig wordt verdeeld, verdeelt Azure de resterende exemplaren 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 plan wordt verdeeld als elke zone hetzelfde aantal VM's heeft of verschilt per exemplaar van alle andere zones. 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. Voor meer informatie, zie Fysieke zones voor een App Service-plan weergeven.

Overwegingen

Voor Premium v2-naar-v4-abonnementen kan een storing in de beschikbaarheidszone van invloed zijn op bepaalde aspecten van Azure App Service, 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 voor uw App Service Premium v2-naar-v4-abonnement , verbetert u ook de tolerantie tijdens platformupdates. Zie Tolerantie voor serviceonderhoud voor meer informatie.

Voor App Service-plannen die niet zijn geconfigureerd als zone-redundant, zijn de onderliggende VM-exemplaren (virtuele machines) 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 naar v4-abonnementen gebruikt, worden er geen kosten toegevoegd voor het inschakelen van beschikbaarheidszones als u twee of meer exemplaren hebt. Kosten zijn gebaseerd op uw App Service-plan-SKU, de capaciteit die u opgeeft en eventuele exemplaren die u schaalt op basis van uw criteria voor automatisch schalen.

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.

Ondersteuning voor beschikbaarheidszones configureren

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 deze aanpak kan de oplossing enige capaciteitsverlies tolereren en blijven werken zonder verslechterde prestaties. Zie Capaciteit beheren met overinrichting voor meer informatie.

Gedrag wanneer alle zones in orde zijn

In de volgende lijst 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 alle beschikbare App Service-planinstanties 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.

Gedrag tijdens een zonefout

Een storing in de beschikbaarheidszone kan van invloed zijn op bepaalde aspecten van App Service, ook al blijft de toepassing verkeer leveren. Dit gedrag omvat het schalen van Een App Service-plan, het maken van toepassingen, het configureren van toepassingen en het publiceren van toepassingen.

In de volgende lijst 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.
  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Resource Health echter gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Alle actieve aanvragen die verbinding maken met een Exemplaar van een App Service-plan in de defecte beschikbaarheidszone, worden beëindigd. Probeer deze aanvragen opnieuw.

  • Verkeer omleiden: App Service detecteert de verloren exemplaren uit die zone en probeert nieuwe vervangende exemplaren te vinden. Nadat App Service vervangingen heeft gevonden, wordt het verkeer naar behoefte verdeeld over de nieuwe exemplaren.

    Als automatische schaalaanpassing is geconfigureerd en bepaalt dat er meer exemplaren nodig zijn, worden instanties van App Service aangevraagd. Gedrag voor automatisch schalen werkt onafhankelijk van het gedrag van het App Service-platform. De specificatie voor het aantal exemplaren hoeft dus geen veelvoud van twee te zijn. Zie Een app omhoog schalen in App Service en overzicht van automatische schaalaanpassing voor meer informatie.

    Belangrijk

    Azure garandeert niet dat aanvragen voor meer exemplaren slagen in een zone-down scenario. Het platform probeert verloren exemplaren opnieuw in te vullen op basis van best effort. Als u gegarandeerde capaciteit nodig hebt tijdens een storing in de beschikbaarheidszone, maakt en configureert u uw App Service-plannen om rekening te houden met zoneverlies door de capaciteit te overbelasten.

  • Niet-uitgevoerd gedrag: Toepassingen 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.

Zoneherstel

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 zonefouten

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

Tolerantie voor storingen in de hele regio

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

Aangepaste oplossingen voor meerdere regio's voor veerkracht

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

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

Houd rekening met de volgende gerelateerde resources:

Backups en herstel

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

Deze mogelijkheden helpen wanneer het moeilijk is om code opnieuw te implementeren of wanneer u de status op schijf opslaat. De meeste oplossingen moeten niet uitsluitend afhankelijk zijn van back-ups. Gebruik in plaats daarvan de andere mogelijkheden in deze handleiding om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren.

Belangrijk

Vanaf 31 maart 2028 bieden aangepaste Back-ups van Azure App Service geen ondersteuning meer voor het maken van back-ups van gekoppelde databases. Zie Afschaffing van back-ups van gekoppelde databases voor meer informatie.

Gebruik in plaats daarvan de systeemeigen hulpprogramma's voor back-up en herstel van uw gekoppelde database. Zie Een back-up maken van uw app en deze herstellen in App Service voor meer informatie.

Tolerantie voor serviceonderhoud

App Service voert reguliere service-upgrades en andere onderhoudstaken uit. Om uw verwachte capaciteit tijdens een upgrade te behouden, voegt het platform automatisch extra exemplaren van het App Service-plan toe tijdens het upgradeproces.

Schakel zoneredundantie in. Wanneer u zoneredundantie inschakelt voor uw App Service-plan, verbetert u ook de tolerantie tijdens platformupdates. Updatedomeinen bestaan uit verzamelingen vm's die offline gaan tijdens een update en die worden toegewezen aan beschikbaarheidszones. Door meerdere exemplaren in uw App Service-plan te implementeren en zoneredundantie voor uw plan in te schakelen, wordt er een extra tolerantielaag toegevoegd als een exemplaar of zone beschadigd raakt tijdens een upgrade.

Zie Routine gepland onderhoud voor App Service en routineonderhoud voor App Service, opnieuw opstarten en downtime voor meer informatie.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen 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.

Gerelateerde inhoud

  • Last updated on