Doporučení pro používání zón dostupnosti a oblastí
Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury Azure Well-Architected Framework:
| RE:05 | Přidejte redundanci na různých úrovních, zejména pro kritické toky. Využijte redundanci na výpočetní prostředky, data, síť a další vrstvy infrastruktury v souladu s určenými cíli spolehlivosti. |
|---|
Související příručky: Redundance vysoce dostupného víceregionálního návrhu |
Tato příručka popisuje doporučení pro určení, kdy nasazovat úlohy napříč zónami dostupnosti nebo oblastmi.
Při návrhu řešení pro Azure se musíte rozhodnout, jestli nasadíte napříč několika zónami dostupnosti v oblasti nebo nasadíte do několika oblastí. Toto rozhodnutí má vliv na spolehlivost, náklady a výkon vašeho řešení a schopnost vašeho týmu provozovat řešení. Tato příručka obsahuje informace o klíčových obchodních požadavcích, které ovlivňují vaše rozhodnutí, přístupy, které můžete zvážit, kompromisy spojené s každým přístupem a vliv jednotlivých přístupů na základní pilíře architektury Azure Well-Architected Framework.
Rozhodnutí o tom, které oblasti Azure je pro vaše řešení nejvhodnější, je kritická volba. Průvodce výběrem oblastí Azure popisuje, jak vybrat a pracovat v několika geografických oblastech. Volba způsobu použití oblastí a zón dostupnosti v rámci vašeho řešení ovlivňuje také několik pilířů dobře architektuře:
- Spolehlivost: Výběr přístupu k nasazení vám může pomoct zmírnit různé typy rizik. Obecně platí, že rozšířením úlohy do geograficky distribuované oblasti dosáhnete vyšší odolnosti.
- Optimalizace nákladů: Některé přístupy architektury vyžadují nasazení více prostředků než jiné, což může zvýšit náklady na prostředky. Mezi další přístupy patří odesílání dat napříč geograficky oddělenými zónami dostupnosti nebo oblastmi, což může mít za síťový provoz poplatky. Je také důležité zvážit průběžné náklady na správu prostředků, což je obvykle vyšší, pokud máte komplexní obchodní požadavky.
- Efektivita výkonu: Zóny dostupnosti jsou propojené prostřednictvím síťového propojení s vysokou šířkou pásma s nízkou latencí, což je dostatečné pro většinu úloh, aby bylo možné synchronizovat replikaci a komunikaci napříč zónami. Pokud se ale vaše úloha otestovala a je citlivá na latenci sítě napříč zónami, možná budete muset zvážit fyzické umístění komponent vaší úlohy blízko sebe, aby se minimalizovala latence při jejich komunikaci.
- Efektivita provozu: Složitá architektura vyžaduje větší úsilí při nasazování, konfiguraci a správě. Kromě toho pro vysoce dostupné řešení možná budete muset naplánovat, jak převzít služby při selhání sekundární sadě 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 pokud jsou vyžadovány 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 Infrastruktura jako kód, OE:09 Automatizace úloh, OE:10 Návrh automatizace a Postupy nasazení OE:11.
Vy ale navrhujete své řešení, použije se pilíř zabezpečení. Rozhodnutí o tom, jestli a jak používáte zóny dostupnosti a oblasti, obvykle nemění stav zabezpečení. Azure použije stejnou úroveň zabezpečení pro každou oblast a zónu dostupnosti.
Tip
U mnoha produkčních úloh poskytuje zónově redundantní nasazení nejlepší rovnováhu mezi kompromisy. Tento přístup můžete rozšířit pomocí asynchronního zálohování dat do jiné oblasti. Pokud si nejste jistí, jaký přístup vybrat, začněte tímto typem nasazení.
Zvažte další přístupy k úlohám, pokud potřebujete konkrétní výhody, které tyto přístupy poskytují, ale mějte na paměti související kompromisy.
Definice
| Pojem | definice |
|---|---|
| Aktivní-aktivní | Architektura, ve které více instancí řešení aktivně zpracovává požadavky současně. |
| Aktivní-pasivní | Architektura, ve které je jedna instance řešení urč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í není k dispozici. |
| Asynchronní replikace | Přístup replikace dat, ve kterém se data zapisuje a zapisuje do jednoho umístění. Později se změny replikují do jiného umístění. |
| Availability zone | Oddělená skupina datacenter v rámci oblasti. Každá zóna dostupnosti je nezávislá na ostatních a má vlastní napájení, chlazení a síťovou infrastrukturu. Řada 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 je prostředek nasazený do jedné oblasti bez odkazu na zónu dostupnosti. V oblasti, která podporuje zóny dostupnosti, může být prostředek nasazený v kterékoli z zón 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é povolit konkrétní typy řešení s více oblastmi. Novější oblasti Azure nejsou spárované. |
| Oblast | Geografická hraniční síť, která obsahuje sadu datacenter. |
| Architektura oblastí | Konkrétní konfigurace oblasti Azure, včetně počtu zón dostupnosti a toho, jestli je oblast spárovaná s jinou oblastí. |
| Synchronní replikace | Přístup replikace dat, ve kterém se data zapisuje a zapisuje do více umístění. Každé umístění musí potvrdit dokončení operace zápisu před tím, než se celková operace zápisu považuje za dokončenou. |
| Nasazení zónových (připnutých) | Model nasazení, ve kterém je prostředek nasazený 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. Microsoft spravuje synchronizaci dat, distribuci provozu a převzetí služeb při selhání, pokud dojde k výpadku zóny. |
Klíčové strategie návrhu
Azure má velkou globální stopu. Oblast Azure je geografická hraniční oblast, která obsahuje sadu datacenter. Potřebujete mít úplný přehled o oblastech Azure a zónách dostupnosti.
Oblasti Azure mají řadu konfigurací, které se také označují jako architektury oblastí.
Řada oblastí Azure poskytuje zóny dostupnosti, které 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 od sebe dostatečně vzdálené, aby se snížila pravděpodobnost, že místní výpadky nebo počasí ovlivní více než jedno. Zóny dostupnosti mají nezávislou infrastrukturu napájení, chlazení a sítě. Jsou navrženy tak, aby v případě výpadku jedné zóny byly regionální služby, kapacita a vysoká dostupnost zajištěny zbývajícími zónami.
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 společně použít více zón dostupnosti. 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.
V řešení existují dva způsoby použití zón dostupnosti:
- Zónové prostředky jsou pevně vázané na určitou zónu dostupnosti. Chcete-li zajistit splnění požadavků vysoké dostupnosti, můžete kombinovat několik zónových nasazení napříč různými zónami. Za správu replikace dat a distribuci požadavků napříč zónami odpovídáte vy. Pokud dojde k výpadku v jedné zóně dostupnosti, zodpovídáte za převzetí služeb při selhání v jiné zóně dostupnosti.
- Zónově redundantní prostředky jsou rozložené do více zón dostupnosti. Šíření požadavků a replikaci dat napříč zónami spravuje Microsoft. Pokud dojde k výpadku v jedné zóně dostupnosti, Microsoft zajistí převzetí služeb při selhání automaticky.
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 pracují se zónami dostupnosti, najdete v tématu Služby Azure s podporou zóny dostupnosti.
Když Microsoft nasadí aktualizace do služeb, pokusíme se použít přístupy, které jsou pro vás nejméně rušivé. Snažíme se například nasadit aktualizace do jedné zóny dostupnosti najednou. Tento přístup může snížit dopad, který aktualizace můžou mít na aktivní úlohu, protože úloha může běžet v jiných zónách, zatímco probíhá aktualizace. Je ale nakonec zodpovědností týmu úloh zajistit, aby během upgradů platformy fungovaly i nadále své úlohy. 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řízení – nasazení dalších instancí prostředku – aby některé instance zůstaly dostupné, zatímco jiné instance se upgradují. Další informace o tom, jak Azure nasazuje aktualizace, najdete v tématu Pokročilé postupy 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 stále nasazovat ř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 rozdělení odpovědností mezi poskytovatele cloudu (Microsoft) a vámi. V závislosti na typu služeb, které používáte, můžete převzít větší nebo menší odpovědnost za provoz služby.
Microsoft poskytuje zóny dostupnosti a oblasti, které vám poskytnou flexibilitu při návrhu řešení tak, aby splňovalo vaše požadavky. Když používáte spravované služby, Microsoft převezme větší odpovědnost 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.
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 těch, ke kterým dochází v případě 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 vaše aplikace zkusil znovu připojení ke službám.
Identifikace klíčových obchodních požadavků a požadavků na úlohy
Pokud chcete informovaně rozhodnout, jak ve vašem řešení používat zóny dostupnosti a oblasti, musíte porozumět vašim požadavkům. Tyto požadavky by měly být řízeny diskuzemi mezi návrháři řešení a obchodními účastníky.
Tolerance rizik
Různé organizace mají různé stupně tolerance rizik. I v rámci organizace se tolerance rizik často pro každou úlohu liší. Většina úloh nepotřebuje extrémně vysokou dostupnost. Některé úlohy jsou ale tak důležité, aby se dokonce hodily zmírnit rizika, která se nepravděpodobně vyskytují, 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 zvážit v cloudovém prostředí:
| Riziko | Příklady | Pravděpodobnost |
|---|---|---|
| Výpadek hardwaru | Problém s pevným diskem nebo síťovým zařízením Restartuje hostitele. |
Vysoká. Každá strategie odolnosti by měla zohlednit tato rizika. |
| Výpadek datacentra | Selhání 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á ovlivňuje širokou geografickou oblast. Problém se sítí nebo službou, který znepřístupňuje jednu nebo více služeb Azure v celé oblasti. |
Nízká |
Je ideální zmírnit všechna možná rizika pro každou úlohu, ale není to praktické ani nákladově efektivní. Je důležité mít otevřenou diskuzi s obchodními účastníky, abyste mohli činit 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 úlohy vyžadují cíle vysoké spolehlivosti, měly by být strategie pro zmírnění rizik komplexní a měli byste snížit riziko i událostí s nízkou pravděpodobností. U jiných úloh proveďte informované rozhodnutí o tom, jaká rizika jste připraveni přijmout a která potřebujete zmírnit.
Požadavky na odolnost
Je důležité porozumět požadavkům na odolnost pro vaši úlohu, včetně cíle doby obnovení (RTO) a cíle bodu obnovení (RPO). Tyto cíle vám pomůžou rozhodnout, které přístupy se mají vyloučit. Pokud nemáte jasné požadavky, nemůžete se informovaně rozhodnout, jaký přístup je třeba postupovat. Další informace naleznete v tématu Cílové funkční a nefunkční požadavky.
Cíle na úrovni služby
Měli byste porozumět očekávanému cíli úrovně služeb na úrovni služeb (SLO) 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 označuje úroveň doby provozu, kterou byste měli od služby očekávat, a podmínky, které potřebujete splnit, aby bylo dosaženo očekávané smlouvy SLA. Mějte ale na paměti, že způsob, jakým smlouva AZURE SLA značí dostupnost služby, neodpovídá vždy způsobu, jakým zvažujete stav vaší úlohy.
Vaše rozhodnutí o architektuře ovlivňují složené SLO vašeho řešení. Obecně platí, že čím větší redundanci do svého řešení vytváříte, tím vyšší bude cíl úrovně služby pravděpodobně vyšší. Mnoho služeb Azure poskytuje vyšší smlouvy SLA při nasazování služeb v zónově redundantní konfiguraci nebo konfiguraci s více oblastmi. Projděte si smlouvy SLA pro jednotlivé služby Azure, které používáte, a ujistěte se, že rozumíte tomu, jak maximalizovat odolnost a smlouvu SLA služby.
Umístění dat
Některé organizace umisťují omezení fyzických umístění, do kterých je možné ukládat a zpracovávat jejich data. Tyto požadavky jsou někdy založené na právních nebo regulačních normách. V jiných situacích se organizace může rozhodnout přijmout zásady rezidence dat, aby se vyhnuly 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 nedůvodným předpokladům ohledně požadavků na rezidenci dat. Pokud potřebujete dodržovat konkrétní regulační normy, ověřte, co tyto standardy skutečně určují.
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í řadu možností, jak podporovat geograficky rozptýlenou uživatelskou základnu.
Pokud jsou vaši uživatelé soustředěni v jedné oblasti, nasazení v jedné oblasti může zjednodušit provozní požadavky a snížit náklady. Musíte ale zvážit, jestli nasazení s jednou oblastí splňuje vaše požadavky na spolehlivost. V případě důležitých aplikací byste měli stále používat nasazení ve více oblastech, i když jsou vaši uživatelé spolulokovaní.
Pokud jsou vaši uživatelé geograficky rozptýlení, může být vhodné nasadit úlohu napříč několika oblastmi. Služby Azure poskytují různé možnosti pro podporu nasazení ve více oblastech a globální stopu Azure můžete využít ke zlepšení uživatelského prostředí a k přiblížení vašich aplikací do blízkosti vaší uživatelské základny. 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 s omezeným rozpočtem, je důležité zvážit náklady spojené s nasazením redundantních komponent úloh. Tyto náklady můžou zahrnovat další poplatky za prostředky, náklady na sítě a provozní náklady na správu více prostředků a složitější prostředí.
Složitost
Osvědčeným postupem je vyhnout se zbytečné složitosti architektury řešení. Čím větší složitost představujete, tím obtížnější je rozhodovat se o architektuře. Složité architektury jsou obtížněji funkční, obtížněji zabezpečené a často méně výkonné. Dodržujte zásadu jednoduchosti.
Usnadnění azure
Díky poskytování oblastí a zón dostupnosti vám Azure umožňuje vybrat přístup nasazení, který vyhovuje vašim potřebám. Existuje mnoho přístupů, ze kterých si můžete vybrat, z nichž každá poskytuje výhody a nese náklady.
Pokud chcete znázornit přístupy 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. Účelem je poskytnout jednoduchý příklad pro ilustraci 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 vysoké úrovni můžete zvážit místně redundantní zónové (připnuté), zónově redundantní 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 jak ovlivňují vaši architekturu:
| Architektonické obavy | 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. |
Zbytek 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 nezaručuje, jestli se prostředky nasadí do jednoho datacentra nebo rozdělí mezi několik datacenter v dané oblasti. V některých situacích může Azure také přesunout prostředek mezi zónami dostupnosti.
Většina prostředků Azure je ve výchozím nastavení vysoce dostupná s vysokými smlouvami SLA a integrovanou redundancí v datacentru spravovaném platformou. Pokud ale některá část oblasti dojde k výpadku, může to mít vliv na vaši úlohu z hlediska spolehlivosti. Pokud ano, vaše řešení může být nedostupné nebo může dojít ke ztrátě dat.
U vysoce latencí citlivých úloh může tento přístup také vést k nižšímu výkonu. Součásti úloh nemusí být společně přiděleny ve stejném datacentru, takže můžete sledovat latenci provozu uvnitř oblasti. Azure může také transparentně přesouvat instance služeb mezi zónami dostupnosti, což může mírně ovlivnit výkon. U většiny úloh to ale není problém.
Tato tabulka shrnuje některé aspekty pilířů:
| Pilíř | Dopad |
|---|---|
| Spolehlivost | Nízká spolehlivost. Pokud dojde k selhání datacentra, služby podléhají výpadkům. 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 jenom jednu instanci každého prostředku a neúčtují se žádné náklady na šířku pásma 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 citlivé na vysokou latenci: Nízký výkon. U komponent s vysokou latencí není zaručeno, že se nacházejí ve stejné zóně dostupnosti, takže u vysoce latencí citlivých komponent se může zobrazit nižší výkon. |
| Efektivita provozu | Vysoká provozní efektivita. Stačí nasadit a spravovat jenom jednu instanci každého prostředku. |
Tato tabulka shrnuje některé aspekty z hlediska architektury:
| Architektonické obavy | Dopad |
|---|---|
| Dodržování předpisů s rezidencí dat | Vysoká. Když nasadíte řešení, které používá tento přístup, uloží se data 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 provedením pravidelných záloh infrastruktury a dat do sekundární oblasti. Tento přístup přidá další vrstvu ochrany, která se zmírní proti výpadku ve vaší primární oblasti. Vypadá takto:
Při implementaci tohoto přístupu je potřeba pečlivě zvážit rto a cíl bodu obnovení:
- Doba obnovení: Pokud dojde k výpadku oblasti, 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 mohli rychle znovu nasadit do jiné oblasti, pokud dojde k závažné havárii. 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í vašeho řešení, i když dojde k výpadku. Naplánujte a naučte se kroky, které jsou potřeba k obnovení řešení zpět 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í). Obvykle můžete řídit frekvenci zálohování, abyste mohli splnit svůj cíl bodu obnovení.
Tato tabulka shrnuje některé aspekty pilířů:
| Pilíř | Dopad |
|---|---|
| Spolehlivost | Střední spolehlivost. Pokud dojde k selhání datacentra, služby podléhají výpadkům. Data se zálohují asynchronně do geograficky oddělené oblasti, což snižuje účinek výpadku celé oblasti minimalizací ztráty dat. V úplném výpadku oblasti můžete operace ručně obnovit do jiné oblasti. Procesy obnovení ale můžou být složité a ruční obnovení do druhé 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 citlivé na vysokou latenci: Nízký výkon. U komponent s vysokou latencí není zaručeno, že se nacházejí ve stejné zóně dostupnosti, takže u vysoce latencí citlivých komponent se může zobrazit nižší výkon. |
| 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é obavy | Dopad |
|---|---|
| Dodržování předpisů s rezidencí dat | Závisí na výběru oblasti. Data se primárně ukládají v zadané oblasti Azure. Pro ukládání záloh ale musíte vybrat jinou oblast, takže je důležité vybrat oblast, která je kompatibilní s 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é do zóny.
Zónový přístup snižuje latenci mezi komponentami. Sama o sobě ale nezvyšuje odolnost vašeho řešení. Pokud chcete zvýšit odolnost, musíte nasadit více 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 směrování provozu typu aktivní-pasivní :
V předchozím příkladu se nástroj pro vyrovnávání zatížení nasadí napříč několika zónami dostupnosti. Je důležité zvážit způsob směrování provozu mezi instancemi v různých zónách dostupnosti, protože výpadek zóny může ovlivnit také 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ý není vůbec nasazený do oblasti.
Při použití modelu zónového nasazení převezmete mnoho zodpovědností:
- Potřebujete nasadit prostředky do každé zóny dostupnosti a nakonfigurovat a spravovat tyto prostředky jednotlivě.
- Musíte se rozhodnout, jak a kdy replikovat data mezi zónami dostupnosti, a pak nakonfigurovat a spravovat replikaci.
- Zodpovídáte za distribuci požadavků na správné prostředky 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 použít aktivní-pasivní nebo aktivní-aktivní model distribuce požadavků.
- Pokud dojde k výpadku zóny dostupnosti, musíte zpracovat převzetí služeb při selhání, abyste mohli odesílat provoz 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 zotavení po havárii metra.
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 vůči 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 datového centra nebo zóny dostupnosti. |
| Optimalizace nákladů | Při nasazení v jedné zóně dostupnosti: Nízké náklady. Nasazení s jednou zónou 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 fakturuje samostatně. |
| Efektivita výkonu | Vysoký výkon. Latence může být velmi nízká, když se komponenty, které obsluhují požadavek, nacházejí ve stejné zóně dostupnosti. |
| Efektivita provozu | Nízká provozní efektivita. Potřebujete 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é obavy | Dopad |
|---|---|
| Dodržování předpisů s rezidencí dat | Vysoká. Když nasadíte řešení, které používá tento přístup, uloží se data v oblasti Azure, kterou vyberete. |
| Regionální dostupnost | Oblasti se zónami dostupnosti Tento přístup je k dispozici v libovolné oblasti, která podporuje zóny dostupnosti. |
Tento přístup se obvykle používá pro úlohy 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 regionální 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é plánujete použít. Pokud například chcete zobrazit seznam skladových položek virtuálních počítačů, které 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. Posloupnost čísel zón se pro každé předplatné Azure liší. Pokud nasadíte 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 rozdělí mezi více zón dostupnosti. Když požadavky dorazí, nástroj pro vyrovnávání zatížení, který je integrovaný do služby (který sám zahrnuje zóny dostupnosti), rozdělí požadavky napříč instancemi 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 v případě, že jsou všechny tyto změny dokončeny. Tento proces zajišťuje, že každá zóna dostupnosti bude mít vždy aktuální kopii dat. Pokud dojde k výpadku zóny dostupnosti, můžete 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 datacenter. Vzhledem k tomu, že se data replikují synchronně, musí vaše aplikace počkat na zápis dat napříč několika samostatnými umístěními, 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 citlivých na vysokou latenci ale 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, můžete mít za vyšší úrovně služeb určité náklady, aby se povolila redundance zón. |
| Efektivita výkonu | Pro většinu úloh: Přijatelný výkon. Tento přístup pravděpodobně zajistí uspokojivý výkon. Pro úlohy citlivé na vysokou latenci: Nízký výkon. Některé komponenty můžou být citlivé na latenci kvůli provozu mezi zónami nebo času 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 stává se automaticky. |
Tato tabulka shrnuje některé aspekty z hlediska architektury:
| Architektonické obavy | Dopad |
|---|---|
| Dodržování předpisů s rezidencí dat | Vysoká. Když nasadíte řešení, které používá tento přístup, uloží se data v oblasti Azure, kterou vyberete. |
| Regionální dostupnost | Oblasti se zónami dostupnosti Tento přístup je k dispozici v libovolné oblasti, která podporuje zóny dostupnosti. |
Tento přístup je možný u mnoha služeb Azure, včetně služeb Azure Virtual Machine Scale Sets, Aplikace Azure Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Service Bus a mnoha dalších. Úplný seznam služeb, které podporují redundanci zón, najdete v tématu Služba zóny dostupnosti a regionální podpora.
Zónově redundantní nasazení se zálohováním napříč oblastmi
Zónově redundantní nasazení můžete rozšířit provedením pravidelných záloh 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írní extrémně nepravděpodobné výpadky celé oblasti.
Při implementaci tohoto přístupu je potřeba pečlivě zvážit rto a cíl bodu obnovení:
Doba obnovení: Pokud dojde k výpadku oblasti, 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 během závažné 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 zkoušejte kroky potřebné k obnovení řešení zpět 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í obvykle můžete řídit tak, aby splňovaly váš 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. Tato záloha snižuje dopad výpadku celé oblasti minimalizací ztráty dat. Po úplném výpadku oblasti můžete operace ručně obnovit do jiné oblasti. Procesy obnovení ale můžou být složité a ruční obnovení do druhé oblasti může nějakou dobu trvat. |
| Optimalizace nákladů | Střední náklady. Přidání zálohy do jiné oblasti obvykle stojí jen o něco víc než implementace redundance zón. |
| Efektivita výkonu | Pro většinu úloh: Přijatelný výkon. Tento přístup pravděpodobně zajistí uspokojivý výkon. Pro úlohy citlivé na vysokou latenci: Nízký výkon. Některé komponenty můžou být citlivé na latenci kvůli provozu mezi zónami nebo času 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 provádí se automaticky. Během regionální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é aspekty z hlediska architektury:
| Architektonické obavy | 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 pro ukládání záloh je potřeba 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 v libovolné oblasti, která podporuje 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 několik oblastí Azure. Tento přístup pro více oblastí můžete použít ke zlepšení spolehlivosti vašeho řešení nebo k podpoře geograficky distribuovaných uživatelů. Nasazením do několika oblastí také snížíte riziko, že v jedné oblasti dojde k dočasnému omezení kapacity prostředků. Pokud je rezidencí dat pro vaše řešení důležitým zájmem, 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 má smysl mít více oblastí, které aktivně zpracovávají požadavky současně (nasazení aktivní-aktivní). U jiných úloh je lepší určit jednu primární oblast a pro převzetí služeb při selhání použít jednu nebo více sekundárních oblastí (nasazení typu aktivní-pasivní). Tato část se zaměřuje na druhý scénář, ve kterém je jedna oblast aktivní a druhá je pasivní. Informace o řešeních s více oblastmi aktivní-aktivní naleznete 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 data potřebují cestovat. Pokud se připojujete mezi dvěma oblastmi, podívejte se na statistiku latence odezvy sítě Azure pro očekávanou latenci sítě.
Latence sítě napříč oblastmi může výrazně ovlivnit návrh vašeho řešení, protože je potřeba pečlivě zvážit, jak latence navíc ovlivňuje replikaci dat a další transakce. U mnoha řešení architektura napříč oblastmi vyžaduje 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á na potvrzení změny ve všech oblastech. 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, že latence připojení mezi oblastmi nemá přímý vliv na výkon aplikace. Kvůli zpoždění replikace ale může dojít ke ztrátě dat v celé oblasti. K této ztrátě dat může dojít, protože oblast může po dokončení zápisu v primární oblasti dojít k výpadku, ale před replikací změny do jiné oblasti.
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 v případě převzetí služeb při selhání je možná ztráta dat. |
| Optimalizace nákladů | Vysoké náklady. Potřebujete nasadit samostatné prostředky v každé oblasti a každý prostředek nese 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 je obvykle nízký latence. |
| Efektivita provozu | Nízká provozní efektivita. Potřebujete nasadit a spravovat prostředky napříč několika oblastmi. Během regionálního výpadku také zodpovídáte za převzetí služeb při selhání mezi oblastmi. |
Tato tabulka shrnuje některé aspekty z hlediska architektury:
| Architektonické obavy | Dopad |
|---|---|
| Dodržování předpisů s rezidencí dat | Závisí na výběru oblasti. Tento přístup vyžaduje, abyste pro spuštění úlohy vybrali více oblastí. 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 spouštíte úlohu v oblasti, která nemá pár, budete možná 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 způsobená čekáním na operace zápisu závisí na vzdálenosti mezi oblastmi. U mnoha úloh může latence mezi oblastmi zajistit, aby synchronní replikace byla 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 se vždy synchronizují napříč oblastmi, takže i když dojde ke ztrátě celé 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 každý prostředek nese 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. Během regionálního výpadku také zodpovídáte za převzetí služeb při selhání mezi oblastmi. |
Tato tabulka shrnuje některé aspekty z hlediska architektury:
| Architektonické obavy | Dopad |
|---|---|
| Dodržování předpisů s rezidencí dat | Závisí na výběru oblasti. Tento přístup vyžaduje, abyste pro spuštění úlohy vybrali více oblastí. 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 spouštíte úlohu v oblasti, která nemá pár, budete možná muset k replikaci dat použít jiný přístup. |
Architektury oblastí
Při návrhu řešení s více oblastmi zvažte, jestli se oblasti Azure, které plánujete použít, spárují.
Řešení s více oblastmi můžete vytvořit i v případě, že oblasti nejsou spárované. Přístupy, které použijete k implementaci architektury s více oblastmi, se ale můžou lišit. Ve službě Azure Storage můžete například použít geograficky redundantní úložiště (GRS) s 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 více oblastí.
Kombinování přístupů více zón a více oblastí
Pokud vaše obchodní požadavky vyžadují takové řešení, měli byste kombinovat příkazy s více zónami a více oblastmi. Do každé oblasti můžete například nasadit zónově redundantní komponenty a nakonfigurovat replikaci mezi oblastmi. U některých řešení tento přístup poskytuje velmi vysoký stupeň 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 navrhování důležitých úloh, najdete v dokumentaci k důležitým úlohám.
Jak služby Azure podporují přístupy k nasazení
Je důležité pochopit konkrétní podrobnosti o službách Azure, které používáte. Některé služby Azure například vyžadují, abyste při prvním nasazení prostředku nakonfigurovali konfiguraci zóny dostupnosti, zatímco jiné podporují změnu přístupu k nasazení později. Podobně nemusí být některé funkce služeb dostupné u každého přístupu k nasazení.
Další informace o konkrétních možnostech nasazení a přístupech, které je potřeba zvážit pro každou službu Azure, najdete v centru spolehlivosti.
Příklady
Tato část popisuje některé běžné případy použití a klíčové požadavky, které obvykle potřebujete zvážit pro každou úlohu. Pro každou úlohu se poskytuje 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 podniky
Contoso, Ltd., je velká výrobní společnost. Společnost implementuje obchodní aplikaci, která spravuje některé součásti svých finančních procesů.
Obchodní požadavky: Informace, které systém spravuje, je obtížné nahradit, takže data musí být spolehlivě zachována. Architekti říkají, že systém musí mít co nejmenší výpadek a co nejmenší ztrátu dat. Zaměstnanci společnosti Contoso používají systém v průběhu pracovního dne, takže vysoký výkon je důležitý, aby členové týmu nemuseli čekat. Náklady jsou také obavy, protože finanční tým musí zaplatit za řešení.
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
Čtvrtá káva je malá firma. Společnost vyvíjí novou interní aplikaci, kterou mohou zaměstnanci použít k odesílání časových rozvrhů.
Obchodní požadavky: Pro tuto úlohu je hlavní problémem nákladová efektivita. Čtvrtá káva vyhodnotila obchodní dopad výpadků a rozhodla se, že aplikace nemusí určovat prioritu odolnosti nebo výkonu. Společnost přijímá riziko, že výpadek v zóně nebo oblasti dostupnosti Azure může aplikaci dočasně znepřístupnit.
Navrhované přístupy:
- Místně redundantní nasazení se zálohováním napříč oblastmi má nejnižší náklady, ale má také významná rizika.
- Zónově redundantní nasazení se zálohováním napříč oblastmi zajišťuje lepší odolnost, ale mírně vyšší náklady.
Migrace starší verze aplikace
Společnost Fabrikam, Inc., migruje starší verzi aplikace 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 chattovaná.
Obchodní požadavky: Výkon je pro tuto aplikaci prioritou. Odolnost je také důležitá a aplikace musí i nadále 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ími nasazeními napříč několika zónami dostupnosti (zotavení po havárii v jednotlivých oblastech).
Zdravotnická aplikace
Lamna Healthcare Company implementuje nový systém elektronických záznamů o zdravotním stavu v Azure.
Obchodní požadavky: Vzhledem k povaze dat, která toto řešení ukládá, je rezidence dat velmi důležitá. Lamna pracuje v rámci striktního regulačního rámce, který vyžaduje, aby data zůstala v určitém umístění.
Navrhované přístupy:
- Nasazení více zón ve více oblastech, pokud existuje více oblastí, které odpovídají požadavkům na rezidenci dat Lamna.
- Pokud existuje jenom 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 poskytuje řešení s jednou oblastí.
Bankovní systém
Společnost Woodgrove Bank provozuje základní bankovní operace z rozsáhlého řešení nasazeného do Azure.
Obchodní požadavky: Jedná se o nepostradatelný systém. Jakékoli výpadky můžou způsobit velký finanční dopad pro zákazníky. V důsledku toho má Woodgrove Bank velmi nízkou odolnost vůči riziku. Systém potřebuje nejvyšší možnou úroveň spolehlivosti a architektura potřebuje zmírnit riziko jakýchkoli selhání, která je možné zmírnit.
Navrhovaný přístup: Pro kritický systém použijte nasazení s více zónami ve více oblastech. Zajistěte, aby oblasti odpovídaly 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 geograficky široce distribuovaná.
Obchodní požadavky: Proseware musí umožnit každému ze svých zákazníků zvolit oblast nasazení, která je blízko zákazníka. Povolení této volby je důležité pro latenci a požadavky zákazníků na rezidenci dat.
Navrhované přístupy:
- Nasazení s více zónami pro více oblastí je obvykle dobrou volbou pro poskytovatele SaaS, zejména pokud se používá v rámci vzoru Razítka nasazení.
- Zónově redundantní nasazení s jednou oblastí ve spojení s globálním řešením zrychlení 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í s více zónami a více oblastmi:
- Standardní vysoce dostupná zónově redundantní webová aplikace
- Vysoce dostupná webová aplikace pro více oblastí
- N-vrstvá aplikace s více oblastmi
- Vícevrstvé webové aplikace vytvořené pro vysokou dostupnost nebo zotavení po havárii
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: Principy replikace mezi zónami služby Azure NetApp Files
- Redundance Azure Storage
Kontrolní seznam pro spolehlivost
Projděte si kompletní sadu doporučení.