Doporučení pro použití zón dostupnosti a oblastí

Platí pro toto doporučení kontrolního seznamu spolehlivosti azure Well-Architected Framework:

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

Související příručky:Vysoce dostupný návrh | ve více oblastechRedundance

Tato příručka popisuje doporučení pro určení, kdy nasadit úlohy napříč zónami dostupnosti nebo oblastmi.

Při návrhu řešení pro Azure se musíte rozhodnout, jestli nasadíte do více zón dostupnosti v určité oblasti nebo do více oblastí. Toto rozhodnutí ovlivňuje spolehlivost, náklady a výkon vašeho řešení a schopnost vašeho týmu řešení provozovat. Tato příručka obsahuje informace o klíčových obchodních požadavcích, které ovlivňují vaše rozhodnutí, přístupech, které můžete zvážit, kompromisech, které jsou součástí jednotlivých přístupů, a o vlivu jednotlivých přístupů na základní pilíře architektury Azure Well-Architected.

Rozhodnutí o nejlepších oblastech Azure pro vaše řešení je zásadní volbou. Průvodce Vybrat oblasti Azure popisuje, jak vybrat a pracovat v několika geografických oblastech. Vaše volba způsobu použití oblastí a zón dostupnosti v rámci řešení ovlivňuje také několik pilířů Well-Architected Frameworku:

• Spolehlivost: Volba přístupu k nasazení vám může pomoct zmírnit různé typy rizik. Obecně platí, že rozložením úloh do geograficky distribuovaných oblastí můžete dosáhnout vyšší odolnosti.
• Optimalizace nákladů: Některé přístupy k architektuře vyžadují nasazení více prostředků než jiné, což může zvýšit náklady na prostředky. Jiné přístupy zahrnují odesílání dat do geograficky oddělených zón dostupnosti nebo oblastí, za které se můžou účtovat poplatky za síťový provoz. Je také důležité vzít v úvahu průběžné náklady na správu prostředků, které jsou obvykle vyšší, pokud máte komplexní obchodní požadavky.
• Efektivita výkonu: Zóny dostupnosti jsou vzájemně propojené prostřednictvím síťového propojení s velkou šířkou pásma s nízkou latencí, které většině úloh stačí k umožnění synchronní replikace a komunikace napříč zónami. Pokud ale vaše úloha prošla testováním a je citlivá na latenci sítě napříč zónami, možná budete muset zvážit fyzické umístění komponent úloh blízko sebe, abyste minimalizovali latenci při komunikaci.
• Efektivita provozu: Nasazení, konfigurace a správa složité architektury vyžaduje větší úsilí. U řešení s vysokou dostupností navíc možná budete muset naplánovat, jak provést převzetí služeb při selhání sekundární sadou prostředků. Převzetí služeb při selhání, navrácení služeb po obnovení a transparentní přesměrování provozu může být složité, zejména v případě, že se vyžadují ruční kroky. Je vhodné automatizovat procesy nasazení a správy. Další informace najdete v průvodcích pilířů Efektivita provozu, včetně OE:05 Infrastructure as code, OE:09 Task automation, OE:10 Automation design a OE:11 Deployment practices.

Ať už řešení navrhnete, použije se pilíř Zabezpečení. Rozhodnutí o tom, jestli a jak používáte zóny dostupnosti a oblasti, obvykle nezmění stav zabezpečení. Azure uplatňuje stejnou přísnost zabezpečení na každou oblast a zónu dostupnosti.

Tip

Pro mnoho produkčních úloh poskytuje zónově redundantní nasazení nejlepší rovnováhu mezi kompromisy. Tento přístup můžete rozšířit o asynchronní zálohování dat do jiné oblasti. Pokud si nejste jistí, který přístup vybrat, začněte tímto typem nasazení.

Pokud potřebujete konkrétní výhody, které tyto přístupy poskytují, zvažte další přístupy k úlohám, ale mějte na paměti související kompromisy.

Definice

Období	Definice
Aktivní-aktivní	Architektura, ve které více instancí řešení aktivně zpracovává požadavky najednou.
Aktivní-pasivní	Architektura, ve které je jedna instance řešení označená jako primární a zpracovává provoz a jedna nebo více sekundárních instancí se nasadí pro obsluhu provozu, pokud primární instance není k dispozici.
Asynchronní replikace	Přístup k replikaci dat, při kterém se data zapisují a zapisují do jednoho umístění. Později se změny replikují do jiného umístění.
Zóna dostupnosti	Samostatná skupina datacenter v rámci oblasti. Každá zóna dostupnosti je nezávislá na ostatních zónách s vlastní infrastrukturou napájení, chlazení a sítě. Mnoho oblastí podporuje zóny dostupnosti.
Datové centrum	Zařízení, které obsahuje servery, síťové vybavení a další hardware pro podporu prostředků a úloh Azure.
Místně redundantní nasazení	Model nasazení, ve kterém se prostředek nasadí do jedné oblasti bez odkazu na zónu dostupnosti. V oblasti, která podporuje zóny dostupnosti, může být prostředek nasazený do kterékoli zóny dostupnosti dané oblasti.
Nasazení ve více oblastech	Model nasazení, ve kterém se prostředky nasazují do několika oblastí Azure.
Spárované oblasti	Vztah mezi dvěma oblastmi Azure. Některé oblasti Azure jsou připojené k jiné definované oblasti, aby bylo možné používat konkrétní typy řešení pro více oblastí. Novější oblasti Azure nejsou spárované.
Oblast	Geografická hranice, která obsahuje sadu datových center.
Architektura oblasti	Konkrétní konfigurace oblasti Azure, včetně počtu zón dostupnosti a toho, jestli je tato oblast spárovaná s jinou oblastí.
Synchronní replikace	Přístup k replikaci dat, při kterém se data zapisují a zapisují do více umístění. Každé umístění musí potvrdit dokončení operace zápisu předtím, než se celková operace zápisu považuje za dokončenou.
Zónové nasazení (připnuté)	Model nasazení, ve kterém se prostředek nasadí do konkrétní zóny dostupnosti.
Zónově redundantní nasazení	Model nasazení, ve kterém je prostředek nasazený napříč několika zónami dostupnosti. Pokud v zóně dojde k výpadku, spravuje microsoft synchronizaci dat, distribuci provozu a převzetí služeb při selhání.

Klíčové strategie návrhu

Azure má velké globální nároky. Oblast Azure je geografická hranice, která obsahuje sadu datových center. Potřebujete mít úplné znalosti o oblastech Azure a zónách dostupnosti.

Oblasti Azure mají různé konfigurace, kterým se také říká architektury oblastí.

