Redundance všech položek

Vaše aplikace by měla být redundantní, abyste se vyhnuli kritickým prvkům způsobujícím selhání.

Odolné aplikace se vyhýbají selháním. Identifikujte kritické cesty ve vaší aplikaci. Existuje ke každému bodu v cestě redundance? Když dojde k selhání subsystému, aplikace převezme služby při selhání na něco jiného?

V dokonalé implementaci může přidání jednotné redundance exponenciálně zvýšit dostupnost systému. Představte si například, že máte N ekvivalentní rovnoměrně vyvážené komponenty, které:

• může nezávisle na sobě a současně odebrat z fondu
• mají stejný stav nebo žádný stav
• nemá žádnou probíhající práci, která je trvale ztracena během poruchy
• jsou identické ve funkcích.
• navzájem nemají žádné závislosti
• zpracovává snížení kapacity bez další poruchy.

Pokud má každá jednotlivá komponenta Adostupnost , lze celkovou dostupnost systému vypočítat pomocí vzorce 1 - (1 - A)^N.

Doporučení

Zvažte obchodní požadavky. Objem redundance integrovaný do systému může ovlivnit náklady i složitost. Vaše architektura by měla být informována vašimi obchodními požadavky, jako je cíl doby obnovení (RTO) a cíl bodu obnovení (RPO). Měli byste také zvážit požadavky na výkon a schopnost vašeho týmu spravovat složité sady prostředků.

Zvažte architekturu s více zónami a více oblastmi. Ujistěte se, že rozumíte tomu, jak zóny dostupnosti a oblasti poskytují odolnost a různé sady kompromisů architektury.

Zóny dostupnosti Azure jsou izolované sady datových center v rámci oblasti. Pomocí zón dostupnosti můžete být odolní vůči selháním jednoho datového centra nebo celé zóny dostupnosti. Zóny dostupnosti můžete využít k kompromisům mezi náklady, zmírněním rizik, výkonem a obnovitelností. Když například ve své architektuře používáte zónově redundantní služby, Azure poskytuje automatickou replikaci dat a převzetí služeb při selhání mezi geograficky oddělenými instancemi, což snižuje řadu různých typů rizik.

Pokud máte kritickou úlohu a potřebujete zmírnit riziko výpadku na úrovni celé oblasti, zvažte nasazení ve více oblastech. Nasazení ve více oblastech vás chrání před regionálními katastrofami, ale stojí za to. Nasazení ve více oblastech jsou dražší než nasazení v jedné oblasti a jejich správa je složitější. Budete potřebovat provozní postupy pro zpracování převzetí služeb při selhání a navrácení služeb po obnovení. V závislosti na požadavcích na cíl bodu obnovení možná budete muset přijmout mírně nižší výkon, abyste umožnili replikaci dat mezi oblastmi. Další náklady a složitost můžou být u některých obchodních scénářů odůvodněny.

Tip

Pro mnoho úloh poskytuje zónově redundantní architektura nejlepší sadu kompromisů. Pokud vaše obchodní požadavky naznačují, že potřebujete zmírnit nepravděpodobné riziko výpadku na úrovni celé oblasti, zvažte architekturu s více oblastmi a pokud jste připraveni přijmout kompromisy, které jsou součástí takového přístupu.

Další informace o tom, jak navrhnout řešení tak, aby používalo zóny dostupnosti a oblasti, najdete v tématu Doporučení pro používání zón dostupnosti a oblastí.

Umístěte virtuální počítače za nástroj pro vyrovnávání zatížení. Nepoužívejte pro kritické úlohy jeden virtuální počítač. Místo toho umístíte víc virtuálních počítačů za nástroj pro vyrovnávání zatížení. Pokud se některý virtuální počítač stane nedostupným, nástroj pro vyrovnávání zatížení distribuuje provoz na zbývající funkční virtuální počítače.

