Co jsou redundance, replikace a zálohování?

Cloud často považujeme za globálně distribuovaný a všudypřítomný systém. Ve skutečnosti se ale cloud skládá z hardwaru běžícího v datacentrech. Odolnost vyžaduje, abyste zohlednili některá rizika spojená s fyzickými umístěními, ve kterých běží komponenty hostované v cloudu.

Tento článek obsahuje obecný úvod k redundanci, replikaci a zálohování, což jsou metody, které se používají k vytváření úloh odolných vůči fyzickým rizikům, které způsobují přerušení služeb, výpadky nebo ztrátu dat.

Redundance je schopnost udržovat více identických kopií součásti služby a používat tyto kopie způsobem, který brání tomu, aby se každá komponenta stala jediným bodem selhání.

Replikace nebo redundance dat je schopnost udržovat více kopií dat, označovaných jako repliky.

Zálohování je schopnost udržovat kopii dat s časovým razítkem, která se dají použít k obnovení ztracených dat.

Z hlediska spolehlivosti je důležitým způsobem, jak zmírnit mnoho rizik, zahrnout do plánování kontinuity podnikových procesů určitou formu redundance, replikace nebo zálohování.

Poznámka:

Tento článek neposkytuje pokyny k návrhu ani podrobné informace o jednotlivých službách Azure. Informace o tom, jak konkrétní služby Azure fungují z hlediska spolehlivosti, najdete v průvodci spolehlivostí jednotlivých služeb.

Nadbytečnost

Redundance se skládá z nasazení více instancíkomponenty. I když je redundance jednoduchá pro pochopení, v některých situacích se může stát složitou implementací.

Když začnete rozumět redundanci, je nejjednodušší zvážit redundanci ve vztahu k bezstavovým komponentám, což jsou komponenty, které neukládají žádná data. I když většina řešení z reálného světa vyžaduje správu stavu, v této části probereme redundanci z hlediska příkladu bezstavového aplikačního programovacího rozhraní (API). Ukázkové rozhraní API přijímá vstup, pracuje na tomto vstupu a pak vrací výstup, aniž by ukládaly žádná data. V následující části Replikace: Redundance pro data přidáme důležité informace o stavové redundanci.

Scénář: Bezstavová redundance

V tomto příkladu se na virtuální počítač nasadí bezstavová komponenta rozhraní API. Aby nedošlo k výpadkům komponenty rozhraní API, pokud na fyzickém hostiteli dojde k selhání hardwaru, příklad implementuje redundantní řešení, které:

• Nasadí několik kopií instance rozhraní API.
• Implementuje nástroj pro vyrovnávání zatížení pro distribuci požadavků mezi instancemi rozhraní API.

Nástroj pro vyrovnávání zatížení monitoruje stav každé instance tak, aby odesílal požadavky pouze do instancí, které jsou v pořádku.

Důležité informace o redundanci

Při implementaci redundantních řešení, například ve výše uvedeném scénáři, je důležité vzít v úvahu následující skutečnosti:

• Náklady na zdroje Redundance podle definice zahrnuje několik kopií něčeho, což zvyšuje celkové náklady na hostování řešení.

• Výkon. Čím širší geografickou oblast distribuujete kopie těchto věcí, tím více rizik pomůžete zmírnit. Požadavkům od klientů bude trvat déle, aby urazily delší vzdálenosti, protože musí procházet více síťové infrastruktury, což zvyšuje latenci sítě.

  Ve většině reálných situací je latence sítě nekonvenční pro krátké vzdálenosti, například v rámci datacentra nebo dokonce mezi datovými centry napříč městem. Pokud ale distribuujete kopie napříč dlouhou vzdáleností, může být latence sítě významnější.

