Tillförlitlighet i Azure Functions
Den här artikeln beskriver tillförlitlighetsstöd i Azure Functions och beskriver både intraregional återhämtning med tillgänglighetszoner och återställning mellan regioner och affärskontinuitet. En mer detaljerad översikt över tillförlitlighetsprinciper i Azure finns i Azures tillförlitlighet.
Stöd för tillgänglighetszoner för Azure Functions är tillgängligt för både Premium-planer (Elastic Premium) och Dedikerade (App Service). Den här artikeln fokuserar på zonredundansstöd för Premium-planer. Zonredundans för dedikerade planer finns i Migrera App Service till stöd för tillgänglighetszoner.
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 Functions stöder en zonredundant distribution.
När du konfigurerar Functions som zonredundant sprider plattformen automatiskt funktionsappinstanserna ö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 funktionsappar är tre.
- När du anger en kapacitet som är större än tre sprids instanserna jämnt bara när kapaciteten är en multipel av 3.
- För ett kapacitetsvärde som är mer än 3*N sprids extra instanser över de återstående en eller två zonerna.
Viktigt!
Azure Functions kan köras på Azure App Service-plattformen. På App Service-plattformen kallas planer som är värdar för Funktionsappar för Premium-plan elastiska Premium-planer, med SKU-namn som EP1. Om du väljer att köra funktionsappen på en Premium-plan ska du skapa en plan med ett SKU-namn som börjar med "E", till exempel EP1. App Service-plan-SKU-namn som börjar med "P", till exempel P1V2 (Premium V2 Small Plan), är faktiskt dedikerade värdplaner. Eftersom de är dedikerade och inte Elastic Premium skalas inte planer med SKU-namn som börjar med "P" dynamiskt och kan öka dina kostnader.
Regional tillgänglighet
Zonredundanta Premium-planer är tillgängliga i följande regioner:
| Nord- och Sydamerika | Europa | Mellanöstern | Afrika | Asien och stillahavsområdet |
|---|---|---|---|---|
| Brasilien, södra | Frankrike, centrala | Israel, centrala | Sydafrika, norra | Australien, östra |
| Kanada, centrala | Tyskland, västra centrala | Qatar, centrala | Indien, centrala | |
| Central US | Italien, norra | Förenade Arabemiraten, norra | Norra Kina 3 | |
| East US | Europa, norra | Asien, östra | ||
| USA, östra 2 | Norge, östra | Japan, östra | ||
| USA, södra centrala | Sverige, centrala | Sydostasien | ||
| Västra USA 2 | Schweiz, norra | |||
| Västra USA 3 | Storbritannien, södra | |||
| Europa, västra |
Förutsättningar
Stöd för tillgänglighetszoner är en egenskap för Premium-planen. Följande är de aktuella kraven/begränsningarna för att aktivera tillgänglighetszoner:
- Du kan bara aktivera tillgänglighetszoner när du skapar en Premium-plan för din funktionsapp. Du kan inte konvertera en befintlig Premium-plan till att använda tillgänglighetszoner.
- Du måste använda ett zonredundant lagringskonto (ZRS) för funktionsappens lagringskonto. Om du använder en annan typ av lagringskonto kan Functions visa oväntat beteende under ett zonindelade avbrott.
- Både Windows och Linux stöds.
- Måste finnas på en Elastic Premium - eller Dedikerad värdplan. Information om hur du använder zonredundans med en dedikerad plan finns i Migrera App Service till stöd för tillgänglighetszoner.
- Stöd för tillgänglighetszoner är för närvarande inte tillgängligt för funktionsappar i förbrukningsplaner .
- Funktionsappar som finns i en Premium-plan måste ha minst antal alltid redo instanser på tre.
- Plattformen tillämpar det här minsta antalet bakom kulisserna om du anger ett instansantal som är mindre än tre.
- Om du inte använder Premium-abonnemang eller en skalningsenhet som stöder tillgänglighetszoner, befinner dig i en region som inte stöds eller är osäker kan du läsa migreringsvägledningen.
Prissättning
Det finns ingen extra kostnad i samband med aktivering av tillgänglighetszoner. Prissättningen för en zonredundant Premium App Service-plan är samma som en Premium-plan i en zon. För varje App Service-plan som du använder debiteras du baserat på den SKU du väljer, kapaciteten 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 för en App Service-plan tillämpar plattformen ett minsta antal instanser på tre för apptjänstplanen och debiterar dig för dessa tre instanser.
Skapa en zonredundant Premium-plan och funktionsapp
Det finns för närvarande två sätt att distribuera en zonredundant Premium-plan och funktionsapp. Du kan använda antingen Azure-portalen eller en ARM-mall.
Öppna Azure-portalen och gå till sidan Skapa funktionsapp . Information om hur du skapar en funktionsapp i portalen finns här.
På sidan Grundläggande fyller du i fälten för funktionsappen . Var särskilt uppmärksam på fälten i tabellen nedan (även markerade i skärmbilden nedan), som har specifika krav för zonredundans.
Inställning Föreslaget värde Anteckningar för zonredundans Region Önskad region Prenumerationen som den nya funktionsappen skapas under. Du måste välja en region som är tillgänglighetszonaktiverad från listan ovan. 
På sidan Värd fyller du i fälten för din funktionsapps värdplan. Var särskilt uppmärksam på fälten i tabellen nedan (även markerade i skärmbilden nedan), som har specifika krav för zonredundans.
Inställning Föreslaget värde Anteckningar för zonredundans Lagringskonto Ett zonredundant lagringskonto Som vi nämnde ovan i avsnittet om förhandskrav rekommenderar vi starkt att du använder ett zonredundant lagringskonto för din zonredundanta funktionsapp. Plantyp Functions Premium Den här artikeln beskriver hur du skapar en zonredundant app i en Premium-plan. Zonredundans är för närvarande inte tillgängligt i förbrukningsplaner. Information om zonredundans för App Service-planer finns i den här artikeln. Zonredundans Aktiverat Det här fältet fyller i flaggan som avgör om din app är zonredundant eller inte. Du kommer inte att kunna välja Enabledom du inte har valt en region som stöder zonredundans, enligt beskrivningen i steg 2.
För resten av processen för att skapa funktionsappen skapar du funktionsappen som vanligt. Det finns inga fält i resten av skapandeprocessen som påverkar zonredundans.
När den zonredundanta planen har skapats och distribuerats anses alla funktionsappar som finns i din nya plan vara zonredundanta.
Migrering av tillgänglighetszon
Azure Function Apps stöder för närvarande inte migrering på plats av befintliga instanser av funktionsappar. Information om hur du migrerar den offentliga Premium-planen för flera klientorganisationer från icke-tillgänglighetszon till stöd för tillgänglighetszoner finns i Migrera App Service till stöd för tillgänglighetszoner.
Zon-ned-upplevelse
Alla tillgängliga funktionsappinstanser av zonredundanta funktionsappar är aktiverade och bearbetar händelser. När en zon slutar fungera identifierar Functions förlorade instanser och försöker automatiskt hitta nya ersättningsinstanser om det behövs. Beteendet för elastisk skalning gäller fortfarande. I ett zon-ned-scenario finns det dock ingen garanti för att begäranden om ytterligare instanser kan lyckas, eftersom förlorade instanser för säkerhetskopiering sker på bästa sätt. Program som distribueras i en tillgänglighetszonaktiverad Premium-plan fortsätter att köras även när andra zoner i samma region drabbas av ett avbrott. Det är dock möjligt att icke-körningsbeteenden fortfarande kan påverkas av ett avbrott i andra tillgänglighetszoner. Dessa påverkade beteenden kan vara skalning av Premium-plan, programskapande, programkonfiguration och programpublicering. Zonredundans för Premium-planer garanterar endast fortsatt drifttid för distribuerade program.
När Functions allokerar instanser till en zonredundant Premium-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 Premium-plan anses vara balanserad när varje zon har antingen samma antal virtuella datorer (± 1 virtuell dator) i alla andra zoner som används av Premium-planen.
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.
I det här avsnittet beskrivs några av de strategier som du kan använda för att distribuera Functions för att möjliggöra haveriberedskap.
Haveriberedskap för flera regioner
Eftersom det inte finns någon inbyggd redundans tillgänglig körs funktioner i en funktionsapp i en specifik Azure-region. För att undvika körningsförlust vid avbrott kan du redundant distribuera samma funktioner för att fungera appar i flera regioner. Mer information om distributioner i flera regioner finns i vägledningen i Webbprogram för flera regioner med hög tillgänglighet.
När du kör samma funktionskod i flera regioner finns det två mönster att tänka på, aktiv-aktiv och aktiv-passiv.
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 på ett duplicerat sätt eller i rotation. Vi rekommenderar att du använder 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. Front door kan också regelbundet kontrollera hälsotillståndet för varje slutpunkt. När en funktion i en region slutar svara på hälsokontroller tar Azure Front Door bort den från rotationen och vidarebefordrar endast trafik till de återstående felfria funktionerna.
Viktigt!
Vi rekommenderar dock starkt att du använder det aktiva-passiva mönstret för icke-HTTPS-utlösarfunktioner. Du kan skapa aktiva-aktiva distributioner för icke-HTTP-utlösta funktioner. Du måste dock överväga hur de två aktiva regionerna interagerar eller samordnar med varandra. När du distribuerar samma funktionsapp till två regioner där varje utlöses i samma Service Bus-kö fungerar de som konkurrerande konsumenter vid avköning av kön. Det innebär att varje meddelande bara bearbetas av någon av instanserna, men det innebär också att det fortfarande finns en felpunkt på den enda Service Bus-instansen.
Du kan i stället distribuera två Service Bus-köer, med en i en primär region, en i en sekundär region. I det här fallet kan du ha två funktionsappar, där var och en pekar på Service Bus-kön som är aktiv i deras region. Utmaningen med den här topologin är hur kömeddelandena fördelas mellan de två regionerna. Det innebär ofta att varje utgivare försöker publicera ett meddelande till båda regionerna, och varje meddelande bearbetas av båda aktiva funktionsapparna. Även om detta skapar önskat aktivt/aktivt mönster, skapar det även andra utmaningar kring duplicering av beräkning och när eller hur data konsolideras.
Aktivt-passivt mönster för icke-HTTPS-utlösarfunktioner
Vi rekommenderar att du använder aktivt-passivt mönster för dina händelsedrivna, icke-HTTP-utlösta funktioner, till exempel Service Bus- och Event Hubs-utlösta funktioner.
Om du vill skapa redundans för icke-HTTP-utlösarfunktioner använder du ett aktivt-passivt mönster. Med ett aktivt-passivt mönster körs funktioner aktivt i den region som tar emot händelser. medan samma funktioner i en andra region förblir inaktiva. Det aktiva-passiva mönstret är ett sätt för endast en enskild funktion att bearbeta varje meddelande och samtidigt tillhandahålla en mekanism för redundansväxling till den sekundära regionen i en katastrof. Funktionsappar fungerar med redundansbeteenden för partnertjänsterna, till exempel Geo-återställning i Azure Service Bus och Geo-återställning av Azure Event Hubs.
Överväg en exempeltopologi med en Azure Event Hubs-utlösare. 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.
- Geokatastrof aktiverad för att koppla ihop de primära och sekundära händelsehubbarna. Detta skapar också ett alias som du kan använda för att ansluta till händelsehubbar 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 regionen (redundans) där appen i den sekundära regionen i princip är inaktiv eftersom meddelanden inte skickas dit.
- Funktionsappen utlöser direkt (icke-alias) anslutningssträng för respektive händelsehubb.
- Utgivare till händelsehubben bör publicera till aliaset anslutningssträng.
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 utlösa 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.
Läs mer om information och överväganden för redundansväxling med Service Bus och Event Hubs.