Sdílet prostřednictvím

Spolehlivost v Azure App Service

Azure App Service je služba založená na protokolu HTTP pro hostování webových aplikací, rozhraní REST API a mobilních back-endů. App Service se integruje s Microsoft Azure, aby poskytovala zabezpečení, vyrovnávání zatížení, automatické škálování a automatizovanou správu pro aplikace. Služba App Service poskytuje jako službu Azure celou řadu funkcí, které podporují vaše požadavky na spolehlivost.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost služby App Service vůči nejrůznějším potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti, výpadků oblastí a údržby služeb. Popisuje také, jak se dají zálohy použít k zotavení z jiných typů problémů a zvýrazní některé klíčové informace o smlouvě o úrovni služeb App Service (SLA).

Poznámka:

Pokud hledáte informace o podpoře spolehlivosti ve službě App Service Environment, přečtěte si téma Spolehlivost ve službě App Service Environment.

Doporučení pro nasazení do produkčního prostředí

Azure Well-Architected Framework poskytuje doporučení týkající se spolehlivosti, výkonu, zabezpečení, nákladů a provozu. Informace o tom, jak tyto oblasti vzájemně ovlivňují a přispívají ke spolehlivému řešení služby App Service, najdete v tématu Osvědčené postupy architektury pro App Service (Web Apps) v architektuře Azure Well-Architected Framework.

Přehled architektury spolehlivosti

Když vytvoříte webovou aplikaci App Service, zadáte plán služby App Service , který aplikaci spustí.

Plán služby App Service definuje sadu výpočetních prostředků, které spouští vaše webové aplikace. Všechny webové aplikace musí běžet uvnitř plánu. Plán můžete škálovat tak, aby běžel na více instancích virtuálních počítačů, označovaných také jako pracovní procesy. Tyto instance poskytují výpočetní prostředky, které spouštějí kód aplikace. Jeden plán služby App Service může hostovat více aplikací. Všechny aplikace běží na stejné sdílené sadě instancí virtuálních počítačů.

App Service poskytuje následující funkce redundance:

  • Distribuce napříč doménami selhání: Na úrovni platformy Azure automaticky distribuuje instance virtuálních počítačů plánu služby App Service napříč doménami selhání v rámci oblasti Azure. Tato distribuce minimalizuje riziko selhání lokalizovaného hardwaru seskupením virtuálních počítačů, které sdílejí společný zdroj napájení a síťový přepínač.

  • Distribuce napříč zónami dostupnosti: Pokud povolíte redundanci zón v podporovaném plánu služby App Service, Azure distribuuje vaše instance napříč zónami dostupnosti v rámci dané oblasti. Tato konfigurace poskytuje vyšší odolnost, pokud dojde k výpadku zóny. Další informace o redundanci zón najdete v tématu Podpora zón dostupnosti.

  • Škálování aplikace: Když nakonfigurujete plán služby App Service tak, aby spouštět více instancí virtuálních počítačů, všechny aplikace v plánu se ve výchozím nastavení spouštějí na všech instancích. Pokud nakonfigurujete plán automatického škálování, všechny aplikace horizontálně navyšte kapacitu společně na základě nastavení automatického škálování. Pomocí škálování jednotlivých aplikací ale můžete přizpůsobit, kolik instancí plánu spouští konkrétní aplikaci.

  • Jednotky škálování: App Service interně běží na infrastruktuře platformy označované jako jednotky škálování, označované také jako kolky nebo webspaces. Jednotka škálování zahrnuje všechny komponenty potřebné k hostování a spouštění služby App Service, včetně výpočetních prostředků, úložiště, sítí a vyrovnávání zatížení. Azure spravuje jednotky škálování, které zajišťují vyváženou distribuci úloh, provádějí rutinní údržbu a udržují celkovou spolehlivost platformy.

    Některé funkce se můžou použít jenom u konkrétních jednotek škálování. Některé jednotky škálování služby App Service můžou například podporovat redundanci zón, zatímco jiné jednotky škálování ve stejné oblasti ne.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátké, přerušované selhání v komponentách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly při komunikaci se všemi cloudovými rozhraními API, databázemi a dalšími komponentami postupovat podle pokynů pro zpracování přechodných chyb Azure. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

