Sdílet prostřednictvím

Doporučení pro návrh redundance

  • Článek

vztahuje se na toto doporučení seznamu pro spolehlivost v rámci architektury Azure Well-Architected Framework:

RE:05 přidat redundanci na různých úrovních, zejména pro kritické toky, aby bylo možné splnit cíle spolehlivosti. Zvažte redundantní komponenty infrastruktury, jako jsou výpočetní prostředky a síť, a několik instancí vašeho řešení.

Související příručky:vysoce dostupný multiregionální design | Používání zón dostupnosti a oblastí

Tato příručka popisuje doporučení pro přidání redundance v rámci kritických toků v různých vrstvách úloh, což optimalizuje odolnost. Splnění požadavků definovaných cílů spolehlivosti použitím správných úrovní redundance na výpočetní prostředky, data, sítě a další úrovně infrastruktury. Využijte tuto redundanci, abyste svým úlohám poskytli silnou a spolehlivou základnu, na které můžete stavět. Při sestavování úloh bez redundance infrastruktury hrozí vysoké riziko delšího výpadku kvůli potenciálním selháním.

definice

Termín Definice
Nadbytečnost Implementace více identických instancí komponenty pracovního zatížení.
Polyglotní trvalost Koncept použití různých technologií úložiště stejnou aplikací nebo řešením k využití nejlepších možností jednotlivých komponent.
Konzistence dat Míra toho, nakolik je daná datová sada synchronizovaná či nesynchronizovaná v různých úložištích.
Rozkládání Proces fyzického rozdělení dat do samostatných úložišť dat.
Střep Strategie horizontálního dělení databáze, která podporuje více instancí úložiště se společným schématem. Data se ve všech instancích nereplikují.

Klíčové strategie návrhu

V kontextu spolehlivosti použijte redundanci k tomu, aby obsahovala problémy, které mají vliv na jeden prostředek, a ujistěte se, že tyto problémy nemají vliv na spolehlivost celého systému. Pomocí informací, které jste identifikovali o důležitých tocích a cílech spolehlivosti, můžete provádět informovaná rozhodnutí, která jsou nutná pro redundanci jednotlivých toků.

Můžete mít například několik uzlů webového serveru spuštěných najednou. Důležitost toku, který podporují, může vyžadovat, aby všichni z nich měli repliky připravené k přijetí provozu, pokud dojde k problému, který ovlivňuje celý fond, například regionální výpadek. Alternativně, protože rozsáhlé problémy jsou vzácné a je nákladné nasadit celou sadu replik, můžete nasadit omezený počet replik, aby tok fungoval ve sníženém stavu, dokud problém nevyřešíte.

Když navrhujete redundanci v kontextu efektivity výkonu, distribuujte zatížení mezi několik redundantních uzlů, abyste zajistili optimální výkon každého uzlu. V souvislosti se spolehlivostí sestavte volnou kapacitu tak, aby absorbovaly selhání nebo poruchy, které ovlivňují jeden nebo více uzlů. Ujistěte se, že náhradní kapacita dokáže absorbovat selhání po celou dobu potřebnou k obnovení ovlivněných uzlů. S tímto rozdílem musí obě strategie spolupracovat. Pokud rozdělíte provoz mezi dva uzly kvůli výkonu a oba běží s 60% využitím a jeden uzel selže, je váš zbývající uzel ohrožen přetížením, protože nemůže fungovat na 120 procent. Rozložte zatížení na jiný uzel, abyste zajistili, že vaše výkonové a spolehlivostní cíle budou zachovány.

Kompromisy:

  • Větší redundance úloh odpovídá většímu počtu nákladů. Pečlivě zvažte přidání redundance a pravidelně prověřujte svou architekturu, abyste měli jistotu, že zajišťujete správnou správu nákladů, zejména když používáte nadbytečné kapacity. Pokud používáte overprovisioning jako strategii odolnosti, vyvažte toto dobře definovanou strategií škálování , abyste minimalizovali neefektivity nákladů.
  • Při sestavování ve vysokém stupni redundance může dojít k kompromisům z hlediska výkonu. Například prostředky, které se šíří mezi zónami dostupnosti nebo oblastmi, můžou ovlivnit výkon, protože musíte odesílat provoz přes připojení s vysokou latencí mezi redundantními prostředky, jako jsou webové servery nebo databázové instance.
  • Různé toky ve stejné úloze můžou mít různé požadavky na spolehlivost. Návrhy redundance specifické pro toky můžou potenciálně zavádět do celkového návrhu složitost.