Mnoho oblastí Azure poskytuje zóny dostupnosti, což jsou oddělené skupiny datacenter. V rámci oblasti jsou zóny dostupnosti dostatečně blízko, aby měly připojení s nízkou latencí k jiným zónám dostupnosti, ale jsou dostatečně vzdálené, aby se snížila pravděpodobnost, že místní výpadky nebo počasí ovlivní více než jednu. Zóny dostupnosti mají nezávislou infrastrukturu napájení, chlazení a sítě. Jsou navržené tak, aby v případě výpadku jedné zóny podporovaly zbývající zóny místní služby, kapacitu a vysokou dostupnost.

Následující diagram znázorňuje několik ukázkových oblastí Azure. Oblasti 1 a 2 podporují zóny dostupnosti.

Pokud nasadíte do oblasti Azure, která obsahuje zóny dostupnosti, můžete použít více zón dostupnosti současně. Pomocí více zón dostupnosti můžete uchovávat samostatné kopie aplikace a dat v samostatných fyzických datacentrech ve velké metropolitní oblasti.

Existují dva způsoby použití zón dostupnosti v řešení:

• Zónové prostředky jsou připnuté ke konkrétní zóně dostupnosti. Pokud chcete splnit požadavky na vysokou spolehlivost, můžete kombinovat několik zónových nasazení napříč různými zónami. Zodpovídáte za správu replikace dat a distribuci požadavků mezi zóny. Pokud dojde k výpadku v jedné zóně dostupnosti, zodpovídáte za převzetí služeb při selhání do jiné zóny dostupnosti.
• Zónově redundantní prostředky jsou rozložené do několika zón dostupnosti. Microsoft spravuje rozložení požadavků mezi zóny a replikaci dat mezi zónami. Pokud dojde k výpadku v jedné zóně dostupnosti, Microsoft automaticky spravuje převzetí služeb při selhání.

Služby Azure podporují jeden nebo oba tyto přístupy. Služby PaaS (Platforma jako služba) obvykle podporují zónově redundantní nasazení. Služby infrastruktury jako služby (IaaS) obvykle podporují zónová nasazení. Další informace o tom, jak služby Azure fungují se zónami dostupnosti, najdete v tématu Služby Azure s podporou zóny dostupnosti.

Když Microsoft nasazuje aktualizace služeb, snažíme se používat přístupy, které jsou pro vás nejméně rušivé. Naším cílem je například nasadit aktualizace do jedné zóny dostupnosti najednou. Tento přístup může snížit dopad, který můžou mít aktualizace na aktivní úlohu, protože v průběhu aktualizace může úloha běžet i v jiných zónách. V konečném důsledku je ale zodpovědností týmu úloh zajistit, aby jejich úlohy během upgradů platformy dál fungovaly. Pokud například používáte škálovací sady virtuálních počítačů s flexibilním režimem orchestrace nebo většinu služeb Azure PaaS, Azure inteligentně umístí vaše prostředky, aby se snížil dopad aktualizací platformy. Kromě toho můžete zvážit nadměrné zřizování – nasazení více instancí prostředku – aby některé instance zůstaly dostupné, zatímco jiné se upgradují. Další informace o tom, jak Azure nasazuje aktualizace, najdete v tématu Zlepšování postupů bezpečného nasazení.

Mnoho oblastí má také spárovanou oblast. Spárované oblasti podporují určité typy přístupů k nasazení ve více oblastech. Některé novější oblasti mají více zón dostupnosti a nemají spárovanou oblast. Do těchto oblastí můžete nasadit řešení pro více oblastí, ale přístupy, které používáte, se můžou lišit.

Další informace o tom, jak Azure používá oblasti a zóny dostupnosti, najdete v tématu Co jsou oblasti Azure a zóny dostupnosti?

Vysvětlení sdílených odpovědností

Princip sdílené odpovědnosti popisuje, jak se odpovědnost rozděluje mezi poskytovatele cloudu (Microsoft) a vás. V závislosti na typu služeb, které používáte, můžete za provoz služby převzít větší nebo menší zodpovědnost.

Microsoft poskytuje zóny dostupnosti a oblasti, aby vám poskytl flexibilitu v tom, jak navrhujete řešení tak, aby splňovalo vaše požadavky. Když používáte spravované služby, Microsoft přebírá větší část odpovědnosti za správu vašich prostředků, což může zahrnovat i replikaci dat, převzetí služeb při selhání, navrácení služeb po obnovení a další úlohy související s provozem distribuovaného systému.

Váš vlastní kód potřebuje doporučené postupy a vzory návrhu pro řádné zpracování chyb. Tyto postupy jsou ještě důležitější během operací převzetí služeb při selhání, například při převzetí služeb při selhání zóny dostupnosti nebo oblasti, protože převzetí služeb při selhání mezi zónami nebo oblastmi obvykle vyžaduje, aby se vaše aplikace znovu zkusil připojit ke službám.

Identifikace klíčových obchodních požadavků a požadavků na úlohy

Pokud se chcete informovaně rozhodnout, jak používat zóny dostupnosti a oblasti ve vašem řešení, musíte porozumět svým požadavkům. Tyto požadavky by měly být řízeny diskusemi mezi návrháři řešení a obchodními účastníky.

Tolerance rizik

Různé organizace mají různé stupně tolerance rizik. Tolerance rizik se u každé úlohy často liší i v rámci organizace. Většina úloh nepotřebuje extrémně vysokou dostupnost. Některé úlohy jsou ale tak důležité, že je dokonce vhodné zmírnit rizika, která pravděpodobně nenastane, například velké přírodní katastrofy, které ovlivňují širokou geografickou oblast.

Tato tabulka uvádí několik běžných rizik, která byste měli v cloudovém prostředí zvážit:

Riziko	Příklady	Pravděpodobnost
Výpadek hardwaru	Problém s pevným diskem nebo síťovým vybavením Hostitel se restartuje.	Vysoká. Tato rizika by měla zohlednit jakákoli strategie odolnosti.
Výpadek datacentra	Výpadky napájení, chlazení nebo sítě v celém datacentru Přírodní katastrofa v jedné části metropolitní oblasti.	Střední
Výpadek oblasti	Velká přírodní katastrofa, která postihla širokou geografickou oblast. Problém se sítí nebo službou, který způsobuje nedostupnost jedné nebo více služeb Azure v celé oblasti.	Nízká

Ideální by bylo zmírnit všechna možná rizika pro každou úlohu, ale není to praktické ani nákladově efektivní. Je důležité vést otevřenou diskuzi se zúčastněnými stranami z firmy, abyste mohli dělat informovaná rozhodnutí o rizicích, která byste měli zmírnit.

