Azure Stack: disaster recovery do Azure s Azure Site Recovery

Přemýšlíte o využití Azure Stack pro aplikace, které z důvodů latence chcete provozovat lokálně nebo pro které chcete využít CAPEX modelu a přitom si zachovat vlastnosti cloudu? Možná ale budete potřebovat některé stroje z Azure Stack zrcadlit do Azure. Důvodem může být třeba DR strategie, kdy chcete mít zdroje v Azure Stack, ale než platit drahé záložní centrum, použijete pro DR Azure. Platíte jen za nějaký replikační software a storage, ale VMka vytočíte (a zaplatíte) jen když to bude potřeba. Další scénář může být, že na infrastruktuře pro aplikaci pracujete lokálně v Azure Stack, ale pak ji budete potřebovat přesunout do Azure. Možná z důvodu navýšení celkové kapacity před Vánoční špičkou nebo přesun aplikace, která se stala tak úspěšnou u zákazníků, že dává větší smysl provozovat ji v public cloudu. Samozřejmě takový scénář je ideální řešit moderními prostředky typu mikroslužby a kontejnery a aplikaci v Azure přenasadit, ale mohou být situace, kdy chcete sáhnout po infrastrukturním řešení a nareplikovat VMka do Azure tak jak jsou v Azure Stack.

Na tyto scénáře můžete použít službu Azure Site Recovery. Podívejme se jak s Azure Stack funguje.

Rozchození replikace

Nebudu detailně popisovat postup, protože jsem šel krok za krokem přesně podle dokumentace zde: https://docs.microsoft.com/en-us/azure/site-recovery/azure-stack-site-recovery

V zásadě jsem v azure vytvořil Recovery Services Vault a stáhnul si soubor s přihlašovacími údaji. V Azure Stack jsem rozjel VM s Windows a nainstaloval do něj ASR komponentu Configuration Server, která slouží jako lokální překladiště a zajišťuje komunikaci a koordinaci s ASR v cloudu. Pro Azure Stack se aktuálně využívá model ASR podobný replikaci VMware farmy nebo fyzických serverů. Na chráněná VM se doinstaluje komponenta Mobility Service, která monitoruje zapisovací operace a zrcadlí je do Configuration Server. Ten je bere a posílá do cloudu. Díky tomuto řešení je možné se dostat na velmi nízké RPO - podle přírustků dat a kapacity linky to klidně může být v jednotkách minut.

Replikace tedy funguje tak, že ASR jednou za čas udělá aplikačně konzistentní snapshot s využitím VSC technologie. To je vhodné zejména pro aplikace, kde je aplikační konzistence zásadní, jako jsou databáze. Kromě toho následně posílá přírůstkové informace z jednotlivých write operací. ASR v cloudu tyto přijímá, dává si je do překladiště ve formě blob storage a nasazuje optimalizační technologie jako je caching, komprese a zajišťuje silné šifrování při přenosu. ASR na základě toho průběžně montuje Azure Disk, který je připravený pro nastartování VM v případě potřeby.

Při havárii tedy máte na výběr ze tří možností:

  • Maximální konzistence - použijte App consistent snapshot. Ten může být nějakou dobu pozadu (třeba 30 minut, tedy RPO) a jeho nasazení nějakou dobu potrvá (RTO bude vyšší), protože ASR z tohoto snapshotu bude muset teprve vytvořit disk.
  • Co nejnižší RTO - v takovém případě použijete poslední zpracovaný write. Tak jak přichází jednotlivé zápisy, ASR je zpracovává tak, že z nich montuje výsledný disk. RPO bude pravděpodobně velmi nízké (třeba 5 minut) a RTO bude také nízké, protože disk už je vytvořen, takže jde o nahození VM.
  • Co nejnižší RPO - použijte nejčerstvější data, která má ASR už v cloudu k dispozici. RPO tedy může být velmi malé, klidně i jen několik vteřin, ale ASR musí nejprve data zpracovat a vyrobit disk, tedy RTO bude o něco vyšší.

Problematika DR je podstatně složitější a v tomto článku nemám ambici ji celou rozebrat. Jsou tu otázky jak se sítí (možnost pustit na stejných IP a předělat routing nebou pouštět na jiných a předělat DNS), můžete naskriptovat pořadí spouštění různých strojů a tak podobně.