Návrh redundantní architektury

Při návrhu redundantní architektury zvažte dva přístupy: aktivní-aktivní nebo aktivní-pasivní. Zvolte svůj přístup v závislosti na závažnosti toku uživatele a systémového toku, který komponenty infrastruktury podporují. Z hlediska spolehlivosti vám návrh s více oblastmi aktivní-aktivní pomáhá dosáhnout nejvyšší možné úrovně spolehlivosti, ale je výrazně dražší než aktivní-pasivní návrh. Rozhodování o vhodných geografických oblastech se stane další kritickou volbou. Tyto přístupy k návrhu můžete použít také pro jednu oblast pomocí zón dostupnosti. Další informace najdete v tématu Doporučení pro vysoce dostupný víceregionální návrh.

Razítka nasazení a jednotky škálování

Bez ohledu na to, zda nasazujete v modelu aktivní-aktivní nebo aktivní-pasivní, postupujte podle vzoru návrhu Razítka nasazení, abyste zajistili, že nasazujete úlohy opakovatelným a škálovatelným způsobem. Razítka nasazení jsou seskupení prostředků, které jsou potřeba k doručení vaší úlohy do dané podmnožiny vašich zákazníků. Podmnožinou může být například oblastní podmnožina nebo podmnožina se stejnými požadavky na ochranu osobních údajů dat jako vaše úloha. Každé razítko si můžete představit jako jednotku škálování, kterou můžete duplikovat, abyste mohli škálovat úlohy horizontálně nebo provádět modrá-zelená nasazení. Navrhněte svou úlohu s razítky nasazení, abyste optimalizovali implementaci aktivní-aktivní nebo aktivní-pasivní pro zajištění odolnosti a zátěže správy. Plánování horizontálního navýšení kapacity pro více oblastí je také důležité k překonání potenciálních dočasných omezení kapacity prostředků v oblasti.

Zóny dostupnosti v rámci oblastí Azure

Bez ohledu na to, jestli nasadíte návrh typu aktivní-aktivní nebo aktivní-pasivní, využijte zón dostupnosti v rámci aktivních oblastí, abyste plně optimalizovali odolnost. Mnoho oblastí Azure poskytuje několik zón dostupnosti, které jsou oddělené skupiny datových center v rámci oblasti. V závislosti na službě Azure můžete využívat zóny dostupnosti tím, že nasadíte prvky úlohy redundantně napříč zónami nebo připnete prvky do konkrétních zón. Další informace najdete v tématu Doporučení pro použití zón dostupnosti a oblastí.

