Delen via

Betrouwbaarheid in Azure-app Service

  • Artikel

In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure-app Service beschreven. Het omvat zowel regionale tolerantie als beschikbaarheidszones en informatie over implementaties in meerdere regio's.

Tolerantie is een gedeelde verantwoordelijkheid tussen u en Microsoft. In dit artikel worden ook manieren beschreven waarop u een flexibele oplossing kunt bouwen die aan uw behoeften voldoet.

Azure App Service is een op HTTP gebaseerde service voor het hosten van webtoepassingen, REST API's en mobiele back-ends. Azure-app Service voegt de kracht van Microsoft Azure toe aan uw toepassing, met mogelijkheden voor beveiliging, taakverdeling, automatisch schalen en geautomatiseerd beheer. Als u wilt weten hoe Azure-app Service de betrouwbaarheid en tolerantie van uw toepassingsworkload kan verbeteren, raadpleegt u Waarom App Service gebruiken?

Wanneer u Azure-app Service implementeert, kunt u meerdere exemplaren van een App Service-plan maken, dat de rekenwerkers vertegenwoordigt die uw toepassingscode uitvoeren. Zie Azure-app Service-plan voor meer informatie. Hoewel het platform moeite doet om de exemplaren in verschillende foutdomeinen te implementeren, worden de exemplaren niet automatisch verspreid over beschikbaarheidszones.

Aanbevelingen voor productie-implementatie

Voor productie-implementaties moet u het volgende doen:

  • Gebruik Premium v3 App Service-abonnementen.
  • Schakel zoneredundantie in. Hiervoor moet uw App Service-plan minimaal drie 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. Ze 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 bij het communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het overdragen van tijdelijke fouten voor meer informatie over het afhandelen van tijdelijke fouten.

Door Microsoft geleverde SDK's verwerken meestal tijdelijke fouten. Omdat u uw eigen toepassingen op Azure-app Service host, kunt u overwegen om tijdelijke fouten te voorkomen door ervoor te zorgen dat u:

  • Implementeer meerdere exemplaren van uw plan. Azure-app Service voert geautomatiseerde updates en andere vormen van onderhoud uit op exemplaren van 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 nog niet gereed is om verkeer te verwerken. U kunt de impact van dit gedrag beperken door meerdere exemplaren van uw App Service-plan te implementeren.

  • Gebruik implementatiesites. Azure-app Service-implementatiesites maken implementaties van uw toepassingen zonder downtime mogelijk. Gebruik implementatiesites om de impact van implementaties en configuratiewijzigingen voor uw gebruikers te minimaliseren. Het gebruik van implementatiesites vermindert ook de kans dat uw toepassing opnieuw wordt opgestart. Opnieuw opstarten veroorzaakt een tijdelijke fout.

  • Vermijd omhoog of omlaag schalen. Selecteer in plaats daarvan een laag en instantiegrootte die voldoen aan uw prestatievereisten onder normale belasting. Schaal alleen exemplaren uit om wijzigingen in het verkeersvolume af te handelen. Omhoog en omlaag schalen kan ertoe leiden dat een toepassing opnieuw wordt opgestart.

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.

Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?

Azure-app Service kan worden geconfigureerd als zone-redundant, wat betekent dat uw resources zijn verdeeld over meerdere beschikbaarheidszones. Door meerdere zones te spreiden, kunnen uw productieworkloads tolerantie en betrouwbaarheid bereiken. Ondersteuning voor beschikbaarheidszones is een eigenschap van het App Service-plan.

Het verspreiden van exemplaren met een zone-redundante implementatie wordt bepaald met behulp van de volgende regels. Deze regels zijn ook van toepassing wanneer de app wordt ingeschaald en uitgeschaald:

  • Het minimale aantal exemplaren van een App Service-plan is drie.
  • De exemplaren worden gelijkmatig verdeeld als u een capaciteit opgeeft die groter is dan drie en het aantal exemplaren is deelbaar door drie.
  • Alle exemplaren tellen meer dan 3*N zijn verspreid over de resterende één of twee zones.

Wanneer het App Service-platform instanties toewijst voor een zoneredundant App Service-plan, wordt gebruikgemaakt van zoneverdeling met de best effort-zone die wordt aangeboden door de onderliggende virtuele-machineschaalsets van Azure. Een App Service-plan wordt verdeeld als elke zone hetzelfde aantal virtuele machines of plus- of mintekens heeft in alle andere zones. Zie Zone balancing voor meer informatie.

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

Ondersteunde regio's

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 abonnementstypen Premium v2 of Premium v3 gebruiken.

  • Beschikbaarheidszones worden alleen ondersteund voor de nieuwere App Service-footprint. Zelfs als u een van de ondersteunde regio's gebruikt, krijgt u een foutmelding als beschikbaarheidszones niet worden ondersteund voor uw resourcegroep. Om ervoor te zorgen dat uw workloads terechtkomen op een stempel die beschikbaarheidszones ondersteunt, moet u mogelijk een nieuwe resourcegroep, App Service-plan en App Service maken.

  • U moet minimaal drie exemplaren van uw abonnement implementeren.