• Konzistence instancí Je důležité udržovat instance v souladu s ostatními a vyhnout se individuální konfiguraci instancí, protože mezi instancemi můžete omylem zavést rozdíly. Pokud existují rozdíly mezi instancemi, můžou se požadavky zpracovávat odlišně v závislosti na tom, která instance je obsluhuje. To může způsobit obtížné diagnostiky chyb a chování.

• Rozdělení práce. Pokud máte více instancí komponenty, musíte mezi ně distribuovat práci. Můžete rovnoměrně rozprostřet práci napříč všemi instancemi nebo můžete odesílat požadavky do jedné primární instance a použít sekundární instanci pouze v případě, že primární instance není k dispozici.

  U komponent, které přijímají příchozí požadavky, se nástroje pro vyrovnávání zatížení často používají k odesílání těchto požadavků do instancí. Někdy ale komponenty fungují nezávisle a nedostávají žádosti od klientů, takže v těchto situacích můžou instance potřebovat koordinovat svou práci s ostatními.

• Monitorování stavu Stav každé instance určuje, jestli může tato instance provádět svou práci, a monitorování stavu je důležité, aby bylo možné rychle obnovit, pokud dojde k problému.

  Nástroje pro vyrovnávání zatížení obvykle provádějí monitorování stavu. U komponent, které neobsahují nástroj pro vyrovnávání zatížení, můžete mít externí komponentu, která sleduje stav všech instancí, nebo může každá instance monitorovat stav ostatních instancí.

Fyzická umístění v cloudu

Potřeba redundance je jasná, když pochopíte, že i v cloudovém prostředí se instance nebo část dat ukládají do konkrétního fyzického umístění.

Například:

• Virtuální počítač běží na jednom fyzickém místě najednou.
• Data se ukládají v určitém fyzickém umístění, například na jednotce SSD (Solid-State Drive) nebo na pevném disku připojeném k serverům.

I když existuje více kopií dat nebo instancí komponenty, každá kopie je svázaná s fyzickým hardwarem, na který je uložený.

Fyzické umístění cloudového prostředí jako celek je možné uspořádat do fyzických oborů. V každém fyzickém oboru existují potenciální rizika, která by mohla ohrozit komponenty nebo data v daném oboru. Tady je neúplný seznam rizik, která lze definovat z hlediska fyzického rozsahu:

Fyzický rozsah	Možné riziko
Určitý hardware, například disk nebo server	Selhání hardwaru
Rack v datacentru	Výpadek síťového přepínače umístěného nahoře v racku
Datové centrum	Problém s chladicím systémem budovy
Skupina datacenter, která se v Azure nazývá zóna dostupnosti	Elektrická bouře na celém městě
Širší geografická oblast, ve které je datové centrum, například město, což je oblast Azure	Rozšířená přírodní katastrofa

Z hlediska spolehlivosti je důležitým způsobem, jak zmírnit rizika spojená s fyzickým oborem, rozložit instance komponenty do různých fyzických oborů. Služby Azure s integrovanou redundancí vám můžou nabídnout jeden nebo více z následujících tří způsobů nasazení redundantních instancí:

• Místní redundance umístí instance do několika částí jednoho datacentra Azure a chrání před selháním hardwaru, které můžou mít vliv na jednu instanci. Místní redundance obvykle poskytuje nejnižší náklady a latenci. Selhání datového centra ale může znamenat, že všechny instance nejsou k dispozici.

• Redundance zón rozloží instance mezi více zón dostupnosti v jedné oblasti Azure. Redundance zón chrání kromě selhání hardwaru také před selháními datacentra.

• Geografická redundance umístí instance napříč několika oblastmi Azure a poskytuje ochranu před rozsáhlými oblastmi výpadků. Geografická redundance má vyšší náklady a vyžaduje zvážení širšího návrhu řešení a způsobu přepínání mezi instancemi komponent v jednotlivých oblastech. Musíte také zvážit latenci, která je popsaná v synchronní a asynchronní replikaci.

Jak funguje redundance v Azure: Výpočetní služby

