Dela via

Tillförlitlighet i Azure Functions

Azure Functions är en händelsedriven beräkningstjänst som gör att du kan köra små kodblock (funktioner) utan att uttryckligen behöva etablera eller hantera infrastruktur. Funktioner kan svara på händelser som HTTP-begäranden, timers, kömeddelanden och ändringar i andra Azure-tjänster, vilket gör det lämpligt för att bearbeta data, integrera system och köra bakgrundsuppgifter.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur du gör Azure Functions motståndskraftigt mot olika potentiella avbrott och problem, inklusive tillfälliga fel, fel i tillgänglighetszonen och regionomfattande fel. Den visar också viktig information om serviceavtalet för Azure Functions (SLA).

Rekommendationer för produktionsdistribution

Azure Well-Architected Framework ger rekommendationer om tillförlitlighet, prestanda, säkerhet, kostnad och åtgärder. Information om hur dessa områden påverkar varandra och bidrar till en tillförlitlig Azure Functions-lösning finns i Metodtips för arkitektur för Azure Functions.

Översikt över tillförlitlighetsarkitektur

När du distribuerar Azure Functions är det viktigt att känna till flera begrepp:

  • Värdplaner: Planer representerar värdmiljön för dina funktionsappar. Planen avgör vilka beräkningsresurser som är tillgängliga, prismodellen och skalningsbeteendet.

  • Lagringskonton: När du skapar en funktionsapp måste du ange ett värdlagringskonto. Lagringskontot används för att hantera aspekter av funktionsappens interna åtgärder, inklusive lagring av funktionskod, loggning och samtidighetshantering (till exempel bloblån för vissa utlösartyper).

    Du kan också använda ett lagringskonto för distribution. Det här lagringskontot kan vara detsamma som värdlagringskontot eller ett annat lagringskonto.

    Viktigt!

    Lagringskontona är viktiga delar av din tillförlitlighetsarkitektur för Azure Functions och du bör konfigurera dem så att de uppfyller funktionsappens återhämtningskrav.

  • Utlösare och bindningar: Med dessa kan din funktion svara på händelser, ta emot och skriva data från andra tjänster.

  • Durable Functions: Varaktiga funktioner är tillståndskänsliga funktioner, inklusive långvariga orkestreringar och tillståndskänsliga entiteter.

    När du använder Durable Functions konfigurerar du en lagringsprovider som lagrar tillståndet. Du måste utvärdera tillförlitlighetsegenskaperna för det tillståndslager du väljer och konfigurera det så att det uppfyller dina återhämtningskrav.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

Överväg följande rekommendationer för hantering av tillfälliga fel i funktionsapparna:

  • Utlösare och bindningar: Azure Functions-plattformen innehåller inbyggd tillfällig felhantering för många utlösare och bindningar. När ett tillfälligt fel inträffar när en utlösare som stöds utlöses eller en bindning som stöds läser eller skriver data, kan plattformen automatiskt försöka utföra åtgärden igen. Det här inbyggda återförsöksbeteendet hjälper till att säkerställa att tillfälliga anslutningsproblem eller tjänstblips inte hindrar din funktion från att köras. Mer information finns i Felhantering och återförsök i Azure Functions.

    Det här skyddet omfattar dock endast tillfälliga fel. Beständiga fel, till exempel en felkonfigurerad anslutningssträng eller en borttagen resurs, görs inte på nytt.

    Beständiga fel och upprepade tillfälliga fel behandlas som fel och du kan konfigurera loggning för att samla in information om funktionskörningsfel. Mer information finns i Konfigurera övervakning för Azure Functions.

  • Din funktionskod: I din funktions brödtext ansvarar du för att hantera tillfälliga fel när du gör anrop till externa tjänster. Du bör implementera mönster för omprövningslogik, tidsgränser och kretsbrytare efter behov för eventuella externa tjänstanrop som görs i funktionskoden. Utforma dina funktioner så att de är idempotenta där det är möjligt, så att återförsök inte orsakar dubbletter av bieffekter.

  • Klienter: Alla klientprogram som ansluter till funktioner synkront, till exempel med hjälp av en HTTP-anslutning, bör vara motståndskraftiga mot tillfälliga fel.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Förbrukningsplaner stöder inte tillgänglighetszoner. Om zonredundans är ett krav för din arbetsbelastning bör du överväga att använda plantyperna Flex Consumption plan, Premium-plan eller Dedikerad (App Service).

Flex Consumption-planer stöder zonredundanta distributioner.

Premium-planer stöder zonredundanta distributioner.

