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 Azure jsou aspoň tři fyzicky oddělené skupiny datacenter v rámci každé oblasti Azure. Datová centra v každé zóně jsou vybavena nezávislou infrastrukturou napájení, chlazení a sítě. V případě selhání místní zóny jsou zóny dostupnosti navrženy tak, aby v případě ovlivnění jedné zóny, regionální služby, kapacity a vysoké dostupnosti podporovaly zbývající dvě zóny.

Selhání můžou být v rozsahu od selhání softwaru a hardwaru až po události, jako jsou zemětřesení, záplavy a požáry. Odolnost vůči selháním se dosahuje redundancí a logickou izolací služeb Azure. Podrobnější informace o zónách dostupnosti v Azure najdete v tématu Oblasti a zóny dostupnosti.

Služby s podporou zón dostupnosti Azure jsou navržené tak, aby poskytovaly správnou úroveň spolehlivosti a flexibility. Dají se nakonfigurovat dvěma způsoby. Můžou být buď zónově redundantní, s automatickou replikací napříč zónami, nebo zónově, s instancemi připnutými ke konkrétní zóně. Tyto přístupy můžete také kombinovat. Další informace o zónové a zónově redundantní architektuře najdete v tématu Doporučení pro použití zón dostupnosti a oblastí.

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.

Regionální dostupnost

Zónově redundantní plány Premium jsou dostupné v následujících oblastech:

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.

"resources": [
    {
        "type": "Microsoft.Web/serverfarms",
        "apiVersion": "2021-01-15",
        "name": "<YOUR_PLAN_NAME>",
        "location": "<YOUR_REGION_NAME>",
        "sku": {
            "name": "EP1",
            "tier": "ElasticPremium",
            "size": "EP1",
            "family": "EP", 
            "capacity": 3
        },
        "kind": "elastic",
        "properties": {
            "perSiteScaling": false,
            "elasticScaleEnabled": true,
            "maximumElasticWorkerCount": 20,
            "isSpot": false,
            "reserved": false,
            "isXenon": false,
            "hyperV": false,
            "targetWorkerCount": 0,
            "targetWorkerSizeId": 0, 
            "zoneRedundant": true
        }
    }
]

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.

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.

Další kroky

• Zotavení po havárii a geografická distribuce v Azure Durable Functions
• Vytvoření služby Azure Front Door
• Důležité informace o převzetí služeb při selhání služby Event Hubs
• Průvodce centrem architektury Azure o zónách dostupnosti
• Spolehlivost v Azure