Tip

Bez ohledu na cíle spolehlivosti musí mít všechny úlohy určité omezení pro zotavení po havárii. Pokud vaše úloha vyžaduje vysoce spolehlivé cíle, měly by být strategie omezení rizik komplexní a měli byste snížit riziko událostí s i nízkou pravděpodobností. U ostatních úloh se informovaně rozhodujte o tom, jaká rizika jste připraveni přijmout a která potřebujete zmírnit.

Požadavky na odolnost

Je důležité pochopit požadavky na odolnost vašich úloh, včetně cíle doby obnovení (RTO) a cíle bodu obnovení (RPO). Tyto cíle vám pomůžou rozhodnout, které přístupy vyloučit. Pokud nemáte jasné požadavky, nemůžete se informovaně rozhodnout, jaký přístup použít. Další informace najdete v tématu Cílové funkční a nefunkční požadavky.

Cíle na úrovni služeb

Měli byste znát očekávaný cíl úrovně služeb (SLO) pro dobu provozu vašeho řešení. Můžete mít například obchodní požadavek, aby vaše řešení splňovalo 99,9% dobu provozu.

Azure poskytuje smlouvy o úrovni služeb (SLA) pro každou službu. Smlouva SLA určuje úroveň provozuschopnosti, kterou byste měli od služby očekávat, a podmínky, které musíte splnit, abyste dosáhli této očekávané smlouvy SLA. Mějte ale na paměti, že způsob, jakým smlouva Azure SLA indikuje dostupnost služby, nemusí vždy odpovídat způsobu, jakým berete v úvahu stav úloh.

Vaše rozhodnutí o architektuře ovlivňují složeného cíle úrovně služeb vašeho řešení. Obecně platí, že čím větší redundanci do svého řešení zabudujete, tím vyšší bude váš cíl úrovně služeb (SLO) pravděpodobně vyšší. Řada služeb Azure poskytuje vyšší smlouvy SLA při nasazování služeb v zónově redundantní konfiguraci nebo konfiguraci ve více oblastech. Projděte si smlouvy SLA pro každou službu Azure, kterou používáte, a ujistěte se, že rozumíte tomu, jak maximalizovat odolnost a smlouvu SLA služby.

Rezidence dat

Některé organizace omezují fyzická umístění, do kterých je možné ukládat a zpracovávat jejich data. Někdy jsou tyto požadavky založené na právních nebo regulačních standardech. V jiných situacích se organizace může rozhodnout, že přijme zásady rezidence dat, aby se vyhnula obavám zákazníků. Pokud máte přísné požadavky na rezidenci dat, možná budete muset použít nasazení v jedné oblasti nebo použít podmnožinu oblastí a služeb Azure.

Poznámka

Vyhněte se nepodloženému předpokladu o požadavcích na rezidenci dat. Pokud potřebujete dodržovat konkrétní regulační normy, ověřte, co tyto standardy skutečně specifikují.

Umístění uživatele

Když pochopíte, kde se vaši uživatelé nacházejí, můžete se informovaně rozhodnout, jak optimalizovat latenci a spolehlivost pro vaše potřeby. Azure nabízí mnoho možností pro podporu geograficky rozptýlené uživatelské základny.

Pokud jsou vaši uživatelé soustředěni v jedné oblasti, nasazení v jedné oblasti může zjednodušit vaše provozní požadavky a snížit náklady. Musíte ale zvážit, jestli nasazení v jedné oblasti splňuje vaše požadavky na spolehlivost. U důležitých aplikací byste měli stále používat nasazení ve více oblastech, i když jsou vaši uživatelé společně umístění.

Pokud jsou vaši uživatelé geograficky rozptýlení, může mít smysl nasadit úlohu napříč několika oblastmi. Služby Azure poskytují různé možnosti pro podporu nasazení ve více oblastech. Globální stopy Azure můžete využít ke zlepšení uživatelského prostředí a přiblížení aplikací uživatelské základně. Můžete použít model razítka nasazení nebo model Geodes nebo replikovat prostředky napříč několika oblastmi.

I když jsou vaši uživatelé v různých geografických oblastech, zvažte, jestli potřebujete nasazení ve více oblastech. Zvažte, jestli můžete dosáhnout svých požadavků v rámci jedné oblasti pomocí globální akcelerace provozu, jako je akcelerace poskytovaná službou Azure Front Door.

Rozpočet

Pokud pracujete v rámci omezeného rozpočtu, je důležité zvážit náklady spojené s nasazením redundantních komponent úloh. Tyto náklady můžou zahrnovat dodatečné poplatky za prostředky, náklady na sítě a provozní náklady na správu více prostředků a složitějšího prostředí.

Složitost

V architektuře řešení je vhodné se vyhnout zbytečné složitosti. Čím složitější je, tím obtížnější je rozhodování o architektuře. Složité architektury jsou obtížně ovladatelné, obtížně zabezpečené a často méně výkonné. Dodržujte princip jednoduchosti.

Usnadnění Azure

Díky poskytování oblastí a zón dostupnosti vám Azure umožňuje vybrat si přístup k nasazení, který vyhovuje vašim potřebám. Existuje mnoho přístupů, ze kterých si můžete vybrat. Každý z nich přináší výhody a náklady.

Pro ilustraci přístupů k nasazení, které můžete použít, zvažte ukázkový scénář. Předpokládejme, že uvažujete o nasazení nového řešení, které zahrnuje aplikaci, která zapisuje data do nějakého druhu úložiště:

Tento příklad není specifický pro žádné konkrétní služby Azure. Jejím cílem je poskytnout jednoduchý příklad pro znázornění základních konceptů.

Toto řešení můžete nasadit několika způsoby. Každý přístup poskytuje jinou sadu výhod a přináší různé náklady. Na nejvyšší úrovni můžete zvážit místně redundantní, zónové (připnuté)nasazení nebo nasazení ve více oblastech . Tato tabulka shrnuje některé aspekty pilířů:

Pilíř	Místně redundantní	Zónové (připnuté)	Zónově redundantní	Více oblastí
Spolehlivost	Nízká spolehlivost	Závisí na přístupu	Vysoká nebo velmi vysoká spolehlivost	Vysoká nebo velmi vysoká spolehlivost
Optimalizace nákladů	Nízké náklady	Závisí na přístupu	Střední náklady	Vysoké náklady
Efektivita výkonu	Přijatelný výkon (pro většinu úloh)	Vysoký výkon	Přijatelný výkon (pro většinu úloh)	Závisí na přístupu
Efektivita provozu	Nízké provozní požadavky	Vysoké provozní požadavky	Nízké provozní požadavky	Vysoké provozní požadavky

