Sdílet prostřednictvím

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 závisí na vašem plánu hostování služby Functions:

Plán hostování Úroveň podpory Další informace...
Plán flexibilní spotřeby GA V horní části tohoto článku vyberte Flex Consumption .
Plán Elastic Premium GA V horní části tohoto článku vyberte Premium .
Vyhrazený plán (App Service) GA Viz Spolehlivost ve službě Azure App Service.
Plán spotřeby není k dispozici Není podporováno plánem Consumption.

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci každé oblasti Azure. Když jedna zóna selže, služby mohou přejít na jednu ze zbývajících zón.

Azure Functions podporuje zónově redundantní nasazení.

Podpora zón dostupnosti

Když nakonfigurujete aplikace plánu Flex Consumption jako zónově redundantní, platforma automaticky rozloží instance vaší aplikace funkcí mezi zóny ve vybrané oblasti s různými pravidly pro vždy připravené instance a instance na vyžádání.

Pokud je v plánu Flex Consumption povolená redundance zón, rozprostření instancí se určuje v následujících pravidlech:

  • Vždy připravené instance jsou distribuovány alespoň ve dvou zónách rovnoměrně.
  • Instance na vyžádání, které se vytvářejí v důsledku zdrojových svazků událostí, protože aplikace se škáluje nad rámec always-ready, se distribuují napříč zónami dostupnosti na základě maximálního úsilí . To znamená, že u instancí na vyžádání se upřednostňuje rychlejší tempo rozšíření kapacity oproti rovnoměrné distribuci napříč zónami dostupnosti. Platforma se v průběhu času pokouší vyrovnat distribuci.
  • Aby se zajistila odolnost zón se zónami dostupnosti, platforma automaticky udržuje alespoň dvě instance vždy připravené pro každou funkci škálování nebo skupinu bez ohledu na vždy připravenou konfiguraci aplikace. Všechny instance vytvořené platformou jsou spravovány platformou, jsou účtovány jako vždy připravené instance a nemění nastavení jejich vždy připravené konfigurace.

Když nakonfigurujete plány aplikace funkcí Elastic Premium jako zónově redundantní, platforma automaticky rozloží instance aplikace funkcí mezi zóny ve vybrané oblasti.

Rozšíření instance při zónově redundantním nasazení je určeno podle následujících pravidel, i když se aplikace škáluje dovnitř a ven.

  • Minimální počet instancí funkční aplikace je dvě.
  • Pokud zadáte kapacitu větší než počet zón, instance se rovnoměrně rozdělí pouze v případě, že je kapacita násobkem počtu zón.
  • Pokud je hodnota kapacity větší než počet zón * počet instancí, jsou další instance rozloženy mezi zbývající zóny.

Důležité

Azure Functions se dá spustit na platformě Aplikace Azure Service. Na platformě App Service se plány, které hostují funkční aplikace v rámci plánu Premium, označují jako plány Elastic Premium s názvy SKU, jako jsou 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á E, například EP1. Názvy skladových položek plánu služby App Service, které začínají P, například P1V2 (plán Premium V2 Small), jsou plány vyhrazeného hostování. Vzhledem k tomu, že se jedná o vyhrazené plány a ne Elastic Premium, plány s názvy skladových položek začínající na P se neškálují dynamicky a mohou zvýšit vaše náklady.

Regionální dostupnost

V současné době nepodporují všechny oblasti redundanci zón pro plány Flex Consumption. Pomocí Azure CLI můžete zobrazit oblasti, které ji podporují:

  1. Pokud jste to ještě neudělali, nainstalujte a přihlaste se k Azure pomocí Azure CLI:

    az login

    Příkaz az login vás přihlásí ke svému účtu Azure.

  2. az functionapp list-flexconsumption-locations Tento příkaz s --zone-redundant=true možností vrátí seznam oblastí, které aktuálně podporují zónově redundantní plány Flex Consumption:

    az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table

Když vytvoříte aplikaci Flex Consumption na webu Azure Portal, povolí se část stránky Zone redundancy, když ji vaše vybraná oblast podporuje.

Zónově redundantní plány Premium jsou dostupné v těchto oblastech:

