Upravit

Scénáře vysoké dostupnosti a zotavení po havárii pro aplikace IaaS

Azure Site Recovery
Azure Virtual Machines
Azure Disk Storage

Tento článek představuje rozhodovací strom a příklady možností vysoké dostupnosti (HA) a zotavení po havárii (DR) při nasazování vícevrstvých aplikací infrastruktury jako služby (IaaS) do Azure.

Architektura

Tento diagram znázorňuje rozhodovací strom s vysokou dostupností.

Workflow

Skupiny dostupnosti (AS) poskytují redundanci a dostupnost virtuálních počítačů v rámci datacentra tím, že distribuují virtuální počítače napříč několika izolovanými hardwarovými uzly. Podmnožina virtuálních počítačů běží během plánovaných nebo neplánovaných výpadků, takže celá aplikace zůstane dostupná a funkční.

Zóny dostupnosti (AZ) jsou jedinečná fyzická umístění, která zahrnují datacentra v rámci oblasti Azure. Každý az přistupuje k jednomu nebo více datacentrům, které mají nezávislé napájení, chlazení a sítě, a každá oblast Azure s podporou AZ má minimálně tři samostatné AZ. Fyzické oddělení zón AZ v rámci oblasti chrání nasazené virtuální počítače před selháním datacentra.

Vývojový diagram rozhodnutí odráží princip, že pokud je to možné, aplikace vysoké dostupnosti by měly používat AZ. Mezi zónami, a proto mezi datovými centry poskytuje > vysoká dostupnost 99,99% smlouvu SLA z důvodu odolnosti proti selhání datacentra.

ASs a AZ pro různé úrovně aplikací není zaručeno, že budou v rámci stejných datacenter. Pokud je latence aplikace primárním problémem, měli byste služby v jednom datacentru společně přidělit pomocí skupin umístění bezkontaktní komunikace (PPG) se službami AZ a AS.

Komponenty

Alternativy

  • Jako alternativu k regionálnímu zotavení po havárii pomocí Azure Site Recovery můžete v případě, že aplikace nativně replikuje data, implementovat zotavení po havárii ve více oblastech pomocí aktivních nebo studených pohotovostních serverů, jako je roztažený cluster pouze pro zotavení po havárii. Tato alternativa není podrobně popsána v příkladech, ale je možné ji přidat do některého z řešení. Všimněte si, že replikace mezi oblastmi je asynchronní a očekává se určitá ztráta dat.

    Pokud máte také vlastní technologii replikace dat, můžete ji použít k vytvoření sekundární zóny v oblasti pro zotavení po havárii. V závislosti na oblasti vašich úloh může být také možné použít Azure Site Recovery k replikaci položek do alternativní zóny, můžete zkontrolovat regionální dostupnost a přečíst si další informace o této funkci v části Povolit zotavení po havárii zóny pro virtuální počítače Azure.

  • Vysoká dostupnost ve více oblastech je možná, ale vyžaduje globální nástroj pro vyrovnávání zatížení, jako je Front Door nebo Traffic Manager. Další informace najdete v tématu Spuštění N-vrstvé aplikace ve více oblastech Azure pro zajištění vysoké dostupnosti.

Podrobnosti scénáře

Vícevrstvé nebo n-vrstvé architektury jsou běžné v tradičních místních aplikacích, takže jsou přirozenou volbou pro migraci místních aplikací do cloudu nebo při vývoji aplikací pro místní i cloud. N-úrovňové architektury se obvykle implementují jako aplikace IaaS rozdělené do logických vrstev a fyzických vrstev s nejvyšší webovou nebo prezentační vrstvou, střední obchodní vrstvou a datovou vrstvou.

V n-vrstvé aplikaci IaaS se každá vrstva spouští na samostatné sadě virtuálních počítačů. Webové a obchodní vrstvy jsou bezstavové, což znamená, že jakýkoli virtuální počítač v této vrstvě dokáže zpracovat jakýkoli požadavek na danou úroveň. Datová vrstva je replikovaná databáze, úložiště objektů nebo úložiště souborů. Více virtuálních počítačů v každé vrstvě zajišťuje odolnost, pokud jeden virtuální počítač selže, a nástroje pro vyrovnávání zatížení distribuují požadavky napříč virtuálními počítači.

Vrstvy můžete škálovat na více instancí přidáním dalších virtuálních počítačů do fondů a pomocí škálovacích sad virtuálních počítačů automaticky škálovat stejné virtuální počítače. Vzhledem k tomu, že používáte nástroje pro vyrovnávání zatížení, můžete škálovat vrstvy na více instancí, aniž by to mělo vliv na dobu provozu aplikace.

