Dela via

AppTjänst-appmetoder för flera regioner för haveriberedskap

Azure App Service
Azure Front Door

När du distribuerar en Azure App Service-webbapp till en enda region som på grund av haveri eller avbrott blir otillgänglig riskerar du att programmet blir otillgängligt. För att säkerställa att programmet fortsätter att vara tillgängligt när regionen inte är tillgänglig kan du implementera en arkitektur för flera regioner. Med en arkitektur för flera regioner skapar du en identisk distribution i en sekundär Azure-region. Med en distribution i en sekundär region kan du replikera dina data för att återställa det senaste programtillståndet. och kan även replikera andra lösningskomponenter.

Den här artikeln beskriver tre arkitekturmetoder i flera regioner som ofta används för både App Service och App Service-miljön.

Metoder att tänka på

Affärskontinuitetsplaner påverkas av två viktiga mått:

  • Mål för återställningstid (RTO), vilket är den maximala tolerabla stilleståndstiden under en katastrof.
  • Mål för återställningspunkt (RPO), vilket är den maximala tillåtna dataförlusten under en katastrof.

Mer information om återställningsmål som RTO och RPO finns i Återställningsmål och rekommendationer för att definiera tillförlitlighetsmål.

Med Azure-plattformen kan du utforma programlösningar för flera regioner på olika sätt. Den här artikeln beskriver arkitekturer som stöder olika RTO- och RPO-krav och har andra kompromisser för kostnader och komplexitet:

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 Nej 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

De tre metoderna som beskrivs här är vanliga, men de är inte det enda sättet att uppnå en lösning för flera regioner i Azure. Anpassa lösningarna så att de uppfyller dina egna krav.

Kommentar

Ditt program beror troligen på andra tjänster i Azure, till exempel Azure SQL Database, Azure Storage-konton och meddelandeköer. När du utformar en strategi för haveriberedskap måste du även tänka på var och en av dessa beroende Azure-tjänster.

Mer information om lösningar i flera regioner för Azure-tjänster finns i tillförlitlighetsguider för Azure-tjänster.

Övervakning

Det är viktigt att du konfigurerar övervakning och aviseringar för dina webbappar så att ditt team får meddelanden i tid under ett regionfel. Azure Application Insights-tillgänglighetstester är ett sätt att övervaka ett programs tillgänglighet. Mer information finns i Application Insights-tillgänglighetstester.

Distribution

Lösningar för flera regioner kan vara komplexa att distribuera och konfigurera. Det är viktigt att instanser i varje region hålls synkroniserade.

Om du vill hantera distributionen och konfigurationen av Azure-resurser som App Service 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 Bicep, Azure Resource Manager-mallar eller Terraform.

Du bör också konfigurera DINA CI/CD-pipelines för att distribuera koden, inklusive när du använder flera regioner. Överväg att använda Azure Pipelines eller GitHub Actions. Mer information finns i Kontinuerlig distribution till Azure App Service.

Aktiv-aktiv arkitektur

I en aktiv-aktiv arkitektur distribueras identiska webbappar i två separata regioner. Azure Front Door används för att dirigera trafik till båda de aktiva regionerna:

Diagram som visar en aktiv-aktiv distribution av App Service.

Varje regions App Service-program använder samma konfiguration, inklusive prisnivå och antal instanser.

Under normal drift blockeras den offentliga trafiken direkt till App Service-appen. Trafiken dirigeras i stället via Azure Front Door till båda de aktiva regionerna. Den här metoden hjälper dig att se till att begäranden inspekteras av Brandväggen för Azure Front Door-webbprogram (WAF) eller att de på annat sätt skyddas eller hanteras centralt.

Om en av regionerna går offline under ett regionfel identifierar Azure Front Door-hälsoavsökningarna det felaktiga ursprunget och konfigurerar om vägarna så att trafiken skickas exklusivt till den region som förblir online.

Under en felaktig regionåterställning (återställning efter fel) identifierar Azure Front Door-hälsoavsökningarna det felfria ursprunget och återställer normal trafikroutning.

Rekommendationer

  • Om du vill uppfylla ett RPO på noll för programinnehåll använder du en CI/CD-lösning för att distribuera programfiler till båda webbapparna.

  • Lagra om möjligt programtillstånd utanför App Service-filsystemet, till exempel i en databas eller Azure Storage. Konfigurera dessa komponenter så att de uppfyller dina geo-redundanskrav.

    Dricks

    Om ditt program aktivt ändrar filsystemet och App Service-appregionen har en länkad region kan du minska RPO för filsystemet genom att 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.