Redundance se používá téměř v každé části Azure. Jako příklad implementace redundance v Azure zvažte služby, které spouštějí výpočetní úlohy.

V Azure běží jednotlivé virtuální počítače na jednom fyzickém hostiteli v datacentru Azure. Do Azure můžete poskytnout pokyny, abyste zajistili, že virtuální počítač běží na očekávaném místě, jako je oblast a zóna dostupnosti, a v některých situacích byste ho mohli chtít umístit na hostitele, který je pro vás vyhrazený.

Je běžné spouštět více instancí virtuálního počítače. V tomto scénáři se můžete rozhodnout, jestli je budete spravovat jednotlivě, nebo pomocí škálovací sady virtuálních počítačů. Když použijete škálovací sadu, stále uvidíte jednotlivé virtuální počítače, které ji podporují, ale škálovací sada poskytuje řadu funkcí, které vám pomůžou spravovat redundantní virtuální počítače. Mezi tyto funkce patří automatické umístění virtuálních počítačů na základě vámi určených pravidel, například jejich rozložením mezi domény selhání v rámci oblasti nebo zóny dostupnosti.

Existuje mnoho dalších výpočetních služeb Azure, které k provádění výpočetních úloh spoléhají na virtuální počítače. Výpočetní služby obecně nabízejí různá nastavení redundance, která určují způsob distribuce virtuálních počítačů. Služba může například poskytnout nastavení redundance zóny, které můžete povolit automatické distribuci virtuálních počítačů mezi zóny dostupnosti a nakonfigurovat vyrovnávání zatížení.

Replikace: Datová redundance

Redundance, když je použita na stav (data), se nazývá replikace. Pomocí replikace můžete udržovat více kopií živých dat v reálném čase nebo téměř v reálném čase, označovaných jako repliky. Pokud chcete zlepšit odolnost vůči rizikům, můžete repliky distribuovat do různých umístění. Pokud se jedna replika stane nedostupnou, může systém přepnout, aby jiná replika převzala její funkci.

Existují různé typy replikace a každá z nich klade různé priority na konzistenci dat, výkon a náklady. Každý typ replikace ovlivňuje dvě klíčové metriky používané v diskuzích o provozní kontinuitě: cíl doby obnovení (RTO), což je maximální doba výpadku, kterou můžete tolerovat ve scénáři havárie, a cíl bodu obnovení (RPO), což je maximální objem ztráty dat, kterou můžete tolerovat ve scénáři havárie. Další informace o těchto metrikách a jejich vztahu k provozní kontinuitě najdete v tématu Co jsou provozní kontinuita, vysoká dostupnost a zotavení po havárii?

Vzhledem k důležitosti replikace při splnění funkčních a výkonnostních požadavků zahrnuje většina databázových systémů a dalších produktů a služeb úložiště dat určitý druh replikace jako úzce integrovaná funkce. Typy replikace, které nabízejí, jsou obvykle založené na jejich architektuře a způsobech jejich použití. Další informace o typech replikace podporovaných službami Azure najdete v průvodcích spolehlivostí služeb Azure.

Důležité

Replikace není stejná jako zálohování. Replikace synchronizuje všechny změny mezi více replikami a neudržuje staré kopie dat.

Předpokládejme, že omylem odstraníte nějaká data. Operace odstranění se replikuje do každé repliky a vaše data se odstraní všude. V takovém případě pravděpodobně budete muset obnovit odstraněná data ze zálohy. Zálohování je popsáno dále v tomto článku.

Synchronní a asynchronní replikace

Při replikaci dat se všechny změny dat musí uchovávat v synchronizaci mezi replikami. Při pokusu o zachování konzistence při změně dat existuje několik hlavních problémů:

• Latence. Aktualizace repliky nějakou dobu trvá a čím dál od sebe repliky jsou, tím déle trvá přenos dat mezi replikami a přijetí potvrzení.

