Haveriberedskap och geo-distribution i Durable Functions

Microsoft strävar efter att säkerställa att Azure-tjänster alltid är tillgängliga. Oplanerade tjänststopp kan dock inträffa. När programmet kräver återhämtning bör du konfigurera appen för geo-redundans.

Du bör också ha en haveriberedskapsplan för hantering av ett regionalt tjänststopp. En viktig del av en haveriberedskapsplan förbereds för redundansväxling till de sekundära replikerna av både din app och ditt lagringskonto när de primära replikerna blir otillgängliga.

I den här artikeln beskrivs exempelscenarier för att konfigurera haveriberedskap och geo-distribution med hjälp av funktionen Durable Functions i Azure Functions.

Bakgrund

I Durable Functions sparas alla tillstånd i Azure Storage som standard. En aktivitetshubb är en logisk container för Azure Storage-resurser som används för orkestreringar och entiteter. Orchestrator-, aktivitets- och entitetsfunktioner kan bara interagera med varandra när de tillhör samma aktivitetshubb. Den här artikeln refererar till aktivitetshubbar när du beskriver scenarier för att hålla dessa Azure Storage-resurser högtillgängliga.

Orkestreringar och entiteter kan utlösas via klientfunktioner som själva utlöses via HTTP eller någon av de andra Azure Functions-utlösartyper som stöds. Orkestreringar och entiteter kan också utlösas via inbyggda HTTP-API:er. För enkelhetens skull fokuserar den här artikeln på scenarier som omfattar Azure Storage- och HTTP-baserade funktionsutlösare, tillsammans med alternativ för att öka tillgängligheten och minimera stilleståndstiden under haveriberedskap. Den här artikeln beskriver inte uttryckligen andra utlösartyper, till exempel Azure Service Bus- eller Azure Cosmos DB-utlösare.

Scenarierna i den här artikeln baseras på aktiva/passiva konfigurationer, som bäst stöder användningen av Azure Storage. Det här mönstret består av att distribuera en reservfunktionsapp (passiv) till en annan region. Azure Traffic Manager övervakar den primära (aktiva) funktionsappen för HTTP-tillgänglighet. Den redundansväxlar till funktionsappen för säkerhetskopiering när den primära appen misslyckas. Mer information finns i Prioritetstrafikdirigeringsmetod.

Allmänna överväganden

Tänk på följande när du konfigurerar en aktiv/passiv redundanskonfiguration för Durable Functions:

• Vägledningen i den här artikeln förutsätter att du använder Azure Storage-standardprovidern för lagring av Durable Functions-körningstillståndet. Du kan också konfigurera alternativa lagringsproviders som lagrar tillstånd någon annanstans, till exempel i en SQL Server-databas. Alternativa lagringsproviders kan kräva olika strategier för haveriberedskap och geo-distribution. Mer information finns i Durable Functions-lagringsproviders.
• Den föreslagna aktiva/passiva konfigurationen säkerställer att en klient alltid kan utlösa nya orkestreringar via HTTP. Men när två funktionsappar delar samma aktivitetshubb i lagringen kan vissa lagringstransaktioner i bakgrunden distribueras mellan apparna. Som ett resultat av den här fördelningen kan den här konfigurationen resultera i extra utgående kostnader för den sekundära funktionsappen.
• Det underliggande lagringskontot och uppgiftshubben skapas båda i den primära regionen. Funktionsapparna delar det här lagringskontot och uppgiftshubben.
• Alla funktionsappar som är redundant distribuerade måste dela samma funktionsåtkomstnycklar när de aktiveras via HTTP. Azure Functions-körningen exponerar ett hanterings-API som du kan använda för att programmatiskt lägga till, ta bort och uppdatera funktionsnycklar. Du kan också hantera nycklar med hjälp av Azure Resource Manager-API:er.

Scenario 1: Belastningsutjämning av beräkning med delad lagring

För att minska risken för stilleståndstid om funktionsappresurserna blir otillgängliga använder det här scenariot två funktionsappar som distribuerats till olika regioner. Vi rekommenderar det här scenariot som en lösning för redundansväxlingar.

Traffic Manager har konfigurerats för att identifiera problem i den primära funktionsappen och automatiskt omdirigera trafik till funktionsappen i den sekundära regionen. Den här funktionsappen delar samma Azure Storage-konto och aktivitetshubb. Funktionsapparnas tillstånd går inte förlorat och arbetet kan återupptas normalt. När hälsotillståndet har återställts till den primära regionen börjar Azure Traffic Manager dirigera begäranden till funktionsappen automatiskt.

Det finns flera fördelar med att använda det här distributionsscenariot:

• Om beräkningsinfrastrukturen misslyckas kan arbetet återupptas i redundansregionen utan dataförlust.
• Traffic Manager tar hand om den automatiska redundansväxlingen till den felfria funktionsappen.
• Traffic Manager återställer automatiskt trafik till den primära funktionsappen när driftstoppet har upphört.

Scenariospecifika överväganden

• Om du distribuerar funktionsappen med hjälp av en dedikerad Azure App Service-plan ökar kostnaderna om du replikerar beräkningsinfrastrukturen i redundanscentret.

• Det här scenariot omfattar avbrott i beräkningsinfrastrukturen, men lagringskontot fortsätter att vara den enda felpunkten för funktionsappen. Om ett Azure Storage-avbrott inträffar drabbas programmet av stilleståndstid.

• Om funktionsappen redundas ökar svarstiden eftersom appen har åtkomst till sitt lagringskonto mellan regioner.

