Azure Functions geo-haveriberedskap
När hela Azure-regioner eller datacenter drabbas av driftstopp måste den verksamhetskritiska koden fortsätta bearbetas i en annan region. Den här artikeln beskriver några av de strategier som du kan använda för att distribuera funktioner för haveriberedskap.
Grundläggande begrepp
Azure Functions körs i en funktionsapp i en viss region. Det finns ingen inbyggd redundans tillgänglig. För att undvika körningsförlust under avbrott kan du redundant distribuera samma funktioner till funktionsappar i flera regioner.
När du kör samma funktionskod i flera regioner finns det två mönster att tänka på:
| Mönster | Description |
|---|---|
| Aktiv/aktiv | Funktioner i båda regionerna körs 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 kritiska HTTP-utlösta funktioner. |
| Aktiv/passiv | Funktioner körs aktivt i regionen som tar emot händelser, medan samma funktioner i en andra region förblir inaktiva. När redundans krävs aktiveras den andra regionen och tar över bearbetningen. Vi rekommenderar det här mönstret för dina händelsedrivna, icke-HTTP-utlösta funktioner, till exempel Service Bus och event hub-utlösta funktioner. |
Mer information om distributioner i flera regioner finns i vägledningen i webbprogrammet för flera regioner med hög tillgång.
Redundans för HTTP-utlösarfunktioner
Mönstret aktiv/aktiv är den bästa distributionsmodellen för HTTP-utlösarfunktioner. I det här fallet måste du använda Azure Front Door för att samordna begäranden mellan båda regionerna. Azure Front Door kan dirigera och resursallokerings-HTTP-begäranden mellan funktioner som körs i flera regioner. Den kontrollerar också regelbundet hälsotillståndet för varje slutpunkt. När en funktion i en region slutar svara på hälsokontroller Azure Front Door den från rotationen och vidarebefordrar endast trafik till de återstående felfria funktionerna.
Redundans för icke-HTTP-utlösarfunktioner
Redundans för funktioner som använder händelser från andra tjänster kräver ett annat mönster, som fungerar med redundansmönstret för de relaterade tjänsterna.
Aktiv/passiv redundans för icke-HTTP-utlösarfunktioner
Aktiv/passiv är ett sätt för endast en enskild funktion att bearbeta varje meddelande, men ger en mekanism för redundans till en sekundär region vid en katastrof. Funktionsappar fungerar med redundansbeteenden för partnertjänsterna, till exempel Azure Service Bus geo-återställning Azure Event Hubs geo-återställning. Den sekundära funktionsappen betraktas som passiv eftersom redundanstjänsten som den är ansluten till för närvarande inte är aktiv, så funktionsappen är i stort sett inaktiv.
Tänk dig 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 Hub distribuerad till både en primär och sekundär region.
- Geo-katastrof aktiverad för att koppla ihop den primära och sekundära händelsehubben. Detta skapar också ett alias som du kan använda för att ansluta till händelsehubbbar 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 stort sett är inaktiv eftersom meddelanden inte skickas dit.
- Funktionsappen utlöses på den direkta (icke-alias) anslutningssträngen för respektive händelsehubb.
- Utgivare till händelsehubben ska publicera till aliasanslutningssträngen.
Före redundans 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 redundans har initierats 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ösas automatiskt. Effektiv redundans till en sekundär region kan köras helt från händelsehubben, och funktionerna blir bara aktiva när respektive händelsehubb är aktiv.
Läs mer om information och överväganden för redundans med Service Bus och Event Hubs.
Aktiv/aktiv redundans för icke-HTTP-utlösarfunktioner
Du kan fortfarande uppnå aktiva/aktiva distributioner för icke-HTTP-utlösta funktioner. Du måste dock tänka på hur de två aktiva regionerna interagerar eller koordineras med varandra. När du distribuerar samma funktionsapp till två regioner där var och en utlöses i samma Service Bus kö, skulle de fungera som konkurrerande konsumenter när kön tas bort från kön. Detta innebär att varje meddelande endast bearbetas av någon av instanserna, men det innebär också att det fortfarande finns en enskild felpunkt på den enskilda Service Bus instansen.
Du kan i stället distribuera 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 aktiv i sin region. Utmaningen med den här topologin är hur kömeddelandena distribueras 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. Detta skapar önskat aktivt/aktivt mönster, men det skapar även andra utmaningar kring duplicering av beräkning och när eller hur data konsolideras. På grund av dessa utmaningar rekommenderar vi att du använder det aktiva/passiva mönstret för icke-HTTPS-utlösarfunktioner.