Spolehlivost ve službě Azure Functions
Tento článek popisuje podporu spolehlivosti ve službě Azure Functions a zabývá se vnitřní odolností zón dostupnosti a obnovením mezi oblastmi a provozní kontinuitou. Podrobnější přehled principů spolehlivosti v Azure najdete v tématu Spolehlivost Azure.
Podpora zón dostupnosti pro Azure Functions je dostupná v plánech Premium (Elastic Premium) i Dedicated (App Service). Tento článek se zaměřuje na podporu redundance zón pro plány Premium. Informace o redundanci zón ve vyhrazených plánech najdete v tématu Migrace služby App Service do podpory zón dostupnosti.
Podpora zón dostupnosti
Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci každé oblasti Azure. Když jedna zóna selže, můžou služby převzít služby při selhání jedné ze zbývajících zón.
Další informace o zónách dostupnosti v Azure najdete v tématu Co jsou zóny dostupnosti?.
Azure Functions podporuje zónově redundantní nasazení.
Když nakonfigurujete funkce jako zónově redundantní, platforma automaticky rozdělí instance aplikace funkcí do tří zón ve vybrané oblasti.
Rozšíření instance s zónově redundantním nasazením se určuje uvnitř následujících pravidel, i když se aplikace škáluje a zvětší:
- Minimální počet instancí aplikace funkcí je tři.
- Když zadáte kapacitu větší než tři, instance jsou rovnoměrně rozloženy pouze v případě, že je kapacita násobkem 3.
- U hodnoty kapacity větší než 3*N se extra instance rozdělí mezi zbývající jednu nebo dvě zóny.
Důležité
Azure Functions se dá spustit na platformě Aplikace Azure Service. Plány, které hostují aplikace funkcí plánu Premium, se na platformě App Service označují jako plány Elastic Premium s názvy skladových položek, jako je EP1. Pokud se rozhodnete spustit aplikaci funkcí v plánu Premium, nezapomeňte vytvořit plán s názvem skladové položky, který začíná na "E", například EP1. Názvy skladových položek plánu služby App Service, které začínají na "P", například P1V2 (plán Premium V2 Small), jsou ve skutečnosti vyhrazené plány hostování. Vzhledem k tomu, že jsou vyhrazené a ne Elastic Premium, plány s názvy skladových položek začínající na "P" se nebudou škálovat dynamicky a můžou zvýšit náklady.
Regionální dostupnost
Zónově redundantní plány Premium jsou dostupné v následujících oblastech:
| Amerika | Evropě | Střední východ | Afrika | Asie a Tichomoří |
|---|---|---|---|---|
| Brazílie – jih | Francie – střed | Izrael - střed | Jižní Afrika – sever | Austrálie – východ |
| Střední Kanada | Německo – středozápad | Střední Katar | Indie – střed | |
| USA – střed | Itálie - sever | Spojené arabské emiráty – sever | Čína – sever 3 | |
| East US | Severní Evropa | Východní Asie | ||
| USA – východ 2 | Norsko – východ | Japonsko – východ | ||
| Středojižní USA | Švédsko – střed | Southeast Asia | ||
| Západní USA 2 | Švýcarsko – sever | |||
| USA – západ 3 | Velká Británie – jih | |||
| Západní Evropa |
Požadavky
Podpora zóny dostupnosti je vlastností plánu Premium. Toto jsou aktuální požadavky a omezení pro povolení zón dostupnosti:
- Zóny dostupnosti můžete povolit jenom při vytváření plánu Premium pro vaši aplikaci funkcí. Existující plán Premium nemůžete převést na použití zón dostupnosti.
- Pro účet úložiště vaší aplikace funkcí musíte použít zónově redundantní účet úložiště (ZRS). Pokud používáte jiný typ účtu úložiště, může funkce během výpadku zón zobrazit neočekávané chování.
- Podporují se Windows i Linux.
- Musí být hostovaný v plánu elastického hostování nebo plánu vyhrazeného hostování. Informace o použití redundance zón s vyhrazeným plánem najdete v tématu Migrace služby App Service do podpory zón dostupnosti.
- Podpora zón dostupnosti není aktuálně dostupná pro aplikace funkcí v plánech Consumption .
- Aplikace funkcí hostované v plánu Premium musí mít minimálně počet vždy připravených instancí tři.
- Platforma vynucuje tento minimální počet na pozadí, pokud zadáte počet instancí menší než tři.
- Pokud nepoužíváte plán Premium nebo jednotku škálování, která podporuje zóny dostupnosti, nacházíte se v nepodporované oblasti nebo si nejste jistí, přečtěte si pokyny k migraci.
Ceny
S povolením zón dostupnosti nejsou spojené žádné další náklady. Ceny pro zónově redundantní plán služby App Service úrovně Premium jsou stejné jako jeden plán Premium zóny. Pro každý plán služby App Service, který používáte, se vám účtují poplatky na základě zvolené skladové položky, vámi zadané kapacity a všech instancí, na které se škálujete na základě kritérií automatického škálování. Pokud povolíte zóny dostupnosti, ale zadáte kapacitu menší než tři pro plán služby App Service, platforma vynutí minimální počet instancí tří pro tento plán služby App Service a za tyto tři instance vám bude účtovat poplatky.
Vytvoření zónově redundantního plánu Premium a aplikace funkcí
V současné době existují dva způsoby nasazení zónově redundantního plánu Premium a aplikace funkcí. Můžete použít web Azure Portal nebo šablonu ARM.
Na webu Azure Portal přejděte na stránku Vytvořit aplikaci funkcí. Další informace o vytvoření aplikace funkcí na portálu najdete v tématu Vytvoření aplikace funkcí.
Vyberte Functions Premium a pak vyberte tlačítko Vybrat . Tento článek popisuje, jak vytvořit zónově redundantní aplikaci v plánu Premium. Redundance zón není v současné době dostupná v plánech Consumption. Informace o redundanci zón v plánech služby App Service najdete v tématu Spolehlivost ve službě Aplikace Azure Service.
Na stránce Vytvořit aplikaci funkcí (Functions Premium) na kartě Základy zadejte nastavení aplikace funkcí. Věnujte zvláštní pozornost nastavením v následující tabulce (zvýrazněné také na následujícím snímku obrazovky), které mají specifické požadavky na redundanci zón.
Nastavení Navrhovaná hodnota Poznámky k redundanci zón Oblast Upřednostňovaná podporovaná oblast Oblast, ve které se vytvoří nová aplikace funkcí. Musíte vybrat oblast, která podporuje zóny dostupnosti. Podívejte se na seznam dostupnosti oblastí. Cenový plán Jeden z plánů Elastic Premium Další informace naleznete v tématu Dostupné skladové položky instance. Tento článek popisuje, jak vytvořit zónově redundantní aplikaci v plánu Premium. Redundance zón není v současné době dostupná v plánech Consumption. Informace o redundanci zón v plánech služby App Service najdete v tématu Spolehlivost ve službě Aplikace Azure Service. Redundance zón Povoleno Toto nastavení určuje, jestli je vaše aplikace zónově redundantní. Nebudete moct vybrat Enabled, pokud jste nevybrali oblast, která podporuje redundanci zón, jak je popsáno výše.
Na kartě Úložiště zadejte nastavení účtu úložiště aplikace funkcí. Věnujte zvláštní pozornost nastavení v následující tabulce, která má specifické požadavky na redundanci zón.
Nastavení Navrhovaná hodnota Poznámky k redundanci zón Účet úložiště Zónově redundantní účet úložiště Jak je popsáno v části Požadavky , důrazně doporučujeme pro vaši zónově redundantní aplikaci funkcí použít účet zónově redundantního úložiště. Pro zbytek procesu vytváření aplikace funkcí vytvořte aplikaci funkcí jako obvykle. Ve zbytku procesu vytváření nejsou žádná nastavení, která mají vliv na redundanci zón.
Po vytvoření a nasazení zónově redundantního plánu se všechny aplikace funkcí hostované v novém plánu považují za zónově redundantní.
Migrace zóny dostupnosti
Aplikace Azure Functions v současné době nepodporují místní migraci existujících instancí aplikací funkcí. Informace o tom, jak migrovat veřejný plán multiklientů Premium z zóny dostupnosti do podpory zóny dostupnosti, najdete v tématu Migrace služby App Service do podpory zóny dostupnosti.
Prostředí pro zónu dolů
Všechny dostupné instance aplikací funkcí zónově redundantních aplikací funkcí jsou povolené a zpracovávají události. Když dojde k výpadku zóny, služba Functions zjistí ztracené instance a v případě potřeby se automaticky pokusí najít nové náhradní instance. Chování elastického škálování stále platí. Ve scénáři mimo zónu však neexistuje žádná záruka, že požadavky na další instance mohou být úspěšné, protože ztracené instance se zaplňují na základě maximálního úsilí. Aplikace nasazené v plánu Premium s povolenou zónou dostupnosti budou dál běžet i v případě, že dojde k výpadku jiných zón ve stejné oblasti. Je však možné, že chování mimo modul runtime může být stále ovlivněno výpadkem v jiných zónách dostupnosti. Toto ovlivněné chování může zahrnovat škálování plánu Premium, vytvoření aplikace, konfiguraci aplikace a publikování aplikací. Redundance zón pro plány Premium zaručuje pouze trvalou dobu provozu pro nasazené aplikace.
Když služba Functions přiděluje instance zónově redundantnímu plánu Premium, využívá vyrovnávání zón s nejlepším úsilím, které nabízí základní škálovací sady virtuálních počítačů Azure. Plán Premium se považuje za vyvážený, když každá zóna má buď stejný počet virtuálních počítačů (± 1 virtuální počítač) ve všech ostatních zónách používaných plánem Premium.
Zotavení po havárii napříč oblastmi a provozní kontinuita
Zotavení po havárii (DR) se týká zotavení z událostí s vysokým dopadem, jako jsou přírodní katastrofy nebo neúspěšná nasazení, která vedou k výpadkům a ztrátě dat. Bez ohledu na příčinu je nejlepším řešením havárie dobře definovaný a otestovaný plán zotavení po havárii a návrh aplikace, který aktivně podporuje zotavení po havárii. Než začnete přemýšlet o vytvoření plánu zotavení po havárii, přečtěte si doporučení pro návrh strategie zotavení po havárii.
Pokud jde o zotavení po havárii, Microsoft používá model sdílené odpovědnosti. V modelu sdílené odpovědnosti Microsoft zajišťuje, aby byly dostupné základní služby infrastruktury a platformy. Současně mnoho služeb Azure automaticky nereplikuje data nebo se vrátí z oblasti, která selhala, aby se křížově replikovala do jiné povolené oblasti. Za tyto služby zodpovídáte za nastavení plánu zotavení po havárii, který funguje pro vaši úlohu. Většina služeb, které běží na nabídkách PaaS (Platforma jako služba) Azure, poskytuje funkce a pokyny pro podporu zotavení po havárii a pomocí funkcí specifických pro služby můžete podporovat rychlé obnovení , které vám pomůže s vývojem plánu zotavení po havárii.
Tato část vysvětluje některé strategie, které můžete použít k nasazení služby Functions, aby bylo možné provést zotavení po havárii.
Informace o zotavení po havárii pro Durable Functions najdete v tématu Zotavení po havárii a geografická distribuce v Azure Durable Functions.
Zotavení po havárii ve více oblastech
Vzhledem k tomu, že není k dispozici žádná integrovaná redundance, funkce běží v aplikaci funkcí v konkrétní oblasti Azure. Abyste se vyhnuli ztrátě spuštění během výpadků, můžete redundantně nasadit stejné funkce do aplikací funkcí ve více oblastech. Další informace o nasazeních ve více oblastech najdete v doprovodných materiálech ve webové aplikaci s vysokou dostupností ve více oblastech.
Když spustíte stejný kód funkce ve více oblastech, je potřeba vzít v úvahu dva vzory, aktivní-aktivní a aktivní-pasivní.
Model aktivní-aktivní pro funkce triggeru HTTP
S modelem aktivní-aktivní jsou funkce v obou oblastech aktivně spuštěné a zpracovávají události, a to buď duplicitním způsobem, nebo v obměně. Pro důležité funkce aktivované protokolem HTTP, které můžou směrovat a dotazovat požadavky HTTP mezi funkcemi běžícími v několika oblastech, doporučujeme použít v kombinaci se službou Azure Front Door vzor aktivní-aktivní. Front door také může pravidelně kontrolovat stav každého koncového bodu. Když funkce v jedné oblasti přestane reagovat na kontroly stavu, Azure Front Door ji vynechá z rotace a přesměruje provoz jenom na zbývající funkce, které jsou v pořádku.
Příklad najdete v ukázce implementace vzoru geode tím, že rozhraní API nasadíte do geodes v distribuovaných oblastech Azure.
Důležité
I když se důrazně doporučuje používat model aktivní-pasivní pro funkce triggeru jiného typu než HTTPS. Můžete vytvořit nasazení aktivní-aktivní pro funkce, které nejsou aktivované protokolem HTTP. Je však potřeba zvážit, jak tyto dvě aktivní oblasti vzájemně komunikují nebo koordinují. Když nasadíte stejnou aplikaci funkcí do dvou oblastí s každou aktivací ve stejné frontě Service Bus, budou fungovat jako konkurenční spotřebitelé při de-queueingu této fronty. I když to znamená, že každá zpráva se zpracovává pouze jednou z instancí, znamená to, že v jedné instanci služby Service Bus stále existuje jediný bod selhání.
Místo toho můžete nasadit dvě fronty služby Service Bus s jednou v primární oblasti, jednu v sekundární oblasti. V tomto případě můžete mít dvě aplikace funkcí, přičemž každá odkazuje na frontu služby Service Bus aktivní v jejich oblasti. Problémem s touto topologií je způsob distribuce zpráv fronty mezi dvěma oblastmi. Často to znamená, že se každý vydavatel pokusí publikovat zprávu do obou oblastí a každá zpráva je zpracována oběma aktivními aplikacemi funkcí. I když se tím vytvoří požadovaný model aktivní/aktivní, vytvoří se také další problémy související s duplikací výpočetních prostředků a tím, kdy nebo jak se data konsolidují.
Model aktivní-pasivní pro funkce triggeru jiného typu než HTTPS
Doporučuje se používat model aktivní-pasivní pro funkce aktivované událostmi, které nejsou aktivované protokolem HTTP, jako jsou například funkce aktivované službou Service Bus a Event Hubs.
Pokud chcete vytvořit redundanci pro funkce triggeru jiného typu než HTTP, použijte model aktivní-pasivní. Pomocí modelu aktivní-pasivní běží funkce aktivně v oblasti, která přijímá události; zatímco stejné funkce v druhé oblasti zůstávají nečinné. Model aktivní-pasivní představuje způsob, jak zpracovat každou zprávu pouze jednou funkcí a současně poskytuje mechanismus převzetí služeb při selhání sekundární oblasti v havárii. Aplikace funkcí pracují s chováním partnerských služeb při selhání, jako je geografické obnovení služby Azure Service Bus a geografické obnovení služby Azure Event Hubs.
Představte si ukázkovou topologii pomocí triggeru služby Azure Event Hubs. V tomto případě vyžaduje aktivní/pasivní model následující komponenty:
- Služba Azure Event Hubs nasazená do primární i sekundární oblasti.
- Geografická havárie umožňuje spárovat primární a sekundární centra událostí. Tím se také vytvoří alias, který můžete použít pro připojení k centrem událostí a přepnout z primární na sekundární beze změny informací o připojení.
- Aplikace funkcí se nasazují do primární i sekundární oblasti (převzetí služeb při selhání) a aplikace v sekundární oblasti je v podstatě nečinná, protože se tam neodesílají zprávy.
- Aplikace funkcí se aktivuje na přímém (ne aliasu) připojovací řetězec pro příslušné centrum událostí.
- Vydavatelé do centra událostí by měli publikovat alias připojovací řetězec.
Před převzetím služeb při selhání vydavatelé odesílají trasu sdíleného aliasu do primárního centra událostí. Primární aplikace funkcí naslouchá výhradně primárnímu centru událostí. Sekundární aplikace funkcí je pasivní a nečinná. Jakmile se zahájí převzetí služeb při selhání, vydavatelé odesílající do sdíleného aliasu se směrují do sekundárního centra událostí. Sekundární aplikace funkcí se teď stane aktivní a spustí se automaticky. Efektivní převzetí služeb při selhání do sekundární oblasti je možné řídit zcela z centra událostí, přičemž funkce jsou aktivní pouze v případě, že je příslušné centrum událostí aktivní.
Přečtěte si další informace a důležité informace o převzetí služeb při selhání se službou Service Bus a Event Hubs.