SDKs poskytnuté společností Microsoft obvykle zvládají přechodné chyby. Vzhledem k tomu, že hostujete vlastní aplikace ve službě App Service, proveďte kroky ke snížení pravděpodobnosti přechodných chyb:

  • Nasaďte ve svém plánu několik instancí. App Service provádí automatizované aktualizace a další formy údržby instancí ve vašem plánu. Pokud se instance stane nezdravou, může služba tuto instanci automaticky nahradit novou, zdravou instancí. Během procesu nahrazení může být krátké období, kdy předchozí instance není k dispozici a nová instance není připravená obsluhovat provoz. Pokud chcete tyto účinky zmírnit, nasaďte několik instancí plánu služby App Service.

  • Použijte nasazovací sloty. Sloty nasazení služby App Service umožňují nasazení aplikací bez výpadků. Pomocí slotů nasazení minimalizujte účinek nasazení a změn konfigurace pro vaše uživatele. Sloty nasazení také snižují pravděpodobnost restartování aplikace. Restartování aplikace způsobí přechodnou chybu.

  • Vyhněte se zvětšování nebo zmenšování. Tyto operace mění procesor, paměť a další prostředky přiřazené ke každé instanci a můžou aktivovat restartování aplikace. Místo toho vyberte úroveň a velikost instance, které splňují vaše požadavky na výkon při typickém zatížení. Pokud chcete škálovat na více instancí a škálovat je, dynamicky přidávat a odebírat instance pro zpracování změn v objemu provozu.

Odolnost proti chybám zóny dostupnosti

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

Pro úrovně Premium v2 až v4 můžete službu App Service nakonfigurovat jako zónově redundantní, což znamená, že vaše prostředky se distribuují napříč několika zónami dostupnosti. Distribuce napříč několika zónami pomáhá produkčním úlohám dosáhnout odolnosti a spolehlivosti. Při konfiguraci redundance zón v plánech služby App Service se všechny aplikace, které plán používají, stanou zónově redundantní.

Požadavky

Pokud chcete povolit redundanci zóny, musíte splnit následující požadavky:

Distribuce instancí napříč zónami

Když vytvoříte zónově redundantní plán služby App Service, Azure distribuuje instance plánu mezi zóny dostupnosti v dané oblasti. Tato distribuce zajišťuje, že vaše aplikace zůstanou dostupné, i když dojde k výpadku jedné zóny.

Distribuce instancí v zónově redundantním nasazení se řídí konkrétními pravidly. Tato pravidla platí také při horizontálním navýšení a snížení kapacity aplikace:

  • Minimální počet instancí: Pro redundanci zón musí mít váš plán služby App Service minimálně dvě instance.

  • Maximální počet zón dostupnosti podporovaných vaším plánem: Azure určuje počet zón dostupnosti, které váš plán může použít, což se označuje jako maximumNumberOfZones. Pokud chcete zobrazit počet zón dostupnosti, které může váš konkrétní plán používat, přečtěte si téma Kontrola podpory redundance zón pro plán služby App Service.

  • Distribuce instancí: Pokud je povolená redundance zón, Azure distribuuje instance plánu mezi více zón dostupnosti automaticky. Distribuce je založená na následujících pravidlech:

    • Pokud počet instancí překročí maximumNumberOfZones a rovnoměrně rozdělí, Azure tyto instance rovnoměrně distribuuje napříč zónami.

    • Pokud se počet instancí rovnoměrně nerozdělí, Azure distribuuje zbývající instance napříč zbývajícími zónami.

    • Když platforma App Service přiděluje instance pro zónově redundantní plán služby App Service, využívá vyrovnávání zátěže mezi zónami na základě dostupných možností, které poskytují základní škálovací sady virtuálních počítačů Azure. Plán je vyvážen, pokud má každá zóna stejný počet virtuálních počítačů nebo se liší o jednu instanci ze všech ostatních zón. Další informace najdete v tématu Vyrovnávání zóny.

  • Umístění fyzické zóny: Můžete zobrazit zónu fyzické dostupnosti používanou pro každou instanci plánu služby App Service. Další informace najdete v tématu Zobrazení fyzických zón pro plán služby App Service.