• Správa změn Data se můžou změnit, když se repliky synchronizují, takže správa konzistence dat může být složitá.

Pro řešení těchto problémů existují dva hlavní způsoby, jak replikovat změny dat a spravovat konzistenci dat:

• Synchronní replikace vyžaduje, aby se aktualizace uskutečnily na více replikách, než je aktualizace považována za dokončenou. Následující diagram znázorňuje, jak funguje synchronní replikace:

  

  V tomto příkladu nastane následující posloupnost kroků:

  1. Klient změní data a požadavek se odešle na repliku 1, která požadavek zpracuje a uloží změněná data.
  2. Replika 1 odešle změny do repliky 2, která zpracuje požadavek a uloží změněná data.
  3. Replika 2 bere na vědomí změnu zpět na repliku 1.
  4. Replika 1 potvrdí změnu zpět klientovi.

  Synchronní replikace může zaručit konzistenci, což znamená, že podporuje RPO nuly. To však přichází na úkor výkonu. Čím dále od sebe jsou vaše repliky geograficky a čím více přeskoků v síti je potřeba překonat, tím více latence bude způsobena procesem replikace.

• Asynchronní replikace probíhá na pozadí. Následující diagram znázorňuje, jak funguje asynchronní replikace:

  

  V tomto příkladu nastane následující posloupnost kroků:

  1. Klient změní data a požadavek se odešle na repliku 1.
  2. Replika 1 zpracuje požadavek, uloží změněná data a okamžitě potvrdí změnu zpět klientovi.
  3. V pozdějším okamžiku replika 1 synchronizuje změnu s replikou 2.

  Vzhledem k tomu, že asynchronní replikace probíhá mimo toky transakcí, odstraňuje replikaci jako překážku výkonu aplikace. Pokud ale potřebujete přepnout na jinou repliku, nemusí obsahovat nejnovější data, takže váš RPO musí být větší než nula. Přesný bod obnovení, který může asynchronní replikace podporovat, závisí na frekvenci replikace.

Replikové role

V mnoha systémech replikace můžou repliky provádět různé role, což pomáhá koordinovat změny dat a snižuje riziko konfliktů. Existují dva hlavní typy rolí, aktivní a pasivní. Existují dva běžné způsoby distribuce replik s těmito rolemi:

• Aktivní-pasivní replikace znamená, že máte jednu aktivní repliku, která je zodpovědná za to, že funguje jako zdroj pravdy. Jakékoliv změny provedené na datech musí být použity na tuto repliku. Všechny ostatní repliky fungují v pasivní roli, což znamená, že přijímají aktualizace dat z aktivní repliky, ale nezpracovávají změny přímo od klientů. Pasivní repliky se nepoužívají pro živý provoz, pokud nedojde k převzetí služeb při selhání a role replik se změní. Následující diagram znázorňuje systém aktivní-pasivní s jednou pasivní replikou:

  

  V systému aktivní-pasivní délka času potřebného k převzetí služeb po selhání určuje RTO. RtO pro aktivní pasivní systém se obvykle měří v minutách.

  Některá řešení replikace také podporují repliky jen pro čtení, které umožňují číst (ale ne zapisovat) data z pasivních replik. Tento přístup může být užitečný k získání většího využití z replik, například když potřebujete provádět analýzy nebo vytváření sestav dat, aniž by to mělo vliv na primární repliku, kterou používáte pro transakční práci vaší aplikace. Několik služeb Azure podporuje repliky jen pro čtení, včetně Azure Storage s typem replikace GRS (RA-GRS) pro čtení a aktivní geografickou replikací služby Azure SQL Database.

• Replikace aktivní-aktivní umožňuje použít současně více aktivních replik pro přímý provoz, a každá replika může zpracovávat požadavky.

  

  Replikace aktivní-aktivní umožňuje vysokou úroveň výkonu, protože systém může používat prostředky na všech replikách. Replikace aktivní-aktivní může v některých situacích podporovat RTO rovnající se nule. Tyto výhody ale stojí za to, že komplikují konzistenci dat, protože souběžné konkurenční změny na více replikách může být potřeba sloučit asynchronně.

