Tillförlitlighet i Azure App Service
Den här artikeln beskriver tillförlitlighetsstöd i Azure App Service och beskriver både intraregional återhämtning med tillgänglighetszoner och haveriberedskap mellan regioner och affärskontinuitet. En mer detaljerad översikt över tillförlitlighetsprinciper 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
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?
Stöd för tillgänglighetszon
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 mot 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.
Azure-tillgänglighetszoner-aktiverade tjänster ä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 på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.
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 App Service som zonredundant sprider plattformen automatiskt instanserna av Azure App Service-planen över tre zoner i den valda regionen.
Instansspridning med en zonredundant distribution bestäms i följande regler, även när appen skalar in och ut:
- Det minsta antalet App Service Plan-instanser ä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.
Stöd för tillgänglighetszoner är en egenskap för 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 v3. Mer information om App Service-miljön v3 finns i översikten över App Service-miljön v3.
För App Services som inte är konfigurerade att vara zonredundanta är virtuella datorinstanser inte zontåliga och kan uppleva driftstopp under ett avbrott 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.
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.
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örs 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 tillämpas. Plattformen tillämpar det här minimiantalet i bakgrunden om du anger ett instansantal som är mindre ä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
- Israel, centrala
- Italien, norra
- Japan, östra
- Sydkorea, centrala
- Mexiko, centrala
- Europa, norra
- Norge, östra
- Polen, centrala
- Qatar, centrala
- Sydafrika, norra
- USA, södra centrala
- Sydostasien
- Spanien, centrala
- 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 – USA 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
Distribuera en zonredundant App Service för flera klientorganisationer
Om du vill aktivera tillgänglighetszoner med hjälp av Azure CLI tar du med 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 tillräckligt många instanser för programmet, så att förlora en zon av 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
Dricks
Om du vill bestämma instanskapaciteten kan du använda följande beräkning:
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.
Distribuera en zonredundant App Service med hjälp av en dedikerad miljö
Information om hur du skapar en App Service-miljön v3 på planen Isolerad v2 finns i Skapa en App Service-miljön.
Felsökning
| Felmeddelande | beskrivning | Rekommendation |
|---|---|---|
| Zonredundans är inte tillgängligt för resursgruppen RG-NAME. Distribuera apptjänstplanen ASP-NAME till en ny resursgrupp. | 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 skapar du en ny resursgrupp, App Service-plan och App Service. |
Feltolerans
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.
Zon-ned-upplevelse
Trafiken dirigeras till alla tillgängliga App Service-instanser. Om en zon slutar fungera identifierar App Service-plattformen 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, utfärdar autoskalning också en begäran till App Service om att lägga till fler instanser. Observera att autoskalningsbeteendet är oberoende av App Service-plattformens beteende och att specifikationen för antalet autoskalningsinstanser inte behöver vara en multipel av tre.
Kommentar
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. Den rekommenderade lösningen är att skapa och konfigurera dina App Service-planer för att ta hänsyn till att en zon förloras enligt beskrivningen i nästa avsnitt.
Program som distribueras i en App Service-plan som har tillgänglighetszoner aktiverade fortsätter att köra och hantera trafik även om andra zoner i samma region drabbas av ett avbrott. Det är dock möjligt att icke-körningsbeteenden, inklusive App Service-planskalning, skapande av program, programkonfiguration och programpublicering, fortfarande kan påverkas av ett avbrott i andra Tillgänglighetszoner. Zonredundans för App Service-planer säkerställer 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 möjliga ansträngning som erbjuds av de underliggande Skalningsuppsättningarna för virtuella Azure-datorer. En App Service-plan kommer att "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.
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 dina resurser med tillgänglighetszoner aktiverade.
Prissättning
För miljöer med flera klientorganisationer som 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 instansantal på tre och debiterar dig för dessa tre instanser. App Service-miljön v3 har en annan prismodell för tillgänglighetszoner. Prisinformation för App Service-miljön v3 finns i Priser.
Haveriberedskap och affärskontinuitet mellan regioner
Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.
När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.
Det här avsnittet beskriver några vanliga strategier för webbappar som distribueras till App Service.
När du skapar en webbapp i App Service och väljer en Azure-region när resursen skapas är det en enskild regionapp. När regionen blir otillgänglig under en katastrof blir programmet också otillgängligt. Om du skapar en identisk distribution i en sekundär Azure-region med hjälp av en geografiarkitektur för flera regioner blir ditt program mindre känsligt för en katastrof i en enda region, vilket garanterar affärskontinuitet. Med all datareplikering i regionerna kan du återställa ditt senaste programtillstånd.
För IT drivs affärskontinuitetsplaner till stor del av mål för återställningstid (RTO) och mål för återställningspunkt (RPO). Mer information om RTO och RPO finns i Återställningsmål.
Normalt är det opraktiskt att underhålla ett serviceavtal kring RTO för regionala katastrofer, och du skulle vanligtvis utforma din strategi för haveriberedskap enbart kring RPO (dvs. fokusera på att återställa data och inte på att minimera avbrott). Med Azure är det dock inte bara praktiskt utan kan även vara enkelt att distribuera App Service för automatiska geo-redundansväxlingar. På så sätt kan du katastrofsäkra dina program ytterligare genom att ta hand om både RTO och RPO.
Beroende på dina önskade RTO- och RPO-mått används ofta tre arkitekturer för haveriberedskap för både App Service-multitenanter och App Service-miljön. Varje arkitektur beskrivs i följande tabell:
| Mått | Aktiv-aktiv | Aktiv-passiv | Passiv/kall |
|---|---|---|---|
| RTO | Realtid eller sekunder | Minuter | timmar |
| RPO | Realtid eller sekunder | Minuter | timmar |
| Kostnad | $$$ | $$ | $ |
| Scenarier | Verksamhetskritiska appar | Appar med hög prioritet | Appar med låg prioritet |
| Möjlighet att hantera användartrafik i flera regioner | Ja | Ja/kanske | Nej |
| Distribution av kod | CI/CD-pipelines föredras | CI/CD-pipelines föredras | Säkerhetskopiering och återställning |
| Skapande av nya App Service-resurser under driftstopp | Krävs inte | Krävs inte | Obligatoriskt |
Kommentar
Ditt program beror troligen på andra datatjänster i Azure, till exempel Azure SQL Database- och Azure Storage-konton. Vi rekommenderar att du utvecklar strategier för haveriberedskap även för var och en av dessa beroende Azure-tjänster. Information om SQL Database finns i Aktiv geo-replikering för Azure SQL Database. Information om Azure Storage finns i Redundans för Azure Storage.
Haveriberedskap i geografi för flera regioner
Det finns flera sätt att replikera innehåll och konfigurationer för webbappar i Azure-regioner i en aktiv-aktiv eller aktiv-passiv arkitektur, till exempel att använda säkerhetskopiering och återställning av App Service. Säkerhetskopiering och återställning skapar dock ögonblicksbilder av tidpunkter och leder så småningom till problem med versionshantering av webbappar i olika regioner. Se följande tabell nedan för en jämförelse mellan vägledning för rygg- och återställning jämfört med vägledning för diasteråterställning:
Säkerhetskopiera och återställa jämfört med haveriberedskap
| Plattform | Vägledning för säkerhetskopiering och återställning | Vägledning om haveriberedskap |
|---|---|---|
| App Service-webbappar (Kostnadsfria och delade prisnivåer) |
Om du har webbprogram distribuerade till den kostnadsfria eller delade nivån och kräver åtkomst för att säkerhetskopiera och återställa funktioner för dessa webbappar skalar du upp till Basic-nivån eller högre. | Aktivera App Service-resurser igen i en annan Azure-region under en regional katastrof. Från och med den 31 mars 2025 kommer App Service-program inte att placeras i haveriberedskapsläge under en katastrof i en Azure-region enligt beskrivningen i artikeln återställa från regionomfattande fel . Vi rekommenderar att du implementerar vanliga tekniker för haveriberedskap för att förhindra driftstopp och dataförlust vid en regional katastrof. |
| App Service-webbappar (Prisnivåer för Basic, Standard och Premium) |
I Azure App Service kan du göra anpassade säkerhetskopior på begäran eller använda automatiska säkerhetskopieringar. Du kan återställa en säkerhetskopia genom att skriva över en befintlig app eller genom att återställa till en ny app eller ett nytt fack. Mer information finns i Säkerhetskopiera och återställa din app i Azure App Service. |
Den aktuella vägledningen om hur du ansluter App Service-resurser i en annan Azure-region under ett regionalt haveri finns i Återställ från regionomfattande fel – Azure App Service. Från och med den 31 mars 2025 kommer Azure App Service-webbprogram inte längre att placeras i haveriberedskapsläge under en katastrof i en Azure-region enligt beskrivningen i artikeln återställa från regionomfattande fel . Vi rekommenderar att du implementerar vanliga metoder för haveriberedskap för att förhindra förlust av funktioner eller data för dina webbappar om det uppstår en regional katastrof. |
| App Service-miljön (V2 och V3) | I Azure App Service-miljön kan du göra anpassade säkerhetskopior på begäran eller använda automatiska säkerhetskopieringar. Automatiska säkerhetskopieringar kan återställas till en målapp inom samma App Service-miljön, inte i en annan App Service-miljön. Anpassade säkerhetskopior kan återställas till en målapp i en annan App Service-miljön (till exempel från en V2-App Service-miljön till en V3-App Service-miljön). Säkerhetskopior kan återställas till en målapp för samma OS-plattform som källappen. Mer information finns i Säkerhetskopiera och återställa din app i Azure App Service. |
Vi rekommenderar att du implementerar riktlinjer för haveriberedskap för webbappar som distribueras till App Service-miljön med hjälp av vanliga tekniker för haveriberedskap. |
| Azure Functions: Dedikerad plan |
När du kör funktionsappen i en dedikerad (App Service)-plan underhålls det nödvändiga funktionsappinnehållet med inbyggd lagring. I en dedikerad plan kan du göra anpassade säkerhetskopior på begäran eller använda automatiska säkerhetskopior. Du kan återställa en säkerhetskopia genom att skriva över en befintlig app eller genom att återställa till en ny app eller ett nytt fack. Mer information finns i Säkerhetskopiera och återställa din app i Azure App Service. Azure Files används inte av en dedikerad plan, men om du har konfigurerat appen fel med en Azure Files-anslutning stöds inte säkerhetskopiering. |
Aktuell vägledning om hur du ansluter funktionsappresurser i en dedikerad plan igen i en annan Azure-region under ett regionalt haveri finns i Återställ från regionomfattande fel – Azure App Service. Från och med den 31 mars 2025 kommer App Service-program inte att placeras i haveriberedskapsläge under en katastrof i en Azure-region enligt beskrivningen i artikeln återställa från regionomfattande fel . Du bör i stället planera för tillförlitlighet i dina funktionsappar. Du kan också referera till vanliga haveriberedskapstekniker för funktionsappar i en dedikerad plan. |
| Azure Functions: Flexförbrukning, Förbrukning och Premium-planer |
Funktionsappar som körs i en Flex Consumption-plan, i en förbrukningsplan eller i en Premium-plan kan inte använda anpassade eller automatiska säkerhetskopieringsfunktioner i App Service. I dessa planer för dynamisk skalning underhålls funktionsappens innehåll i Azure Storage. Använd redundansalternativ för Azure Storage för att säkerställa att ditt lagringskonto uppfyller sina tillgänglighets- och hållbarhetsmål under ett avbrott. Du kan också ladda ned ditt befintliga funktionsappsprojekt som en .zip fil från Azure Portal. |
Vi rekommenderar starkt att du planerar för tillförlitlighet i dina funktionsappar. |
För att undvika begränsningarna för säkerhetskopierings- och återställningsmetoder konfigurerar du DINA CI/CD-pipelines för att distribuera kod till båda Azure-regionerna. Överväg att använda Azure Pipelines eller GitHub Actions. Mer information finns i Kontinuerlig distribution till Azure App Service.
Identifiering, avisering och hantering av avbrott
Vi rekommenderar att du konfigurerar övervakning och aviseringar för dina webbappar för att få meddelanden i tid under en katastrof. Mer information finns i Application Insights-tillgänglighetstester.
Om du vill hantera dina programresurser i Azure använder du en IaC-mekanism (infrastructure-as-Code). I en komplex distribution i flera regioner krävs en förutsägbar, testbar och repeterbar process för att hantera regionerna oberoende av varandra och för att hålla konfigurationen synkroniserad mellan regioner på ett tillförlitligt sätt. Överväg ett IaC-verktyg som Azure Resource Manager-mallar eller Terraform.
Konfigurera haveriberedskap och avbrottsidentifiering
För att förbereda för haveriberedskap i ett geografiskt område i flera regioner kan du använda antingen en aktiv-aktiv eller aktiv-passiv arkitektur.
Active-Active-arkitektur
I aktiv-aktiv haveriberedskapsarkitektur distribueras identiska webbappar i två separata regioner och Azure Front Door används för att dirigera trafik till båda de aktiva regionerna.
Med den här exempelarkitekturen:
- Identiska App Service-appar distribueras i två separata regioner, inklusive prisnivå och antal instanser.
- Offentlig trafik direkt till App Service-apparna blockeras.
- Azure Front Door används för att dirigera trafik till båda de aktiva regionerna.
- Under en katastrof blir en av regionerna offline och Azure Front Door dirigerar trafik exklusivt till den region som förblir online. RTO under en sådan geo-redundans är nära noll.
- Programfiler bör distribueras till båda webbapparna med en CI/CD-lösning. Detta säkerställer att RPO är praktiskt taget noll.
- Om ditt program aktivt ändrar filsystemet är det bästa sättet att minimera RPO att bara skriva till en monterad Azure Storage-resurs i stället för att skriva direkt till webbappens /heminnehållsresurs. Använd sedan Azure Storage-redundansfunktionerna (GZRS eller GRS) för din monterade resurs, som har ett RPO på cirka 15 minuter.
Steg för att skapa en aktiv-aktiv arkitektur för webbappen i App Service sammanfattas på följande sätt:
Skapa två App Service-planer i två olika Azure-regioner. Konfigurera de två App Service-planerna på samma sätt.
Skapa två instanser av din webbapp, med en i varje App Service-plan.
Skapa en Azure Front Door-profil med:
- En slutpunkt.
- Två ursprungsgrupper, var och en med prioriteten 1. Samma prioritet talar om för Azure Front Door att dirigera trafik till båda regionerna på samma sätt (därmed aktiv-aktiv).
- En väg.
Begränsa nätverkstrafiken till webbapparna endast från Azure Front Door-instansen.
Konfigurera och konfigurera alla andra serverdelstjänst i Azure, till exempel databaser, lagringskonton och autentiseringsproviders.
Distribuera kod till båda webbapparna med kontinuerlig distribution.
Självstudie: Skapa en app för flera regioner med hög tillgänglighet i Azure App Service som visar hur du konfigurerar en aktiv-passiv arkitektur. Samma steg med minimala ändringar (att ange prioritet till "1" för båda ursprungen i ursprungsgruppen i Azure Front Door) ger dig en aktiv-aktiv arkitektur.
Aktiv-passiv arkitektur
I den här haveriberedskapsmetoden distribueras identiska webbappar i två separata regioner och Azure Front Door används endast för att dirigera trafik till en region (den aktiva regionen).
Med den här exempelarkitekturen:
Identiska App Service-appar distribueras i två separata regioner.
Offentlig trafik direkt till App Service-apparna blockeras.
Azure Front Door används för att dirigera trafik till den primära regionen.
För att spara kostnader är den sekundära App Service-planen konfigurerad för att ha färre instanser och/eller ligga på en lägre prisnivå. Det finns tre möjliga metoder:
Föredraget Den sekundära App Service-planen har samma prisnivå som den primära, med samma antal instanser eller färre. Den här metoden säkerställer paritet i både funktions- och VM-storleksändring för de två App Service-planerna. RTO under en geo-redundans beror bara på tiden för att skala ut instanserna.
Mindre prioriterat Den sekundära App Service-planen har samma prisnivåtyp (till exempel PremiumV3) men mindre storlek på virtuella datorer, med mindre instanser. Den primära regionen kan till exempel finnas på P3V3-nivån medan den sekundära regionen finns på P1V3-nivån. Den här metoden säkerställer fortfarande funktionsparitet för de två App Service-planerna, men bristen på storleksparitet kan kräva en manuell uppskalning när den sekundära regionen blir den aktiva regionen. RTO under en geo-redundans beror på tiden för att både skala upp och skala ut instanserna.
Minst föredragen Den sekundära App Service-planen har en annan prisnivå än de primära och mindre instanserna. Den primära regionen kan till exempel finnas på P3V3-nivån medan den sekundära regionen är på S1-nivå. Kontrollera att den sekundära App Service-planen har alla funktioner som programmet behöver för att kunna köras. Skillnader i funktionstillgänglighet mellan de två kan orsaka fördröjningar i webbappens återställning. RTO under en geo-redundans beror på tiden för att både skala upp och skala ut instanserna.
Autoskalning konfigureras på den sekundära regionen om den aktiva regionen blir inaktiv. Det är lämpligt att ha liknande regler för autoskalning i både aktiva och passiva regioner.
Under en katastrof blir den primära regionen inaktiv och den sekundära regionen börjar ta emot trafik och blir den aktiva regionen.
När den sekundära regionen blir aktiv utlöser nätverksbelastningen förkonfigurerade autoskalningsregler för att skala ut den sekundära webbappen.
Du kan behöva skala upp prisnivån för den sekundära regionen manuellt om den inte redan har de funktioner som krävs för att köras som den aktiva regionen. Automatisk skalning kräver till exempel standardnivå eller högre.
När den primära regionen är aktiv igen dirigerar Azure Front Door automatiskt trafiken tillbaka till den och arkitekturen är tillbaka till aktiv-passiv som tidigare.
Programfiler bör distribueras till båda webbapparna med en CI/CD-lösning. Detta säkerställer att RPO är praktiskt taget noll.
Om ditt program aktivt ändrar filsystemet är det bästa sättet att minimera RPO att bara skriva till en monterad Azure Storage-resurs i stället för att skriva direkt till webbappens /heminnehållsresurs. Använd sedan Azure Storage-redundansfunktionerna (GZRS eller GRS) för din monterade resurs, som har ett RPO på cirka 15 minuter.
Stegen för att skapa en aktiv-passiv arkitektur för webbappen i App Service sammanfattas på följande sätt:
- Skapa två App Service-planer i två olika Azure-regioner. Den sekundära App Service-planen kan etableras med någon av de metoder som nämnts tidigare.
- Konfigurera regler för automatisk skalning för den sekundära App Service-planen så att den skalas till samma instansantal som den primära när den primära regionen blir inaktiv.
- Skapa två instanser av din webbapp, med en i varje App Service-plan.
- Skapa en Azure Front Door-profil med:
- En slutpunkt.
- En ursprungsgrupp med prioriteten 1 för den primära regionen.
- En andra ursprungsgrupp med prioriteten 2 för den sekundära regionen. Skillnaden i prioritet gör att Azure Front Door föredrar den primära regionen när den är online (alltså aktiv-passiv).
- En väg.
- Begränsa nätverkstrafiken till webbapparna endast från Azure Front Door-instansen.
- Konfigurera och konfigurera alla andra serverdelstjänst i Azure, till exempel databaser, lagringskonton och autentiseringsproviders.
- Distribuera kod till båda webbapparna med kontinuerlig distribution.
Självstudie: Skapa en app för flera regioner med hög tillgänglighet i Azure App Service som visar hur du konfigurerar en aktiv-passiv arkitektur.
Passiv-kall arkitektur
Använd en passiv/kall arkitektur för att skapa och underhålla regelbundna säkerhetskopior av dina webbappar i ett Azure Storage-konto som finns i en annan region.
Med den här exempelarkitekturen:
En enskild webbapp distribueras till en enda region.
Webbappen säkerhetskopieras regelbundet till ett Azure Storage-konto i samma region.
Replikering mellan regioner av dina säkerhetskopior beror på konfigurationen av dataredundans i Azure Storage-kontot. Du bör ange ditt Azure Storage-konto som GZRS om möjligt. GZRS erbjuder både synkron zonredundans inom en region och asynkron i en sekundär region. Om GZRS inte är tillgängligt konfigurerar du kontot som GRS. Både GZRS och GRS har ett RPO på cirka 15 minuter.
För att säkerställa att du kan hämta säkerhetskopior när lagringskontots primära region blir otillgänglig aktiverar du skrivskyddad åtkomst till den sekundära regionen (vilket gör lagringskontot RA-GZRS respektive RA-GRS). Mer information om hur du utformar dina program för att dra nytta av geo-redundans finns i Använda geo-redundans för att utforma program med hög tillgänglighet.
Vid en katastrof i webbappens region måste du manuellt distribuera alla nödvändiga App Service-beroende resurser med hjälp av säkerhetskopiorna från Azure Storage-kontot, troligen från den sekundära regionen med läsåtkomst. RTO kan vara timmar eller dagar.
För att minimera RTO rekommenderar vi starkt att du har en omfattande spelbok som beskriver alla steg som krävs för att återställa säkerhetskopieringen av webbappen till en annan Azure-region.
Stegen för att skapa en passiv-kall region för webbappen i App Service sammanfattas på följande sätt:
Skapa ett Azure Storage-konto i samma region som din webbapp. Välj Standardprestandanivå och välj redundans som Geo-redundant lagring (GRS) eller Geo-Zone-redundant lagring (GZRS).
Aktivera RA-GRS eller RA-GZRS (läsåtkomst för den sekundära regionen).
Konfigurera anpassad säkerhetskopiering för webbappen. Du kan välja att ange ett schema för säkerhetskopieringar av webbappar, till exempel varje timme.
Kontrollera att säkerhetskopieringsfilerna för webbappen kan hämtas den sekundära regionen för ditt lagringskonto.
Dricks
Förutom Azure Front Door tillhandahåller Azure andra alternativ för belastningsutjämning, till exempel Azure Traffic Manager. En jämförelse av de olika alternativen finns i Alternativ för belastningsutjämning – Azure Architecture Center.
Haveriberedskap i geografi för en region
Om webbappens region inte har GZRS- eller GRS-lagring eller om du befinner dig i en Azure-region som inte är ett av ett regionalt par måste du använda zonredundant lagring (ZRS) eller lokalt redundant lagring (LRS) för att skapa en liknande arkitektur. Du kan till exempel manuellt skapa en sekundär region för lagringskontot på följande sätt:
Steg för att skapa en passiv-kall region utan GRS och GZRS sammanfattas på följande sätt:
Skapa ett Azure Storage-konto i samma region i webbappen. Välj Standard-prestandanivå och välj redundans som zonredundant lagring (ZRS).
Konfigurera anpassad säkerhetskopiering för webbappen. Du kan välja att ange ett schema för säkerhetskopieringar av webbappar, till exempel varje timme.
Kontrollera att säkerhetskopieringsfilerna för webbappen kan hämtas den sekundära regionen för ditt lagringskonto.
Skapa ett andra Azure-lagringskonto i en annan region. Välj Standard-prestandanivå och välj redundans som lokalt redundant lagring (LRS).
Genom att använda ett verktyg som AzCopy replikerar du din anpassade säkerhetskopia (Zip, XML och loggfiler) från den primära regionen till den sekundära lagringen. Till exempel:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'Du kan använda Azure Automation med en PowerShell Workflow-runbook för att köra replikeringsskriptet enligt ett schema. Kontrollera att replikeringsschemat följer ett liknande schema som säkerhetskopieringarna av webbappen.