Návrh spolehlivých aplikací Azure

Vytváření spolehlivých aplikací v cloudu se liší od tradičního vývoje aplikací. I když jste si v minulosti možná zakoupili úrovně redundantního hardwaru vyšší kategorie, abyste minimalizovali riziko selhání celé aplikační platformy, v cloudu si předem uvědomujeme, že k selhání dojde. Místo snahy kompletně zabránit selháním je cílem minimalizace dopadu selhání jedné komponenty. Selhání, která tady můžete očekávat, jsou inherentní vysoce distribuným systémům, nikoli funkci Azure.

Klíčové body

• Pokud Zóny dostupnosti používejte ke zlepšení spolehlivosti a optimalizaci nákladů.
• Navrhujte aplikace tak, aby v případě selhání šly fungovat.
• Využijte nativní možnosti odolnosti PaaS k zajištění celkové spolehlivosti aplikací.
• Návrh pro horizontální navýšení velikosti.
• Ověřte, že požadovaná kapacita je v rámci limitů a kvót škálování služeb Azure.

Použití Zóny dostupnosti v rámci oblasti

Pokud vaše požadavky vyžadují ještě větší izolaci selhání, než Zóny dostupnosti může nabídnout samotná služba, zvažte nasazení do více oblastí. Pro účely převzetí služeb při selhání ve stavu havárie by se mělo používat více oblastí. Je potřeba vzít v úvahu další náklady. Příkladem požadavků na náklady jsou data a sítě a služby, jako je Azure Site Recovery.

Navrhovat architekturu aplikace tak, Zóny dostupnosti v rámci oblasti Zóny dostupnosti lze použít k optimalizaci dostupnosti aplikací v rámci oblasti tím, že poskytuje odolnost proti chybám na úrovni datacentra. Architektura aplikace ale nesmí sdílet závislosti mezi zónami, aby je bylo možné efektivně používat.

Zvažte, jestli se kvůli výkonu aplikace vyžaduje blízkost komponent. Pokud je veškerá aplikace nebo část aplikace vysoce citlivá na latenci, může ovat spolu localitu komponent, která může omezit použitelnost strategií pro více oblastí a více zón.

Reakce na selhání

Ve veřejném cloudu není možné zabránit selhání, a proto aplikace vyžadují odolnost, aby reagovaly na výpadky a doručují spolehlivost. Aplikace by proto měla být navržená tak, aby provoz byla ovlivněna selháním místních, zónových, služeb nebo komponent napříč kritickými aplikačními scénáři a funkcemi. U operací aplikací může během výpadku docházet ke snížení funkčnosti nebo snížení výkonu.

Definujte strategii dostupnosti, která bude zachytávání toho, jak aplikace zůstane dostupná, když je ve stavu selhání. Měl by platit pro všechny komponenty aplikace a razítko nasazení aplikace jako celek, například nasazování více geografických jednotek. Mají to také dopad na náklady: Aby bylo možné zajistit vysokou dostupnost, je potřeba předem zřídit další prostředky. Nastavení aktivní-aktivní, přestože je nákladnější než jedno nasazení, dokáže vyvážit náklady snížením zatížení na jednom kolku a snížením celkového množství potřebných prostředků.

Kromě strategie dostupnosti definujte strategii bcdr (Business Continuity Disaster Recovery) pro aplikaci nebo její klíčové scénáře. Strategie zotavení po havárii by měla zachycovat, jak aplikace reaguje na situaci havárie, jako je oblastní výpadk nebo ztráta důležité služby platformy, a to buď pomocí opětovného nasazení, aktivního-pasivního řešení s teplou rezervou nebo přístupu aktivní-aktivní vytížené za provozu.

Pokud chcete náklady seskupit, zvažte rozdělení komponent aplikace a dat do skupin. Například:

• Musí chránit
• Je dobré chránit
• Dočasné/je možné je znovu vytvořit nebo ztratit místo ochrany všech dat pomocí stejné zásady.

Důležité informace o zlepšení spolehlivosti

Je aplikace navržená k používání spravovaných služeb?

Spravované služby Azure poskytují nativní možnosti odolnosti, které podporují celkovou spolehlivost aplikací. K využívání těchto možností by se měly použít nabídky PaaS (platforma jako služba). Možnosti PaaS se snadněji konfiguruje a spravují. Nemusíte zřizovat virtuální počítače, nastavovat virtuální sítě, spravovat opravy a aktualizace a starat se o ostatní režii spojenou se spouštěním softwaru na virtuálním počítači. Další informace najdete v tématu Použití spravovaných služeb.

Byla aplikace navržena pro horizontální navýšení velikosti?

Azure poskytuje elastickou škálovatelnost a měli byste navrhnout horizontální navýšení velikosti. Aplikace ale musí k procházení limitů služeb a předplatných využívat přístup škálovací jednotky, aby se zajistilo, že jednotlivé komponenty a aplikace jako celek se mohou škálovat horizontálně. Nezapomeňte na horizontální snížení velikosti, což je důležité ke snížení nákladů. Například horizontální navýšení a navýšení velikosti pro App Service se provádí prostřednictvím pravidel. Zákazníci často zapisují pravidla horizontálního navýšení velikosti a nikdy nezapisují pravidla horizontálního navýšení velikosti. To ponechává App Service nákladnější.

Je aplikace nasazená ve více předplatných Azure?

Při analýze, jestli je možné procházet relevantní limity nebo kvóty předplatného, je důležité porozumět prostředí předplatného aplikace a způsobu uspořádání komponent v rámci předplatných nebo napříč předplatným. Zkontrolujte limity předplatného a služeb Azure a ověřte, že požadovaná kapacita je v rámci limitů a kvót škálování služeb Azure. Další informace najdete v tématu Limity předplatného a služeb Azure.

Další krok

Související odkazy

• Informace o minimalizaci závislostí najdete v tématu Minimalizace koordinace.
• Další informace o bodech selhání a režimech selhání najdete v tématu Analýza režimu selhání pro aplikace Azure.
• Informace o spravovaných službách najdete v tématu Použití možností paaS (platformajako služba).

Zpět k hlavnímu článku: Návrh