Tillförlitlighet i Azure App Service
Den här artikeln beskriver tillförlitlighetsstöd i Azure App Service, som omfattar både intraregional återhämtning med tillgänglighetszoner och information om distributioner i flera regioner.
Återhämtning är ett delat ansvar mellan dig och Microsoft, så artikeln beskriver även hur du kan skapa en elastisk lösning som uppfyller dina behov.
Azure App Service är en HTTP-baserad tjänst som är värd för webbprogram, REST-API:er och mobila serverdelar. Azure App Service lägger till kraften i Microsoft Azure i ditt program, med funktioner för säkerhet, belastningsutjämning, automatisk skalning och automatiserad hantering. Information om hur Azure App Service kan öka tillförlitligheten och återhämtningsförmågan för din programarbetsbelastning finns i Varför använda App Service?
När du distribuerar Azure App Service kan du skapa flera instanser av en App Service-plan som representerar beräkningsarbetarna som kör programkoden. Även om plattformen gör ett försök att distribuera instanserna över olika feldomäner sprids inte instanserna automatiskt över tillgänglighetszoner.
Rekommendationer för produktionsdistribution
För produktionsdistributioner bör du:
- Använd Premium v3 App Service-abonnemang.
- Aktivera zonredundans, vilket kräver att din App Service-plan använder minst tre instanser.
- Aktivera zonredundans, vilket kräver att din App Service-plan använder minst tre instanser.
Tillfälliga fel
Tillfälliga fel är korta, tillfälliga fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. De korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program hanterar tillfälliga fel, vanligtvis genom att försöka igen.
Alla molnbaserade program bör följa Azures tillfälliga vägledning för felhantering vid kommunikation med molnbaserade API:er, databaser och andra komponenter. Mer information om hur du hanterar tillfälliga fel finns i Rekommendationer för hantering av tillfälliga fel.
Även om Microsoft-tillhandahållna SDK:er vanligtvis hanterar tillfälliga fel, eftersom du är värd för dina egna program i Azure App Service, måste du överväga hur du undviker att orsaka tillfälliga fel genom att se till att du:
Distribuera flera instanser av din plan. Azure App Service utför automatiserade uppdateringar och andra former av underhåll på instanser av din plan. Om en instans blir felaktig kan tjänsten automatiskt ersätta den instansen med en ny felfri instans. Under ersättningsprocessen kan det finnas en kort tidsperiod då den tidigare instansen inte är tillgänglig och en ny instans ännu inte är redo att hantera trafik. Du kan minimera effekten av det här beteendet genom att distribuera flera instanser av din App Service-plan.
Använd distributionsfack. Distributionsfack för Azure App Service möjliggör distributioner utan driftstopp för dina program. Använd distributionsfack för att minimera effekten av distributioner och konfigurationsändringar på dina användare. Om du använder distributionsfack minskar också sannolikheten för att programmet startas om, vilket orsakar ett tillfälligt fel.
Undvik att skala upp eller ned. Välj i stället en nivå och instansstorlek som uppfyller dina prestandakrav under typisk belastning. Skala bara ut instanser för att hantera ändringar i trafikvolymen. Tänk på att upp- och nedskalning kan utlösa en omstart av programmet.
Stöd för tillgänglighetszon
Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.
Mer information om tillgänglighetszoner i Azure finns i Vad är tillgänglighetszoner?.
Azure App Service kan konfigureras som zonredundant, vilket innebär att dina resurser är spridda över flera tillgänglighetszoner. Spridning över flera zoner hjälper dina produktionsarbetsbelastningar att uppnå återhämtning och tillförlitlighet. Stöd för tillgänglighetszoner är en egenskap för App Service-planen.
Instansspridning med en zonredundant distribution bestäms i följande regler, även när appen skalar in och ut:
- Det minsta antalet App Service-planinstanser är tre.
- Om du anger en kapacitet som är större än tre och antalet instanser är delbart med tre sprids instanserna jämnt.
- Alla instanser som överskrider 3*N är spridda över de återstående en eller två zonerna.
När App Service-plattformen allokerar instanser för en zonredundant App Service-plan använder den zonutjämning med bästa möjliga ansträngning som erbjuds av de underliggande skalningsuppsättningarna för virtuella Azure-datorer. En App Service-plan "balanseras" om varje zon har antingen samma antal virtuella datorer eller +/- en virtuell dator i alla andra zoner som används av App Service-planen.
För App Service-planer som inte är konfigurerade som zonredundanta är virtuella datorinstanser inte motståndskraftiga mot fel i tillgänglighetszonen. De kan uppleva avbrott under ett avbrott i valfri zon i den regionen.
Regioner som stöds
Zonredundanta App Service-planer kan distribueras i alla regioner som stöder tillgänglighetszoner.
Information om vilka regioner som stöder tillgänglighetszoner för App Service-miljön v3 finns i Regioner.
Krav
Du måste använda antingen Premium v2- eller Premium v3-plantyperna.
Tillgänglighetszoner stöds endast på det nyare App Service-fotavtrycket. Även om du använder en av de regioner som stöds får du ett felmeddelande om tillgänglighetszoner inte stöds för resursgruppen. För att säkerställa att dina arbetsbelastningar hamnar på en stämpel som stöder tillgänglighetszoner kan du behöva skapa en ny resursgrupp, App Service-plan och App Service.
- Du måste distribuera minst tre instanser av planen.
Att tänka på
Program som distribueras i en zonredundant App Service-plan fortsätter att köras och hantera trafik även om flera zoner i regionen drabbas av ett avbrott. Det är dock möjligt att icke-körningsbeteenden, inklusive skalning av App Service-planer, skapande av program, programkonfiguration och programpublicering, fortfarande kan påverkas under ett avbrott i tillgänglighetszonen. Zonredundans för App Service-planer säkerställer endast fortsatt drifttid för distribuerade program.
Kostnad
När du använder App Service Premium v2- eller Premium v3-abonnemang finns det ingen extra kostnad för att aktivera tillgänglighetszoner så länge du har tre eller fler instanser i din App Service-plan. Du debiteras baserat på din App Service-plan-SKU, den kapacitet du anger och alla instanser som du skalar till baserat på dina autoskalningsvillkor. Om du aktiverar tillgänglighetszoner men anger en kapacitet som är mindre än tre framtvingar plattformen ett minsta antal instanser på tre och debiterar dig för dessa tre instanser.
App Service-miljön v3 har en specifik prismodell för zonredundans. Prisinformation för App Service-miljön v3 finns i Priser.
Konfigurera stöd för tillgänglighetszoner
Om du vill distribuera en ny zonredundant Azure App Service-plan väljer du alternativet Zonredundant när du distribuerar planen.
Information om hur du distribuerar en ny zonredundant Azure-App Service-miljön finns i Skapa en App Service-miljön.
Zonredundans kan bara konfigureras när du skapar en ny App Service-plan. Om du har en befintlig App Service-plan som inte är zonredundant måste du ersätta den med en ny zonredundant plan. Du kan inte konvertera en befintlig App Service-plan till att använda tillgänglighetszoner. På samma sätt kan du inte inaktivera zonredundans i en befintlig App Service-plan.
Kapacitetsplanering och -hantering
För att förbereda dig för fel i tillgänglighetszonen bör du överetablera tjänstens kapacitet för att säkerställa att lösningen kan tolerera kapacitetsförluster på 1/3 och fortsätta att fungera utan försämrade prestanda vid avbrott i hela zonen. Eftersom plattformen sprider virtuella datorer över tre zoner och du måste ta hänsyn till minst fel i en zon multiplicerar du antalet högsta arbetsbelastningsinstanser med en faktor för zoner/(zon 1) eller 3/2. Om din vanliga högsta arbetsbelastning till exempel kräver fyra instanser bör du etablera sex instanser: (2/3 * 6 instanser) = 4 instanser.
Trafikroutning mellan zoner
Under normal drift dirigeras trafiken mellan alla dina tillgängliga App Service-planinstanser över alla tillgänglighetszoner.
Zon-down-upplevelse
Identifiering och svar: App Service-plattformen ansvarar för att identifiera ett fel i en tillgänglighetszon och svara. Du behöver inte göra något för att initiera en zonredundansväxling.
Aktiva begäranden: När en tillgänglighetszon inte är tillgänglig avslutas alla pågående begäranden som är anslutna till en App Service-planinstans i den felaktiga tillgänglighetszonen och måste göras om.
Omdistribution av trafik: När en zon inte är tillgänglig identifierar Azure App Service de förlorade instanserna från den zonen. Den försöker automatiskt hitta nya ersättningsinstanser. Sedan sprider den trafik över de nya instanserna efter behov.
Om du har konfigurerat autoskalning , och om det beslutar att fler instanser behövs, utfärdar autoskalning även en begäran till App Service om att lägga till fler instanser.
Kommentar
Autoskalningsbeteendet är oberoende av apptjänstens plattformsbeteende. Specifikationen för antalet autoskalningsinstanser behöver inte vara en multipel av tre.
Viktigt!
Det finns ingen garanti för att begäranden om ytterligare instanser i ett zon-down-scenario lyckas. Tillbakafyllningen av förlorade instanser sker på bästa sätt. Om du behöver garanterad kapacitet när en tillgänglighetszon går förlorad bör du skapa och konfigurera dina App Service-planer för att ta hänsyn till att en zon går förlorad. Du kan göra det genom att överetablera kapaciteten för din App Service-plan.
Återställning efter fel
När tillgänglighetszonen återställs skapar Azure App Service automatiskt instanser i den återställda tillgänglighetszonen, tar bort alla tillfälliga instanser som skapats i de andra tillgänglighetszonerna och dirigerar trafik mellan dina instanser som vanligt.
Testa för zonfel
Azure App Service-plattformen hanterar trafikroutning, redundans och återställning efter fel för zonredundanta App Service-planer. Eftersom den här funktionen är helt hanterad behöver du inte initiera eller verifiera felprocesser i tillgänglighetszonen.
Stöd för flera regioner
Azure App Service är en tjänst för en region. Om regionen blir otillgänglig är programmet inte heller tillgängligt.
Alternativa lösningar för flera regioner
För att säkerställa att programmet blir mindre känsligt för ett fel med en region måste du distribuera programmet till flera regioner. För att göra detta bör du:
- Distribuera ditt program till instanserna i varje region.
- Konfigurera belastningsutjämnings- och redundansprinciper.
- Replikera dina data mellan regionerna så att du kan återställa ditt senaste programtillstånd.
Exempel på arkitekturer som illustrerar den här metoden finns i:
- Referensarkitektur: Webbprogram för flera regioner med hög tillgänglighet.
- App Service-appar i flera regioner för haveriberedskap
Om du vill följa med i en självstudiekurs som skapar en app för flera regioner kan du läsa Självstudie: Skapa en app med hög tillgänglighet för flera regioner i Azure App Service.
Ett exempel på en metod som illustrerar den här arkitekturen finns i Företagsdistribution med hög tillgänglighet med hjälp av App Service-miljön.
Säkerhetskopior
När du använder Basic-nivån eller senare kan du säkerhetskopiera din App Service-app till en fil med hjälp av funktionerna för säkerhetskopiering och återställning av App Service. Den här funktionen är användbar om det är svårt att distribuera om koden eller om du lagrar tillståndet på disken. För de flesta lösningar bör du dock inte förlita dig på App Service-säkerhetskopior och i stället använda de andra metoderna som beskrivs i den här artikeln för att stödja dina återhämtningskrav.
Serviceavtal (SLA)
Serviceavtalet (SLA) för Azure App Service beskriver den förväntade tillgängligheten för tjänsten. Den beskriver också de villkor som måste uppfyllas för att uppnå den tillgänglighetsförväntningen. För att förstå dessa villkor är det viktigt att du granskar serviceavtalen (SLA) för onlinetjänster.
När du distribuerar en zonredundant App Service-plan ökar den drifttidsprocent som definieras i serviceavtalet.