När zonredundans är aktiverat sprider plattformen automatiskt dina planinstanser över alla tillgänglighetszoner i den valda regionen. Om någon tillgänglighetszon i regionen har problem fortsätter dina funktioner att köras med hjälp av instanser i felfria zoner.

Du måste också aktivera zonredundant lagring (ZRS) på värdlagringskontot, vilket säkerställer att det även är motståndskraftigt mot zonfel.

Diagram som visar zonredundant Azure Functions-plan med tre instanser spridda över tre zoner och ett zonredundant lagringskonto.

Den dedikerade planen (App Service) stöder zonredundanta distributioner. När zonredundans är aktiverat sprider plattformen automatiskt dina instanser över alla tillgänglighetszoner i den valda regionen. Du konfigurerar zonredundans för planen. Fullständig information om hur App Service hanterar zonredundans finns i Tillförlitlighet i Azure App Service.

Om du inte aktiverar zonredundans är planen icke-zonindelad eller regional, vilket innebär att planinstanser kan placeras i valfri tillgänglighetszon i regionen eller inom samma zon, och de är inte motståndskraftiga mot fel i tillgänglighetszonen. Din plan kan uppleva driftstopp under ett avbrott i valfri zon i regionen.

Requirements

  • Regionstöd: Zonredundanta Flex Consumption-planer kan distribueras till en specifik uppsättning regioner. Du kan hämta den aktuella listan över regioner som stöds med hjälp av Azure CLI. Mer information finns i Visa regioner som stöder tillgänglighetszoner.

  • Regionstöd: Zonredundanta Premium-planer kan distribueras till följande regioner:

    Amerika Europa Mellanöstern Africa Asia Pacific
    Syd-Brasilien Frankrike Centrala Israel Centrala Sydafrika Nord Australia East
    Canada Central Tyskland Västcentrala Qatar Central Centralindien
    Central US Italy North UAE North Norra Kina 3
    East US North Europe Östasien
    Östra USA 2 Norway East Japan Öst
    Södra Centrala USA Centrala Sverige Sydostasien
    Västra USA 2 Switzerland North
    Västra USA 3 UK South
    West Europe

  • Operativsystem: Både Windows- och Linux-planer stöds.

  • Minsta antal instanser: Minst två alltid redo instanser krävs när zonredundans är aktiverat för Premium-planer.

  • Värdlagringskonto: Du måste konfigurera funktionsappens standardkonto för värdlagring så att zonredundant lagring (ZRS) används. Om du använder ett värdlagringskonto som inte har konfigurerats för ZRS kan appen bete sig oväntat under ett zonstopp.
  • Lagringskonto för distributionscontainer: Om du använder ett separat lagringskonto för appens distributionscontainer bör du även uppdatera det till zonredundant.

Överväganden

Zonredundans garanterar endast fortsatt drifttid för distribuerade program. Ett avbrott i tillgänglighetszonen kan påverka vissa aspekter av Azure Functions, även om programmet fortsätter att hantera trafik. Dessa beteenden omfattar planskalning, skapande av program, programkonfiguration och programpublicering.

Instansdistribution mellan zoner

När du konfigurerar Flex Consumption-planappar som zon-redundant sprider plattformen automatiskt planinstanser mellan flera zoner i den valda regionen, med olika regler för alltid redo-instanser kontra instanser på begäran.

  • Alltid redo-instanser distribueras mellan minst två zoner på ett rundgångssätt.

    För att säkerställa zonåterhämtning underhåller plattformen automatiskt minst två alltid redo instanser för varje skalningsfunktion eller grupp per funktion, oavsett den alltid redo konfigurationen för appen. Alla instanser som skapas av plattformen är plattformshanterade, faktureras som alltid redo-instanser och ändrar inte konfigurationsinställningarna för alltid redo.

  • Instanser på begäran skapas som ett resultat av händelsekällans volymer när appen skalar bortom antalet alltid redo instanser. Instanser på begäran distribueras mellan tillgänglighetszoner efter bästa förmåga. Snabbare utskalning prioriteras framför jämn fördelning mellan zoner. Plattformen försöker jämna ut fördelningen över tid.

När du konfigurerar Elastic Premium funktionsappar som zon-redundanta, sprider plattformen automatiskt instanserna av planerna mellan flera zoner i den valda regionen. Instansspridning följer dessa regler, även när appen skalar in och ut:

  • Det minsta antalet instanser av funktionsappar är två.
  • När du anger en kapacitet som är större än antalet zoner sprids instanserna jämnt bara när kapaciteten är en multipel av antalet zoner.
  • För ett kapacitetsvärde som är större än Antal zoner * Antal instanser sprids extra instanser mellan de återstående zonerna.

