Azure Site Recovery – VMWARE (1)


Připravil jsem pro vás sérii článků, zabývající se technologií Azure Site Recovery. Konkrétně v šesti na sebe navazujících článcích se dozvíte, jak správně nasadit Azure Site Recovery. Postupně vás tyto články od začátku provedou celým procesem a to od samotné instalace a nastavení potřebných komponent, po obnovení virtuálních strojů po výpadku produkčního prostředí. Všechny na sebe navazující články pak budou popisovat spolupráci Azure Site Recovery v kombinaci s VMWARE virtualizační platfomou.

V této části článku se budeme zabývat vysvětlením základních pojmů, popisem komponent a vytvořením nezbytných komponent v samotném Microsoft Azure.

Vysvětlení pojmů:

Site recovery – dalo by se říci, že tento pojem by lépe vysvětloval popis „Other Site for Recovery“, neboli jiná vzdálená lokalita pro obnovu. V podstatě se jedná o myšlenku mít v jiné samostatné lokalitě k dispozici „zálohu“ našich stávajících systému, resp. primárně „zálohu“ produkčních virtualizovaných, nebo fyzických serverů. Tedy v podstatě dochází k replikaci našich stávajících serverů a to i serverů s různými operačními systémy do vzdálené lokality. Nyní si asi říkáte, ale jaký je rozdíl mezi např. Hyper-V replika, nebo VMWARE vSphere replika a Site recovery? Odpověď je poměrně jednoduchá. Zásadní.

Replika - Hyper-V, nebo VMWARE replika v případě výpadku původních produkčních serverů vyžaduje kompletní ruční zásah/řízení celé operace obnovy. Je v podstatě nutné mít sepsaný tzv. Recovery plán, tedy plán obnovy a dle něj postupovat tak, že na jiné lokalitě v určitém pořadí bude obsluha, nebo odpovědný technik postupně spouštět jednotlivé replikované servery. K tomu je třeba mít tento sepsaný a odzkoušený plán obnovy a mít k dispozici vyškolený personál, který tyto procedury zná a může dle nich postupovat. Navíc tyto postupy musí řešit i vícero úskalí, například jak řešit změny v DNS, případně změny v IP adresách apod. Navíc obvykle jediná možnost jak toto běžně realizovat je v tomto případě mít k dispozici jiné separátní nezávislé On-premise datové centrum s dostatečným výkonem a kapacitami, kde bude možné opětovně spustit replikované produkční servery. Což sebou nese každopádně nemalé náklady, spojené s vybudováním a údržbou takového separátního datového centra. Navíc v případě fyzických serverů není replika obvykle možná vůbec.

Tedy shrnuto, Site Recovery obvykle nabízí automatizaci celého procesu obnovy funkčnosti produkčních serverů v jiné lokalitě/datovém centru a tím se snaží vyloučit např. riziko lidského faktoru.

Azure Site Recovery – umožnuje replikovat vaše produkční servery a to jak virtuální, tak fyzické na mnoho způsobů. Azure Site Recovery podporuje řadu scénářů. Například mezi SCVMM a Azure. Nebo mezi dvěma SCVMM Sites. Nebo také mezi dvěma VMWARE Sites. My se zaměříme na scénář, kdy jsou virtuální stroje běžící na VMWARE replikovány přímo do Microsoft Azure, resp. na Storage Account, který je vytvořen v Microsoft Azure v konkrétní subskripci zákazníka. Tento scénář pak umožnuje využít výpočetní výkon a diskové kapacity v samotném Microsoft Azure, aniž by muselo dojít k nákladným investicím do vlastní infrastruktury, např. v rámci vybudování dalšího On-premise datového centra.

Zde lze pak najít aktuální ceny spojené s provozováním Azure Site Recovery:

https://azure.microsoft.com/en-us/pricing/details/site-recovery/

a1

Jednoduché schéma komunikace management serveru s Microsoft Azure a On-Premise virtuálními stroji

Předpoklady a omezení:

Nejzásadnější předpoklady:

· V případě Faillback (bude vysvětleno později) je nutné mít k dispozici funkční síťový propoj do Azure vNet sítě, tedy například ExpressRoute, nebo Site-to-Site VPN

· Otevřený port TCP 443 z Process Serveru (bude vysvětleno později) do “Internetu”

· Otevřený port TCP 9443 z replikovaných virtuálních, nebo fyzických serverů na samotný Process Server (interní komunikace)

· Existující Azure Storage Account typu Geo-Redundant

· Existující Azure vNet. Ale to jen v případě, pokud mají být servery (v případě samotného Failoveru) dostupné i jinak, než protřednictvím VIP IP Adres a Endpointů.

· vNet a Storage account musí být vytvořeny ve stejném regionu, jako Azure Site Recovery. Tedy například v lokalitě WEST EUROPE.

Nejzásadnější omezení:

· Jsou podporovány pouze 64-bitové operační systémy Windows Server 2012 R2, Windows Server 2012, nebo Windows Server 2008 R2 alespoň s SP1. Dále pouze 64-bitové operační systémy Red Hat Enterprise Linux 6.7, Centos 6.5,6.6,6.7, Oracle Enterprise Linux 6.4, 6.5 běžícím na Red Hat compatible kernel, nebo Unbreakable Enterprise Kernel Release 3 (UEK3), SUSE Linux Enterprise Server 11 SP3