Pokud smlouva o úrovni služeb (SLA) pro aplikaci IaaS vyžaduje > 99% dostupnost, můžete virtuální počítače umístit do skupin dostupnosti, zón dostupnosti a skupin umístění bezkontaktní komunikace a nakonfigurovat tak vysokou dostupnost aplikace. Řešení vysoké dostupnosti a zotavení po havárii, která zvolíte, závisí na požadované úrovni smlouvy SLA, požadavcích na latenci a požadavcích na regionální zotavení po havárii.

Potenciální případy použití

  • Migrujte n-vrstvou aplikaci z místního prostředí do cloudu.
  • Nasaďte n-vrstvou aplikaci v místním prostředí i do cloudu.
  • Nakonfigurujte vysokou dostupnost a zotavení po havárii pro aplikaci IaaS.

Toto řešení lze použít pro libovolné odvětví, včetně následujících scénářů:

  • Aplikace veřejného sektoru
  • Bankovnictví (finanční odvětví)
  • Zdravotnictví

Důležité informace

  • AZ nejsou dostupné ve všech oblastech Azure.

  • Před sestavením řešení rozhodněte, kterou možnost nasazení chcete použít. I když je to možné, není snadné přejít z jedné možnosti na jinou po nasazení. Virtuální počítače byste museli odstranit a znovu je vytvořit ze základních spravovaných disků, což je zahrnutý proces.

  • Ujistěte se, že aplikaci můžete namapovat na vybrané řešení. Mnoho vzorů odolnosti vrstev aplikací a návrhů je mimo rozsah tohoto rozhodovacího stromu.

  • Tři scénáře můžou vést k restartování virtuálních počítačů Azure: neplánovaná údržba hardwaru, neočekávané výpadky a plánovaná údržba. Další informace o těchto událostech a osvědčených postupech pro zajištění vysoké dostupnosti pro snížení jejich dopadu najdete v tématu Vysvětlení restartování virtuálních počítačů, údržby a výpadků.

Jeden virtuální počítač

Pokud aplikace nevyžaduje > 99,9% dostupnost, nemusíte ji konfigurovat pro vysokou dostupnost a můžete nasadit jednotlivé virtuální počítače. Škálovací sady virtuálních počítačů můžete použít k automatickému horizontálnímu navýšení kapacity identických virtuálních počítačů. Nasaďte jednotlivé virtuální počítače bez určení zóny, takže se distribuují v celé oblasti. Tyto aplikace mají smlouvu SLA 99,9 %, pokud používáte disky SSD úrovně Azure Premium.

Jednotlivé virtuální počítače používají výchozí funkce opravy služeb integrované do všech datacenter Azure. V případě předvídatelných selhání tato funkce obvykle používá migraci za provozu, ale během nepředvídatelných událostí můžou být virtuální počítače restartovány nebo nedostupné.

Vysoká dostupnost

Pokud aplikace vyžaduje smlouvu SLA > 99,9 %, navrhňte aplikaci pro vysokou dostupnost. Pokud je to možné, používejte AZ, protože poskytují odolnost proti chybám datacentra. Místo ASs můžete použít ASs, ale použití ASs snižuje dostupnost z 99,99 % na 99,95 %, protože AS nemůže tolerovat selhání datacentra.

AZ jsou vhodné pro mnoho scénářů clusterovaných aplikací, včetně clusterů AlwaysOn SQL, použití aktivní-aktivní, aktivní-pasivní nebo kombinace obou úrovní vysoké dostupnosti na každé úrovni s rychlým převzetím služeb při selhání. Synchronní replikace je možná mezi všemi uzly dbMS (Database Management System), protože je nízká latence mezi zónovou sítí. Můžete také spustit konfiguraci roztaženého clusteru napříč zónami, která má vyšší latenci a podporuje asynchronní replikaci.

Pokud chcete použít clusterový arbiter založený na virtuálních počítačích, například určující sdílenou složku, umístěte ho do třetího az, abyste zajistili, že se kvorum neztratí, pokud selže nějaká jedna zóna. Alternativně můžete použít cloudovou kopii clusteru v jiné oblasti.

Všechny virtuální počítače v az jsou v jedné doméně selhání (FD) a aktualizují doménu (UD), což znamená, že sdílejí společný zdroj napájení a síťový přepínač a všechny se můžou restartovat současně. Pokud vytváříte virtuální počítače v různých zónách AZ, vaše virtuální počítače se efektivně distribuují mezi různé FD a UD, takže se všechny nezdaří nebo se restartují současně. Pokud chcete mít redundantní virtuální počítače v zóně i virtuální počítače mezi zónami, měli byste umístit virtuální počítače v zóně do ASs v PPG, aby se zajistilo, že se všechny nerestartují najednou. I u úloh virtuálních počítačů s jednou instancí, které nejsou dnes redundantní, můžete i nadále volitelně používat AS v PPG, abyste umožnili budoucí růst a flexibilitu.

