Tillförlitlighet i Azure App Service
Den här artikeln beskriver tillförlitlighetsstöd i Azure App Service och beskriver intraregional återhämtning med tillgänglighetszoner. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.
Azure App Service är en HTTP-baserad tjänst som är värd för webbprogram, REST-API:er och mobila serverdelar och lägger till kraften i Microsoft Azure i ditt program, till exempel:
- Säkerhet
- Belastningsutjämning
- Automatisk skalning
- Automatiserad hantering
Om du vill utforska hur Azure App Service kan öka återhämtningstiden för din programarbetsbelastning kan du läsa Varför använda App Service?
Rekommendationer för tillförlitlighet
Det här avsnittet innehåller rekommendationer för att uppnå återhämtning och tillgänglighet. Varje rekommendation ingår i en av två kategorier:
Hälsoobjekt omfattar områden som konfigurationsobjekt och rätt funktion för de viktigaste komponenterna som utgör din Azure-arbetsbelastning, till exempel Konfigurationsinställningar för Azure-resurser, beroenden för andra tjänster och så vidare.
Riskobjekt omfattar områden som tillgänglighets- och återställningskrav, testning, övervakning, distribution och andra objekt som, om de lämnas olösta, ökar risken för problem i miljön.
Prioritetsmatris för tillförlitlighetsrekommendationer
Varje rekommendation markeras i enlighet med följande prioritetsmatris:
| Bild | Prioritet | Description |
|---|---|---|
|
Högt | Omedelbar korrigering behövs. |
|
Medel | Åtgärda inom 3–6 månader. |
|
Låg | Måste granskas. |
Sammanfattning av tillförlitlighetsrekommendationer
Hög tillgänglighet
ASP-1 – Distribuera zonredundanta App Service planer
För att förbättra återhämtning och tillförlitlighet för dina affärskritiska arbetsbelastningar rekommenderar vi att du distribuerar dina nya App Service-planer med zonredundans. Följ stegen för att distribuera om till tillgänglighetszonsstöd, konfigurera dina pipelines för att distribuera om din WebApp på den nya App Services-planen och använd sedan en blågrön distributionsmetod för redundansväxling till den nya webbplatsen.
Genom att distribuera dina program mellan flera tillgänglighetszoner kan du säkerställa att de fortsätter att fungera även om det uppstår fel på datacenternivå. Mer information om stöd för tillgänglighetszoner i Azure App Service finns i Stöd för tillgänglighetszoner.
// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where sku_tier !in ("Free", "LinuxFree", "Basic", "WorkflowStandard", "ElasticPremium", "Dynamic", "Shared", "", "Isolated", "Standard") and zoneRedundant == false
| project name, subscriptionId, sku_tier, zoneRedundant
Återhämtning
ASP-2 – Använd en App Service plan som stöder tillgänglighetszoner
Stöd för tillgänglighetszoner är endast tillgängligt för vissa App Service planer. Information om vilken plan du behöver för att använda tillgänglighetszoner finns i Krav för tillgänglighetszon.
// Azure Resource Graph Query
// The query filters the resources based on the type "microsoft.web/serverfarms" i.e. App Service Plans that are not setup to use standard or premium SKUs.
resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where sku_tier !contains 'premium' and sku_tier !contains 'standard'
| project name, sku_tier
ASP-4 – Skapa separata App Service planer för produktion och testning
För att förbättra återhämtning och tillförlitlighet för dina affärskritiska arbetsbelastningar bör du migrera dina befintliga App Service-planer och App Service miljöer till tillgänglighetszonstöd. Genom att distribuera dina program mellan flera tillgänglighetszoner kan du säkerställa att de fortsätter att fungera även om det uppstår fel på datacenternivå. Mer information om stöd för tillgänglighetszoner i Azure App Service finns i Stöd för tillgänglighetszoner.
Skalbarhet
ASP-3 – Undvik att skala upp eller ned ofta
Vi rekommenderar att du undviker att ofta skala upp eller ned dina Azure App Service instanser. Välj i stället en lämplig nivå- och instansstorlek som kan hantera din typiska arbetsbelastning och skala ut instanserna för att hantera ändringar i trafikvolymen. Upp- eller nedskalning kan potentiellt utlösa en programomstart, vilket kan leda till avbrott i tjänsten.
ASP-5 – Aktivera automatisk skalning/automatisk skalning för att säkerställa att tillräckliga resurser är tillgängliga för tjänstbegäranden
Vi rekommenderar att du aktiverar automatisk skalning/automatisk skalning för din Azure App Service för att säkerställa att det finns tillräckligt med resurser för att hantera inkommande begäranden. Autoskalning är regelbaserad skalning, medan automatisk skalning utför automatisk in- och utskalning baserat på HTTP-trafik. Mer information finns i automatisk skalning i Azure App Service eller kom igång med autoskalning i Azure.
// Azure Resource Graph Query
// The query filters the resources based on the type "microsoft.web/serverfarms" i.e. App Service Plans that are not setup to use standard or premium SKUs.
// TODO: Extend this query to show automatic scaling or App level automatic scale
resources
| where type =~ "microsoft.insights/autoscalesettings"
| where properties.targetResourceUri contains "microsoft.web/serverfarms"
| project AppServicePlan = split(properties.targetResourceUri, '/')[8], ResourceGroup = split(properties.targetResourceUri, '/')[4]
| project AppServicePlan, ResourceGroup
Stöd för tillgänglighetszoner
Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.
Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans för fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.
Azures tillgänglighetszoner är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa i en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Skapa lösningar med tillgänglighetszoner.
Azure App Service kan distribueras mellan tillgänglighetszoner (AZ) för att hjälpa dig att uppnå återhämtning och tillförlitlighet för dina affärskritiska arbetsbelastningar. Den här arkitekturen kallas även zonredundans.
När du konfigurerar att vara zonredundant sprider plattformen automatiskt instanserna av den Azure App Service planen över tre zoner i den valda regionen. Det innebär att det minsta antalet App Service planinstanser alltid är tre. Om du anger en kapacitet som är större än tre och antalet instanser är delbart med tre sprids instanserna jämnt. Annars sprids antalet instanser utöver 3*N över de återstående en eller två zonerna.
Stöd för tillgänglighetszoner är en egenskap för den App Service planen. App Service planer kan skapas i en hanterad miljö för flera klientorganisationer eller en dedikerad miljö med hjälp av App Service-miljön. Mer information om App Service-miljön finns i översikten över App Service-miljön v3.
För App Services som inte är konfigurerade att vara zonredundanta är vm-instanser inte zontåliga och kan uppleva driftstopp i alla zoner i den regionen.
Information om arkitekturen för företagsdistribution finns i Företagsdistribution med hög tillgänglighet med hjälp av App Service-miljön.
Förutsättningar
De aktuella kraven/begränsningarna för att aktivera tillgänglighetszoner är:
Både Windows och Linux stöds.
Din App Services-plan måste vara ett av följande planer som stöder tillgänglighetszoner:
- I en miljö med flera klientorganisationer med App Service Premium v2- eller Premium v3-abonnemang.
- I en dedikerad miljö med App Service-miljön v3, som används med isolerade v2-App Service planer.
För dedikerade miljöer måste din App Service-miljön vara v3.
Viktigt
App Service-miljön v2 och v1 dras tillbaka den 31 augusti 2024. App Service-miljön v3 är enklare att använda och köra på kraftfullare infrastruktur. Mer information om App Service-miljön v3 finns i App Service-miljön översikt. Om du för närvarande använder App Service-miljön v2 eller v1 och vill uppgradera till v3 följer du stegen i den här artikeln för att migrera till den nya versionen.
Minsta antal instanser av tre zoner framtvingas. Plattformen tillämpar det här minsta antalet i bakgrunden om du anger ett antal instanser som är färre än tre.
Tillgänglighetszoner kan bara anges när du skapar en ny App Service plan. Det går inte att konvertera en befintlig App Service plan för att använda tillgänglighetszoner.
Följande regioner stöder Azure App Services som körs i miljöer med flera klientorganisationer:
- Australien, östra
- Brasilien, södra
- Kanada, centrala
- Indien, centrala
- Central US
- Asien, östra
- East US
- USA, östra 2
- Frankrike, centrala
- Tyskland, västra centrala
- Japan, östra
- Sydkorea, centrala
- Europa, norra
- Norge, östra
- Polen, centrala
- Qatar, centrala
- Sydafrika, norra
- USA, södra centrala
- Sydostasien
- Sverige, centrala
- Schweiz, norra
- Förenade Arabemiraten, norra
- Storbritannien, södra
- Europa, västra
- USA, västra 2
- USA, västra 3
- Microsoft Azure drivs av 21Vianet – Kina, norra 3
- Azure Government - US Gov, Virginia
Information om vilka regioner som stöder tillgänglighetszoner för App Service-miljön v3 finns i Regioner.
Skapa en resurs med tillgänglighetszonen aktiverad
Så här distribuerar du en zonredundant App Service
Om du vill aktivera tillgänglighetszoner med hjälp av Azure CLI inkluderar du parametern --zone-redundant när du skapar din App Service-plan. Du kan också inkludera parametern --number-of-workers för att ange kapacitet. Om du inte anger en kapacitet är plattformen som standard tre. Kapaciteten bör anges baserat på arbetsbelastningskravet, men inte mindre än tre. En bra tumregel för att välja kapacitet är att se till att det finns tillräckligt många instanser för programmet så att förlust av en zon med instanser lämnar tillräckligt med kapacitet för att hantera förväntad belastning.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
Tips
Om du vill bestämma instanskapaciteten kan du använda följande beräkning:
Eftersom plattformen sprider ut 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/(zoner-1) eller 3/2. Om din typiska topparbetsbelastning till exempel kräver fyra instanser bör du etablera sex instanser: (2/3 * 6 instanser) = 4 instanser.
Distribuera en zonredundant App Service med hjälp av en dedikerad miljö
Information om hur du skapar en App Service-miljön v3 i planen Isolerad v2 finns i Skapa en App Service-miljön.
Feltolerans
För att förbereda för fel i tillgänglighetszonen bör du överetablera tjänstens kapacitet för att säkerställa att lösningen kan tolerera 1/3 kapacitetsförlust och fortsätta att fungera utan försämrad prestanda vid zonomfattande avbrott. Eftersom plattformen sprider ut 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/(zoner-1) eller 3/2. Om din typiska topparbetsbelastning till exempel kräver fyra instanser bör du etablera sex instanser: (2/3 * 6 instanser) = 4 instanser.
Zon ned-upplevelse
Trafiken dirigeras till alla dina tillgängliga App Service instanser. Om en zon kraschar identifierar App Service plattform förlorade instanser och försöker automatiskt hitta nya ersättningsinstanser och sprida trafik efter behov. Om du har konfigurerat autoskalning, och om det beslutar att fler instanser behövs, kommer autoskalning också att utfärda en begäran om att App Service för att lägga till fler instanser. Observera att autoskalningsbeteendet är oberoende av App Service plattformsbeteende och att specifikationen för antalet autoskalningsinstanser inte behöver vara en multipel av tre.
Anteckning
Det finns ingen garanti för att begäranden om ytterligare instanser i ett zon ned-scenario lyckas. Tillbakafyllningen av förlorade instanser sker efter bästa förmåga. Den rekommenderade lösningen är att skapa och konfigurera dina App Service planer för att ta hänsyn till att förlora en zon enligt beskrivningen i nästa avsnitt.
Program som distribueras i en App Service plan som har tillgänglighetszoner aktiverade fortsätter att köras och hantera trafik även om andra zoner i samma region drabbas av ett avbrott. Det är dock möjligt att icke-körningsbeteenden som App Service planskalning, programskapande, programkonfiguration och programpublicering fortfarande kan påverkas av ett avbrott i andra Tillgänglighetszoner. Zonredundans för App Service planer garanterar endast fortsatt drifttid för distribuerade program.
När App Service-plattformen allokerar instanser till en zonredundant App Service plan använder den zonutjämning med bästa prestanda som erbjuds av den underliggande Azure-Virtual Machine Scale Sets. 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 plan.
Migrering av tillgänglighetszon
Du kan inte migrera befintliga App Service-instanser eller miljöresurser från stöd för icke-tillgänglighetszoner till stöd för tillgänglighetszoner. För att få stöd för tillgänglighetszoner måste du skapa resurser med tillgänglighetszoner aktiverade.
Prissättning
Det tillkommer ingen extra kostnad för att aktivera tillgänglighetszoner. Prissättningen för en zonredundant App Service är samma som en enda zon App Service. 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. Prisinformation för App Service-miljön v3 finns i Priser.