· Aktuálně jsou podporovány jen virtuální stroje první generace. Pokud je replikován například z Hyper-V serveru virtuální stroj druhé generace, je automaticky převeden na stroj první generace.

· Je podporován hypervizor VMWARE ESXi 5.1, 5.5 a 6.0. A dále je podporován VMWARE vCenter 5.5 a 6.0

· OS disk do velikosti 1023 GB a datový disk do velikosti 1023 GB. Pozn. Tento problém lze obejít tak, že interně v rámci OS bude více datových disků do velikosti 1023 GB spojeno dohromady pomocí RAID 0

Bližší informace o všech dalších omezeních lze získat zde:

https://azure.microsoft.com/en-us/documentation/articles/site-recovery-best-practices/#azure-virtual-machine-requirements

https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmware-to-azure-classic/#before-you-start-deployment

Komponenty v On-Premise prostředí:

Configuration server – Koordinuje komunikaci a spravuje replikaci dat a samotný proces obnovy

Process Server – funguje jako brána pro replikace. Přijímá data ze serverů, kde je instalován Agent, resp. Mobility service (na portu 9443 - lze změnit). Tyto data pak “kešuje” na lokální disk (proto doporučovaný požadavek na 600 GB připojené kapacity v rychlých discích pro rychlé a úspěšné zpracování dat), komprimuje, šifruje a tyto replikovaná data následně posílá do Azure Storage. Navíc řídí instalaci Mobility service na servery, které mají být replikovány. Na obrázcích níže pak vidíte seznam služeb, které vzniknou po instalaci všech hlavních komponent.

a2a3

a4a5

a6a7

a8a9

Zde pak konfigurační soubor Process serveru (cxps.exe)

a10

Master target server – zpracovává replikovaná data v případě failback z Microsoft Azure.

a11a12

Pokud neběží služba Microsoft Azure Site Recovery Service, lze najít v podrobnostech o stavu management serveru tuto chybu:

a13

Mobility service – jedná se o „agenta“, který je instalován na každý fyzický, nebo virtuální stroj, který má být replikován do Azure. Agent pak komunikuje přímo s Process serverem.

a14

a15a16

Poznámka: První tři komponenty (Configuration Server, Process Server a Master Target Server) jsou automaticky instalovány společně. A to na konkrétní fyzický, nebo virtuální management server. V případě instalace komponent na fyzický stroj jsou zde pak jistá omezení. Konkrétně by bylo nutné nainstalovat do virtuálního stroje separátní master target server a to pro řešení/příjem failback komunikace.

1. Fáze vytvoření Site Recovery Vault a storage account

Bohužel Azure Site Recovery je aktuálně dostupný pouze skrze původní portál na adrese: https://manage.windowsazure.com

Po přihlášení do vaší subskripce Následně v levém menu klikněte na položku „Recovery Services“.

a17

Následně v dolní části okno klikněte na tlačítko „+ NEW

a18

Dále v menu vyberte „DATA SERVICES“, „RECOVERY SERVICES“ a „SITE RECOVERY VAULT

a19

Vyberte „QUICK CREATE“ a do pole „NAME“ zadejte název nového Site Recovery Vault (dále jen jako SRV) a vyberte správný region. Nezapomeňte, že pro úspěšné nastavení replikace virtuálních strojů, musí být ještě předtím vytvořen storage account, ale ten musí být vytvořen navíc ve stejném regionu jako SRV! To stejné pak platí o vytvoření vNET, tedy virtuální sítě.

Poznámka: Ovšem vytvoření virtuální sítě není bezpodmínečně nutné. Je nutné mít vytvořenu vNet, jen v případě, pokud mají být např. skrze Site-to-Site VPN tyto replikované servery dostupné z vaší lokální sítě (a to tedy v případě Test Failover, nebo Failover scénáře).

a20

Po úspěšném vytvoření SRV je nutné ještě vytvořit Storage Account. Tedy kam budou uloženy data replikovaných virtuálních strojů.

a21

Následně v dolní části okno klikněte na tlačítko „+ NEW

a22

Dále v menu vyberte „DATA SERVICES“, „STORAGE“, „QUICK CREATE“. Do pole „URL“ zadejte název budoucího Azure Storage Account. Tento název musí být jedinečný skrze celý Azure! Poté vyberte stejný region, v jakém byl vytvořen SRV a co je nejpodstatnější, jako typ replikace musíte vybrat „Geo-Redundant“. Poznámka: Premium storage není aktuálně podporován.

a23

Příklad vytvoření Storage Account pomocí PowerShellu

New-AzureStorageAccount -StorageAccountName mynewstorageaccount0002 -Label "mynewstorageaccount" -Location "West Europe" -Type Standard_GRS

Příklad založení SRV pomocí PowerShellu a to prostřednictvím Azure Resource Managera.

New-AzureRmSiteRecoveryVault -Name mynewsrv00001 -ResourceGroupName Group-1 -Location "West Europe"

Managera

- Jakub Heinz, KPCS CZ

Mohlo by vás také zajímat:

ITCamp2016 (Azure) - Module 4 Azure Site Recovery

Comments (0)

Skip to main content