Pokud chcete nasadit škálovací sady virtuálních počítačů napříč AZ, zvažte použití režimu Orchestraation, který je aktuálně ve verzi Public Preview, což umožňuje kombinování disků FD a AZ.

AZs with in-zone PPG allow for one of the lowest network latencies in Azure, and an SLA of a least 99,99% because of multi-datacenter resiliency. Pokud je to možné, používejte akcelerované síťové služby na virtuálních počítačích.

Toto řešení může představovat scénář, kdy služba spuštěná na virtuálním počítači v jedné zóně musí komunikovat se službou v jiné zóně. Může se například jednat o webovou vrstvu aktivní-aktivní a aktivní-pasivní databázovou vrstvu napříč zónami. Některé požadavky budou napříč zónami, což představuje latenci. I když latence napříč zónami je stále velmi nízká, pokud potřebujete zajistit nejnižší možnou latenci, zachovejte veškerou síťovou komunikaci mezi vrstvami aplikací v rámci zóny.

Důležité informace o latenci

Latence sítě závisí mimo jiné na fyzické vzdálenosti mezi nasazenými virtuálními počítači. Pokud aplikace vyžaduje velmi nízkou latenci mezi úrovněmi, můžete ji nasadit v jednom datacentru pomocí PPG s ASs pro každou vrstvu. Pokud je to možné, použijte na virtuálních počítačích akcelerované síťové služby. Tento scénář umožňuje jednu z nejnižších latencí sítě v Azure a smlouvu SLA o 99,95 %.

Pomocí následujících nástrojů můžete získat lepší přehled o podmínkách latence pro různé scénáře:

  • Pokud chcete otestovat latenci mezi virtuálními počítači, přečtěte si téma Otestování latence sítě virtuálních počítačů.
  • K otestování latence mezi zónami použijte AvZone-Latency-Test. Tento test vám může pomoct určit, které logické zóny mají nejnižší latenci pro vaše předplatné.
  • K otestování latence mezi oblastmi Azure použijte http://www.azurespeed.com/. Tento pravidelně aktualizovaný nástroj může být užitečný při zvažování asynchronní replikace mezi oblastmi.

Zotavení po havárii

Mezi důležité informace o zotavení po havárii patří dostupnost, schopnost aplikace dál běžet v dobrém stavu a stálost dat, zachování dat, pokud dojde k havárii.

Převzetí služeb při selhání vysoké dostupnosti by mělo být rychlé, bez ztráty dat a má velmi omezený vliv na službu. Naproti tomu tradiční převzetí služeb při selhání zotavení po havárii může mít delší přidruženou plánovanou dobu obnovení (RTO) a cíl bodu obnovení (RPO) a je asynchronní s potenciální ztrátou dat.

Zóny dostupnosti můžete využít pro vysokou dostupnost i zotavení po havárii pomocí jiné zóny dostupnosti pro vaše řešení zotavení po havárii. Zóny dostupnosti jsou dostatečně blízko, aby měly připojení s nízkou latencí k jiným zónám dostupnosti (latence odezvy kratší než 2 min.). Jsou ale dostatečně vzdálené, aby snížily pravděpodobnost, že místní výpadky nebo počasí můžou ovlivnit více než jednu zónu dostupnosti. U důležitých úloh byste měli zvážit řešení, které kromě několika zón dostupnosti používá více oblastí.

Azure Site Recovery umožňuje replikovat virtuální počítače do jiné oblasti Azure pro regionální zotavení po havárii a provozní kontinuitu. Azure Site Recovery můžete použít k obnovení aplikací v případě výpadků zdrojové oblasti nebo k provádění pravidelných postupů zotavení po havárii, abyste zajistili splnění požadavků na dodržování předpisů.

Pokud vaše aplikace podporuje Azure Site Recovery, můžete poskytnout regionální řešení zotavení po havárii pro zvýšenou ochranu, pokud to vyžaduje důležitost aplikace. Vysoká dostupnost mezi zónami, mezi centry ale může být dostatečná ochrana, protože pokud je aplikace plně odolná vůči selhání datacentra, nemělo by dojít k výpadkům ani ztrátě dat.

Optimalizace nákladů

Za virtuální počítače nasazené v AZ nejsou žádné další náklady. Můžou se účtovat další poplatky za přenos dat mezi virtuálními počítači mezi az. Další informace najdete na stránce s cenami šířky pásma.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Další kroky