Tato tabulka shrnuje některé z přístupů, které můžete použít, a jejich vliv na vaši architekturu:

Architektonický problém	Místně redundantní	Zónové (připnuté)	Zónově redundantní	Více oblastí
Dodržování předpisů s rezidencí dat	Vysoká	Vysoká	Vysoká	Závisí na oblasti.
Regionální dostupnost	Všechny oblasti	Oblasti se zónami dostupnosti	Oblasti se zónami dostupnosti	Závisí na oblasti.

Zbývající část tohoto článku popisuje jednotlivé přístupy uvedené v předchozí tabulce. Seznam přístupů není vyčerpávající. Můžete se rozhodnout kombinovat více přístupů nebo používat různé přístupy v různých částech řešení.

Přístup k nasazení 1: Místně redundantní nasazení

Pokud při nasazování prostředků nezadáte více zón dostupnosti nebo oblastí, Azure neposkytuje žádné záruky ohledně toho, jestli jsou prostředky nasazené do jednoho datacentra nebo rozdělené mezi více datacenter v dané oblasti. V některých situacích může Azure také přesunout váš prostředek mezi zónami dostupnosti.

Většina prostředků Azure je ve výchozím nastavení vysoce dostupná s vysokou úrovní smluv SLA a integrovanou redundancí v rámci datacentra spravovaného platformou. Z hlediska spolehlivosti ale platí, že pokud dojde k výpadku některé části oblasti, je možné, že to ovlivní vaši úlohu. Pokud ano, vaše řešení může být nedostupné nebo může dojít ke ztrátě vašich dat.

U úloh s vysokou latencí může tento přístup vést také k nižšímu výkonu. Součásti úloh nemusí být společně umístěné ve stejném datacentru, takže můžete pozorovat určitou latenci provozu v rámci oblasti. Azure může také transparentně přesouvat instance služeb mezi zónami dostupnosti, což může mírně ovlivnit výkon. Pro většinu úloh to ale není problém.

Tato tabulka shrnuje některé aspekty pilířů:

Pilíř	Dopad
Spolehlivost	Nízká spolehlivost. Pokud dojde k selhání datového centra, dojde k výpadkům služeb. Můžete ale vytvořit aplikaci, která bude odolná vůči jiným typům selhání.
Optimalizace nákladů	Nejnižší náklady. Potřebujete mít jenom jednu instanci každého prostředku a neúčtují se vám žádné náklady na šířku pásma mezi zónami nebo mezi oblastmi.
Efektivita výkonu	Pro většinu úloh:Přijatelný výkon. Tento přístup pravděpodobně zajistí uspokojivý výkon. Pro úlohy s vysokou latencí:Nízký výkon. Komponenty se nemusí nacházet ve stejné zóně dostupnosti, takže u komponent s vysokou latencí může docházet k nižšímu výkonu.
Efektivita provozu	Vysoká provozní efektivita. Stačí nasadit a spravovat pouze jednu instanci každého prostředku.

Tato tabulka shrnuje některé aspekty z hlediska architektury:

Architektonický problém	Dopad
Dodržování předpisů s rezidencí dat	Vysoká. Když nasadíte řešení, které používá tento přístup, data se uloží v oblasti Azure, kterou vyberete.
Regionální dostupnost	Vysoká. Tento přístup je možné použít v libovolné oblasti Azure.

Místně redundantní nasazení se zálohováním napříč oblastmi

Místně redundantní nasazení můžete rozšířit pravidelným zálohováním infrastruktury a dat do sekundární oblasti. Tento přístup přidává další vrstvu ochrany pro zmírnění výpadku v primární oblasti. Vypadá takto:

Při implementaci tohoto přístupu je potřeba pečlivě zvážit plánovanou dobu obnovení a cíl bodu obnovení:

• Doba obnovení: Pokud dojde k regionálnímu výpadku, možná budete muset znovu sestavit řešení v jiné oblasti Azure, což má vliv na dobu obnovení. Zvažte vytvoření řešení pomocí přístupu infrastruktury jako kódu (IaC), abyste v případě velké havárie mohli rychle znovu nasadit do jiné oblasti. Zajistěte, aby vaše nástroje a procesy nasazení byly stejně odolné jako vaše aplikace, abyste je mohli použít k opětovnému nasazení řešení, i když dojde k výpadku. Naplánujte a vyzkoušejte kroky potřebné k obnovení řešení do funkčního stavu.
• Bod obnovení: Frekvence zálohování určuje míru ztráty dat, ke které může dojít (váš bod obnovení). Obvykle můžete řídit frekvenci zálohování, abyste mohli splnit cíl bodu obnovení.

Tato tabulka shrnuje některé aspekty pilířů:

Pilíř	Dopad
Spolehlivost	Střední spolehlivost. Pokud dojde k selhání datového centra, dojde k výpadkům služeb. Data se zálohují asynchronně do geograficky oddělené oblasti, což snižuje dopad úplného výpadku oblasti minimalizací ztráty dat. Při úplném výpadku oblasti můžete ručně obnovit operace do jiné oblasti. Procesy obnovení ale můžou být složité a ruční obnovení do jiné oblasti může nějakou dobu trvat.
Optimalizace nákladů	Nízké náklady. Přidání zálohy do jiné oblasti obvykle stojí jen o něco víc než nasazení místně redundantního prostředku.
Efektivita výkonu	Pro většinu úloh:Přijatelný výkon. Tento přístup pravděpodobně zajistí uspokojivý výkon. Pro úlohy s vysokou latencí:Nízký výkon. Komponenty se nemusí nacházet ve stejné zóně dostupnosti, takže u komponent s vysokou latencí může docházet k nižšímu výkonu.
Efektivita provozu	Během jakéhokoli výpadku v rámci oblasti:Nízká provozní efektivita. Převzetí služeb při selhání je vaší zodpovědností a může vyžadovat ruční operace a opětovné nasazení.

Tato tabulka shrnuje některé aspekty z hlediska architektury:

Architektonický problém	Dopad
Dodržování předpisů s rezidencí dat	Závisí na výběru oblasti. Data se primárně ukládají v oblasti Azure, kterou zadáte. K ukládání záloh ale musíte vybrat jinou oblast, takže je důležité vybrat oblast, která je kompatibilní s vašimi požadavky na rezidenci dat.
Regionální dostupnost	Vysoká. Tento přístup můžete použít v libovolné oblasti Azure.

