Plánování kapacity s využitím Azure Site Recovery
Jako organizace je nezbytné přijmout strategii provozní kontinuity a zotavení po havárii (BCDR), která zajišťuje bezpečnost dat, dostupné aplikace a úlohy online během plánovaných a neplánovaných výpadků.
Prostřednictvím replikace úloh virtuálních počítačů z primární lokality do sekundární lokality poskytuje Azure Site Recovery ve službě Azure Stack Hub služby, které můžou během výpadků podporovat bezpečnost dat organizace, dostupnosti aplikací a úloh. Pokud například dojde k výpadku v primární lokalitě, přepnete na sekundární umístění pro přístup k vašim aplikacím. Jakmile bude primární místo znovu spuštěno, můžete se přepnout zpět na něj. Další informace naleznete v tématu O službě Site Recovery.
Pokud chcete povolit replikaci virtuálních počítačů mezi dvěma instancemi Azure Stack Hub, nakonfigurujte dvě prostředí:
-
zdrojové prostředí:
- Razítko služby Azure Stack Hub, ve kterém jsou spuštěné virtuální počítače tenanta.
-
Cílové prostředí:
- Kde běží poskytovatel prostředků Azure Site Recovery.
Důležitou součástí úspěchu plánu provozní kontinuity a zotavení po havárii je plánování kapacity. Během plánování kapacity je potřeba vzít v úvahu několik faktorů:
Cíle doby obnovení (RTO) a cíle bodu obnovení (RPO) pro konkrétní úlohy, které chcete chránit.
Úlohy a charakteristiky aplikace:
- Jak často se data mění v příslušném virtuálním počítači.
- Kolik dat se generuje nebo odebírá?
- Jak návrh aplikace vypadá a další?
Velikosti virtuálních počítačů, počet disků a způsob, jakým jsou jednotlivé virtuální počítače svázané s jinými virtuálními počítači.
- U řešení, která vyžadují několik virtuálních počítačů, zjistěte, v jakém pořadí je potřeba tyto virtuální počítače spustit.
Šířka pásma sítě mezi zdrojovým a cílovým prostředím Tato komponenta může ovlivnit RPOs.
Každý z těchto bodů je důležitý a má široké důsledky při vytváření plánu BCDR.
Následující části obsahují hlavní body, které je potřeba vzít v úvahu z pohledu Azure Site Recovery. Každý plán BCDR se liší a je založený na specifikách úloh, které plánujete chránit. Tento seznam proto není vyčerpávající.
Důležité informace o zdroji
Ve zdrojovém prostředí azure Stack Hub spouští zařízení virtuálního počítače Azure Site Recovery. Virtuální počítač je virtuální počítač Standard_DS4_v2 (8 virtuálních procesorů, 28 Gb paměti, 32 datových disků), který běží v předplatném uživatele služby Azure Stack Hub.
Ve zdrojovém prostředí zvažte následující oblasti:
Kvóta:
- Měli byste mít dostatečnou kvótu pro vytvoření aplikace virtuálního počítače Azure Site Recovery. Potřebujete jednu nebo více v závislosti na celkovém plánu.
Úložiště pro zařízení virtuálního počítače Azure Site Recovery:
Samotné zařízení virtuálního počítače Azure Site Recovery má požadavky na data definované velikostí virtuálního počítače.
Při plánování kapacity se ujistěte, že má virtuální zařízení dostatek úložiště pro použití mechanismů obnovení a opětovné zabezpečení.
Poznámka
Pokud existují omezení úložiště, může zpětné obnovení a opětovná ochrana selhat s chybou zprávy došlo k vnitřní chybě. Uživatelé by měli zkontrolovat protokoly událostí na zařízení a potvrdit skutečnou chybu Azure Resource Manageru. Další informace najdete v tématu známé problémy se službou Azure Site Recovery.
Šířka pásma:
- Počáteční replikace generuje vysoké využití šířky pásma.
- Změny jednotlivých virtuálních počítačů se replikují v závislosti na zásadách replikace a jednotlivých typech aplikací.
Ohledy na cíl
V cílovém prostředí je potřeba zvážit dvě části plánování kapacity:
Požadavky služby Azure Site Recovery: kolik je spotřebováno ke spuštění Služby Azure Site Recovery, aniž by bylo nutné chránit jakékoli úlohy.
Požadavky na chráněné pracovní zátěže.
Cílové prostředí vyžaduje vytvoření jednoho trezoru Azure Site Recovery pro každé zařízení Site Recovery, aby bylo možné chránit virtuální počítače ze zdroje (jedno zařízení na trezor). I když to není omezení z hlediska kapacity, měli byste při plánování návrhu celkového prostředí vzít v úvahu.
Prostředky služby Azure Site Recovery RP
Instalace Služby Azure Site Recovery ve službě Azure Stack Hub vyžaduje, abyste nainstalovali poskytovatele prostředků Site Recovery.
Poznámka
S Microsoft.SiteRecovery-1.2301.2216.2287 Azure Site Recovery ve službě Azure Stack Hub nevyžaduje službu Event Hubs jako závislost.
Tato služba se vytváří v předplatném pro správu služby Azure Stack Hub a spravuje ji sama služba Azure Stack Hub, takže není nutná žádná konfigurace. Stejně jako u jakékoli služby tyto prostředky spotřebovávají paměť, úložiště a mají přidělené určité virtuální procesory:
| Služba | vCore | Paměť | Velikost disku |
|---|---|---|---|
| Azure Site Recovery | 18 | 64 GB | 384 GB |
Poznámka
Tyto prostředky jsou služby Azure Stack Hub na správní straně Azure Stack Hub. Po instalaci spravuje platforma tyto prostředky.
Chráněné pracovní úlohy
Při vytváření plánu BCDR zvažte všechny aspekty chráněných úloh. Následující seznam není úplný a měl by se považovat za výchozí bod:
Velikost virtuálního počítače, počet disků, velikost disku, IOPS, četnost změn dat a vytvořená nová data.
Aspekty šířky pásma sítě:
- Šířka pásma sítě, která se vyžaduje pro rozdílovou replikaci.
- Propustnost v cílovém prostředí, kterou azure Site Recovery může získat ze zdrojového prostředí.
- Počet virtuálních počítačů, které je třeba dávkovat najednou. Toto číslo vychází z odhadované šířky pásma pro dokončení počáteční replikace v daném časovém intervalu.
- Cíl bodu obnovy (RPO), kterého lze dosáhnout pro danou šířku pásma.
- Dopad na požadovaný cíl RPO, pokud je zajištěna nižší šířka pásma.
Důležité informace o úložišti:
- Kolik dat je potřeba pro počáteční replikaci.
- Kolik bodů obnovení se uchovává a jak se v těchto intervalech zvyšuje počet dat pro každý chráněný virtuální počítač.
- Kolik kvót je potřeba přiřadit k cílovým předplatným uživatelů služby Azure Stack Hub, aby měli uživatelé dostatečné přidělení.
- Účet úložiště mezipaměti pro replikaci.
Úvahy o výpočetních prostředcích:
- Když dojde k převzetí služeb při selhání systému, virtuální počítače se spustí v cílovém uživatelském předplatném služby Azure Stack Hub. K tomu, aby bylo možné spustit tyto prostředky virtuálních počítačů, musí být kvóty přiděleny v dostatečném množství.
- Když je chráněný virtuální počítač aktivní ve zdrojovém prostředí, během ochrany virtuálního počítače se v cílovém prostředí spotřebovávají žádné prostředky související s virtuálními počítači, jako jsou vCPU, paměť atd. Tyto prostředky se stanou relevantními pouze během procesu převzetí služeb v případě poruchy, jako je testovací proces převzetí služeb.
Pro rozsah Služby Azure Site Recovery ve službě Azure Stack Hub tady je výchozí bod pro výpočty, zejména pro použitý účet úložiště mezipaměti:
Pokud dojde k převzetí služeb při selhání během normálních operací, vynásobte počet replikovaných disků průměrným RPO. Můžete mít například (2 MB * 250s). Účet úložiště mezipaměti je obvykle několik kB až 500 MB na disk.
Pokud dojde k převzetí služeb při selhání v případě nejhoršího scénáře, vynásobte počet replikovaných disků průměrným RPO za celý den.
Důležitý
Pokud některé části Azure Site Recovery nefungují, ale jiné fungují, může být v účtu úložiště maximálně jeden den difflogu, než se Azure Site Recovery rozhodne vypršet časový limit.
Přepnutí zpět na nový virtuální počítač Vypočítejte součet velikostí disků jednotlivých dávek.
- Celý disk se musí zkopírovat do účtu úložiště mezipaměti, aby bylo možné aplikovat cílový virtuální počítač, protože cílový disk je prázdný.
- Přidružená data jsou po zkopírování odstraněna, ale pravděpodobně dojde k maximálnímu využití při součtu všech velikostí disků.
Vytvořte plán BDCR na základě specifik řešení, které se pokoušíte chránit.
Následující tabulka je příkladem spuštění testů v našich prostředích. Tento přehled můžete použít k získání směrného plánu pro vlastní aplikaci, ale každá úloha se liší:
Konfigurace
| Velikost bloku | Propustnost disku |
|---|---|
| 2 MB | 2 MB/s |
| 64 kB | 2 MB/s |
| 8 kB | 1 MB/s |
| 8 kB | 2 MB/s |
Výsledek
| Počet podporovaných disků | Celková propustnost | Celkový počet OPS | Úzké hrdlo |
|---|---|---|---|
| 68 | 136 MB/s | 68 | skladování |
| 60 | 120 MB/s | 2048 | skladování |
| 28 | 28 MB/s | 3584 | Procesor a paměť Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Poznámka
8 kB je nejmenší velikost bloku dat, která Azure Site Recovery podporuje. Všechny změny menší než 8 kB se považují za 8 kB.
Abychom mohli dále testovat, vygenerovali jsme konzistentní typ pracovní zátěže; například konzistentní změny úložiště v blocích 8 kB, které celkově dosahují až 1 MB/s na jeden disk. Tento scénář není pravděpodobně ve skutečné úloze, protože změny můžou probíhat v různých denních časech nebo ve špičkách různých velikostí.
K replikaci těchto náhodných vzorů jsme také otestovali následující scénáře:
- 120 virtuálních počítačů (80 Windows, 40 Linux) chráněných prostřednictvím stejného zařízení virtuálního počítače Azure Site Recovery
Každý virtuální počítač generující v náhodných intervalech, alespoň dvakrát za hodinu, náhodné bloky celkem 5 Gb dat napříč pěti soubory.
Replikace proběhla úspěšně na všech 120 virtuálních počítačích s nízkým až středním zatížením služeb Azure Site Recovery.
Poznámka
Tato čísla by se měla používat jenom jako směrný plán. Nemusí se nutně škálovat lineárně. Přidání další dávky stejného počtu virtuálních počítačů může mít menší dopad než počáteční dávka. Výsledky jsou vysoce závislé na typu použitých úloh.
Jak byste měli plánovat a testovat
Aplikace a úlohy řešení mají určité požadavky na plánovanou dobu obnovení (RTO) a cíl bodu obnovení (RPO). Efektivní návrh provozní kontinuity a zotavení po havárii (BCDR) využívá možnosti na úrovni platformy, které splňují tyto požadavky, protože používáme mechanismy specifické pro řešení. Pokud chcete navrhnout možnosti BCDR, zachyťte požadavky na zotavení po havárii platformy a zvažte všechny tyto faktory ve vašem návrhu:
Požadavky na dostupnost aplikací a dat:
- Požadavky na RTO a RPO pro každou pracovní zátěž.
- Podpora vzorů dostupnosti typu aktivní-aktivní a aktivní-pasivní.
Podpora nasazování ve více regionech pro převzetí služeb při selhání, s blízkostí součástí pro zajištění výkonu. Během výpadku můžete zaznamenat operace aplikací se sníženou funkčností nebo sníženým výkonem.
Poznámka
Aplikace může nativně vědět, že se má spustit nebo má určité komponenty, které můžou běžet v několika prostředích služby Azure Stack Hub. V takovém případě můžete pomocí Azure Site Recovery replikovat pouze virtuální počítače s komponentami, které tuto funkci nemají; Například front-endové nebo back-endové řešení, ve kterém můžete front-endy nasadit napříč prostředími služby Azure Stack Hub.
Nepoužívejte překrývající se rozsahy IP adres v produkčních sítích a sítích zotavení po havárii.
- Produkční sítě a sítě zotavení po havárii, které mají překrývající se IP adresy, vyžadují proces převzetí služeb při selhání, který může komplikovat a zpozdit převzetí služeb při selhání aplikace. Pokud je to možné, naplánujte síťovou architekturu BCDR, která poskytuje souběžné připojení ke všem lokalitám.
Určení velikosti cílových prostředí:
- Pokud zdroj a cíl používáte způsobem 1:1, přidělte v cílovém prostředí trochu více úložiště. Důvodem je způsob, jakým probíhá historie záložek disku. Toto přidělení nepředstavuje dvojnásobné zvýšení, protože zahrnuje pouze změny dat. V závislosti na typu dat a očekávaných změnách a zásadách replikace, které mají v cíli 1,5x až 2x více úložiště, zajistí, aby procesy převzetí služeb při selhání nepředstavily žádné obavy.
- Můžete zvážit, že cílové prostředí Azure Stack Hub může být cílem pro více zdrojů Azure Stack Hub. V tomto případě snižujete celkové náklady, ale musíte naplánovat, co se stane, když se některé úlohy sníží. Například zdroj musí mít prioritu.
- Pokud se vaše cílové prostředí používá ke spouštění jiných úloh, musí plán BCDR zahrnovat chování těchto úloh. Můžete například spouštět virtuální počítače pro vývoj/testování v cílovém prostředí a pokud dojde k problému se zdrojovým prostředím, můžete vypnout všechny virtuální počítače v cíli, abyste zajistili, že jsou k dispozici dostatek prostředků pro spuštění chráněných virtuálních počítačů.
BCDR byste měli otestovat a pravidelně ověřovat. Můžete to provést pomocí procesů testovacího převzetí služeb při selhání nebo přesunutím celých pracovních zátěží pro důkladné ověření průchodů od začátku do konce.