Úvahy

V případě plánů Premium v2 až v4 může výpadek zóny dostupnosti ovlivnit některé aspekty služby Azure App Service, i když aplikace dál obsluhuje provoz. Tyto chování zahrnují škálování plánu služby aplikace, vytváření aplikací, konfiguraci aplikací a publikování aplikací.

Když povolíte zónovou redundanci v plánu App Service Premium v2 až v4 , zvýšíte také odolnost při aktualizacích platformy. Další informace naleznete v tématu Odolnost vůči údržbě služby.

U plánů služby App Service, které nejsou nakonfigurované jako zónově redundantní, nejsou základní instance virtuálních počítačů odolné vůči selháním zóny dostupnosti. Mohou zaznamenat výpadek během poruchy v kterékoliv zóně v daném regionu.

Náklady

Pokud používáte plány App Service Premium v2 a v4, povolení zón dostupnosti nepřidá náklady, pokud máte dvě nebo více instancí. Poplatky vycházejí ze skladové položky plánu služby App Service, vámi zadané kapacity a všech instancí, na které škálujete na základě kritérií automatického škálování.

Pokud povolíte zóny dostupnosti, ale určíte kapacitu menší než dvě, platforma vynutí minimální počet instancí dvou. Platforma vám za tyto dvě instance účtuje poplatky.

Konfigurujte podporu zón dostupnosti

Plánování a řízení kapacit

Pokud se chcete připravit na selhání zóny dostupnosti, zvažte předimenzování kapacity plánu služby App Service. Tento přístup umožňuje řešení tolerovat určitou ztrátu kapacity a nadále fungovat bez snížení výkonu. Další informace najdete v tématu Správa kapacity pomocí nadměrného zřizování.

Chování, když jsou všechny zóny v pořádku

Následující seznam popisuje, co očekávat, když jsou plány služby App Service nakonfigurované pro redundanci zón a všechny zóny dostupnosti jsou funkční:

  • Směrování provozu mezi zónami: Během normálních operací se provoz směruje mezi všemi dostupnými instancemi plánu služby App Service napříč všemi zónami dostupnosti.

  • Replikace dat mezi zónami: Během normálních operací se všechny stavy uložené v systému souborů vaší aplikace ukládají v zónově redundantním úložišti a synchronně replikují mezi zónami dostupnosti.

Chování při selhání zóny

Výpadek zóny dostupnosti může mít vliv na některé aspekty služby App Service, i když aplikace dál obsluhuje provoz. Tyto chování zahrnují škálování plánu služby aplikace, vytváření aplikací, konfiguraci aplikací a publikování aplikací.

Následující seznam popisuje, co očekávat, když jsou plány služby App Service nakonfigurované pro redundanci zón a jedna nebo více zón dostupnosti není k dispozici:

  • Detekce a odpověď: Platforma App Service automaticky rozpozná selhání v zóně dostupnosti a zahájí odpověď. K zahájení převzetí služeb při selhání zóny se nevyžaduje žádný ruční zásah.

  • Aktivní požadavky: Všechny probíhající požadavky, které se připojují k instanci plánu služby App Service v zóně vadné dostupnosti, se ukončí. Zkuste tyto žádosti zopakovat.

  • Přesměrování provozu: App Service zjistí ztracené instance z této zóny a pokusí se najít nové náhradní instance. Jakmile Služba App Service najde náhrady, podle potřeby distribuuje provoz mezi nové instance.

    Pokud je automatické škálování nakonfigurované a určuje, že je potřeba více instancí, vyžádá si instance ze služby App Service. Chování automatického škálování funguje nezávisle na chování platformy služby App Service. Specifikace počtu instancí proto nemusí být násobkem dvou. Další informace najdete v tématu Vertikální navýšení kapacity aplikace ve službě App Service a přehledu automatického škálování.

    Důležité

    Azure nezaručuje, že požadavky na další instance budou v situaci mimo zónu úspěšné. Platforma se pokusí o obnovení ztracených instancí na základě maximálního úsilí. Pokud potřebujete garantovanou kapacitu během selhání zóny dostupnosti, vytvořte a nakonfigurujte plány služby App Service tak, aby zohlednily ztrátu zón tím, že kapacitu zřídíte.

  • Nesvícené chování: Aplikace v zónově redundantním plánu služby App Service se budou dál spouštět a obsluhovat provoz, i když dojde k výpadku zóny dostupnosti. Chování, které neprobíhá v době běhu, však mohou být během výpadku zóny dostupnosti ovlivněna. Tyto chování zahrnují škálování plánu služby aplikace, vytváření aplikací, konfiguraci aplikací a publikování aplikací.