Přístup k nasazení 2: Zónová (připnutá) nasazení

V zónovém nasazení určíte, že se vaše prostředky mají nasadit do konkrétní zóny dostupnosti. Tento přístup se někdy označuje jako nasazení připnuté k zóně .

Zónový přístup snižuje latenci mezi komponentami. Samo o sobě ale nezvyšuje odolnost vašeho řešení. Pokud chcete zvýšit odolnost, musíte nasadit několik instancí komponent do několika zón dostupnosti a rozhodnout se, jak směrovat provoz mezi jednotlivými instancemi. Tento příklad ukazuje přístup ke směrování provozu aktivní-pasivní :

V předchozím příkladu je nástroj pro vyrovnávání zatížení nasazený napříč několika zónami dostupnosti. Je důležité zvážit, jak směrujete provoz mezi instancemi v různých zónách dostupnosti, protože výpadek zóny může mít vliv také na síťové prostředky nasazené do této zóny. Můžete také zvážit použití globálního nástroje pro vyrovnávání zatížení, jako je Azure Front Door nebo Azure Traffic Manager, který se do oblasti vůbec nenasadí.

Při použití modelu zónového nasazení na sebe berete mnoho zodpovědností:

• Potřebujete nasadit prostředky do každé zóny dostupnosti a nakonfigurovat a spravovat je jednotlivě.
• Musíte se rozhodnout, jak a kdy se mají replikovat data mezi zónami dostupnosti, a pak nakonfigurovat a spravovat replikaci.
• Zodpovídáte za distribuci požadavků do správných prostředků, například pomocí nástroje pro vyrovnávání zatížení. Musíte zajistit, aby nástroj pro vyrovnávání zatížení splňoval vaše požadavky na odolnost. Musíte se také rozhodnout, jestli chcete použít model distribuce požadavků aktivní-pasivní nebo aktivní-aktivní.
• Pokud u zóny dostupnosti dojde k výpadku, je potřeba zpracovat převzetí služeb při selhání, aby se provoz odesílal do prostředků v jiné zóně dostupnosti.

Nasazení typu aktivní-pasivní napříč několika zónami dostupnosti se někdy označuje jako zotavení po havárii v oblasti nebo metro dr.

Tato tabulka shrnuje některé aspekty pilířů:

Pilíř	Dopad
Spolehlivost	Při nasazení v jedné zóně dostupnosti:Nízká spolehlivost. Zónové nasazení neposkytuje žádnou odolnost proti výpadku v datacentru nebo zóně dostupnosti. Abyste dosáhli vysoké odolnosti, musíte nasadit redundantní prostředky napříč několika zónami dostupnosti. Při nasazení ve více zónách dostupnosti:Vysoká spolehlivost. Služby mohou být odolné vůči výpadku datacentra nebo zóny dostupnosti.
Optimalizace nákladů	Při nasazení v jedné zóně dostupnosti:Nízké náklady. Jednozónové nasazení vyžaduje pouze jednu instanci každého prostředku. Při nasazení ve více zónách dostupnosti:Vysoké náklady. Nasadíte několik instancí prostředků, z nichž každá se účtuje samostatně. Za replikaci dat musíte také platit za provoz mezi zónami.
Efektivita výkonu	Vysoký výkon. Latence může být velmi nízká, pokud se komponenty, které obsluhují požadavek, nacházejí ve stejné zóně dostupnosti.
Efektivita provozu	Nízká provozní efektivita. Musíte nakonfigurovat a spravovat více instancí vaší služby. Potřebujete replikovat data mezi zónami dostupnosti. Během výpadku zóny dostupnosti zodpovídáte za převzetí služeb při selhání.

Tato tabulka shrnuje některé aspekty z hlediska architektury:

Architektonický problém	Dopad
Dodržování předpisů s rezidencí dat	Vysoká. Když nasadíte řešení, které používá tento přístup, data se uloží v oblasti Azure, kterou vyberete.
Regionální dostupnost	Oblasti se zónami dostupnosti Tento přístup je k dispozici ve všech oblastech, které podporují zóny dostupnosti.

Tento přístup se obvykle používá u úloh, které jsou založené na virtuálních počítačích. Úplný seznam služeb, které podporují zónová nasazení, najdete v tématu Služba zóny dostupnosti a místní podpora.

Při plánování zónového nasazení ověřte, že služby Azure, které používáte, jsou podporované v zónách dostupnosti, které chcete používat. Pokud například chcete zjistit, které skladové položky virtuálních počítačů jsou dostupné v jednotlivých zónách dostupnosti, přečtěte si téma Kontrola dostupnosti skladové položky virtuálního počítače.

Tip

Když nasadíte prostředek do konkrétní zóny dostupnosti, vyberete číslo zóny. Pořadí čísel zón se pro každé předplatné Azure liší. Pokud nasazujete prostředky napříč několika předplatnými Azure, ověřte čísla zón, která byste měli použít v každém předplatném. Další informace najdete v tématu Fyzické a logické zóny dostupnosti.

Přístup k nasazení 3: Zónově redundantní nasazení

Když použijete tento přístup, vaše aplikační vrstva se rozloží do několika zón dostupnosti. Když dorazí požadavky, nástroj pro vyrovnávání zatížení, který je integrovaný do služby (která sama zahrnuje zóny dostupnosti), rozdělí požadavky mezi instance v každé zóně dostupnosti. Pokud dojde k výpadku zóny dostupnosti, nástroj pro vyrovnávání zatížení směruje provoz do instancí v zónách dostupnosti, které jsou v pořádku.

Vaše úroveň úložiště je také rozložená do několika zón dostupnosti. Kopie dat vaší aplikace se distribuují napříč několika zónami dostupnosti prostřednictvím synchronní replikace. Když aplikace provede změnu dat, služba úložiště zapíše změnu do více zón dostupnosti a transakce se považuje za dokončenou pouze po dokončení všech těchto změn. Tento proces zajistí, že každá zóna dostupnosti bude mít vždy aktuální kopii dat. Pokud u zóny dostupnosti dojde k výpadku, je možné pro přístup ke stejným datům použít jinou zónu dostupnosti.

Zónově redundantní přístup zvyšuje odolnost vašeho řešení vůči problémům, jako jsou výpadky datacentra. Vzhledem k tomu, že se data replikují synchronně, musí vaše aplikace počkat na zápis dat do několika samostatných umístění, která můžou být v různých částech metropolitní oblasti. U většiny aplikací je latence komunikace mezi zónami zanedbatelná. U některých úloh s vysokou citlivostí na latenci však může synchronní replikace napříč zónami dostupnosti ovlivnit výkon aplikace.