Att tänka på

  • Låg RTO: RTO under en sådan geo-redundans beror på hur snart hälsoavsökningarna identifierar den felaktiga regionen. Som standard kontrollerar avsökningar var 30:e sekund, men du kan konfigurera en annan avsökningsfrekvens.

  • Belastningsutjämning och redundansväxling: Den här metoden använder Azure Front Door för global belastningsutjämning, trafikdistribution och redundans. Azure tillhandahåller 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.

Distribuera aktiva App Service-webbappar

Följ de här stegen för att skapa en aktiv-aktiv metod för dina webbappar med hjälp av App Service:

  1. Skapa två App Service-planer i två olika Azure-regioner. Konfigurera de två App Service-abonnemangen på samma sätt.

  2. Skapa två instanser av din webbapp, med en i varje App Service-plan.

  3. Skapa en Azure Front Door-profil med:

    • En slutpunkt.
    • En ursprungsgrupp med två ursprung, var och en med prioriteten 1. Värdena för lika prioritet instruerar Azure Front Door att dirigera trafik till programmen i båda regionerna på samma sätt (aktiv-aktiv).
    • En väg.

  4. Begränsa nätverkstrafiken till webbapparna endast från Azure Front Door-instansen.

  5. Konfigurera alla andra azure-tjänster på serverdelen, till exempel databaser, lagringskonton och autentiseringsproviders.

  6. Distribuera kod till båda webbapparna med kontinuerlig distribution.

Självstudien Skapa en app med hög tillgänglighet för flera regioner i Azure App Service visar hur du konfigurerar en aktiv-passiv arkitektur. Om du vill distribuera en aktiv-aktiv-metod följer du samma steg, men med ett undantag: I Azure Front Door konfigurerar du båda ursprungen i ursprungsgruppen så att de har prioriteten 1.

Aktiv-passiv arkitektur

I en aktiv-passiv arkitektur distribueras identiska webbappar i två separata regioner. Azure Front Door används för att dirigera trafik till endast en region (den aktiva regionen).

Ett diagram som visar en aktiv-passiv arkitektur i Azure App Service.

Under normal drift dirigerar Azure Front Door endast trafik till den primära regionen. Offentlig trafik direkt till App Service-apparna blockeras.

Om den primära regionen blir inaktiv under ett regionfel identifierar Azure Front Door-hälsoavsökningar det felaktiga ursprunget och påbörjar trafikroutning till ursprunget i den sekundära regionen. Den sekundära regionen blir sedan 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.

Under en felaktig regionåterställning (återställning efter fel) dirigerar Azure Front Door automatiskt trafiken tillbaka till den primära regionen och arkitekturen är tillbaka till aktiv-passiv som tidigare.

Kommentar

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.

Rekommendationer

  • Om du vill uppfylla ett RPO på noll för programinnehåll använder du en CI/CD-lösning för att distribuera programfiler till båda webbapparna.

  • Lagra om möjligt programtillstånd utanför App Service-filsystemet, till exempel i en databas eller Azure Storage. Konfigurera dessa komponenter så att de uppfyller dina geo-redundanskrav.

    Dricks

    Om ditt program aktivt ändrar filsystemet och App Service-appregionen har en länkad region kan du minska RPO för filsystemet genom att 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.

Att tänka på

  • Kostnadskontroller: Identiska App Service-appar distribueras i två separata regioner. 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:

    • Prioriterat: 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 prioriterad: 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 bör konfigureras i den sekundära regionen om trafiken omdirigeras och det sker en plötslig tillströmning av begäranden. Det är lämpligt att ha liknande regler för autoskalning i både aktiva och passiva regioner.

  • Belastningsutjämning och redundansväxling: Den här metoden använder Azure Front Door för global belastningsutjämning, trafikdistribution och redundans. Azure tillhandahåller 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.

Distribuera aktiv-passiva App Service-webbappar