Implementace redundance zón pro výpočetní prostředky

  • Zvolte odpovídající výpočetní službu pro vaši úlohu. V závislosti na typu úlohy, kterou navrhujete, může být k dispozici několik možností. Seznamte se s dostupnými službami a zjistěte, které typy úloh fungují nejlépe na dané výpočetní službě. Například úlohy SAP jsou obvykle nejvhodnější pro výpočetní služby typu infrastruktura jako služba (IaaS). U kontejnerizované aplikace určete konkrétní funkce, které potřebujete mít pod kontrolou, abyste zjistili, jestli se má použít Azure Kubernetes Service (AKS) nebo řešení PaaS (platforma jako služba). Vaše cloudová platforma plně spravuje službu PaaS.

  • Pokud to vaše požadavky umožňují, použijte možnosti výpočetních prostředků PaaS. Azure plně spravuje služby PaaS, což snižuje vaši správní zátěž, a je zabudována zdokumentovaná úroveň redundance.

  • Škálovací sady virtuálních počítačů Azure použijte, pokud potřebujete nasadit virtuální počítače. Pomocí škálovacích sad virtuálních počítačů můžete automaticky rozprostřet výpočetní prostředky rovnoměrně mezi zóny dostupnosti.

  • Udržujte výpočetní vrstvu čistou od jakéhokoli stavu, protože jednotlivé uzly, které obsluhují požadavky, mohou být kdykoli odstraněny, poruchové nebo nahrazené.

  • Pokud je to možné, používejte zónově redundantní služby, abyste zajistili vyšší odolnost bez zvýšení provozní zátěže.

  • Nadprovisionování kritických prostředků ke zmírnění selhání redundantních instancí, a to i před zahájením operací automatického škálování, zajišťuje, že systém zůstane funkční i po výpadku komponenty. Vypočítejte přijatelný dopad chyby při zapojení přerozdělování zdrojů do návrhu redundance. Stejně jako u rozhodovacího procesu ohledně redundantnosti určují vaše cíle spolehlivosti a rozhodnutí o finančních kompromisech, do jaké míry přidáváte volnou kapacitu pomocí nadměrného zajištění. Nadměrné zřizování se konkrétně týká škálování, což znamená přidání dalších instancí daného typu výpočetního prostředku, namísto zvýšení výpočetních schopností jednotlivé instance. Pokud například změníte virtuální počítač ze skladové položky nižší vrstvy na skladovou položku vyšší úrovně.

  • Služby IaaS nasaďte ručně nebo prostřednictvím automatizace v každé zóně nebo oblasti dostupnosti, ve které chcete řešení implementovat. Některé služby PaaS mají integrované funkce, které se automaticky replikují napříč zónami a oblastmi dostupnosti.

Zavedení zónové redundance pro datové prostředky

  • Určete, jestli je pro funkčnost vaší úlohy nezbytná synchronní nebo asynchronní replikace dat. Pokud chcete toto určení usnadnit, podívejte se na Doporučení pro používání zón dostupnosti a oblastí.

  • Zvažte míru růstu vašich dat. V případě plánování kapacity naplánujte růst dat, uchovávání dat a archivaci, abyste zajistili splnění požadavků na spolehlivost při nárůstu množství dat ve vašem řešení.  

  • Geograficky distribuujte data podle podpory vaší služby, abyste minimalizovali dopad geograficky lokalizovaných selhání.

  • Replikace dat napříč geografickými oblastmi za účelem zajištění odolnosti vůči oblastním výpadkům a katastrofickým selháním.

  • Automatizovat převzetí funkcí po selhání instance databáze. Automatické převzetí služeb při selhání můžete nakonfigurovat ve více datových službách Azure PaaS. Automatické přepnutí při selhání není vyžadováno pro úložiště dat, která podporují zápisy do více regionů, jako je Azure Cosmos DB. Další informace najdete v tématu Doporučení pro návrh strategie zotavení po havárii.

  • Pro svá data používejte nejlepší úložiště dat. Využijte polyglotní trvalost nebo řešení, která používají kombinaci technologií úložiště dat. Data zahrnují více než jen trvalá data aplikace. Zahrnuje také protokoly aplikací, události, zprávy a mezipaměti.

  • Zvažte požadavky na konzistenci dat a použijte konečnou konzistenci, pokud to požadavky umožňují. Při distribuci dat použijte odpovídající koordinaci k vynucení záruk silné konzistence. Koordinace může snížit propustnost a způsobit, že vaše systémy budou úzce propojené, což může způsobit, že budou křehčí. Pokud například operace aktualizuje dvě databáze, místo aby ji umístila do jednoho oboru transakce, je lepší, pokud systém dokáže přizpůsobit konečnou konzistenci.

  • Rozdělte data pro dostupnost. dělení databáze zlepšuje škálovatelnost a může také zlepšit dostupnost. Pokud jeden fragment selže, ostatní fragmenty jsou stále dostupné. Selhání v jednom shardu přeruší pouze podmnožinu celkových transakcí.

  • Pokud horizontální dělení není možné, můžete pomocí vzoru Command and Query Responsibility Segregation (CQRS) oddělit datové modely pro čtení a zápis a pouze pro čtení. Přidejte další redundantní databázové instance jen pro čtení, abyste zajistili větší odolnost.  

  • Seznamte se s integrovanými možnostmi replikace a redundance služeb stavové platformy, které používáte. Konkrétní možnosti redundance stavových datových služeb najdete v tématu související odkazy.