Ještě musím zmínit jedno aktuální omezení ASR z pohledu Azure Stack. Ten totiž v tuto chvíli může být pouze zdroj, nikoli cíl. ASR tedy nelze použít pro replikaci mezi dvěma Azure Stacky ani z Azure do Azure Stack. Počítejte tedy s tím, že pokud technologii využíváte ne pro migraci, ale pro DR, tak zpětné překlopení z Azure do Azure Stack už nebude automatizované tímto produktem a musí se udělat ručně (například nakopírováním VHD disků nebo synchronizací dat apod.). Pokud hledáte řešení i na tyto situace, Azure i Azure Stack podporuje například Commvault nebo ZeroDown.

Vyzkoušíme výsledek

V Azure Recovery Vault mám v tuto chvíli dvě VM, které jsou replikované.

Aktuálně se mi daří RPO na úrovni 3 minuty. To samozřejmě záleží na přírůstku nových dat ve VM vs. kompresní poměr vs. kapacita linky.

Grafika hezky ukazuje jak technologie ASR funguje. Co je tam nepřesně je vCenter - ASR pro Azure Stack totiž používá stejný mechanismus, jako pro VMware nebo bare metal (jde o to, že z bezpečnostních důvodu v Azure Stack nemá nikdo, tedy ani ASR, přístup k Hyper-V, aby orchestrovalo přímo jeho vlastnosti).

Všimněte si v obrázku, že ASR průběžně montuje Azure Disk tak, aby byl připraven pro rychlé naběhnutí VM v případě potřeby. Ty ostatně najdeme v příslušné resource group.

V rámci nastavení si můžeme pohrát s velikostí VM a dalšími parametry, které chceme v procesu DR použít. V mém případě jsou tam stejná nastavení sizingu jako v mém Azure Stack, což odpovídá mým požadavkům. Napojeno to mám do VNETu dr-net. Ten je udělaný tak, že má separátní rozsah IP a je VPNkou napojený a routovaný v rámci firmy (používám tedy variantu jiných IP po fail over a nastavení přes DNS pro interní nebo Azure Traffic Manager z pohledu externích přístupů).

V Azure Stack mám nasazen Process Server, který zpracovává data z chráněných VM, provádí kompresi, šifrování, vyrovnávací paměť a upload do Azure Blob Storage. Jak se mu daří? V mém případě v pohodě, ale může se hodit možnost přidat další a balancovat na ně, pokud by nestíhaly.

Proveďme testovací fail over, zda se nám VM rozeběhne v Azure.

Vyberu si nejrychlejší recovery, tedy nízké RTO - crash konzistentní snapshot, který už je zpracovaný a připravený v Azure Disk.

Můžeme sledovat průběh testování.

Po chvilce vidím Azure zdroje, jak startují.

Připojím se, otestuji a pak mohu stroje zase nechat odmazat.

Při přípravě DR můžeme vytvořit plány.

Můžeme například poštelovat pořadí, v jakém chceme stroje nahazovat (třeba po nějakých skupinkách - infra, pak DB, pak app, pak web).

Azure Site Recovery můžete použít v těchto scénářích:

  • Azure Stack -> Azure
  • Azure -> Azure
  • Hyper-V -> Hyper-V
  • VMWare -> VMware
  • Hyper-V -> Azure
  • Azure -> Hyper-V
  • VMware -> Azure
  • Azure -> VMware
  • Bare metal -> Azure

Pokud sedne do vaší DR strategie, použijte. Je to cenově velmi atraktivní v porovnání s nutností budovat DR lokalitu. Platíte totiž za ASR službu a storage, ale VM budíky se vám začnou točit teprve, až když je skutečně budete potřebovat.



Azure SQL pro kritické aplikace BackupDR
Azure Stack: serverless s Azure Functions AzureStack
Azure Stack: napojení na Azure Monitor pro hybridní správu AzureStack
Azure Stack: databázové služby AzureStack
Azure Stack: platformní služby pro webové aplikace s Application Services z pohledu uživatele AzureStack