När Functions allokerar instanser till en zonredundant Premium-plan använder den zonutjämning med bästa prestanda, vilket de underliggande Skalningsuppsättningarna för virtuella Azure-datorer erbjuder. En Premium-plan anses vara balanserad när varje zon har antingen samma antal virtuella datorer i alla andra zoner som används av Premium-planen, plus-eller-minus en virtuell dator.

Kostnad

Det finns ingen extra kostnad i samband med aktivering av zonredundans. Prissättningen på en zonredundant plan är densamma som på en plan för en enda zon.

Men när du aktiverar tillgänglighetszoner i en app med en alltid redo instanskonfiguration på färre än två instanser för varje skalningsfunktion eller grupp per funktion skapar plattformen automatiskt två instanser av den alltid redo typen för varje skalningsfunktion eller grupp per funktion. Dessa nya instanser faktureras också som alltid-redo-instanser.

Men om du aktiverar tillgänglighetszoner i en plan med färre än två instanser tillämpar plattformen ett minsta antal instanser på två för planen och du debiteras för båda instanserna.

Fullständig prisinformation finns i Priser för Azure Functions.

Konfigurera stöd för tillgänglighetszoner

  • Skapa en ny zonredundant Azure Functions-plan. Du kan aktivera zonredundans när du skapar en ny plan. Detaljerade steg finns i Skapa en zonredundant funktionsapp.

  • Aktivera zonredundans för en befintlig plan: För Premium-planer kan du bara aktivera zonredundans när planen skapas. Du kan inte konvertera en befintlig Premium-plan till zonredundant. Du måste istället migrera din app genom att skapa en parallell installation på en ny Premium-plan-app. Mer information finns i Aktivera zonredundans för en befintlig plan.

Kapacitetsplanering och -hantering

Zonredundanta funktionsappar fortsätter att köras även när zoner i regionen drabbas av ett avbrott.

Under ett zonstopp identifierar Azure Functions förlorade instanser och försöker automatiskt hitta eller skapa ersättningsinstanser i de felfria zonerna. Den här processen utförs på bästa sätt och är inte garanterad. Om din arbetsbelastning måste ha ett visst antal instanser för att upprätthålla den förväntade tjänstnivån, bör du överväga att överdimensionera antalet alltid redo instanserna. Med den här metoden kan lösningen tolerera viss kapacitetsförlust och fortsätta att fungera utan försämrad prestanda. Mer information finns i Hantera kapacitet med hjälp av överetablering.

Beteende när alla zoner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när en plan är zonredundant, värdlagringskontot använder ZRS och alla tillgänglighetszoner används.

  • Åtgärd mellan zoner: När du konfigurerar zonredundans i Azure Functions sprids begäranden automatiskt över instanserna i varje tillgänglighetszon. En begäran kan gå till valfri instans i valfri tillgänglighetszon.

  • Datareplikering mellan zoner: Azure Functions är en tillståndslös beräkningstjänst, så det finns inga kunddata att replikera mellan zoner. Plattformen replikerar konfigurationen mellan zoner automatiskt.

    Om värdlagringskontot använder ZRS replikerar Azure Storage synkront sina data över flera tillgänglighetszoner.

    För Durable Functions granskar du lagringsprovidern för att förstå hur den replikerar data mellan zoner.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när en plan är zonredundant, värdlagringskontot använder ZRS och när det är ett avbrott i tillgänglighetszonen.

  • Identifiering och svar: Azure Functions-plattformen ansvarar för att identifiera ett fel i en tillgänglighetszon. Du behöver inte göra något för att påbörja en zone-failover.
  • Meddelande: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för en enskild resurs, och du kan konfigurera Resource Health-aviseringar för att meddela dig om problem. Du kan också använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  • Aktiva begäranden: När en tillgänglighetszon inte är tillgänglig avslutas alla pågående begäranden som är anslutna till en instans i den felaktiga tillgänglighetszonen och måste göras om. Se till att dina program förbereds genom att följa vägledningen för tillfällig felhantering.

  • Förväntad dataförlust: Zonfel förväntas inte orsaka dataförlust eftersom Azure Functions är en tillståndslös tjänst.

    Om värdlagringskontot använder ZRS garanterar Azure Storage ingen dataförlust från ett zonfel.

    För Durable Functions granskar du lagringsprovidern för att förstå om dataförlust är möjlig vid ett zonfel.

  • Förväntad stilleståndstid: Under zonavbrott kan anslutningar uppleva korta avbrott som vanligtvis varar några sekunder när trafiken omfördelas. Se till att dina program förbereds genom att följa vägledningen för tillfällig felhantering.

  • Omdistribution av trafik: Azure Functions identifierar förlorade instanser från den zonen och försöker hitta nya ersättningsinstanser. När Azure Functions har hittat ersättningar distribueras trafik mellan de nya instanserna efter behov.

    Viktigt!

    Azure garanterar inte att begäranden om fler instanser lyckas i ett zon-down-scenario. Plattformen försöker återställa förlorade instanser på bästa möjliga sätt. Om du behöver garanterad kapacitet vid en tillgänglighetszons fel, bör du skapa och konfigurera dina planer för att kompensera för zonförlust genom att tilldela extra kapacitet.

  • Icke aktiva beteenden: Program i en zonredundant funktionsappens plan fortsätter att köras och hantera trafik även om en tillgänglighetszon upplever ett avbrott. Icke-körningstidbeteenden kan men påverkas under ett avbrott i tillgänglighetszonen. Dessa beteenden omfattar skalning av funktionsappar, programskapande, programkonfiguration och programpublicering.