Obnovení zóny

Když se zóna dostupnosti obnoví, App Service automaticky vytvoří instance v obnovené zóně dostupnosti, odebere všechny dočasné instance vytvořené v ostatních zónách dostupnosti a směruje provoz mezi vašimi instancemi obvyklým způsobem.

Testování poruch zón

Platforma App Service spravuje směrování provozu, automatické převzetí služeb při selhání a obnovení provozu pro zónově redundantní plány App Service. Tato funkce je plně spravovaná, takže nemusíte zahajovat ani ověřovat procesy selhání zóny dostupnosti.

Odolnost proti selháním v celé oblasti

App Service je služba s jednou oblastí. Pokud se oblast stane nedostupnou, vaše aplikace bude také nedostupná.

Vlastní řešení pro více regionů pro odolnost systémů

Pokud chcete snížit riziko selhání jedné oblasti ovlivňující vaši aplikaci, můžete nasadit plány napříč několika oblastmi. Následující kroky pomáhají posílit odolnost:

  • Nasaďte aplikaci do plánů v jednotlivých oblastech.
  • Nakonfigurujte politiky rozložení zátěže a převzetí služeb při selhání.
  • Replikujte data napříč oblastmi, abyste mohli obnovit poslední stav aplikace.

Zvažte následující související zdroje informací:

Zálohování a obnovení

Pokud používáte úroveň Basic nebo vyšší, můžete zálohovat aplikace App Service do souboru pomocí funkcí zálohování a obnovení služby App Service.

Tyto funkce pomáhají, když je obtížné znovu nasadit kód nebo když ukládáte stav na disk. Většina řešení by se neměla spoléhat výhradně na zálohy. Místo toho využijte další funkce v této příručce k podpoře vašich požadavků na odolnost. Zálohy ale chrání před některými riziky, která jiné přístupy nechrání.

Důležité

Od 31. března 2028 už vlastní zálohy služby Azure App Service nepodporují zálohování propojených databází. Další informace najdete v tématu Vyřazení záloh propojených databází .

Místo toho použijte nativní nástroje pro zálohování a obnovení propojené databáze. Další informace najdete v tématu Zálohování a obnovení aplikace ve službě App Service.

Odolnost vůči údržbě služeb

App Service provádí pravidelné upgrady služeb a další úlohy údržby. Aby se během upgradu zachovala očekávaná kapacita, platforma během procesu upgradu automaticky přidá další instance plánu služby App Service.

Povolte zónovou redundanci. Když v plánu služby App Service povolíte redundanci zón, zlepšíte také odolnost při aktualizacích platformy. Aktualizační domény se skládají z kolekcí virtuálních počítačů, které během aktualizace přecházejí do režimu offline, a mapují se na zóny dostupnosti. Nasazení několika instancí v plánu služby App Service a povolení redundance zón pro váš plán přidá další vrstvu odolnosti v případě, že instance nebo zóna během upgradu není v pořádku.

Další informace najdete v tématu Rutinní plánovaná údržba služby App Service a rutinní údržba pro službu App Service, restartování a výpadek.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu Smlouvy SLA pro online služby.

Když nasadíte plán App Service odolný vůči zónám, procento dostupnosti definované ve SLA se zvýší.

Související obsah

  • Last updated on