Overwegingen

Toepassingen die zijn geïmplementeerd in een zone-redundant App Service-plan, blijven actief en bedienen verkeer, zelfs als meerdere zones in de regio een storing ondervinden. Niet-uitgevoerd gedrag kan nog steeds 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. Zoneredundantie voor App Service-plannen zorgt alleen voor continue uptime voor geïmplementeerde toepassingen.

Kosten

Wanneer u App Service Premium v2- of Premium v3-abonnementen gebruikt, zijn er geen extra kosten verbonden aan het inschakelen van beschikbaarheidszones zolang u drie 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 alle instanties die u schaalt op basis van uw criteria voor automatische schaalaanpassing.

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

App Service Environment v3 heeft een specifiek prijsmodel voor zoneredundantie. Zie Prijzen voor prijsinformatie voor App Service Environment v3.

Ondersteuning voor beschikbaarheidszones configureren

Als u een nieuw zone-redundant Azure-app Service-plan wilt implementeren, selecteert u de optie Zoneredundant wanneer u het plan implementeert.

Zie Een App Service Environment maken als u een nieuwe zone-redundante Azure-app Service Environment wilt implementeren.

Zoneredundantie kan alleen worden geconfigureerd wanneer u een nieuw App Service-plan maakt. Als u een bestaand App Service-plan hebt dat niet zone-redundant is, vervangt u dit door een nieuw zone-redundant plan. U kunt een bestaand App Service-plan niet converteren om beschikbaarheidszones te gebruiken. Op dezelfde manier kunt u zoneredundantie niet uitschakelen voor een bestaand App Service-plan.

Capaciteitsplanning en -beheer

Als u zich wilt voorbereiden op een storing in de beschikbaarheidszone, moet u de capaciteit van de service te veel inrichten. Deze aanpak zorgt ervoor dat de oplossing 1/3 verlies van capaciteit tolereert en blijft functioneren zonder verminderde prestaties tijdens storingen in de hele zone. Omdat het platform virtuele machines verspreidt over drie zones en u rekening moet houden met ten minste de fout van één zone, vermenigvuldigt u het aantal piekwerkbelastingexemplaren met een factor of zones/(zones-1)3/2. Als uw typische piekworkload bijvoorbeeld vier exemplaren vereist, moet u zes exemplaren inrichten: (2/3 * 6 exemplaren) = 4 exemplaren.

Verkeersroutering tussen zones

Tijdens normale bewerkingen wordt verkeer gerouteerd tussen al uw beschikbare App Service-planexemplaren in alle beschikbaarheidszones.

Zone-down ervaring

Detectie en reactie. Het App Service-platform is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone en reageert. U hoeft niets te doen 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 Azure-app Service de verloren exemplaren uit die zone. Er wordt automatisch geprobeerd nieuwe vervangingsexemplaren te vinden. Vervolgens wordt verkeer verspreid over de nieuwe exemplaren, indien nodig.

Als u automatische schaalaanpassing hebt geconfigureerd en er meer exemplaren nodig zijn, geeft automatisch schalen ook een aanvraag aan App Service uit om meer exemplaren toe te voegen. Zie Een app omhoog schalen in Azure-app Service voor meer informatie.

Notitie

Gedrag voor automatisch schalen is onafhankelijk van het gedrag van het App Service-platform. De specificatie voor het aantal exemplaren voor automatisch schalen hoeft geen veelvoud van drie te zijn.

Belangrijk

Er is geen garantie dat aanvragen voor meer exemplaren in een zone-down scenario slagen. De back-invulling 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 doen door de capaciteit van uw App Service-plan te overprovisioneren.

Failback

Wanneer de beschikbaarheidszone wordt hersteld, maakt Azure-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 als normaal.

Testen op zonefouten

Azure-app Service-platform beheert verkeersroutering, failover en failback voor zone-redundante App Service-abonnementen. 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

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

Alternatieve oplossingen voor meerdere regio's

Om ervoor te zorgen dat uw toepassing minder gevoelig wordt voor een storing in één regio, moet u uw toepassing implementeren in meerdere regio's:

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

Zie bijvoorbeeld architecturen die deze benadering illustreren:

Zie Zelfstudie: Een maximaal beschikbare app voor meerdere regio's maken in Azure-app Service om een zelfstudie te volgen die een app voor meerdere regio's maakt.

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

Back-ups

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. Zie Back-up maken en herstellen van uw app in Azure-app Service voor meer informatie.

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 moet u niet vertrouwen op App Service-back-ups. Gebruik de andere methoden die in dit artikel worden beschreven ter ondersteuning van uw tolerantievereisten.

Service Level Agreement (SLA)

In de SLA (Service Level Agreement) voor Azure-app Service wordt de verwachte beschikbaarheid van de service beschreven. Ook worden de voorwaarden beschreven waaraan moet worden voldaan om die beschikbaarheids verwachting te bereiken. Als u deze voorwaarden wilt begrijpen, bekijkt u de Sla (Service Level Agreements) voor Online Services.

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

Gerelateerde inhoud