Doporučení pro navrhování s využitím redundance

Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury Azure Well-Architected:

RE:05 Přidejte redundanci na různých úrovních, zejména pro kritické toky. Použijte redundanci na výpočetní, datovou, síťovou a další vrstvu infrastruktury v souladu s určenými cíli spolehlivosti.

Související průvodci:Návrh s vysokou dostupností | ve více oblastechPomocí zón dostupnosti a oblastí

Tento průvodce popisuje doporučení pro přidání redundance v rámci kritických toků na různých vrstvách úloh, což optimalizuje odolnost. Splněte požadavky definovaných cílů spolehlivosti tím, že u výpočetních, datových, síťových a dalších úrovní infrastruktury uplatníte správnou úroveň redundance. Využijte tuto redundanci, abyste svým úlohám poskytli silné a spolehlivé základy, na kterých můžete stavět. Při sestavování úloh bez redundance infrastruktury existuje vysoké riziko delšího výpadku z důvodu potenciálních selhání.

Definice

Období Definice
Redundance Implementace více identických instancí součásti úlohy.
Polyglotní použití Koncept použití různých technologií úložiště stejnou aplikací nebo řešením, aby se využily nejlepší možnosti každé komponenty.
Konzistence dat Míra toho, jak se daná datová sada synchronizuje nebo nesynchronizuje napříč několika úložišti.
Dělení 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 nereplikují ve všech instancích.

Klíčové strategie návrhu

V kontextu spolehlivosti použijte redundanci k zahrnutí problémů, které ovlivňují jeden prostředek, a zajistěte, aby tyto problémy neovlivnily spolehlivost celého systému. Pomocí informací, které jste zjistili o důležitých tocích a cílech spolehlivosti, můžete dělat informovaná rozhodnutí, která jsou nutná pro redundanci jednotlivých toků.

Můžete mít například spuštěných více uzlů webového serveru najednou. Důležitost toku, který podporují, může vyžadovat, aby všechny měly repliky, které jsou připravené přijímat provoz, pokud dojde k problému, který ovlivňuje celý fond, například kvůli oblastnímu výpadku. Vzhledem k tomu, že rozsáhlé problémy jsou vzácné a nasazení celé sady replik je nákladné, můžete nasadit omezený počet replik, aby tok fungoval v omezeném stavu, dokud problém nevyřešíte.

Pokud navrhujete redundanci v kontextu efektivity výkonu, rozdělte zatížení mezi několik redundantních uzlů, abyste zajistili optimální výkon každého uzlu. V kontextu spolehlivosti sestavte volnou kapacitu, která absorbuje selhání nebo poruchy, které ovlivňují jeden nebo více uzlů. Ujistěte se, že volná kapacita dokáže absorbovat selhání po celou dobu potřebnou k obnovení ovlivněných uzlů. S ohledem na tento rozdíl je potřeba, aby obě strategie spolupracovaly. Pokud kvůli výkonu rozdělíte provoz mezi dva uzly a oba běží na 60 procentech využití a jeden uzel selže, hrozí zahlcení zbývajícího uzlu, protože nemůže fungovat na 120 procentech. Rozdělte zatížení do jiného uzlu, abyste zajistili, že budou dodrženy vaše cíle v oblasti výkonu a spolehlivosti.

Kompromisy:

  • Větší redundance úloh znamená vyšší náklady. Pečlivě zvažte přidání redundance a pravidelně kontrolujte architekturu, abyste měli jistotu, že spravujete náklady, zejména pokud používáte nadměrné zřizování. Pokud používáte nadměrné zřizování jako strategii odolnosti, vyvažte ji pomocí dobře definované strategie škálování , abyste minimalizovali efektivitu nákladů.
  • Při vytváření s vysokou mírou redundance může docházet ke kompromisům z hlediska výkonu. Například prostředky, které se rozprostírají mezi zónami dostupnosti nebo oblastmi, můžou mít vliv na výkon, protože mezi redundantními prostředky, jako jsou webové servery nebo instance databáze, musíte odesílat provoz přes připojení s vysokou latencí.
  • Různé toky v rámci stejné úlohy můžou mít různé požadavky na spolehlivost. Návrhy redundance specifické pro toky můžou potenciálně vnést do celé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 důležitosti toku uživatele a systémového toku, který komponenty infrastruktury podporují. Z hlediska spolehlivosti pomáhá návrh typu aktivní-aktivní ve více oblastech dosáhnout nejvyšší možné úrovně spolehlivosti, ale je výrazně dražší než návrh typu aktivní-pasivní. Rozhodování o vhodných geografických oblastech se stává 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 návrh s vysokou dostupností ve více oblastech.

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

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

Zóny dostupnosti v oblastech Azure

Bez ohledu na to, jestli nasadíte návrh aktivní-aktivní nebo aktivní-pasivní, využijte výhod zón dostupnosti v aktivních oblastech k úplné optimalizaci odolnosti. Mnoho oblastí Azure poskytuje několik zón dostupnosti, což jsou oddělené skupiny datových center v rámci oblasti. V závislosti na službě Azure můžete využít výhod zón dostupnosti tím, že prvky úloh nasadíte redundantně napříč zónami nebo je připnete ke konkrétním zónám. Další informace najdete v tématu Doporučení pro používání zón dostupnosti a oblastí.

Pokyny k vrstvě infrastruktury