Zonåterställning

När tillgänglighetszonen återställs återställer Azure Functions automatiskt instanser i tillgänglighetszonen, tar bort alla tillfälliga instanser som skapats i de andra tillgänglighetszonerna och omdirigerar trafik mellan dina instanser som vanligt.

Test för zonfel

Azure Functions-plattformen hanterar trafikroutning, failover och zonåterhämtning för zonredundanta resurser. Du behöver inte initiera något. Eftersom den här funktionen är helt hanterad behöver du inte verifiera felprocesser i tillgänglighetszonen.

Motståndskraft mot regionomfattande fel

Azure Functions är en tjänst för en region. Om regionen blir otillgänglig är din Azure Functions-resurs inte heller tillgänglig.

Anpassade lösningar för flera regioner för återhämtning

För att undvika körningsförlust vid avbrott kan du distribuera samma funktioner på ett redundant sätt till funktionsappar i flera regioner.

Du ansvarar för:

  • Distribuera funktionsappar till flera regioner
  • Hantera trafikdistribution mellan regioner
  • Implementera överslagsmekanismer
  • Säkerställa datakonsekvens mellan regioner (om tillämpligt)
  • Övervaka och hantera distributioner mellan regioner

När du kör samma funktionskod i flera regioner finns det två vanliga mönster som du kan överväga: aktiv-aktiv och aktiv-passiv. Följande avsnitt ger en kort introduktion till dessa mönster, men ger inte detaljerad vägledning eller konfigurationssteg.

Aktivt-aktivt mönster för HTTP-utlösarfunktioner

Med ett aktivt-aktivt mönster körs funktioner i båda regionerna aktivt och bearbetar händelser, antingen parallellt eller växelvis. Du bör använda ett aktivt-aktivt mönster i kombination med Azure Front Door för dina viktiga HTTP-utlösta funktioner, som kan dirigera och resursallokera HTTP-begäranden mellan funktioner som körs i flera regioner. Azure Front Door kan också regelbundet kontrollera hälsotillståndet för varje slutpunkt. Om en funktion i en region slutar svara på hälsokontroller tar Azure Front Door bort den ur rotationen och vidarebefordrar endast trafik till de återstående sunda funktionerna.

Diagram som visar ett exempel på aktiv-aktiv arkitektur, med Azure Front Door-routning mellan Azure Functions-appar i olika regioner, var och en med sin egen databas.

Aktivt-passivt mönster för icke-HTTP-utlösarfunktioner

För händelsedrivna, icke-HTTP-utlösta funktioner (till exempel Service Bus- och Event Hubs-utlösta funktioner) använder du ett aktivt-passivt mönster. Med ett aktivt-passivt mönster körs funktioner aktivt i regionen som tar emot händelser, medan samma funktioner i en andra region förblir inaktiva. Det aktiv-passiva mönstret är ett sätt för endast en enskild funktion att bearbeta varje meddelande, vilket är viktigt för att upprätthålla datakonsekvens, samtidigt som det ger en mekanism för failover till den sekundära regionen vid en katastrof såsom ett regionfel.

Redundans för funktionsappen måste beaktas med redundansbeteenden för andra tjänster, till exempel:

