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, pozorujte průvodce spolehlivostí jednotlivých služeb.

Redundancy

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.

Diagram znázorňující tři instance komponenty s nástrojem pro vyrovnávání zatížení, který distribuuje provoz mezi nimi

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.

Diagram znázorňující tři instance komponenty, z nichž jedna selhala, zatímco zbývající dvě instance nadále fungují

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žadavky klientů ale potrvají déle, když budou muset cestovat delší vzdálenosti, protože musí procházet více síťové infrastruktury, což zvyšuje síťovou latenci.

    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. Zde je částečný seznam rizik, která lze definovat v rámci 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 v horní části 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 Azure region 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ů. Azure služby 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í:

  • Local redundance umístí instance do více částí jednoho datacentra Azure a chrání před selháními 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.

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

  • Geo-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ěř ve všech částech Azure. Jako příklad, jak Azure implementovat redundanci, 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. Můžete poskytnout pokyny pro Azure, abyste zajistili, že se virtuální počítač bude spouštět na očekávaném místě, jako je oblast a zóna dostupnosti, a v některých situacích můžete chtít dokonce umístit ho na hostitele, který je vyhrazený pro vás.

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 Azure výpočetních služeb, 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: Redundance dat

Redundance, pokud se jedná o stav (data), se označuje jako 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 bude jedna replika nedostupná, může systém přepnout na záložní, aby jiná replika převzala jeho 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žby 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:

    Diagram znázorňující synchronní replikaci mezi dvěma replikami

    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 zaručuje konzistenci, což znamená, že podporuje RPO nula. To je však na úkor výkonu. Čím dále od sebe vaše repliky jsou geograficky a čím více síťových skoků je potřeba překonat, tím více latence bude proces replikace zavádět.

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

    Diagram znázorňující asynchronní replikaci mezi dvěma replikami

    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 určitém okamžiku později replika 1 synchronizuje změnu na repliku 2.

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

Role repliky

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. Veškeré změny provedené na datech musí být aplikovány 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 nezmění. Následující diagram znázorňuje systém aktivní-pasivní s jednou pasivní replikou:

    Diagram znázorňující replikaci typu aktivní-pasivní mezi dvěma replikami

    Délka doby, kterou trvá převzetí při selhání v systému aktivní-pasivní, 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í geografické replikace v Azure SQL Database.

  • Replikace aktivní-aktivní umožňuje využívat více aktivních replik současně pro živý provoz, přičemž každá z replik může zpracovávat požadavky:

    Diagram znázorňující replikaci aktivní-aktivní mezi dvěma replikami

    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 nulový RTO. 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í. Mohou například nasadit jednu sadu replik v jedné Azure oblasti a jiné v jiné oblasti. V každé oblasti obsluhuje jedna aktivní replika požadavky, zatímco jedna nebo více pasivních replik je připraveno k převzetí provozu při selhání. Současně obě oblasti fungují v modelu aktivní-aktivní, což umožňuje distribuci provozu napříč nimi.

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

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í.

Například Azure Storage může 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 tématu Azure Storage redundance.

Dalším příkladem je Azure Cosmos DB, který také poskytuje replikaci. Všechny Azure Cosmos DB databáze 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ů v případě, že existují konflikty zápisu mezi různými replikami. Další informace najdete v tématu Globální distribuce dat s Azure Cosmos DB – v zákulisí.

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

Při navrhování řešení Azure se podívejte na příručky spolehlivosti pro každou službu, abyste zjistili, jak tato služba zajišťuje redundanci a replikaci, včetně napříč různými lokalitami.

Backup

Zálohování pořídí kopii vašich dat v určitém časovém okamžiku. 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 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ší informace najdete v tématu Testování a cvičení.

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

Pokud se používají jako součást strategie zotavení po havárii, zálohy obvykle podporují RTO a RPO, které se měří v hodinách:

  • RTO je ovlivněné časem potřebným k zahájení a dokončení procesů obnovy, včetně obnovy zálohy a ověření, že obnova byla úspěšně dokončena. 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 Azure služeb 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:

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 nebo ztráty dat a podporují nízký RTO a 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ě vysokou plánovanou dobu obnovy (RTO) a cíl bodu obnovení (RPO), ačkoli způsob, jakým konfigurujete zálohy, ovlivňuje, jak vysoké tyto hodnoty 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:

  • Duplicitní konfigurace prostředků pro konzistenci
  • Spravujte kapacitu během selhání instance prostřednictvím nadměrného přidělování zdrojů.

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ž funkci nasadíte 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ělení nadměrných zdrojů

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 Azure zón dostupnosti v oblasti:

Diagram znázorňující tři zóny dostupnosti se dvěma instancemi webového serveru pro celkem šest instancí kapacity

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í udrželo krok s normálním provozem, může to ovlivnit výkon vašeho řešení.

Pokud se chcete připravit na selhání, můžete předimenzovat 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 nadmíru zřizovat instance svého webového serveru, aby bylo možné reagovat na selhání jedné zóny dostupnosti, postupujte takto:

  1. Určete počet instancí, které vaše špičková pracovní zátěž vyžaduje.
  2. Získejte počet instancí pro nadměrné zřízení 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í úloh ve špičce Faktor [(počet zón/(počet zón-1)] Formula Instance pro zřízení (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í:

Diagram znázorňující nadměrné zřizování webových serverů pro celkem devět instancí kapacity

Další kroky

Přečtěte si informace o přepnutí při selhání a obnovení.

  • Last updated on