Komplexní datové služby můžou kombinovat replikaci typu aktivní-aktivní i pasivní. Můžou například nasadit jednu sadu replik v jedné oblasti Azure a jinou v jiné oblasti. V rámci každého regionu obsluhuje jedna aktivní replika požadavky, zatímco jedna nebo více pasivních replik je připraveno převzít funkci v případě selhání. Mezitím obě oblasti fungují v modelu aktivní-aktivní, což umožňuje distribuci provozu mezi nimi.

Jak funguje replikace v datových službách Azure

Každá služba Azure, která ukládá data, nabízí určitou formu replikace. Každá služba ale může používat jiný přístup, který je specifický pro architekturu služby a zamýšlené použití.

Azure Storage může například poskytovat synchronní i asynchronní replikaci prostřednictvím sady funkcí:

• Několik kopií vašich dat se synchronně replikuje v rámci vaší primární oblasti. Můžete zvolit, jestli umístit repliky na jiný fyzický hardware v jednom datacentru v místně redundantním úložišti (LRS) nebo je rozložit do několika zón dostupnosti pro zónově redundantní úložiště (ZRS).
• Pokud je primární oblast spárovaná a povolíte geograficky redundantní úložiště (GRS), data se také replikují do spárované oblasti. Vzhledem k tomu, že spárované oblasti jsou geograficky vzdálené, dochází k této replikaci asynchronně, aby se snížil dopad na propustnost aplikace.
• Zónově redundantní úložiště a geograficky redundantní úložiště můžete použít současně pomocí geograficky zónově redundantní úrovně úložiště (GZRS). Data v rámci oblasti se replikují synchronně a data napříč oblastmi se replikují asynchronně.

Další informace najdete v článku Možnosti redundance Azure Storage.

Dalším příkladem je Azure Cosmos DB, která také poskytuje replikaci. Všechny databáze Azure Cosmos DB mají více replik. Když distribuujete repliky globálně, podporuje zápisy do více oblastí, kde můžou klienti zapisovat do repliky v libovolné z oblastí, které používáte. Tyto operace zápisu se synchronně replikují v rámci oblasti a pak se replikují asynchronně napříč ostatními oblastmi. Azure Cosmos DB poskytuje mechanismus řešení konfliktů pro případ, že v různých replikách dojde ke konfliktům zápisu. Další informace najdete v tématu Globální distribuce dat pomocí služby Azure Cosmos DB – pod kapotou.

Pokud používáte virtuální počítače, můžete pomocí Azure Site Recovery replikovat virtuální počítače a jejich disky mezi zónami dostupnosti nebo do jiné oblasti Azure.

Při navrhování řešení Azure si projděte příručky pro spolehlivost jednotlivých služeb , abyste pochopili, jak tato služba poskytuje redundanci a replikaci, včetně různých umístění.

Zálohování

Zálohování vytvoří kopii vašich dat k určitému časovému bodu. Pokud dojde k problému, můžete zálohování obnovit později. Jakékoli změny dat, ke kterým došlo po vytvoření zálohy, se ale nebudou v zálohování vyskytovat a můžou být ztraceny.

Pomocí zálohování můžete poskytovat řešení pro zálohování a obnovení dat v rámci cloudu Microsoft Azure nebo do cloudu Microsoft Azure. Zálohování vás může chránit před různými riziky, včetně následujících:

• Závažné ztráty hardwaru nebo jiné infrastruktury.
• Poškození a odstranění dat
• Kybernetické útoky, jako je ransomware.

Důležité