Överväg en exempeltopologi med hjälp av en Azure Event Hubs-utlösare, där ditt Event Hubs-namnområde har konfigurerats för geo-haveriberedskap. I det här fallet kräver det aktiva-passiva mönstret följande komponenter:

  • Azure Event Hubs distribueras till både en primär och sekundär region.
  • Geo-katastrofåterhämtning aktiverad för att para ihop de primära och sekundära händelsehubbarna. Detta skapar också ett alias som du kan använda för att ansluta till Event Hubs-namnområdet och växla från primär till sekundär utan att ändra anslutningsinformationen.
  • Funktionsappar distribueras till både den primära och sekundära (failover) regionen, där appen i den sekundära regionen i princip är overksam eftersom meddelanden inte skickas dit.
  • Funktionsappen utlöses av den direkta (icke-alias) anslutningssträngen för sitt respektive Event Hubs-namnområde.
  • Utgivare till Event Hubs-namnområdet bör publicera till aliasanslutningssträngen.

Diagram som visar ett exempel på aktiv-passiv arkitektur, där Geo-haveriberedskap för Event Hubs omfattar flera regioner och separata funktionsappar och databaser i varje region.

Före redundansväxlingen skickar utgivare till den delade aliasvägen till den primära händelsehubben. Den primära funktionsappen lyssnar exklusivt på den primära händelsehubben. Den sekundära funktionsappen är passiv och inaktiv.

Så snart redundansväxlingen initieras dirigeras utgivare som skickar till det delade aliaset till den sekundära händelsehubben. Den sekundära funktionsappen blir nu aktiv och börjar aktiveras automatiskt. Effektiv redundansväxling till en sekundär region kan köras helt från händelsehubben, där funktionerna endast blir aktiva när respektive händelsehubb är aktiv.

Varaktiga funktioner

Information om haveriberedskap i flera regioner för Durable Functions finns i Haveriberedskap och geo-distribution i Azure Durable Functions.

Motståndskraft mot serviceunderhåll

Azure Functions utför regelbundna serviceuppgraderingar och andra underhållsaktiviteter.

  • Tillfällig motståndskraft mot fel: Under tjänstunderhållet kan instanserna som kör funktionsappen startas om eller uppleva tillfälliga avbrott. Se till att alla klientprogram som interagerar med din funktionsapp är motståndskraftiga mot tillfälliga fel.
  • Aktivera zonredundans: När du aktiverar zonredundans för din plan kan du också förbättra återhämtning under plattformsuppdateringar. Om du distribuerar flera instanser i din plan och aktiverar zonredundans för dina planer läggs ett extra lager av motståndskraft om en instans eller zon drabbas av problem vid en uppgradering.

För att behålla den förväntade kapaciteten under en uppgradering lägger plattformen automatiskt till extra instanser av planen under uppgraderingsprocessen.

  • Aktivera zonredundans: När du aktiverar zonredundans för din plan kan du också förbättra återhämtning under plattformsuppdateringar. Uppdateringsdomäner består av samlingar av virtuella datorer som kopplas från under en uppdatering och de mappas till tillgänglighetszoner. Genom att distribuera flera instanser i planen och aktivera zonredundans läggs ett extra lager av robusthet till om en instans eller zon blir opålitlig under en uppgradering.

  • App Service-miljö: Om du är värd för din funktionsapp i en App Service-miljö kan du anpassa uppgraderingscykeln. Om du behöver verifiera effekten av uppgraderingar på din arbetsbelastning aktiverar du manuella uppgraderingar. Med den här metoden kan du utföra validering och testning på en icke-produktionsinstans innan du tillämpar dem på din produktionsinstans.

    Mer information om underhållsinställningar finns i Uppgradera inställningar för planerat underhåll av App Service Environment.

Motståndskraft mot programdistributioner

Programdistributioner medför risk för problem i en produktionsmiljö. Du bör vara beredd att återställa en uppdatering om den orsakar problem. Du bör också styra hur uppdateringar distribueras för att minimera störningar från omstarter av program.

Flex Consumption-planer stöder strategier för webbplatsuppdatering, vilket ger flera sätt att distribuera dina appuppdateringar, inklusive löpande uppdateringar för distributioner med noll driftstopp.

Azure Functions-distributionsfack möjliggör distributioner utan driftstopp för dina funktionsappar. Använd distributionsplatser för att minimera effekten av distributioner och konfigurationsändringar för dina användare. Distributionsplatser minskar också sannolikheten för att din applikation behöver startas om. Om programmet startas om orsakas ett tillfälligt fel.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

Azure Functions tillhandahåller distinkta tillgänglighets serviceavtal för förbrukningsplanen och för andra plantyper.

Relaterat innehåll

  • Last updated on