Följ de här stegen för att skapa en aktiv-passiv metod för dina webbappar med hjälp av App Service:

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

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

  3. Skapa två instanser av din webbapp, med en i varje App Service-plan.

  4. Skapa en Azure Front Door-profil med:

    • En slutpunkt.

    • En ursprungsgrupp med två ursprung:

      • Ett ursprung med prioriteten 1 för programmet i den primära regionen.
      • Ett andra ursprung med prioriteten 2 för programmet i 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.

  5. Begränsa nätverkstrafiken till webbapparna endast från Azure Front Door-instansen.

  6. Konfigurera alla andra azure-tjänster på serverdelen, till exempel databaser, lagringskonton och autentiseringsproviders.

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

I en passiv/kall arkitektur distribueras webbappen till en enda primär region. Programfiler och vissa databaser säkerhetskopieras till ett Azure Storage-konto. Säkerhetskopior replikeras till en annan region. Om den primära regionen inte är tillgänglig distribuerar du manuellt en annan app till en andra region och återställer från säkerhetskopian.

Kommentar

Passiv-kalla metoder förlitar sig på manuella åtgärder vid ett regionfel och resulterar ofta i betydande driftstopp och dataförlust. För de flesta lösningar i produktionsklass bör du överväga en aktiv-aktiv eller aktiv-passiv lösning.

Replikering mellan regioner

Den här metoden använder App Service-säkerhetskopiering för att regelbundet säkerhetskopiera webbappen till ett Azure Storage-konto i samma region. Du konfigurerar replikering mellan regioner av dina säkerhetskopior genom att konfigurera lagringskontot.

Vilken metod du använder för att konfigurera replikering mellan regioner beror på om din region har ett par. Mer information finns i Azure-kopplade regioner och regioner med tillgänglighetszoner och inget regionpar.

Använd RA-GZRS-replikering om den är tillgänglig. RA-GZRS erbjuder både synkron zonredundans inom en region och asynkron i en sekundär region. Det ger också skrivskyddad åtkomst inom den sekundära regionen, vilket är viktigt för att säkerställa att du kan hämta säkerhetskopior när lagringskontots primära region blir otillgänglig.

Om RA-GZRS inte är tillgängligt konfigurerar du kontot som RA-GRS.

Både RA-GZRS och RA-GRS har en RPO på cirka 15 minuter.

Mer information om hur du utformar dina program för att dra nytta av geo-redundant lagring finns i Använda geo-redundans för att utforma program med hög tillgänglighet.

Region-down-upplevelse

Om den primära regionen inte är tillgänglig måste du identifiera regionförlusten. Mer information finns i Övervakning.

Om du vill förbereda den sekundära regionen för att ta emot trafik distribuerar du alla nödvändiga App Service-resurser och beroende resurser med hjälp av säkerhetskopiorna från Azure Storage-kontot i din sekundära region.

Att tänka på

  • Hög RTO: Eftersom den här processen kräver manuell identifiering och svar kan RTO för det här scenariot vara timmar eller till och med dagar. För att minimera din RTO skapar och testar du en omfattande spelbok som beskriver alla steg som krävs för att återställa säkerhetskopieringen av webbappen till en annan Azure-region.

    Även när du har skapat ditt program i den sekundära regionen kan du behöva hantera komplexiteter som DNS-poster och TLS-certifikat. Se till att du har planerat varje steg som krävs för att skicka trafik till din sekundära region och testa dina planer regelbundet.

  • Hög RPO: Säkerhetskopieringar kan schemaläggas till upp till en gång per timme. Om ditt primära program går offline kan säkerhetskopieringen som du återställer till en sekundär region vara inaktuell. Ditt RPO beror på frekvensen för dina säkerhetskopior samt hur snabbt dessa säkerhetskopior replikeras mellan regioner.

Anvisningar

Vilka steg du använder för att konfigurera en passiv-kall distribution beror på om din region har ett par. Mer information finns i Azure-kopplade regioner och regioner med tillgänglighetszoner och inget regionpar.

Stegen för att skapa en passiv-kall region för webbappen i App Service är följande:

  1. Skapa ett Azure Storage-konto i samma region som din webbapp. Välj Standard-prestandanivå och välj redundans som geo-redundant lagring (GRS) eller geo-zonredundant lagring (GZRS).

  2. Aktivera RA-GRS eller RA-GZRS (läsåtkomst för den sekundära regionen).

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

  4. Kontrollera att säkerhetskopieringsfilerna för webbappen kan hämtas i den sekundära regionen för ditt lagringskonto.

Nästa steg

Granska Referensarkitekturer för Azure App Service: