Delen via

Betrouwbaarheid in Azure-app Service

  • Artikel

In dit artikel wordt de betrouwbaarheidsondersteuning in Azure-app Service beschreven, met betrekking tot 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 besproken 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. 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.

Hoewel door Microsoft geleverde SDK's meestal tijdelijke fouten verwerken, omdat u uw eigen toepassingen op Azure-app Service host, moet u overwegen hoe u tijdelijke fouten kunt voorkomen door ervoor te zorgen dat u het volgende doet:

  • 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 waarin 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 op uw gebruikers te minimaliseren. Het gebruik van implementatiesites vermindert ook de kans dat uw toepassing opnieuw wordt opgestart, wat een tijdelijke fout veroorzaakt.

  • 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. Houd er rekening mee dat omhoog en omlaag schalen ertoe kan 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 binnen de volgende regels, zelfs als de app wordt ingeschaald en uitgeschaald:

  • Het minimale aantal exemplaren van een App Service-plan is drie.
  • Als u een capaciteit opgeeft die groter is dan drie en het aantal exemplaren deelbaar is door drie, worden de exemplaren gelijkmatig verdeeld.
  • 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 is 'evenwichtig' als elke zone hetzelfde aantal VM's of +/- één VM heeft, in alle andere zones die door het App Service-plan worden gebruikt.

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

Ondersteunde regio's

U moet de premium v2- of Premium v3-abonnementstypen gebruiken om zoneredundantie te configureren.

  • 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.

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

Vereisten

::: zone-end

  • 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. Het is echter mogelijk dat niet-runtimegedrag, waaronder het schalen van Een App Service-plan, het maken van toepassingen, het configureren van toepassingen en het publiceren van toepassingen, nog steeds wordt beïnvloed tijdens een storing in de beschikbaarheidszone. 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 eventuele instanties waarnaar u schaalt op basis van uw criteria voor automatisch schalen. Als u beschikbaarheidszones inschakelt, maar een capaciteit van minder dan drie opgeeft, dwingt het platform een minimumaantal exemplaren van drie af en worden er kosten in rekening gebracht 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 bij het maken van een nieuw App Service-plan. Als u een bestaand App Service-plan hebt dat niet zone-redundant is, moet u dit vervangen 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

Ter voorbereiding op een storing in de beschikbaarheidszone moet u de capaciteit van de service overschakelen om ervoor te zorgen dat de oplossing 1/3 verlies van capaciteit tolereert en blijft functioneren zonder verminderde prestaties tijdens storingen in de hele zone. Omdat het platform VM's 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 zones/(zones-1) of 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 en moeten ze opnieuw worden geprobeerd.

Verkeer omleiden: wanneer een zone niet beschikbaar is, detecteert Azure-app Service de verloren exemplaren van 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.

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 extra 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. Hiervoor moet u het volgende doen:

  • 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. 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 echter niet afhankelijk zijn van App Service-back-ups en moet u in plaats daarvan de andere methoden gebruiken die in dit artikel worden beschreven om uw tolerantievereisten te ondersteunen.

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, is het belangrijk dat u de Sla (Service Level Agreements) voor Online Services bekijkt.

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

Gerelateerde inhoud