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?

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. Informace o nasazení této konfigurace najdete v tématu [Více virtuálních počítačů pro zajištění škálovatelnosti a dostupnosti][podrobný plán pro více virtuálních počítačů].

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

Ř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 používáte Traffic Manager 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. Použijte Traffic Manager k převzetí služeb při selhání front-endu. Pokud se front-end v jedné oblasti stane nedostupný, Traffic Manager bude směrovat nové žádosti 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í. Traffic Manager použijte pro automatické převzetí služeb při selhání, ale ne pro automatické 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. V závislosti na databázi můžete také před navrácení služeb zpět zkontrolovat konzistenci dat.

Pokud toho chcete dosáhnout, zakažte primární koncový bod Traffic Manageru 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.

Vytvořte redundanci pro Traffic Manager. Traffic Manager je možným bodem selhání. Zkontrolujte smlouvu SLA pro Traffic Manager a rozhodněte se, zda použití samotného Traffic Manageru splňuje vaše podnikové požadavky na vysokou dostupnost. Pokud ne, zvažte přidání jiného řešení správy provozu jako navrácení služeb po obnovení. Pokud služba Azure Traffic Manager selže, změňte záznamy CNAME v DNS tak, aby odkazovaly na jinou službu pro správu provozu.