Výpočetní prostředky

  • Zvolte vhodnou 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í. Projdete si dostupné služby a pochopíte, které typy úloh fungují na dané výpočetní službě nejlépe. Například úlohy SAP jsou obvykle nejvhodnější pro výpočetní služby infrastruktury jako služby (IaaS). U kontejnerizovaných aplikací určete konkrétní funkce, nad nimiž potřebujete kontrolu, abyste mohli určit, jestli chcete použít řešení 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 výpočetní možnosti PaaS. Azure plně spravuje služby PaaS, což snižuje nároky na správu a je zabudován zdokumentovaný stupeň redundance.

  • Pokud potřebujete nasadit virtuální počítače, použijte Azure Virtual Machine Scale Sets. S Virtual Machine Scale Sets můžete své výpočetní prostředky automaticky rovnoměrně rozložit mezi zóny dostupnosti.

  • Udržujte výpočetní vrstvu čistou od jakéhokoli stavu , protože jednotlivé uzly, které obsluhují požadavky, můžou být kdykoli odstraněny, chybovány nebo nahrazeny.

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

  • Nadměrné zřizování důležitých prostředků za účelem zmírnění selhání redundantních instancí, a to i před zahájením operací automatického škálování, aby systém nadále fungoval i po selhání komponenty. Vypočítejte přijatelný účinek chyby, když do návrhu redundance zahrnete nadměrné zřizování. Stejně jako u procesu rozhodování o redundanci určují rozsah, do jaké míry při nadměrném zřizování přidáte volnou kapacitu, vaše cíle spolehlivosti a finanční kompromisy. Nadměrné zřizování se týká konkrétně horizontálního navýšení kapacity, což znamená přidání dalších instancí daného typu výpočetního prostředku, nikoli zvýšení výpočetních možností jednotlivých instancí. Například pokud změníte virtuální počítač ze skladové položky nižší vrstvy na skladovou položku vyšší úrovně.

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

Datové prostředky

  • Určete, jestli je synchronní nebo asynchronní replikace dat nezbytná pro funkce úloh. S tímto určením vám pomůže článek Doporučení pro použití zón dostupnosti a oblastí.

  • Vezměte v úvahu míru růstu vašich dat. Při plánování kapacity naplánujte růst dat, jejich uchovávání a archivaci, abyste zajistili splnění požadavků na spolehlivost při rostoucím 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

  • Automatizace převzetí služeb při selhání po selhání instance databáze Automatizované převzetí služeb při selhání můžete nakonfigurovat v několika datových službách Azure PaaS. Automatizované převzetí služeb při selhání se nevyžaduje pro úložiště dat, která podporují zápisy do více oblastí, jako je Azure Cosmos DB. Další informace najdete v tématu Doporučení pro návrh strategie zotavení po havárii.

  • Používejte pro svá data to nejlepší úložiště dat . Osvojte si polyglotní trvalost nebo řešení, která používají kombinaci technologií úložiště dat. Data zahrnují více než jen trvalá data aplikací. Zahrnují 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 zajistit, aby vaše systémy byly úzce propojené, což může usnadnit jejich křehkost. Pokud například operace aktualizuje dvě databáze místo jejich zařazení do jednoho oboru transakce, je lepší, když systém dokáže pojmout konečnou konzistenci.

  • Pro zajištění dostupnosti rozdělte data na oddíly. Dělení databáze zlepšuje škálovatelnost a může také zlepšit dostupnost. Pokud dojde k poklesu jednoho horizontálního oddílu, ostatní horizontální oddíly jsou stále dostupné. Selhání v jednom horizontálním oddílu pouze naruší podmnožinu celkových transakcí.

  • Pokud horizontální dělení není možné, můžete použít model Command and Query Responsibility Segregation (CQRS) k oddělení datových modelů pro čtení a zápis a jen pro čtení. Přidejte více redundantních instancí databází jen pro čtení, abyste zajistili větší odolnost.  

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

Sítě

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

  • Vyberte vhodnou síťovou službu pro vyrovnávání a přesměrování požadavků v rámci oblastí nebo napříč oblastmi. Pokud je to možné, používejte globální nebo zónově redundantní služby vyrovnávání zatížení, abyste splnili své 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, aby se zohlednilo plánované 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 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é splňují vaše požadavky na šířku pásma a dostupnost. Propustnost brány VPN Gateway se liší v závislosti na jejich skladové pouce. Podpora redundance zón je k dispozici pouze pro některé skladové položky nástroje pro vyrovnávání zatížení.

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

Usnadnění Azure

Platforma Azure pomáhá optimalizovat odolnost úloh a přidat redundanci:

Usnadnění Azure specifické pro DNS

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

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

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

  • Pro scénáře hybridního překladu ip adres mezi místním a cloudovým prostředím použijte Privátní překladač Azure DNS. Tato služba podporuje zónovou redundanci, pokud se vaše úloha nachází v oblasti, která podporuje zóny dostupnosti. Výpadek v celé zóně nevyžaduje během obnovení zóny žádnou akci. Služba se automaticky sama opravuje a vyrovnává, aby využila zóny v pořádku. Další informace najdete v tématu Odolnost v privátním překladače Azure DNS.

  • Pokud chcete eliminovat kritický 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ý překladač v jiné oblasti 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 redundantního nasazení ve více oblastech najdete v tématu Standardní vysoce dostupná zónově redundantní webová aplikace.

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 spolehlivosti

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