Tato tabulka shrnuje některé aspekty pilířů:

Pilíř	Dopad
Spolehlivost	Vysoká spolehlivost. Služby jsou odolné vůči výpadku datacentra nebo zóny dostupnosti. Data se synchronně replikují napříč zónami dostupnosti a bez zpoždění.
Optimalizace nákladů	Střední náklady. V závislosti na službách, které používáte, se vám můžou účtovat určité náklady na vyšší úrovně služby, které umožňují zónovou redundanci, nebo určité náklady na síť mezi zónami.
Efektivita výkonu	Pro většinu úloh:Přijatelný výkon. Tento přístup pravděpodobně zajistí uspokojivý výkon. Pro úlohy s vysokou latencí:Nízký výkon. Některé komponenty můžou být citlivé na latenci kvůli provozu mezi zónami nebo kvůli době replikace dat.
Efektivita provozu	Vysoká provozní efektivita. Obvykle potřebujete spravovat pouze jednu logickou instanci každého prostředku. U většiny služeb je převzetí služeb při výpadku zóny dostupnosti zodpovědností Microsoftu a probíhá automaticky.

Tato tabulka shrnuje některé obavy z hlediska architektury:

Obava z architektury	Dopad
Dodržování předpisů s rezidencí dat	Vysoká. Když nasadíte řešení, které používá tento přístup, data se uloží do oblasti Azure, kterou vyberete.
Regionální dostupnost	Oblasti se zónami dostupnosti Tento přístup je k dispozici ve všech oblastech, které podporují zóny dostupnosti.

Tento přístup je možný u mnoha služeb Azure, včetně Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service, Azure Storage Azure SQL Azure Service Bus a mnoho dalších. Úplný seznam služeb, které podporují zónovou redundanci, najdete v tématu Služba zóny dostupnosti a místní podpora.

Zónově redundantní nasazení se zálohováním napříč oblastmi

Zónově redundantní nasazení můžete rozšířit pravidelným zálohováním infrastruktury a dat do sekundární oblasti. Tento přístup poskytuje výhody zónově redundantního přístupu a přidává vrstvu ochrany, která zmírnit extrémně nepravděpodobný případ úplného výpadku oblasti.

Při implementaci tohoto přístupu je potřeba pečlivě zvážit plánovanou dobu obnovení a cíl bodu obnovení:

• Čas obnovení: Pokud dojde k oblastnímu výpadku, možná budete muset znovu sestavit řešení v jiné oblasti Azure, což má vliv na dobu obnovení. Zvažte vytvoření řešení pomocí přístupu IaC, abyste v případě velké katastrofy mohli rychle znovu nasadit do jiné oblasti. Zajistěte, aby vaše nástroje a procesy nasazení byly stejně odolné jako vaše aplikace, abyste je mohli použít k opětovnému nasazení řešení i v případě výpadku. Naplánujte a vyzkoušejte kroky potřebné k obnovení řešení do funkčního stavu.

• Bod obnovení: Frekvence zálohování určuje množství ztráty dat, ke které může dojít (váš bod obnovení). Frekvenci zálohování můžete obvykle řídit tak, aby splňovala cíl bodu obnovení.

Tip

Tento přístup často poskytuje dobrou rovnováhu pro všechny aspekty architektury. Pokud si nejste jistí, jaký přístup použít, začněte tímto typem nasazení.

Tato tabulka shrnuje některé aspekty pilířů:

Pilíř	Dopad
Spolehlivost	Velmi vysoká spolehlivost. Služby jsou odolné vůči výpadku datacentra nebo zóny dostupnosti. U většiny služeb se data replikují mezi zónami automaticky a bez zpoždění. Data se zálohují asynchronně do geograficky oddělené oblasti. Toto zálohování snižuje dopad úplného výpadku oblasti tím, že minimalizuje ztrátu dat. Po úplném výpadku oblasti můžete ručně obnovit operace do jiné oblasti. Procesy obnovení ale můžou být složité a ruční obnovení do jiné oblasti může nějakou dobu trvat.
Optimalizace nákladů	Mírné náklady. Přidání zálohy do jiné oblasti obvykle stojí jen o něco více než implementace redundance zóny.
Efektivita výkonu	Pro většinu úloh:Přijatelný výkon. Tento přístup pravděpodobně zajistí uspokojivý výkon. Pro úlohy s vysokou latencí:Nízký výkon. Některé komponenty můžou být citlivé na latenci kvůli provozu mezi zónami nebo kvůli době replikace dat.
Efektivita provozu	Během výpadku zóny dostupnosti:Vysoká provozní efektivita. Převzetí služeb při selhání je zodpovědností Microsoftu a probíhá automaticky. Během oblastního výpadku:Nízká provozní efektivita. Převzetí služeb při selhání je vaší zodpovědností a může vyžadovat ruční operace a opětovné nasazení.

Tato tabulka shrnuje některé obavy z hlediska architektury:

Obava z architektury	Dopad
Dodržování předpisů s rezidencí dat	Závisí na výběru oblasti. Data se ukládají primárně v oblasti Azure, kterou zadáte, ale k ukládání záloh musíte vybrat jinou oblast. Vyberte oblast, která je kompatibilní s vašimi požadavky na rezidenci dat.
Regionální dostupnost	Oblasti se zónami dostupnosti Tento přístup je k dispozici ve všech oblastech, které podporují zóny dostupnosti.

Přístup k nasazení 4: Nasazení ve více oblastech

K distribuci řešení napříč širokou geografickou oblastí můžete použít více oblastí Azure najednou. Tento přístup založený na více oblastech můžete použít ke zlepšení spolehlivosti vašeho řešení nebo k podpoře geograficky distribuovaných uživatelů. Nasazením do více oblastí také snížíte riziko, že v jedné oblasti narazíte na dočasné omezení kapacity prostředků. Pokud je rezidence dat pro vaše řešení důležitá, pečlivě zvažte, které oblasti používáte, abyste zajistili, že se vaše data ukládají jenom v umístěních, která splňují vaše požadavky.

Aktivní a pasivní oblasti

Architektury s více oblastmi jsou složité a existuje mnoho způsobů, jak navrhnout řešení pro více oblastí. U některých úloh je vhodné mít několik oblastí, které aktivně zpracovávají požadavky současně (nasazení aktivní-aktivní). Pro jiné úlohy je lepší určit jednu primární oblast a použít jednu nebo více sekundárních oblastí pro převzetí služeb při selhání (aktivní-pasivní nasazení). Tato část se zaměřuje na druhý scénář, kdy je jedna oblast aktivní a druhá pasivní. Informace o řešeních pro více oblastí typu aktivní-aktivní najdete v tématu Model razítka nasazení a model Geode.

