Azure Functions geografické zotavení po havárii
Když celé oblasti Azure nebo datová centra dostanou výpadky, váš kód kritický pro klíčové služby potřebuje pokračovat v zpracování v jiné oblasti. V tomto článku se dozvíte o některých strategiích, které můžete použít k nasazení funkcí umožňujících zotavení po havárii.
Základní koncepty
Azure Functions spustit v aplikaci Function App v konkrétní oblasti. K dispozici není žádná předdefinovaná redundance. Aby nedošlo ke ztrátě provádění během výpadků, můžete redundantní nasazovat stejné funkce pro aplikace Functions v několika oblastech.
Když spustíte stejný kód funkce ve více oblastech, existují dva vzory, které je třeba vzít v úvahu:
| Vzor | Popis |
|---|---|
| Aktivní/aktivní | Funkce v obou oblastech aktivně spouštějí a zpracovávají události, a to duplicitním způsobem nebo při rotaci. Pro vaše důležité funkce aktivované protokolem HTTP doporučujeme použít aktivní/aktivní vzor v kombinaci se službou Azure front-dveří . |
| Aktivní/pasivní | Funkce se aktivně spouštějí v oblasti přijímající události, zatímco stejné funkce ve druhé oblasti zůstávají nečinné. Pokud je vyžadováno převzetí služeb při selhání, je druhá oblast aktivována a převezme se zpracování. pro funkce aktivované událostmi, které nepoužívá protokol HTTP, doporučujeme tento model, jako jsou funkce aktivované Service Bus a centrum událostí. |
Další informace o nasazeních ve více oblastech najdete v doprovodnéch materiálech v oblasti vysoce dostupné webové aplikace s více oblastmi.
Redundance funkcí triggeru HTTP
Vzor aktivní/aktivní je nejlepší model nasazení pro funkce triggeru protokolu HTTP. V takovém případě je potřeba použít přední dveře Azure ke koordinaci požadavků mezi oběma oblastmi. Přední dvířka Azure můžou směrovat a cyklicky dotazovat požadavky HTTP mezi funkcemi běžícími v několika oblastech. Také pravidelně kontroluje stav každého koncového bodu. Když funkce v jedné oblasti přestane reagovat na kontroly stavu, přední dveře Azure přestanou být v provozu a přesměrují provoz na zbývající funkce v pořádku.
Redundance pro funkce triggeru bez protokolu HTTP
Redundance pro funkce, které spotřebovávají události z jiných služeb, vyžadují jiný vzor, který pracuje se vzorem převzetí služeb při selhání souvisejících služeb.
Aktivní/pasivní redundance pro funkce triggeru jiného typu než HTTP
Aktivní/pasivní poskytuje způsob, jak každou zprávu zpracovat jenom jedna funkce, ale poskytuje mechanismus pro převzetí služeb při selhání do sekundární oblasti v případě havárie. aplikace Function app fungují s chováním převzetí služeb při selhání partnerských služeb, jako je azure Service Bus geografické obnovení a azure Event Hubs geografické obnovení. Sekundární aplikace Function App je považována za pasivní , protože služba převzetí služeb při selhání, ke které je připojená, není aktuálně aktivní, takže aplikace Function App je v podstatě nečinná.
Zvažte ukázkovou topologii pomocí triggeru služby Azure Event Hubs. V takovém případě musí vzor aktivní/pasivní zahrnovat následující komponenty:
- Centrum událostí Azure je nasazené do primární i sekundární oblasti.
- Geografická havárie povolená pro spárování primárního a sekundárního centra událostí. Tím se také vytvoří alias , který můžete použít pro připojení k centrům událostí a přepnutí z primárního na sekundární bez změny informací o připojení.
- Aplikace Function App se nasazují do primární i sekundární (převzetí služeb při selhání), přičemž aplikace v sekundární oblasti je v podstatě nečinná, protože se tam neodesílají zprávy.
- Spustí se triggery Function App na přímém (nealiasovém) připojovacím řetězci pro příslušné centrum událostí.
- Vydavatelé do centra událostí by se měli publikovat do připojovacího řetězce aliasu.
Před převzetím služeb při selhání odesílají vydavatelé trasy ke sdílenému aliasu do primárního centra událostí. Primární aplikace Function naslouchá výhradně primárnímu centru událostí. Sekundární aplikace Function App je pasivní a nečinný. Po zahájení převzetí služeb při selhání budou vydavatelé odesílající sdílenému aliasu směrováni do sekundárního centra událostí. Sekundární aplikace Function App se teď stane aktivním automatickým spouštěním. Efektivní převzetí služeb při selhání u sekundární oblasti se dá zcela řídit z centra událostí. funkce se stanou aktivní jenom v případě, že je příslušné centrum událostí aktivní.
přečtěte si další informace a požadavky pro převzetí služeb při selhání pomocí Service Bus a Event Hubs.
Aktivní/aktivní redundance pro funkce triggeru jiného typu než HTTP
Pro funkce aktivované jiným protokolem než HTTP stále můžete dosáhnout aktivních nebo aktivních nasazení. Je však třeba vzít v úvahu, jak obě aktivní oblasti vzájemně spolupracují nebo koordinují mezi sebou. když nasadíte stejnou aplikaci function app do dvou oblastí s každou aktivací ve stejné Service Busové frontě, budou se vystupovat jako konkurenční spotřebitelé při jejich zařazování do fronty. to znamená, že každá zpráva je zpracována pouze jednou z těchto instancí, znamená to také, že v jedné instanci Service Bus je stále jediný bod selhání.
místo toho můžete nasadit dvě fronty Service Bus s jednou v primární oblasti, jednu v sekundární oblasti. v takovém případě můžete mít dvě aplikace function app, přičemž každý z nich ukazuje na aktivní frontu Service Bus ve své oblasti. Výzvou k této topologii je způsob, jakým jsou zprávy fronty distribuovány mezi dvě oblasti. Často to znamená, že se každý Vydavatel pokusí publikovat zprávy do obou oblastí a každá zpráva je zpracována aktivní funkcí aplikace. Když se tím vytvoří požadovaný aktivní/aktivní vzor, vytvoří se taky další výzvy týkající se duplikace výpočetních prostředků a jejich konsolidace a způsobu jejich konsolidace. Z důvodu těchto problémů doporučujeme použít pro funkce triggeru bez HTTPS vzor aktivní/pasivní.