• När funktionsappen är i redundans kommer den åt lagringstjänsten i den ursprungliga regionen. Utgående nätverkstrafik kan leda till högre kostnader.

• Det här scenariot beror på Traffic Manager. Det kan ta lite tid innan ett klientprogram behöver begära funktionsappens adress från Traffic Manager igen. Mer information finns i Så här fungerar Traffic Manager.

• Från och med version 2.3.0 av Durable Functions-tillägget kan du på ett säkert sätt köra två funktionsappar samtidigt med samma lagringskonto och konfiguration av aktivitetshubben. Den första appen som börjar skaffar ett bloblån på programnivå som förhindrar att andra appar stjäl meddelanden från aktivitetshubbens köer. Om den första appen slutar köras upphör lånet att gälla. En andra app kan hämta lånet och börja bearbeta uppgiftshubbens meddelanden.

  För tilläggsversioner före 2.3.0 bearbetar funktionsappar som är konfigurerade att använda samma lagringskonto meddelanden och uppdaterar lagringsartefakter samtidigt. Den här samtidiga aktiviteten resulterar i högre övergripande svarstider och utgående kostnader. Om de primära apparna och replikapparna någonsin har distribuerat annan kod till dem, även tillfälligt, kan orkestreringarna också misslyckas med att köras korrekt på grund av orkestreringsfunktionens inkonsekvenser i de två apparna.

  Alla appar som kräver geo-distribution för haveriberedskap bör använda version 2.3.0 eller senare av Durable Functions-tillägget.

Scenario 2: Belastningsutjämnad beräkning med regional lagring eller en regional varaktig schemaläggare

Föregående scenario omfattar endast fel som är begränsade till beräkningsinfrastrukturen. Ett avbrott i funktionsappen kan också inträffa när antingen lagringstjänsten eller den varaktiga schemaläggaren misslyckas.

För att säkerställa kontinuerlig drift av Durable Functions distribuerar det andra scenariot ett dedikerat lagringskonto eller en varaktig schemaläggare i varje region där funktionsappar finns. Vi rekommenderar för närvarande den här haveriberedskapsmetoden när du använder en beständig schemaläggare.

Den här metoden ger förbättringar i föregående scenario:

• Isolering av regionalt tillstånd: Varje funktionsapp är länkad till ett eget regionalt lagringskonto eller en beständig schemaläggare. Om funktionsappen misslyckas omdirigerar Traffic Manager trafik till den sekundära regionen. Eftersom funktionsappen i varje region använder sin lokala lagring eller hållbara schemaläggare kan Durable Functions fortsätta bearbetningen med hjälp av det lokala tillståndet.
• Ingen extra svarstid vid redundansväxling: Under en redundansväxling samallokeras en funktionsapp och tillståndsprovider (lagringskonto eller varaktig schemaläggare), så det finns ingen extra svarstid i redundansregionen.
• Motståndskraft mot tillståndsstödfel: Om lagringskontot eller den varaktiga schemaläggaren i en region misslyckas misslyckas Durable Functions i den regionen. Felet med Durable Functions utlöser omdirigering till den sekundära regionen. Eftersom både beräknings- och apptillstånd är isolerade per region förblir Durable Functions i redundansregionen i drift.

Scenariospecifika överväganden

• Om du distribuerar funktionsappen med hjälp av en dedikerad App Service-plan ökar kostnaderna om du replikerar beräkningsinfrastrukturen i redundanscentret.
• Det aktuella tillståndet har inte växlats över. Befintliga orkestreringar och entiteter pausas effektivt och är inte tillgängliga förrän den primära regionen återställs. Om den här kompromissen med att bevara svarstiden och minimera utgående kostnader är acceptabel beror på programmets krav.

Scenario 3: Belastningsutjämningsberäkning med delad GRS

Det här scenariot är en ändring av det första scenariot (implementera ett delat lagringskonto). Den största skillnaden är att lagringskontot skapas med geo-replikering aktiverat.

Det här scenariot ger samma funktionella fördelar som det första scenariot, men det ger även andra fördelar med dataåterställning:

• Geo-redundant lagring (GRS) och grs med läsåtkomst (RA-GRS) maximerar tillgängligheten för ditt lagringskonto.
• Om det uppstår ett regionalt avbrott i Azure Storage-tjänsten kan du manuellt initiera en redundansväxling till den sekundära repliken. Under extrema omständigheter där en region går förlorad på grund av en katastrof kan Microsoft initiera en regional redundansväxling. I det här fallet behöver du inte vidta några åtgärder.
• När en redundansväxling inträffar bevaras tillståndet durable functions upp till den sista replikeringen av lagringskontot. Replikeringen sker vanligtvis med några minuters mellanrum.

Mer information finns i Planering och redundans för Haveriberedskap i Azure Storage.

Scenariospecifika överväganden

• En redundansväxling till repliken kan ta lite tid. Tills redundansväxlingen är klar och Dns-posterna för Azure Storage har uppdaterats fortsätter funktionsappen att vara otillgänglig.
• Det finns en ökad kostnad för att använda geo-replikerade lagringskonton.
• GRS-replikering kopierar dina data asynkront. Vissa av de senaste transaktionerna kan gå förlorade på grund av replikeringsprocessens svarstid.
• Som beskrivs i det första scenariot rekommenderar vi att funktionsappar som distribueras i den här strategin använder version 2.3.0 eller senare av Durable Functions-tillägget.

Nästa steg