Replikace dat

Komunikace mezi oblastmi je mnohem pomalejší než komunikace v rámci oblasti. Obecně platí, že větší geografická vzdálenost mezi dvěma oblastmi způsobuje větší latenci sítě kvůli delší fyzické vzdálenosti, kterou musí data urazit. Očekávanou latenci sítě při připojení mezi dvěma oblastmi najdete v tématu Statistika latence sítě Azure .

Latence sítě mezi oblastmi může výrazně ovlivnit návrh řešení, protože je potřeba pečlivě zvážit, jak latence navíc ovlivní replikaci dat a další transakce. U mnoha řešení vyžaduje architektura mezi oblastmi asynchronní replikaci, aby se minimalizoval vliv provozu mezi oblastmi na výkon.

Asynchronní replikace dat

Když implementujete asynchronní replikaci napříč oblastmi, vaše aplikace nečeká, až všechny oblasti potvrdí změnu. Po potvrzení změny v primární oblasti se transakce považuje za dokončenou. Změna se později replikuje do sekundárních oblastí. Tento přístup zajišťuje, aby latence připojení mezi oblastmi přímo neovlivnila výkon aplikace. Kvůli zpoždění replikace však může výpadek v celé oblasti vést ke ztrátě některých dat. K této ztrátě dat může dojít, protože po dokončení zápisu v primární oblasti, ale před replikací změny do jiné oblasti může dojít k výpadku.

Tato tabulka shrnuje některé aspekty pilířů:

Pilíř	Dopad
Spolehlivost	Vysoká spolehlivost. Řešení je odolné vůči výpadku datacentra, zóny dostupnosti nebo celé oblasti. Data se replikují, ale nemusí být synchronní, takže ve scénáři převzetí služeb při selhání může dojít k určité ztrátě dat.
Optimalizace nákladů	Vysoké náklady. Potřebujete nasadit samostatné prostředky v každé oblasti a za každý prostředek se účtují náklady na nasazení a údržbu. Replikace dat napříč oblastmi může také znamenat značné náklady.
Efektivita výkonu	Vysoký výkon. Požadavky aplikací nevyžadují provoz mezi oblastmi, takže provoz má obvykle nízkou latenci.
Efektivita provozu	Nízká provozní efektivita. Potřebujete nasadit a spravovat prostředky napříč několika oblastmi. Zodpovídáte také za převzetí služeb při selhání mezi oblastmi během regionálního výpadku.

Tato tabulka shrnuje některé aspekty z hlediska architektury:

Architektonický problém	Dopad
Dodržování předpisů s rezidencí dat	Závisí na výběru oblasti. Tento přístup vyžaduje, abyste vybrali několik oblastí, ve kterých se má úloha spouštět. Zvolte oblasti, které jsou kompatibilní s vašimi požadavky na rezidenci dat.
Regionální dostupnost	Mnoho oblastí Azure je spárovaných. Některé služby Azure používají spárované oblasti k automatické replikaci dat. Pokud úlohu spouštíte v oblasti, která nemá pár, možná budete muset k replikaci dat použít jiný přístup.

Synchronní replikace dat

Pokud implementujete synchronní řešení s více oblastmi, musí vaše aplikace počkat na dokončení operací zápisu v každé oblasti Azure, než se transakce považuje za dokončenou. Latence při čekání na operace zápisu závisí na vzdálenosti mezi oblastmi. U mnoha úloh může latence mezi oblastmi způsobovat, že synchronní replikace bude příliš pomalá, aby byla užitečná.

Tato tabulka shrnuje některé aspekty pilířů:

Pilíř	Dopad
Spolehlivost	Velmi vysoká spolehlivost. Řešení je odolné vůči výpadku datacentra, zóny dostupnosti nebo celé oblasti. Data jsou vždy synchronizovaná napříč oblastmi, takže i když dojde k úplné ztrátě oblasti, jsou vaše data dostupná a dokončená v jiné oblasti.
Optimalizace nákladů	Vysoké náklady. Potřebujete nasadit samostatné prostředky v každé oblasti a u každého prostředku se účtují náklady na nasazení a údržbu. Replikace dat napříč oblastmi může také znamenat značné náklady.
Efektivita výkonu	Nízký výkon. Požadavky aplikací vyžadují provoz mezi oblastmi. V závislosti na vzdálenosti mezi oblastmi může synchronní replikace znamenat významnou latenci požadavků.
Efektivita provozu	Nízká provozní efektivita. Potřebujete nasadit a spravovat prostředky napříč několika oblastmi. Zodpovídáte také za převzetí služeb při selhání mezi oblastmi během regionálního výpadku.

Tato tabulka shrnuje některé aspekty z hlediska architektury:

Architektonický problém	Dopad
Dodržování předpisů s rezidencí dat	Závisí na výběru oblasti. Tento přístup vyžaduje, abyste vybrali několik oblastí, ve kterých se má úloha spouštět. Vyberte oblasti, které jsou kompatibilní s vašimi požadavky na rezidenci dat.
Regionální dostupnost	Mnoho oblastí Azure je spárovaných. Některé služby Azure používají spárované oblasti k automatické replikaci dat. Pokud úlohu spouštíte v oblasti, která nemá pár, možná budete muset k replikaci dat použít jiný přístup.

Architektury oblastí

Při návrhu řešení s více oblastmi zvažte, jestli jsou oblasti Azure, které chcete použít, spárované.

Řešení s více oblastmi můžete vytvořit i v případě, že tyto oblasti nejsou spárované. Přístupy, které použijete k implementaci architektury s více oblastmi, se ale můžou lišit. Například ve službě Azure Storage můžete použít geograficky redundantní úložiště (GRS) se spárovanými oblastmi. Pokud grs není k dispozici, zvažte použití funkcí, jako je replikace objektů Azure Storage, nebo navrhněte aplikaci tak, aby zapisovat do několika oblastí.

Kombinování přístupů s více zónami a více oblastmi

Pokud vaše obchodní požadavky vyžadují takové řešení, měli byste kombinovat příkazy pro více zón a více oblastí. Můžete například nasadit zónově redundantní komponenty do každé oblasti a také nakonfigurovat replikaci mezi oblastmi. U některých řešení tento přístup poskytuje velmi vysokou míru spolehlivosti. Konfigurace tohoto typu přístupu ale může být složitá a tento přístup může být nákladný.

Důležité