Kromě dalších kroků obnovení je důležité pravidelně testovat a ověřovat procesy zálohování a obnovení. Testování zajišťuje, aby vaše zálohy byly komplexní a bez chyb a aby je procesy správně obnovily. Testy jsou také důležité, aby váš tým rozuměl procesům, které mají následovat. Další podrobnosti viz Testování a cvičení.

Vliv zálohování na vaše požadavky

Používají-li se jako součást strategie zotavení po havárii, zálohy obvykle podporují dobu obnovy (RTO) a cílový bod obnovy (RPO), které se měří v hodinách.

• RTO (plánovaná doba obnovení) je ovlivněné časem potřebným k zahájení a dokončení procesů obnovy, včetně obnovy zálohy a ověření úspěšného dokončení obnovy. V závislosti na velikosti zálohy a na tom, kolik záložních souborů je potřeba číst, je běžné, že úplné obnovení zálohy trvá několik hodin nebo i déle.

• RPO je ovlivněno četností procesu zálohování. Pokud vytváříte zálohy častěji, znamená to, že při obnovení ze zálohy ztratíte méně dat. Zálohy však vyžadují úložiště a v některých situacích můžou mít vliv na výkon služby při provádění záloh. Z tohoto důvodu je potřeba zvážit frekvenci zálohování a najít správnou rovnováhu pro požadavky vaší organizace. Četnost zálohování by měla být při plánování kontinuity podnikových procesů potřeba vzít v úvahu.

Některé systémy zálohování podporují složitější požadavky na zálohování, včetně několika úrovní zálohování s různými obdobími uchovávání a rozdílové nebo přírůstkové zálohování, které jsou rychlejší a šetří a spotřebovávají méně úložiště.

Zálohování ve službách Azure

Mnoho služeb Azure poskytuje možnosti zálohování vašich dat.

Azure Backup je vyhrazené řešení zálohování pro několik klíčových služeb Azure, včetně virtuálních počítačů, Azure Storage a Azure Kubernetes Service (AKS).

Mnoho spravovaných databází také poskytuje své vlastní možnosti zálohování jako součást služby, například:

• Azure SQL Database poskytuje automatizované zálohy.
• Azure Cosmos DB poskytuje možnosti průběžného i pravidelného zálohování.
• Azure Key Vault umožňuje stáhnout zálohu dat ve vašem trezoru.
• Azure App Service poskytuje automatické i vlastní zálohování webových aplikací a může také zálohovat své databáze.

Zálohování vs. replikace

Zálohování a replikace vás chrání před různými riziky a oba přístupy se vzájemně doplňují.

Replikace podporuje každodenní odolnost a běžně se používá ve strategii vysoké dostupnosti. Některé přístupy replikace vyžadují minimální až žádné výpadky a žádnou ztrátu dat a podporují nízkou plánovanou dobu obnovení (RTO) a cíl bodu obnovení (RPO). Replikace vás ale nechrání před riziky, která vedou ke ztrátě nebo poškození dat.

Zálohování je naproti tomu často poslední obranou proti katastrofickým rizikům. Zálohy často vyžadují relativně vysoké RTO a RPO, i když to, jak zálohy nakonfigurujete, přesně ovlivní, jak vysoké budou. Celkové obnovení ze zálohy je často součástí plánu zotavení po havárii.

Příprava komponent pro redundanci

Při návrhu systému, který v rámci architektury využívá redundanci, je důležité zvážit také následující postupy:

• Duplicování konfigurace prostředků pro zachování konzistence
• Spravujte kapacitu při selhání instance pomocí nadměrného zajištění.

Duplicitní konfigurace prostředků

V cloudových prostředích je důležitá konfigurace jednotlivých prostředků. Když například vytvoříte nástroj pro vyrovnávání zatížení sítě, nakonfigurujete řadu nastavení, která ovlivňují jeho fungování; a když nasadíte funkci pomocí Azure Functions, nakonfigurujete nastavení související se zabezpečením, výkonem a nastavením konfigurace aplikace. Každý prostředek v Azure má určitou konfiguraci, která řídí jeho chování.