Implementace redundance zón pro síťové prostředky

  • Rozhodněte se o spolehlivé a škálovatelné síťové topologii. Používejte hvězdicový model nebo model Azure Virtual WAN, který vám pomůže uspořádat cloudovou infrastrukturu v logických vzorech, které usnadňují sestavování a škálování návrhu redundance.

  • Vyberte odpovídající síťovou službu pro vyrovnávání a přesměrování požadavků v rámci oblastí. Pokud je to možné, použijte globální nebo zónově redundantní služby vyrovnávání zatížení, abyste splnili cíle spolehlivosti.

  • Ujistěte se, že jste ve virtuálních sítích a podsítích přidělili dostatečný adresní prostor IP adres pro účely plánovaného využití, včetně požadavků na horizontální navýšení kapacity.

  • Ujistěte se, že aplikace může škálovat v rámci limitů portů zvolené platformy pro hostování aplikací. Pokud aplikace zahájí několik odchozích připojení TCP nebo UDP, může vyčerpat všechny dostupné porty a způsobit nízký výkon aplikace.

  • Zvolte skladové položky a nakonfigurujte síťové služby, které můžou splňovat vaše požadavky na šířku pásma a dostupnost. Propustnost brány VPN se liší podle jejich skladové položky. Podpora redundance zón je dostupná pouze pro určité typy modelů nástroje pro vyrovnávání zatížení.

  • Ujistěte se, že je váš návrh pro zpracování DNS sestavený se zaměřením na odolnost a podporuje redundantní infrastrukturu.

Usnadnění pro Azure

Platforma Azure pomáhá optimalizovat odolnost vaší úlohy a přidat redundanci:

Usnadnění specifické pro DNS Azure

  • Pro scénáře interního překladu názvů použijte privátní zóny Azure DNS, které mají integrovanou redundanci zón a geografickou redundanci. Další informace najdete v tématu odolnost privátní zóny Azure DNS.

  • Pro scénáře překladu externích názvů použijte veřejné zóny Azure DNS, které mají integrovanou redundanci zón a geografickou redundanci.

  • Veřejné a privátní služby Azure DNS jsou globální služby odolné vůči oblastním výpadkům, protože data zón jsou globálně dostupná.

  • Pro scénáře hybridního překladu názvů mezi místním a cloudovým prostředím použijte Azure DNS Private Resolver. Tato služba podporuje redundanci zón, pokud je vaše úloha umístěná v oblasti, která podporuje zóny dostupnosti. Výpadek na úrovni zóny nevyžaduje během obnovení zóny žádnou akci. Služba se automaticky sama opravuje a přizpůsobuje, aby efektivně využila zdravou zónu. Další informace viz Odolnost v Azure DNS Private Resolver.

  • Pokud chcete odstranit jediný bod selhání a dosáhnout odolnějšího hybridního překladu ip adres napříč oblastmi, nasaďte dva nebo více privátních překladačů Azure DNS napříč různými oblastmi. Převzetí služeb při selhání DNS ve scénáři podmíněného předávání se dosahuje přiřazením překladače jako primárního serveru DNS. Přiřaďte druhý resolver v jiném regionu jako sekundární server DNS. Další informace najdete v tématu Nastavení převzetí služeb při selhání DNS pomocí privátních překladačů.

Příklad

Příklad nasazení s více oblastmi a redundancí najdete v tématu Základní parametry vysoce dostupné webové aplikace s redundancí zón.

Následující diagram znázorňuje další příklad:

diagram znázorňující architekturu referenční implementace

Další informace o redundanci najdete v následujících zdrojích informací:

Kontrolní seznam pro spolehlivost

Projděte si kompletní sadu doporučení.

kontrolní seznam spolehlivosti