Klíčové úlohy by měly používat více zón dostupnosti i více oblastí. Další informace o aspektech, které byste měli vzít v úvahu při návrhu klíčových úloh, najdete v dokumentaci k kritickým úlohám.

Jak služby Azure podporují přístupy k nasazení

Je důležité porozumět konkrétním podrobnostem o službách Azure, které používáte. Některé služby Azure například vyžadují, abyste konfiguraci jejich zóny dostupnosti nakonfigurovali při prvním nasazení prostředku, zatímco jiné podporují změnu přístupu k nasazení později. Podobně nemusí být některé funkce služeb dostupné při každém přístupu k nasazení.

Další informace o konkrétních možnostech nasazení a přístupech, které je potřeba zvážit pro jednotlivé služby Azure, najdete v centru Spolehlivosti.

Příklady

Tato část popisuje některé běžné případy použití a klíčové požadavky, které je obvykle potřeba zvážit pro každou úlohu. Pro každou úlohu je k dispozici jeden nebo více navrhovaných přístupů k nasazení na základě požadavků a přístupů popsaných v tomto článku.

Obchodní aplikace pro podnik

Contoso, Ltd., je velká výrobní společnost. Společnost implementuje obchodní aplikaci pro správu některých komponent svých finančních procesů.

Obchodní požadavky: Informace, které systém spravuje, je obtížné nahradit, takže data je potřeba spolehlivě zachovat. Architekti říkají, že systém musí způsobovat co nejmenší výpadky a co nejmenší ztrátu dat. Zaměstnanci společnosti Contoso používají systém během pracovního dne, takže vysoký výkon je důležitý, aby členové týmu nemuseli čekat. Problémem jsou také náklady, protože za řešení musí platit finanční tým.

Navrhovaný přístup: Zónově redundantní nasazení se zálohováním napříč oblastmi poskytuje několik vrstev odolnosti s vysokým výkonem.

Interní aplikace

Fourth Coffee je malá firma. Společnost vyvíjí novou interní aplikaci, kterou můžou zaměstnanci používat k odesílání časových rozvrhů.

Obchodní požadavky: Pro tuto úlohu je primárním problémem efektivita nákladů. Fourth Coffee vyhodnotil obchodní dopad výpadků a rozhodl se, že aplikace nemusí upřednostňovat odolnost nebo výkon. Společnost přijímá riziko, že kvůli výpadku v zóně nebo oblasti dostupnosti Azure může aplikace dočasně být nedostupná.

Navrhované přístupy:

• Místně redundantní nasazení se zálohováním napříč oblastmi má nejnižší náklady, ale zároveň má významná rizika.
• Zónově redundantní nasazení se zálohováním napříč oblastmi poskytuje lepší odolnost, ale s o něco vyššími náklady.

Migrace starších verzí aplikací

Fabrikam, Inc. migruje starší aplikaci z místního datacentra do Azure. Implementace bude používat přístup IaaS založený na virtuálních počítačích. Aplikace nebyla navržena pro cloudové prostředí a komunikace mezi aplikační vrstvou a databází je velmi chatrná.

Obchodní požadavky: Výkon je pro tuto aplikaci prioritou. Odolnost je také důležitá a aplikace musí dál fungovat, i když dojde k výpadku datacentra Azure.

Navrhovaný přístup:

• Společnost Fabrikan by měla nejprve vyzkoušet zónově redundantní nasazení. Měli by ověřit, že výkon splňuje jejich požadavky.
• Pokud výkon zónově redundantního řešení není přijatelný, zvažte zónové (připnuté) nasazení s pasivním nasazením napříč několika zónami dostupnosti (zotavení po havárii v oblasti).

Zdravotnická aplikace

Společnost Lamna Healthcare implementuje v Azure nový systém elektronických zdravotních záznamů.

Obchodní požadavky: Vzhledem k povaze dat, která toto řešení ukládá, je rezidence dat kriticky důležitá. Lamna funguje v rámci striktního regulačního rámce, který nařizuje, aby data zůstala na určitém místě.

Navrhované přístupy:

• Nasazení ve více zónách ve více oblastech, pokud existuje více oblastí, které vyhovují požadavkům lamny na rezidenci dat.
• Pokud existuje pouze jedna oblast, která vyhovuje jejich potřebám, zvažte zónově redundantní nasazení nebo zónově redundantní nasazení se zálohováním napříč oblastmi , které poskytují řešení v jedné oblasti.

Bankovní systém

Společnost Woodgrove Bank provozuje své základní bankovní operace z rozsáhlého řešení nasazeného do Azure.

Obchodní požadavky: Jedná se o systém, který je velmi důležitý. Jakékoli výpadky můžou mít velký finanční dopad na zákazníky. V důsledku toho má Woodgrove Bank velmi nízkou toleranci rizik. Systém potřebuje nejvyšší možnou úroveň spolehlivosti a architektura potřebuje zmírnit riziko případných selhání, která je možné zmírnit.

Navrhovaný přístup: V případě kritického systému použijte nasazení ve více zónách ve více oblastech. Ujistěte se, že oblasti odpovídají požadavkům společnosti na rezidenci dat.

Software jako služba (SaaS)

Proseware, Inc., vytváří software, který používají společnosti po celém světě. Uživatelská základna společnosti je široce geograficky distribuovaná.

Obchodní požadavky: Proseware musí každému ze svých zákazníků umožnit výběr oblasti nasazení, která je blízko zákazníka. Povolení této volby je důležité z důvodu latence a požadavků zákazníků na rezidenci dat.

Navrhované přístupy:

• Nasazení ve více zónách ve více oblastech je obvykle dobrou volbou pro poskytovatele SaaS, zejména pokud se používá v rámci vzoru Razítka nasazení.
• Zónově redundantní nasazení v jedné oblasti ve spojení s řešením globální akcelerace provozu, jako je Azure Front Door.

Související odkazy

Následuje několik referenčních architektur a ukázkových scénářů pro řešení pro více zón a více oblastí:

• Standardní vysoce dostupná zónově redundantní webová aplikace
• Vysoce dostupná webová aplikace pro více oblastí
• N-vrstvá aplikace v různých oblastech
• Vícevrstvá webová aplikace sestavená pro HA/DR

Mnoho služeb Azure poskytuje pokyny k používání více zón dostupnosti, včetně následujících příkladů:

• Azure Site Recovery: Povolení zotavení po havárii virtuálního počítače Azure mezi zónami dostupnosti
• Azure NetApp Files: Vysvětlení replikace Azure NetApp Files mezi zónami
• Redundance Azure Storage

Kontrolní seznam pro spolehlivost

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

Kontrolní seznam pro spolehlivost