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ž subsystém selže, přenechá aplikace služby při selhání něčeho jiného?

Doporučení

Zvažte obchodní požadavky. Objem redundance integrovaný do systému může ovlivnit náklady i složitost. Architektura by měla vycházet z vašich obchodních požadavků, jako je například plánovaná doba obnovení (RTO). Například nasazení ve více oblastech je rozsáhlejší než nasazení v jedné oblasti a je složitější ho spravovat. Budete potřebovat provozní postupy pro převzetí služeb při selhání a navrácení služeb po obnovení. Další náklady a složitost můžou být akceptovatelné pro některé obchodní scénáře, ale ne pro jiné.

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 popisu více virtuálních počítačů pro škálovatelnost a dostupnost.

Replikujte databáze. Azure SQL Database a Cosmos DB automaticky replikují data v rámci oblasti a je možné povolit i geografickou replikaci mezi oblastmi. Pokud používáte databázové řešení IaaS, zvolte takové, které podporuje replikaci a převzetí služeb při selhání, například SQL Server dostupnosti Always On.

Povolte geografickou replikaci. Geografická replikace pro Azure SQL Database a Cosmos DB vytvoří sekundární čitelné repliky vašich dat v jedné nebo několika sekundárních oblastech. V případě výpadku může dojít k převzetí služby při selhání sekundární oblastí pro zápis.

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

Nasazení proveďte do více než jedné oblasti. Kvůli nejvyšší dostupnosti nasaďte aplikaci do více než jedné oblasti. Tímto způsobem může aplikace ve výjimečných případech, kdy problém ovlivňuje celou oblast, převzít služby při selhání v jiné oblasti. 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í.

Synchronizujte převzetí služeb při selhání front-endu a back-endu. Azure Traffic Manager slouží k převzít služby 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 databázovém řešení budete muset koordinovat přebírání služeb při selhání databáze.

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.

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.