Při správě redundantních kopií prostředků na různých místech je důležité řídit jejich konfiguraci. Mnoho nastavení bude potřeba nastavit stejným způsobem napříč jednotlivými kopiemi, aby se prostředky chovaly stejným způsobem. Některá nastavení se ale můžou mezi jednotlivými kopiemi lišit, například odkazy na virtuální síť konkrétní oblasti.

Běžným přístupem k zachování konzistence ve vašich prostředcích je použití infrastruktury jako kódu (IaC), jako je Bicep nebo Terraform. Tyto nástroje umožňují vytvářet soubory, které definují prostředek, a tyto definice můžete znovu použít pro každou instanci prostředku. Pomocí IaC můžete snížit zátěž při vytváření a správě více instancí prostředků pro účely odolnosti a existuje mnoho dalších výhod. Další informace najdete v tématu Co je infrastruktura jako kód (IaC)? a doporučení pro použití infrastruktury jako kódu.

Správa kapacity s využitím přídělu zdrojů nad rámec potřeb

Když instance selže, může se celková kapacita systému lišit od kapacity, která se vyžaduje během operací, které jsou v pořádku. Předpokládejme například, že pro zpracování příchozího webového provozu obvykle máte šest instancí webového serveru a tyto instance jsou rovnoměrně rozdělené mezi tři zóny dostupnosti Azure v oblasti:

Pokud dojde k výpadku zóny dostupnosti, můžete dočasně ztratit dvě instance a zůstat pouze se čtyřmi instancemi webového serveru. Pokud je vaše aplikace obvykle zaneprázdněná a vyžaduje, aby všech šest instancí zvládalo běžný objem provozu, pak by provoz v omezené kapacitě mohl ovlivnit výkon vašeho řešení.

Pokud se chcete připravit na selhání, můžete naddimenzovat kapacitu své služby. Předimenzování umožňuje řešení tolerovat určitou míru ztráty kapacity a fungovat dále bez snížení výkonu.

Chcete-li předimenzovat instance webového serveru pro pokrytí selhání jedné zóny dostupnosti, postupujte takto:

1. Určete počet instancí, které vyžaduje vaše maximální pracovní zátěž.
2. Načíst počet instancí nadměrného zajištění vynásobením počtu instancí při maximálním zatížení faktorem [(zóny/(zóny-1)].
3. Zaokrouhlí výsledek na nejbližší celé číslo.

Poznámka:

Následující tabulka předpokládá, že používáte tři zóny dostupnosti a chcete zohlednit ztrátu v kapacitě jedné z těchto zón. Pokud se vaše požadavky liší, upravte vzorec odpovídajícím způsobem.

Počet instancí pracovního zatížení ve špičce	Faktor [(zón/(zón-1)]	Vzorec	Instance pro poskytování (zaokrouhlené)
3	3/2 nebo 1,5	(3 x 1,5 = 4,5)	5 instancí
4	3/2 nebo 1,5	(4 x 1,5 = 6)	6 instancí
5	3/2 nebo 1,5	(5 x 1,5 = 7,5)	8 instancí
6	3/2 nebo 1,5	(6 x 1,5 = 9)	9 instancí
7	3/2 nebo 1,5	(7 x 1,5 = 10,5)	11 instancí
8	3/2 nebo 1,5	(8 x 1,5 = 12)	12 instancí
9	3/2 nebo 1,5	(9 x 1,5 = 13,5)	14 instancí
10	3/2 nebo 1,5	(10 x 1,5 = 15)	15 instancí

V předchozím příkladu vyžaduje špička zatížení šest instancí webového serveru, takže nadměrné zřizování vyžaduje celkem devět instancí:

Další kroky

Přečtěte si informace o převzetí služeb při selhání a navrácení služeb po obnovení.