Replikujte databáze. Azure SQL Database a Azure Cosmos DB automaticky replikují data v rámci oblasti a je možné je nakonfigurovat tak, aby se replikovaly napříč zónami dostupnosti, aby se zajistila vyšší odolnost. Můžete také povolit geografickou replikaci napříč oblastmi. Geografická replikace pro Azure SQL Database a Azure Cosmos DB vytváří sekundární čitelné repliky vašich dat v jedné nebo více sekundárních oblastech. Pokud dojde k výpadku v primární oblasti, může databáze převzít služby při selhání sekundární oblasti pro zápisy. V závislosti na konfiguraci replikace můžete zaznamenat ztrátu dat z nereplicitovaných transakcí.

Pokud používáte databázové řešení IaaS, zvolte jedno, které podporuje replikaci a převzetí služeb při selhání, jako jsou skupiny dostupnosti AlwaysOn SQL Serveru.

Vytvořte oddíly kvůli dostupnosti. Vytváření oddílů databáze se často používá ke zlepšení škálovatelnosti, ale může také zvýšit dostupnost. Pokud jeden z horizontálních oddílů přestane fungovat, jsou ostatní horizontální oddíly pořád dostupné. Selhání v jednom horizontálním oddílu naruší jenom podmnožinu celkového počtu transakcí.

Otestujte a ověřte redundantní komponenty. Výhody spolehlivosti mnoha způsoby od jednoduchosti a zvýšení redundance můžou zvýšit složitost. Pokud chcete zajistit, aby přidání redundance skutečně vede k vyšší dostupnosti, měli byste ověřit následující:

• Dokáže váš systém spolehlivě rozpoznat v pořádku a nezdravé redundantní komponenty a bezpečně a rychle je odebrat z fondu komponent?
• Dokáže váš systém spolehlivě škálovat kapacitu a v redundantních komponentách?
• Dokáže vaše rutinní, ad hoc a nouzové operace úloh zvládnout redundanci?

Řešení pro více oblastí

Následující diagram znázorňuje aplikaci ve více oblastech, která používá Azure Traffic Manager pro zpracování převzetí služeb při selhání.

Pokud jako mechanismus směrování převzetí služeb při selhání používáte Traffic Manager nebo Azure Front Door v řešení s více oblastmi, zvažte následující doporučení:

Synchronizujte převzetí služeb při selhání front-endu a back-endu. Pomocí mechanismu směrování můžete převzít služby při selhání front-endu. Pokud front-end přestane být v jedné oblasti nedostupný, bude převzetí služeb při selhání směrovat nové požadavky do sekundární oblasti. V závislosti na back-endových komponentách a databázovém řešení možná budete muset koordinovat převzetí služeb při selhání back-endových služeb a databází.

Použijte automatické převzetí služeb při selhání, ale ruční navrácení služeb po obnovení. Použijte automatizaci pro převzetí služeb při selhání, ale ne pro navrácení služeb po obnovení. Automatické navrácení služeb po obnovení představuje riziko, že můžete přepnout na primární oblast předtím, než je oblast úplně v pořádku. Před navrácením služeb po obnovení proto ověřte, že všechny subsystémy aplikace jsou v pořádku. Před navrácením služeb po obnovení byste také měli zkontrolovat konzistenci dat.

Pokud toho chcete dosáhnout, zakažte primární koncový bod po převzetí služeb při selhání. Všimněte si, že pokud je interval monitorování sond krátký a tolerovaný počet selhání je malý, převzetí služeb při selhání a navrácení služeb po obnovení proběhne za krátkou dobu. V některýchpřípadechch Pokud se chcete vyhnout nepotvrzeným navrácení služeb po obnovení, zvažte také implementaci koncového bodu stavu, který může ověřit, že jsou všechny subsystémy v pořádku. Podívejte se na model monitorování koncových bodů stavu.

Zahrňte redundanci pro vaše řešení směrování. Zvažte návrh řešení redundance globálního směrování pro klíčové webové aplikace.