Severní a Jižní Amerika Evropa 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
Kanada – střed Německo – středozápad Katar – střed Indie – střed
Střed USA Itálie – sever Spojené arabské emiráty – sever Čína – sever 3
USA – východ​ Severní Evropa Východní Asie
USA – východ 2 Norsko – východ Japonsko – východ
Střed USA – jih Švédsko – střed Jihovýchodní Asie
USA – západ 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 Flex Consumption. Tady jsou aktuální aspekty používání zón dostupnosti:

Podpora zóny dostupnosti je vlastností plánu Premium. Tady jsou aktuální aspekty zón dostupnosti:

  • Zóny dostupnosti můžete v plánu povolit jenom při vytváření aplikace. Existující plán Premium nemůžete převést na použití zón dostupnosti.
  • Musíte použít zónově redundantní účet úložiště (ZRS) pro výchozí účet úložiště hostitele vaší aplikace funkcí. Pokud používáte jiný typ účtu úložiště, může se vaše aplikace neočekávaně chovat během výpadku zón.
  • Podporují se Windows i Linux.
  • Aplikace funkcí hostované v plánu Premium musí mít minimálně dvě vždy připravené instance.
  • Platforma na pozadí vynucuje tento minimální počet, pokud zadáte počet instancí menší než dva.
  • 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

K povolení zón dostupnosti není přidružený žádný samostatný měřič. Ceny za instance používané pro zónově redundantní aplikaci Flex Consumption jsou stejné jako u aplikace Flex Consumption pro jednu zónu. Další informace naleznete v tématu Fakturace.

Když povolíte zóny dostupnosti v aplikaci s konfigurací vždy připravených instancí, která má méně než dvě instance pro každou škálovací funkci nebo skupinu, platforma automaticky vytvoří dvě instance typu vždy připravené pro každou škálovací funkci nebo skupinu. Tyto nové instance se také účtují jako neustále připravené instance.

S povolením zón dostupnosti nejsou spojené žádné další náklady. Ceny pro zónově redundantní Premium App Service plán jsou stejné jako plán Premium pro jednu zónu. 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 v plánu s méně než dvěma instancemi, platforma vynutí minimální počet dvou instancí pro tento App Service plán a za obě instance vám bude účtováno.

Vytvoření aplikace funkcí v zónově redundantním plánu

V současné době existuje několik způsobů nasazení zónově redundantní aplikace Flex Consumption.

  1. Pokud chcete vytvořit aplikaci funkcí v zónově redundantním plánu, musíte mít existující účet zónově redundantního úložiště. Pokud ještě nemáte zónově redundantní účet úložiště, vytvořte si ho před pokračováním.

  2. Na Azure Portal přejděte na stránku Vytvořit aplikaci funkce. Další informace o vytvoření aplikace funkcí na portálu najdete v tématu Vytvoření aplikace funkcí.

  3. Vyberte Flex Consumption a pak vyberte tlačítko Vybrat .

  4. Na stránce Vytvořit aplikaci funkcí (Flex Consumption) 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é je vytvořen plán Flex Consumption. Musíte vybrat oblast, která podporuje zóny dostupnosti. Podívejte se na seznam dostupnosti oblastí.
    Zónová redundance Povoleno Toto nastavení určuje, jestli je vaše aplikace zónově redundantní. Můžete vybrat Enabled jenom tehdy, když zvolíte oblast, která podporuje redundanci zón.

    Snímek obrazovky záložky Základy na stránce pro vytvoření aplikace Flex Consumption funkcí

  5. Na kartě Úložiště vyberte účet zónově redundantního úložiště pro vaši aplikaci 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ě Účet úložiště zónově redundantní Jak je popsáno v sekci Požadavky, důrazně doporučujeme pro vaši funkci zónově redundantní aplikaci použít účet zónově redundantního úložiště.

  6. 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 aplikace funkcí Flex Consumption hostovaná v novém plánu považuje za zónově redundantní.

Aktualizovat plán Flex Consumption, aby byl zónově redundantní

Změna redundance zóny vaší aplikace vyžaduje restartování, což způsobuje výpadky ve vaší aplikaci.

Před aktualizací plánu Flex Consumption na zónově redundantní byste měli aktualizovat výchozí účet úložiště hostitele tak, aby byl zónově redundantní. Pokud pro kontejner nasazení aplikace používáte samostatný účet úložiště, měli byste ho aktualizovat tak, aby byl zónově redundantní.

Pomocí těchto kroků připravte účty úložiště na změnu:

  1. Projděte si úvahy o úložišti.
  2. Vytvořte nebo identifikujte zónově redundantní účet úložiště, který bude výchozím účtem úložiště hostitele pro aplikaci.
  3. Aktualizujte nastavení aplikace související s úložištěm, například AzureWebJobsStorage, aby odkazovalo na zónově redundantní účet úložiště. Viz Práce s nastavením aplikace.
  4. Aktualizujte účet úložiště nasazení pro aplikaci, který může být stejný nebo jiný jako účet úložiště přidružený k aplikaci. Viz Konfigurace nastavení nasazení.

Po aktualizaci účtů úložiště používaných vaší aplikací můžete plán Flex Consumption aktualizovat tak, aby byl zónově redundantní pomocí šablon Bicep nebo ARM. Azure Portal v současné době nepodporuje aktualizace redundance zón v plánu.

  1. Na webu Azure Portal vyhledejte a vyberte aplikaci funkcí, která se má aktualizovat.

  2. V části Nastavení vyberte Škálování a souběžnost.

  3. Na kartě Redundance zóny zaškrtněte políčko Přidat redundanci zóny a povolte tuto funkci. Pokud je tato možnost zaškrtnutá, můžete zaškrtnutím tohoto políčka tuto funkci zakázat.

  4. Výběrem možnosti Uložit potvrďte změny a restartujte aplikaci.

Snímek obrazovky z karty Škálování a Souběžnost v aplikaci funkcí Flex Consumption.

V současné době existují dva způsoby nasazení zónově redundantního plánu Premium a funkční aplikace. Můžete použít web Azure Portal nebo šablonu ARM.

  1. Na Azure Portal přejděte na stránku Vytvořit aplikaci funkce. Další informace o vytvoření aplikace funkcí na portálu najdete v tématu Vytvoření aplikace funkcí.

  2. Vyberte Functions Premium a pak vyberte tlačítko Vybrat .

  3. 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ří váš plán Elastic Premium. 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é SKU 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.
    Zónová redundance 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.

    Snímek obrazovky s kartou Základy na stránce pro vytvoření aplikace funkcí

  4. 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ě Účet úložiště zónově redundantní Jak je popsáno v sekci Požadavky, důrazně doporučujeme pro vaši funkci zónově redundantní aplikaci použít účet zónově redundantního úložiště.

  5. 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

V současné době nemůžete změnit podporu zóny dostupnosti plánu Elastic Premium pro existující aplikaci funkcí. Informace o tom, jak migrovat veřejný plán s více tenanty Premium z zóny nedostupnosti do podpory zóny dostupnosti, najdete v tématu Migrace služby App Service do podpory zóny dostupnosti.

Zklidňující zážitek

Všechny dostupné instance aplikace funkcí zónově redundantního plánu Flex Consumption jsou povolené a zpracovávají události. Aplikace Flex Consumption nadále běží i v případě, že dojde k výpadku jiných zón ve stejné oblasti. Je ale možné, že v důsledku výpadku v jiných zónách dostupnosti může dojít k ovlivnění chování mimo dobu spuštění. Mezi standardní chování aplikací funkcí, které můžou ovlivnit dostupnost, patří:

  • Stupňování
  • Vytvoření aplikace
  • Změny konfigurace
  • Nasazení

Zónová redundance plánů Flex Consumption zaručuje pouze trvalou dobu provozu pro nasazené aplikace, které běží.

Když dojde k výpadku zóny, služba Functions zjistí ztracené instance a podle potřeby se automaticky pokusí vyhledat nebo vytvořit náhradní instance v dostupných zónách. Během zónového výpadku se platforma pokusí obnovit rovnováhu ve zbývajících dostupných zónách.

Všechny dostupné instance zónově redundantních aplikací funkcí jsou aktivní 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 více instancí 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 dobu běhu by mohlo být 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 do zónově redundantního plánu Premium, využívá vyrovnávání zón podle nejlepších možností, které nabízejí 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čů ve všech ostatních zónách používaných plánem Premium, plus-nebo-minus jeden virtuální počítač.

Zotavení po havárii napříč oblastmi a provozní kontinuita

Zotavení po havárii (DR) označuje postupy, které organizace používají 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 vytvářet plán zotavení po havárii, přečtěte si téma Doporučení pro návrh strategie zotavení po havárii.

Pro DR používá Microsoft model sdílené odpovědnosti. V tomto modelu Microsoft zajišťuje, aby byly dostupné základní služby infrastruktury a platformy. Nicméně mnoho služeb Azure neprovádí automatickou replikaci dat ani nepřepíná z oblasti, která selhala, aby se provedla křížová replikace 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ěží v rámci nabídky platformy jako služby (PaaS) na Azure, poskytuje funkce a pokyny pro podporu disaster recovery (DR). Pomocí funkcí specifických pro službu můžete podporovat rychlé obnovení, což pomůže s vývojem vašeho DR plánu.

Tato část vysvětluje některé strategie, které můžete použít k nasazení aplikace funkcí, která umožňuje 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 nasadit stejné funkce redundantně do aplikací pro funkce v několika regionech. 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í funkce v obou regionech aktivně běží a zpracovávají události, a to buď v duplikátu, anebo střídavě. Pro důležité HTTP funkce byste měli použít aktivní-aktivní model v kombinaci se službou Azure Front Door, která může směrovat a rozdělovat HTTP požadavky mezi funkce běžící v několika regionech. 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.

Architektura pro Azure Front Door a funkce

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é. Vzor aktivně-pasivního přístupu umožňuje, aby každou zprávu zpracovala pouze jedna funkce, a zároveň poskytuje mechanismus pro převzetí služeb do sekundární oblasti v případě havárie. Aplikace funkcí pracují s chováním partnerských služeb při selhání, jako je geografické obnovení sítě Azure Service Bus a geografické obnovení sítě 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 Function jsou nasazeny jak do primární, tak do sekundární (převzetí služeb při selhání) oblasti, přičemž aplikace v sekundární oblasti je v podstatě nečinná, protože se tam neodesílají zprávy.
  • Funkční aplikace se aktivuje přes přímý (bez aliasu) řetězec připojení k příslušnému centru událostí.
  • Vydavatelé by měli publikovat do centra událostí pomocí aliasu připojovacího řetězce.

Příklad architektury typu Aktivní-pasivní

Před přepnutím vydavatelé odesílají prostřednictvím trasy sdíleného aliasu do primárního centra událostí. Primární aplikační funkce naslouchá výhradně primárnímu událostnímu centru. Sekundární funkce aplikace je pasivní a nečinná. Jakmile dojde k přepnutí při selhání, vydavatelé odesílající na sdílený alias jsou směrováni do sekundárního centra událostí. Sekundární funkční aplikace se nyní stává aktivní a automaticky se spouští. Efektivní přepnutí do sekundární oblasti při selhání lze zcela řídit prostřednictvím centra událostí, přičemž funkce se stanou aktivními pouze tehdy, když je příslušné centrum událostí aktivní.

Přečtěte si další informace a možnostech ohledně převzetí služeb při selhání se službami Service Bus a Event Hubs.

Model aktivní-aktivní pro funkce triggeru mimo HTTPS

I když se doporučuje používat model aktivní-pasivní pro funkce triggeru jiného typu než HTTPS, můžete stále vytvářet nasazení aktivní-aktivní pro funkce aktivované mimo PROTOKOL HTTP. Před implementací tohoto modelu je nutné zvážit, jak tyto dvě aktivní oblasti vzájemně komunikují nebo koordinují se zdrojem triggerů.

Zvažte například nasazení stejného kódu funkce aktivovaného službou Service Bus do dvou oblastí, ale aktivaci ve stejné frontě služby Service Bus. V tomto případě obě funkce fungují jako konkurenční spotřebitelé při odběru z jediné fronty. I když každou zprávu může zpracovat pouze jedna ze dvou instancí aplikace, znamená to také, že stále existuje jediný bod selhání, což je jedna instance služby Service Bus. Zvažte povolení funkcí geografického zotavení po havárii a geografické replikace služby Service Bus, aby byla také odolná.

Další kroky

  • Last updated on