Optimalizované IT - portál pro IT pro komunitu

Veeam Direct Restore to Microsoft Azure

Vytisknout E-mail

Josef Vágner Datum zveřejnění: 5. 5. 2016 20:05 Zobrazeno: 666
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

Nedávno se na webu společnosti Veeam objevil nový produkt, který umožňuje obnovu VM ze záloh Veeamu v prostředí Azure a který je zdarma a je dostupný v rámci Marketplace Azure. Zálohu virtuálního stroje je možné získat pomocí standardního produktu Veeam Backup and Restore verze 9 (placené či free verze) nebo fyzického stroje pomocí Veeam Endpoint Backup (verze 1.1). Takto získaný soubor se zálohou překopírujte do prostředí Microsoft Azure. Na adrese https://helpcenter.veeam.com/backup/restore_to_azure/deliver.html lze nalézt několik postupů, jak soubor se zálohou lze dostat do prostředí Azure (pomocí nástroje FastSCP, nakopírování do Azure File Storage, pomocí RDP, připojením VM disku či pomocí FTP přenosu). Video s postupem kopírování pomocí FastSCP je na https://fast.wistia.net/embed/iframe/8m1y31pzxm?popover=true&ad=in-text-link.

clip_image001

Na straně Azure je zapotřebí nasadit v rámci vašeho předplatného applianci Veeam Direct Restore (postup je přehledně uveden na https://helpcenter.veeam.com/backup/restore_to_azure/deploy_var.html případně na videu na https://fast.wistia.net/embed/iframe/hbnvnlq4ut?popover=true&ad=in-text-link).

Postupné kroky:

· Vyberte si zkopírovaný soubor(y) záloh

· Vyberte bod obnovy (restore point)

· Zadejte identifikaci vašeho předplatného a lokalitu Azure, do které budete obnovovat

· Specifikujte velikost VM (minimálně A2) a případně i storage

· Zadejte jméno VM a adresu cloudové služby pod kterou bude obnovený VM dostupný

· Zadejte síť

· Zadejte popis důvodu obnovy

· Zkontrolujte zadaná nastavení

· Spusťte proces

Na adrese https://fast.wistia.net/embed/iframe/pvy9yt1c17?popover=true&ad=in-text-link si lze spustit video, které vás provede těmito kroky.

Po ukončení průvodce se spustí proces konverze. Jakmile konverze doběhne, nastartuje se obnovený VM. Pokud využijete volbu Advanced

Toto bezplatné řešení umožňuje správcům IT využívat Microsoft Azure s možností obnovovat (nebo migrovat) virtuální počítače, fyzické servery a koncová zařízení se systémem Windows ze svého pracoviště do cloudu Azure pomocí automatizovaného konverzního procesu P2V nebo V2V. Veeam Direct Restore to Azure lze využít pro různé scénáře – rychlou obnovu prostředí do Azure, naplánování migrací do Azure nebo pro vytváření testovacího prostředí v Azure.

Azure Site Recovery – VMWARE(6)

Vytisknout E-mail

Jakub Heinz Datum zveřejnění: 2. 5. 2016 8:29 Zobrazeno: 782
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

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 procedurou FAILOVER, FAILBACK a přidáním dalšího PROCESS SERVERu do Azure.

1. Failover

V případě, že dojde k problémům v On-Premise prostředí, je možné inicializovat Failover proceduru. Resp. prostřednictvím RECOVERY PLAN spustit proceduru nastartování virtuálních strojů v Microsoft Azure. A tím zpřístupnit produkční servery a na nich běžící služby a aplikace interním klientům. A to buď prostřednictvím VIP IP adres a vytvořených Endpointů, nebo pak prostřednictvím Site-to-Site VPN. Samozřejmě s touto procedurou se váže spousta i jiných úskalí. Například změny DNS záznamů, přesměrování komunikace apod. Je třeba si uvědomit, že dojde k obnovení produkčních virtuálních strojů do virtuální sítě v Microsoft Azure. A tudíž je třeba pro On-Premise klienty zajistit za těchto nových podmínek kontinuitu ve využívání aplikací a služeb.

Nejprve je ale třeba nastavit replikované virtuální stroje. V sekci „PROTECTED ITEMS“ – „PROTECTED GROUPS“ vyberte konkrétní skupinu a vstupte do ní.

clip_image002

Pak v rámci skupiny vyberte jednotlivé virtuální stroje replikované do Azure. Vstupte do konkrétního virtuálního stroje.

clip_image004

Zde pak přejděte do sekce „CONFIGURE

clip_image006

Zde je pak nutné nastavit parametry virtuálního stoje. Jednak zde v první části, změnou parametru „Size“ můžete ovlivnit velikost budoucího virtuálního stroje, který bude nastartován v Azure v rámci procedur „TEST FAILOVER“ a „FAILOVER“. Rovněž zde můžete v části „Name“ změnit jméno budoucího virtuálního stroje. V další části je pak třeba specifikovat v jaké virtuální síti a jakém subnetu bude při proceduře „FAILOVER“ automaticky virtuální stroj umístěn. A případně jakou bude mít v daném subnetu IP adresu. Pokud IP adresu (TARGET IP ADDRESS) nevyplníte, dostane nastartovaný virtuální stroj IP adresu z Azure DHCP serveru. Změny uložte pomocí tlačítka „SAVE“.

Poznámka: Tlačítko „SAVE“ a následná úloha, která se spustí v sekci „JOBS“ skončí s chybou v případě, že virtuální stroj byl již spuštěn v rámci procedur „TEST FAILOVER“ a „FAILOVER“. Pokud mají být nastartované virtuální stroje dostupné v On-Premise prostředí, je zde třeba nastavit virtuální síť, která je propojená s On-Premise prostředím prostřednictvím Site-to-Site VPN, nebo ExpressRoute.

clip_image008

Nyní přejdeme k samotné proceduře „FAILOVER“. V sekci „RECOVERY PLANS“ vyberte váš RECOVERY PLAN a v dolní části okna klikněte na tlačítko „FAILOVER“.

clip_image010

clip_image011

Otevře se okno pro spuštění „FAILOVER“ procedury. Zde je nutné si vybrat především bod obnovení. Máme na výběr poslední bod obnovení, který byl replikován do Azure (Latest recovery point in time), nebo pak poslední aplikačně-konzistentní bod obnovení (Latest application consistent recovery point), nebo případně poslední „nekonzistentní“ bod obnovení (Latest crash consistent recovery point). Pokud v rámci virtuálních strojů běží aplikace, nebo služby využívající různé interní databáze apod., pak vždy doporučuji obnovit aplikačně konzistentní bod obnovení. Samozřejmě je třeba myslet v tomto případě na to, že aplikačně konzistentní body obnovený se vytvářejí v intervalech nastavených v rámci “PROTECTION GROUP”. A pokud tedy máte například nastaveno, že aplikačně konzistentní bod obnovení se provádí jednou za 4 hodiny, bude obnovený virtuální stroj a data na něm stará 4 hodiny! Což nemusí odpovídat již vašim požadavkům na RPO. Proto je třeba velmi důkladně zvážit nastavení v rámci konkrétní „PROTECTION GROUP“ i s ohledem na pozdější obnovu související s procedurou „FAILOVER“. Poslední volbou je pak „Shut down virtual machine(s) on-premies“. Tato volba vám umožní před spuštěním samotných virtuálních strojů v Azure, vypnout odpovídající virtuální stroje v On-Premise prostředí. Což je určitý bezpečnostní prvek pro případ „kolize“. Jako příklad si můžete představit situaci, kdy v rámci procedury „FAILOVER“ spustíte virtuální stoj replikovaný do Azure, který v On-Premise prostředí funguje jako doménový řadič a je rovněž držitelem všech FSMO rolí. A pokud je tento virtuální stroj spuštěný v Azure virtuální síti routované dále do On-Premis sítí, může případně dojít k vážným problémům.

Samozřejmě tato volba pozbývá významu v případě, pokud VMWARE virtualizace ve vašem prostředí nefunguje ať už z jakýchkoli důvodů a vy spouštíte proceduru „FAILOVER“ proto, aby jste On-Premise klientům zajistily kontinuitu služeb a aplikací.

clip_image013

Já jsem vybral volbu „Latest application consistent recovery point“ a dále jsem povolil volbu. „Shut down virtual machine(s) on-premies“. A jak je vidět dále na obrázku z „tlustého“ klienta pro VMWARE, došlo v rámci procedury „FAILOVER“ k zastavení virtuálního stroje „IIS1“ v On-Premise prostředí.

clip_image015

V sekci „JOBS“ lze pak nalézt běžící, nebo dokončenou úlohu procedury „FAILOVER

clip_image017

Pokud vstoupíme do této úlohy, uvidíme zde detaily. Mimo jiné vidíme, že došlo k úspěšnému nastartování virtuálního stroje v Azure a došlo rovněž k úspěšnému spuštění skriptu.

clip_image019

V původním portálu Azure pak v sekci „VIRTUAL MACHINES“ můžete vidět běžící virtuální stoje, spuštěné pomocí „RECOVERY PLAN“ a v rámci procedury „FAILOVER“.

clip_image021

Rovněž dojde automaticky k vytvoření Cloud Service, na který je navázána VIP IP adresa.

clip_image023

Pokud se vrátíme do sekce „RECOVERY PLANS“ vidíme, že plán je ve stavu „Unplanned Failover Complete“.

clip_image025

2. Failback

Pokud například v našem On-Premise prostředí došlo k dočasnému výpadku služeb, například z důvodu selhání HW nefungovala VMWARE virtualizace a my jsme provedly proceduru „FAILOVER“, tak po případném úspěšném obnovení normální činnosti VMWARE virtualizace, budete pravděpodobně chtít vrátit virtuální stroje do původního stavu. Tedy aby produkční virtuální stroje primárně běžely na VMWARE virtualizaci. K tomuto slouží procedura FAILBACK. Ta umožnuje „obrátit“ replikaci dat a obnovit virtuální stroje v On-Premise prostředí do aktuálního stavu. Tedy dojde i k replikaci změn, které mezi tím nastaly při běhu virtuálních strojů v Azure do On-Premise prostředí.

Poznámka: Základní předpoklad pro úspěšnou proceduru „FAILBACK“ je funkční Site-to-Site VPN (případně ExpressRoute) propoj, mezi Azure virtuální sítí a On-Premis sítěmi. Resp. skrze VPN spojení musí být dostupný On-Premise Management server (resp. Master Target server).

Vybereme „RECOVERY PLAN“, který je ve stavu „Unplanned Failover Complete“. A v dolní části okna klikneme na tlačítko „RE-PROTECT“.

clip_image027

Spustí se průvodce procedurou „RE-PROTECTION“, kdy dojde ke změně směru replikace. A data budou replikována z Azure do On-Premise VMWARE virtualizace.

clip_image029

Na další kartě průvodce je pak nutné vybrat On-Premise „MASTER TARGET SERVER“ a dále „RETENTION DRIVE“ a „DATA STORE“. Kde „RETENTION DRIVE“ je virtuální disk na rychlých discích s „doporučenou“ kapacitou 600 GB, na který se ukládají dočasná replikační data související právě s procedurou „FAILBACK“.

A „DATA STORE“ je klasický „DATA STORE“ na VMWARE ESXi serveru, na který budou ukládány data. Ve výchozím stavu je nabídnut původní „DATA STORE“, ale je možné to změnit. Jak je vidět v tomto případě, nemám možnost vybrat „RETENTION DRIVE“. Důvody a řešení jsou popsány dále.

clip_image031

V mém případě jsem vytvořil virtuální On-Premise management server jen s jedním diskem s kapacitou 80 GB. Tak jak jsem upozorňoval v části zabývající se instalací Management serveru, kde třeba přidat datový disk na rychlých discích o dostatečné kapacitě, aby bylo možné realizovat proceduru „FAILBACK“. Po přidání datového disku je nutné provést restart management serveru. Poznámka: Disk je třeba naformátovat a přidělit mu písmeno!

clip_image033

Pokud se po přidání disku na management serveru v On-Premise prostředí změna neprojeví a to ani pro kliknutí na tlačítko „REFRESH“, je možné tuto změnu vynutit odinstalací komponenty „Master Target Server“. Následuje restart!

clip_image035

A následným spuštěním instalačního programu a opětovným doinstalováním „MASTER TARGET SERVER“. Následuje restart!

clip_image037

clip_image039

Poté je vhodné vynutit nahrání změn do ASR v Azure a to pomocí tlačítka „REFRESH“.

clip_image041

Pokud některý z postupů zafungoval, pokračujte v přechozí proceduře „RE-PROTECT“ a v tuto chvíli by měl být na výběr i „RETENTION DRIVE“.

clip_image043

Na další kartě průvodce vybíráte „PROCESS SERVER“, který bude replikovaná data zpracovávat a dále PROTECTION GROUP, do které bude replikovaný virtuální stroj umístěn. Upozorňuji, že tato procedura v této fázi pouze obrací směr replikací! Co je velmi podstatné v této fázi je výběr „PROCESS SERVERU“. Jak je vidět na obrázku, já jsem vybral „PROCESS SERVER“ vytvořený jako virtuální stroj v Azure a zařazený do Azure virtuální sítě, která je propojená s On-Premise prostředím. Platí, že Management server v On-Premise prostředí musí být dostupný skrze VPN pro PROCESS SERVER umístěný v Azure!

Proč vlastně použít další PROCESS SERVER? No důvod je jednoduchý. Představte si situaci, kdy do Azure replikujete velké množství virtuálních strojů a tento velký objem dat zpracovává PROCESS SERVER běžící v On-Premise prostředí. No a vy zahájíte „RE-PROTECT“ proceduru a další velké množství dat bude zpracovávat tentýž PROCESS SERVER. Vytvoření dalšího PROCESS SERVERU je popsáno na konci tohoto článku.

Poznámka: Jinak platí, že jako PROCESS SERVER lze samozřejmě vybrat i PROCESS SERVER běžící na management serveru v On-Premise prostředí.

clip_image045

Zde pak vidíte příklad detail úspěšně proběhlé úlohy „RE-PROTECT“ v sekci „JOBS“.

clip_image047

Na obrázku pak vidíte seznam úloh, které v rámci procedury „RE-PROTECT“ proběhly na samotném VMWARE vSphere serveru.

clip_image049

Pokud se pokusíte po dokončení „RE-PROTECT“ procedury spustit virtuální stoj ve VMWARE, dojde k vygenerování chyby. Ta odkazuje víceméně na problémy s virtuálním VMDK diskem. Což je v tuto chvíli v pořádku.

An error was received from the ESX host while powering on VM IIS1.

Failed to start the virtual machine.

Module DiskEarly power on failed.

Cannot open the disk '/vmfs/volumes/568cf58d-8f56357a-c9d4-b8ac6f8507ac/IIS1/IIS1.vmdk' or one of the snapshot disks it depends on.

Failed to lock the file

Pokud tedy úloha v sekci „JOBS“ byla úspěšně dokončena, přesuneme se do sekce „PROTECTED ITEMS“ – „PROTECTION GROUPS“ kde je z obrázku patrné, že virtuální stroj se přesunul do druhé „PROTECTION GROUP“ s označením „Failback“ na konci názvu. Vstoupíme do této skupiny.

clip_image051

Jak je patrné z obrázku aktuálně dochází k postupné synronizaci/replikaci dat z Microsoft Azure do On-Premise prostředí na VMWARE ESXi server. Je důležité poznamenat, že tato synchronizace může trvat i poměrně dlouho. Je to závislé od toho, kolik dat se od doby spuštění procedury „FAILOVER“ na virtuálním stroji běžícím v Azure změnilo. Navíc dokud se tato replikace nedokončí, není možné dokončit samotný „FAILBACK“ a virtuální stroj v On-Premise prostředí nepůjde použít.

clip_image053

Zde je pak vidět detail samotného virtuálního stroje, který se replikuje zpět do On-Premise prostředí

clip_image055

Ve chvíli kdy se změna směru replikace z Azure do On-Premise prostředí dokončila, je možné přistoupit k dokončení samotného „FAILBACK“ a zprovoznit produkční virtuální stroj opět na VMWARE ESXi serveru.

clip_image057

Přejděte opět do sekce „RECOVERY PLANS“, vyberte konkrétní plán, který je ve stavu „Unplaned Failover Completed“ a tentokrát ve spodní části okna klikněte na tlačítko „FAILOVER“.


clip_image059

clip_image061

Spustí se okno potvrzení procedury „FAILOVER“ kde pak aktuálně vidíme, že tentokrát je zdrojem Azure a cílem je On-Premise prostředí. V mém případě jsem vybral „Latest application consistent recovery point“.

clip_image063

Pokud vše proběhlo v pořádku a VPN je funkční, dojde automaticky v rámci úlohy k doreplikování změn a automaticky dojde ke spuštění virtuálního stroje v On-Premise prostředí ve VMWARE virtualizaci.

clip_image065 clip_image067

I když úloha na konci vygenerovala chybu, viz pak obrázek níže, i tak se zdá být vše v pořádku a virtuální stroj v On-Premise prostředí se zdá být v pořádku a operační systém také v pořádku naběhl.

clip_image069

clip_image071

Určitou zvláštností je, že i po dokončení „FAILBACK“ zůstane v Azure vypnutý virtuální stroj.

clip_image073

3. Reprotekce zpátky do Azure

Pokud již máme nazpět funkční virtuální stroj v On-Premise prostředí, je vhodné jej znovu začít synchronizovat do Azure, právě pro případ dalšího možného výpadku v On-Premise prostředí. Proto provedeme proceduru „RE-PROTECT“ a obnovíme replikaci virtuálního stroj zpět do Azure.

Poznámka: Níže uvedenou proceduru lze provést i v rámci „RECOVERY PLAN“.

Tedy v sekci „PROTECTED ITEMS“ – „PROTECTION GROUPS“ vstoupíme do skupiny, která na konci názvu označení „failback“. A vybereme konkrétní virtuální stroj. Následně v dolní části okna klikneme na tlačítko „RE-PROTECT“.

clip_image075

clip_image077

Zobrazí se okno s nastavením. Kde opět definujeme PROCESS SERVER a PROTECTION GROUP, jehož součástí bude replikovaný virtuální stroj.

clip_image079

Zde pak ukázka úlohy úspěšně provedené RE-PROTECT.

clip_image081

Následně v dané PROTECTION GROUP jde vidět, že nám přibyl virtuální stroj a zahájila se replikace dat do Azure. A co je zajímavé v této fázi zmizel virtuální server z Azure, ze seznamu virtuálních serverů.

clip_image083

4. Přidání Process serveru v Azure

Jak již bylo v článku výše napsáno, je možné do samotného Azure přidat další PROCESS SERVER. Cílem této akce je pak primárně při proceduře „FAILBACK“ „odlehčit“ zátěž primárnímu PROCESS SERVERu v On-Premise prostředí.

Přejdeme do sekce „SERVERS“ – „CONFIGURATION SERVERS“. V dolní části okna pak klikneme na tlačítko „+ PROCESS SERVER

clip_image085

clip_image087

Zobrazí se okno přidání nového PROCESS SERVERu do Azure. Vyplňte parametry pro nový server. V této fázi je třeba si dát pozor na jednu zásadní věc. Ve chvíli kdy zadáte do pole „PROCESS SERVER NAME“ nějaký název, ten se neprověřuje! Tedy je třeba jednak vymyslet unikátní název v rámci celého Azure! a dále se musí jednat paradoxně o unikátní název z hlediska názvu storage accountu. Jak je v průvodci vidět, resp. vlastně není vidět položka pro zadání názvu storage accountu. Znamená to tedy, že se nejprve v rámci úlohy snaží Azure založit storage account s názvem stejným jako je uvedeno v poli „PROCESS SERVER NAME“. Proto je vhodné nejprve separátně založit nový storage account a pokud je název volný, použit stejný název i pro nový PROCESS SERVER. Poznámka: Tento nový PROCESS SERVER musí mít skrze VPN spojení s On-Premise prostředím!

clip_image089

clip_image091

Pokud je jméno strage account již obsazeno, skončí úloha s poněkud matoucí chybou.

clip_image093

clip_image095

Ve chvíli kdy je PROCESS SERVER dostupný/vytvořený, přihlaste se skrze vzdálenou plochu. Automaticky dojde napoprvé ke spuštění konfiguračního utility PROCESS SERVERu. Zde je nutné vyplnit IP adresu On-Premise PROCESS SERVERu, komunikační port (standarně TCP 443) a co je nejpodstatnější, je třeba zde doplnit správnou Passphrase. Ta byla vygenerována při instalaci On-Premise management serveru. Pokud existuje VPN konektivita mezi Azure virtuální sítí a On-Premise sítí, kde se nachází PROCESS SERVER, klikněte na tlačítko „Save“ a mělo by dojít ke spárování obou PROCESS SERVERů.

clip_image097

Užitečné odkazy:

https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmware-to-azure-classic/#step-6-set-up-credentials-for-the-vcenter-server

https://azure.microsoft.com/en-us/documentation/articles/site-recovery-failover/

https://azure.microsoft.com/en-us/blog/introducing-powershell-support-for-azure-site-recovery/

https://azure.microsoft.com/cs-cz/documentation/articles/site-recovery-runbook-automation/

Azure Site Recovery – VMWARE(5)

Vytisknout E-mail

Jakub Heinz Datum zveřejnění: 25. 4. 2016 8:25 Zobrazeno: 710
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

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 TEST FAILOVER procedurou, tedy proceduru, kdy otestujeme, zda jsou replikované virtuální stroje v Azure plně funkční.

1. Testování Failoveru

Nyní si asi kladete otázku. Dobře teď mám vše nastaveno, a jak zjistím, že to vše skutečně funguje. Jak si ověřím, že v případě výpadku budou fungovat naše aplikace, weby apod. Možnosti jsou dvě. Možnost radikální a složitější se jmenuje FAILOVER, resp. Unplanned/Neplánovaný Failover. A ta jednodušší metoda se jmenu TEST FAILOVER. V této části si ukážeme TEST FAILOVER.

Ten má tu výhodu, že obvykle neovlivní stávající produkční prostředí, nevýhodou pak je, že nelze pravděpodobně otestovat úplně vše.

TEST FAILOVER funguje tak, že dojde ke spuštění virtuálních strojů v samotném Azure a to z dat/virtuálních disků uložených ve storage accountu v Azure. A to buď zařazením do specifické Azure vNet, nebo úplně izolovaně.

V sekci „PROTECTED ITEMS“ – „PROTECTION GROUPS“ vstoupíme do konkrétní skupiny.

clip_image002

Zde pak označíme konkrétní jeden virtuální stroj.

clip_image004

Ve spodní části okna pak klikneme na tlačítko „TEST FAILOVER“.

clip_image005

Zobrazí se okno pro testování failoveru. Zde pak máme možnost vybrat, do jaké virtuální sítě bude virtuální stroj při této operaci zařazen. Pokud vybereme volbu „None“, spustí se virtuální stroj v „izolovaném“ módu, kdy bude virtuální stroj dostupný pouze skrze VIP IP adresu jeho Cloud Service a případné nastavené Endpointy. Pokud vybereme existující virtuální síť, je zde vícero možností/scénářů.

1. Virtuální síť není nijak propojená s On-Premise prostředím. V tom případě tento test nemůže nijak ovlivnit produkční On-Premise prostředí, ale výhodou je, že pokud umístíme do stejné sítě jiný již existující virtuální stroj v Azure, můžeme otestovat i vnitřní komunikaci a nemusíme například, vůbec definovat Endponty a tím vystavovat konkrétní porty/služby do prostředí „Internetu“.

2. Virtuální síť je propojená s On-Premise prostředím např. pomocí Site-to-Site VPN, ale je připojená do izolované On-Premise sítě. Tento scénář je náročnější na realizaci z hlediska konfigurace On-Premise prostředí. Předpokládá, že existuje On-Premise izolovaná síť, která není routována dál do jiných interních sítí a na této izolované sítí jsou k dispozici např. testovací klientské stanice apod. Výhodou tohoto řešení je, že neovlivní stávající produkční prostředí, a navíc lze tímto způsobem otestovat i spuštění komplexního prostředí v Azure, kde pak lze na straně klientů v On-Premise izolované síťi otestovat, zda jsou služby/aplikace dostupné. A tak si ověřit co by mohlo nastat v případě, pokud by nastal skutečný výpadek v On-Premise prostředí. Samozřejmě tímto způsobem nelze pravděpodobně otestovat vše.

3. Virtuální síť je propojená s On-Premise prostředím např. pomocí Site-to-Site VPN a je připojená do On-Premise sítě, která je dále routovaná. Tento scénář se spíše váže na samotný Failover, kdy potřebujete zajistit dostupnost služeb pro interní klienty v případě výpadku On-Premise prostředí. A kdy se předpokládá, že původní produkční servery replikované do Azure aktuálně nejsou dostupné. Nicméně při samotném TEST FAILOVER se dá použit i tento scénář. Nicméně hodně záleží na tom, jaké služby či aplikace jsou testovány a jak. Tedy je třeba zamezit ovlivnění stávajícího produkčního prostředí.

V mém případě jsem vybral volbu „Infra-production“

clip_image007

Pokud přejdeme do sekce „JOBS“ a vstoupíme do konkrétní běžící úlohy TEST FAILOVER, uvidíme detaily samotné úlohy a její průběh. Pokud vše proběhne v pořádku, zastaví se úloha ve fází, kdy očekává potvrzení úspěšnosti/dokončení testování. To tedy znamená, že je čas otestovat služby běžící na virtuálním stroji v Azure.

clip_image009

Jak je vidět z detailu výpisu virtuálního stroje, je ve stavu Running, má veřejnou IP adresu a také díky tomu, že jsem jej nechal zařadit do virtuální sítě „Infra-production“, získal i konkrétní lokální IP adresu.

clip_image011

Zde pak detail Cloud Service, která je rovněž automaticky vytvořena.

clip_image013

Ve výchozím stavu, pokud testujeme failover jen pro jeden virtuální stroj, nedojde k nastavení žádného Endpointu.

clip_image014

Proto jsem přidal Endpoint pro port TCP 3389 (RDP) a pro port TCP 80 (HTTP).

clip_image016

Poté jsem otestoval, že na portu TCP 80 poslouchá služba IIS. Tedy máte otestovánu dostupnost služby IIS.

clip_image018

Dále jsem se přihlásil před RDP klienta, abych otestoval, zda je funkční připojení na vzdálenou plochu.

clip_image020

Jakmile mám otestováno, vrátím se do sekce „JOBS“, vstoupím do konkrétní úlohy a provedu dokončení testu kliknutím na tlačítko „COMPLETE TEST

clip_image021

Následně jsem vyzván k doplnění komentáře, který se uloží a co je hlavní mám možnost říci, že dojde k úklidu a celé testovací prostředí vzniklé při TEST FAILOVER bude zrušeno.

clip_image023

Zde je pak ukázka kompletně dokončené úlohy.

clip_image025

V případě testování kompletních scénářů, mohu realizovat testovací failover prostřednictvím RECOVERY PLAN. Tedy vyberu konkrétní recovery plán, který může obsahovat různé skupiny počítačů a na ně navázané sckripty a spustit TEST FAILOVER.

clip_image027

clip_image029

Stejně jako v předchozím případě jsem nechal virtuální stroje zařadit do sítě „Infra-Production“

clip_image031

Kompletní TEST FAILOVER evidentně doběhl do fáze čekání na prověření. A jak jde vidět skript se rovněž „úspěšně“ dokončil. Ale… po prověření virtuálních strojů jsem zjistil, že nedošlo k přidání EndPointů. Tedy co s tím..?

clip_image033

Musíme se přesunout v Azure do části „AUTOMATION“, kde máme z galerie vytvořený náš RUNBOOK. Vstoupíme do RUNBOOKu.

clip_image035

Zde klikneme na sekci „JOBS“ a vybereme konkrétní úlohu.

clip_image037

Dále přejdeme do sekce „HISTORY“ kde již vidíme, že skript skončil vygenerováním dvou chyb.

clip_image039

Už první chyba nám naznačí to, co jsem předpokládal a to, že doplnění pověření pro poštěstění skriptu již delší dobu musí být realizováno pomocí účtu, který odpovídá organizaci. V mém případě Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript. (nebo pak doménovému účtu z interní Azure Active Directory). A nejsou podporovány účty např. Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript. apod. Dalším možným problémem v samotném Runbooku je parametr –SubscriptionName. Ten již v novějších verzích Azure PowerShell není podporován. A je třeba jej nahradit parametrem –SubscriptionID. Tedy v samotném příkladu Runbooku je chyba.

Select-AzureSubscription : The subscription name Microsoft Azure Enterprise KPCS - Infra doesn't exist.

Parameter name: name

At OpenRemotePorts:51 char:51

+

+ CategoryInfo : CloseError: (:) [Select-AzureSubscription], ArgumentException

+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.Profile.SelectAzureSubscriptionCommand

Add-AzureAccount : -Credential parameter can only be used with Organization ID credentials. For more information,

please refer to http://go.microsoft.com/fwlink/?linkid=331007&clcid=0x409 for more information about the difference

between an organizational account and a Microsoft account.

At OpenRemotePorts:49 char:49

+

+ CategoryInfo : CloseError: (:) [Add-AzureAccount], AadAuthenticationFailedException

+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.Profile.AddAzureAccount

V rámci samotného RUNBOOKu přejdeme do sekce „AUTHOR“ – „PUBLISHED“ a dolní části okna klikneme na tlačítko „EDIT

clip_image041

clip_image043

Zde jsem pak provedl úpravy v kódu a nahradil názvy proměnných

clip_image045

Poté jsem upravený skript uložil tlačítkem „SAVE“ a vypublikoval pomocí tlačítka „PUBLISH“.

clip_image046

Také jsem upravil proměnnou a nahradil SubscriptionName za SubscriptionID.

clip_image048

clip_image050

A nakonec jsem změnil uživatele v rámci definice pověření.

clip_image052

Azure Site Recovery – VMWARE(4)

Vytisknout E-mail

Jakub Heinz Datum zveřejnění: 18. 4. 2016 8:20 Zobrazeno: 647
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

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 vytvořením RECOVERY PLAN, tedy plánu obnovení.

1. Vytvoření Recovery plánu

Následující fázi je vytvoření Recovery plánu. Ten se používá v kombinaci s procedurou Test Failover a Failover. A to je právě přesně to, díky čemu lze zásadně odlišit ASR od standardní replikace do jiného datového centra. Recovery plán nám umožnuje spouštět postupně jednotlivé skupiny virtuálních serverů, tak jak potřebujeme v určitém pořadí a co je zásadní, lze na tyto skupiny počítačů aplikovat skripty, které mohou zautomatizovat různé úlohy, které by bylo nutné jinak realizovat ručně. Příkladem může být vytvoření Endpointů, nebo nastavení load balancingu, či spuštění určitých operací uvnitř virtuálních strojů.

V sekci „RECOVERY PLANS“ klikneme na položku „CREATE RECOVERY PLAN

clip_image002

V rámci průvodce vytvořením RECOVERY PLAN zadáme název plánu a jako zdroj pro RECOVERY PLAN vyberu v mém případě management server „ONPREMISEPS“. Cílem je pochopitelně Azure.

clip_image004

Na další kartě pak vybíráme jednotlivé Protection Group, a případně i jednotlivé virtuální stoje, které budou součástí RECOVERY PLAN.

clip_image006

Výsledkem je pak základní plán, který můžeme dále upravovat dle našich potřeb. Můžeme například přidat další skupinu „GROUP“ a do ní pak přidat další virtuální stroje. Nebo přidat skript „SCRIPT“, nebo manuální akci „MANUAL ACTION“.

clip_image008

clip_image009

Veškeré změny pak můžeme uložit pomocí tlačítka „SAVE

clip_image011

Dále si ukážeme velmi obecně přidání skriptu. Skript můžeme přidat buď tak, že se spustí před inicializací skupiny, nebo po ní. Tedy v mém případě chci například přidat po inicializaci skupiny virtuálních serverů skript, který vytvoří Endpointy pro RDP a HTTP. Já tedy vyberu položku „Add recovery side script after Group1“.

clip_image013

Jak je patrné, nemám v tuto chvíli vytvořen účet v rámci Azure Automation. Proto jsem kliknul na volbu „Create a new Automation Account“.

clip_image015

V rámci původního Azure portálu jsem se dostal do části „AUTOMATION

Zde kliknu na tlačítko „CREATE AN AUTOMATION ACCOUNT“.

clip_image017

A vytvořím si AUTOMATION ACCOUNT s názvem „asrautomation“ v lokalitě „West Europe“.

clip_image019

V rámci nově vytvořeného AUTOMATION ACCOUNT, přejdu do sekce „RUNBOOKS“ a v dolní části okna kliknu na tlačítko „+ NEW“.

clip_image021

clip_image023

Zde pak vyberu „APP SERVICES“ – „AUTOMATION“ – „RUNBOOK

clip_image025

A dále „FROM GALLERY

clip_image027

Zobrazila se mi galerie již hotových skriptů, které mohu využít. Vyberu tedy v rámci galerie „Disaster Recovery“ a následně vyberu skript „Open Remote Desktop Port On A VM in A Recovery Plan

clip_image029

Na další kartě je pak náhled samotného kódu skriptu.

clip_image031

Na poslední kartě zadám název pro RUNBOOK, vyberu AUTOMATION ACCOUNT a subskripci.

clip_image033

Poté vstoupím do samotného RUNBOOK a vyberu sekci „AUTHOR“ – „DRAFT“. Zde je již možné kód i editovat, nebo pokud je kód již hotov, je možné jej vypublikovat. Já jsem kód upravil a přidal navíc kus kódu, který vytváří další Endpoint pro port TCP 80. Dále jsem provedl uložení skriptu pomocí tlačítka „SAVE“ a provedl jsem publikaci skriptu pomocí tlačítka „PUBLISH“. Poznámka: Bez publikace nebude skript dostupný!

clip_image035

clip_image037

clip_image039

clip_image041

To bohužel není vše. Aby skript fungoval, předpokládá se, že jsou definovány proměnné, které se používají v rámci skriptu. V mém případě proměnná „AzureCredential“, což jsou pověření pro samotnou Azure subskripci a dále pak „AzureSubscriptionName“, což je název subskripce, ve které se bude skript spouštět.

clip_image043

Vrátím se zpět do samotného AUTOMATION ACCOUNT a zde vyberu sekci „ASSETS“. Následně v dolní části okna vyberu tlačítko „ADD SETTINGS“.

clip_image044

clip_image045

Mám na výběr několik možností. My potřebuje nejprve vytvořit pověření „ADD CREDENTIAL“ a dále do datového typu String umístit název Subskripce „ADD VARIABLE

clip_image047

V rámci průvodce definice pověření vybereme jako typ „Windows PowerShell Credential“. A zadáme název. V mém případě se musí shodovat s názvem proměnné ve skriptu, tedy název musí být „AzureCredential

clip_image049

Dále pak uvedu jméno uživatele s právy na Azure subskripci a vyplním hesla.

clip_image051

Nakonec nadefinuji název subskripce. Tedy „ADD VARIABLE“, jako typ vyberu String a jako název, který se musí shodovat s názvem proměnné použité ve skriptu, vyplním „AzureSubscriptionName“.

clip_image053

Na další kartě pak zadám hodnotu, v mém případě název subskripce a zvolím, zda má, nebo nemá být tato hodnota šifrována.

clip_image055

Pokud se nyní vrátím do ASR, vyberu svůj nově vytvořený RECOVERY PLAN a kliknu na tlačítko „SCRIPT“ – „Add recovery side script after Group1

clip_image056

Je mi již nabídnuta možnost vybrat mnou vytvořený skript. Zadám název pro skript, vyberu AUTOMATION ACCOUNT a samozřejmě vyberu skript, který jsem právě vytvořil.

clip_image058

Jak je pak patrné v rámci RECOVERY PLAN mi přibyla položka „Group 1: Post-steps“ a přidal se mnou vytvořený/upravený skript.

clip_image060

Azure Site Recovery – VMWARE (3)

Vytisknout E-mail

Jakub Heinz Datum zveřejnění: 11. 4. 2016 8:17 Zobrazeno: 758
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

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 přidáním VMWARE vCentra, vytvořením PROTECTION GROUP a přidáním virtuálních strojů do vytvořené PROTECTION GROUP.

1. Přidání vCenter serveru

Ve chvíli kdy máme pověřovací údaje (jen friendly name) úspěšně synchronizovány do Azure, můžeme přistoupit k dalšímu nezbytnému kroku a to přidání VMWARE vCenter do Azure. Tento krok nám umožní načítat seznam virtuálních strojů, které spadají pod konkrétní vCenter. A dále je možná detekce stavu virtuálních strojů. Tedy v sekci „SERVERS“ – „CONFIGURATION SERVERS“ vyberte konkrétní management server, v ném případě „ONPREMISEPS“ a v dolní části okna klikněte na tlačítko „ADD VCENTER SERVER“.

clip_image002

clip_image004

V okně pro přidání vCenter serveru doplňte údaje vašeho On-Premise vCenter serveru. Jako Process server jsem vybral On-Premise server „ONPREMISEPS“ a v rámci položky „VCENTER ACCOUNT“ jsem vybral v předchozím kroku vytvořené/definované pověření.

clip_image006

Pravděpodobně i v případě této akce, tedy přidání vCenter serveru, nepotřebujete mít navázánu/funkční Site-to-Site VPN (případně ExpressRoute). Pokud se spletete a zadáte např. špatnou IP adresu vCenter serveru, dojde v rámci spuštěné úlohy v sekci “JOBS” k vygenerování chyby. A ta říká, že vCenter, který chcete přidat, musí být dostupný přes výchozí port TCP 443 z Process/management serveru v On-Premise prostředí.

clip_image008

Pokud se rozhodnete odebrat stávající vCenter server, musíte nejprve zrušit replikaci všech virtuálních strojů, které jste přidaly „skrze“ toho vCenter, viz chyba níže.

clip_image010

Po rozkliknuti management serveru, lze vidět seznam vCenter serverů navázaných na tento konkrétní management server.

clip_image012

Pokud vyberete konkrétní přidaný vCenter, máte možnost jej odstranit, nebo upravit jeho parametry, pokud došlo k jejich změně.

clip_image013

2. Vytvoření Protection Group

Dalším krokem je vytvoření Protection Group. Je velmi důležité si zde uvědomit co je Protection Group. Je to skupina virtuálních strojů, které budeme v rámci jedné skupiny replikovat do Azure. Přičemž každá skupina sdílí určité kritické parametry týkající se možnosti obnovení. Je vhodné umístit do jedné skupiny virtuální servery s podobnými požadavky na možnosti obnovení, jako jsou například RPO, Retention, Application Snaphot frequency apod.

Poznámka: Vše bude vysvětleno dále.

V sekci „PROTECTION ITEMS“ vyberte položku „PROTECTION GROUPS“.

clip_image015

V dolní části okna pak klikněte na tlačítko „+ PROTECTION GROUP

clip_image016

V průvodci přidáním „PROTECTION GROUP“ zadejte nejprve název nové skupiny do pole „PROTECTION GROUP NAME“. Dále v poli „FROM“ vyberte odkud se budou virtuální stroje replikovat. V mém případě jsem vybral management server „ONPREMISEPS“. Přičemž cíl je v tomto případě Azure a nelze jej změnit.

clip_image018

Na další kartě průvodce definujeme kritické parametry skupiny.

Položka „MULTI VM CONSISTENCY“ – pokud je nastaveno na „ON“, bude docházet k vytváření sdílených aplikačně-konzistentních bodů obnovení skrze všechny virtuální stoje v dané skupině. Tuto volbu je vhodné zapnout v případě, že na virtuálních strojích v dané skupině jsou servery, kde běží stejné, nebo podobné aplikace či služby. Tedy například Webové servery. Výhodou je pak, že všechny virtuální stroje v rámci skupiny budou obnoveny současně do stejného bodu obnovení, tak aby bylo docíleno datové/aplikační konzistence.

RPO threshold – RPO v podstatě zjednodušeně řečeno uvádí časovou periodu, ve které mohou být data ztracena, aniž by to znamenalo pro nás kritický problém/incident. Ve výchozím stavu je RPO treshold nastaven na 30 minut. To znamená, že pokud se replikace opožďují, nebo neprobíhají správně a není možné zajistit, že v Azure existují replikovaná data ne starší než 30 minut, dojde k vygenerování upozornění. Pak tedy hrozí, že v případě neplánovaného Failoveru/výpadku On-Premise prostředí, budeme mít k dispozici data starší než 30 minut, nebo než námi požadované RPO. Minimum, které lze nastavit je 1 minuta. Maximum pak 240 minut.

Recovery point retention – jedná se časový interval/okno ve kterém dochází k uchovávání jednotlivých bodu obnovení. A znamená to, že se lze vrátit k jakémukoli bodu obnovení v tomto časovém okně. Výchozí hodnota je 24 hodin. Pokud tedy zjistíme, že například před méně než 24 hodinami došlo v důsledku lidské chyby k nenávratnému poškození aplikačního serveru, který je replikován do Azure, lze spustit pro tento server FAILOVER proceduru „a vrátit se v čase“ do bodu, kdy byl aplikační server funkční. Minimum je jedna hodina, maximum pak 72 hodin.

Ukázka Failover procedury, kdy si vybereme „Custom recovery point“.

clip_image020

Na výběr pak máme jak z klasických bodu obnovení, tak z Aplikačně konzistentních bodu obnovení, viz také další volba.

clip_image022

Application-consistent snapshot frequency – udává, jak často se má vytvářet aplikačně konzistentní bod obnovení. Předpokládám, že v případě Windows operačních systému, je díky Mobility service zavolán nějaký konkrétní VSS provider a dojde k dočasnému zmražení všech transakcí a aplikace jsou donuceny se uvést do konzistentního stavu, což by mělo umožnit zálohu konzistentních dat. Přiznám se, že nemám zjištěno, zda jsou možné aplikačně konzistentní body obnovení i v případě Linux operačního systému, ale domnívám se, že ne. Výchozí hodnota je 60 minut. Tedy s pomocí Mobility service, bežící na replikovaném virtuálním stroji se pokusí každou hodinu vytvořit aplikačně konzistentní bod obnovení. Minimální hodnota je „NEVER“, tedy to znamená, že se nebudou vytvářet aplikačně konzistentní body obnovení. Druhá nejnižší možná hodnota je pak 20 minut, a nejvyšší hodnota pak 1440 minut (24 hodin).

clip_image024

Pokud odsouhlasíme vytvoření „PROTECTION GROUP“, automaticky pak dojde vytvoření i druhé skupiny s „označením“ „Failback“ na konci. Failback bude popsán později v článku.

clip_image026

3. Přidání virtuálních strojů do Protection Groups

Dalším krokem je pak přidání konkrétních virtuálních strojů do Protection Group.

POZOR!!! Jakmile přidáte virtuální stroj do protection group, dojde okamžitě k jeho replikaci do Azure. Tedy pro tento úkol je vhodné zvolit dobu, kdy je nejmenší zatížení vašeho On-Premise prostředí. Obvykle to jsou noční, nebo večerní hodiny.

Vybereme konkrétní PROTECTION GROUP, a „vstoupíme do ní“. Zde pak klikneme na položku „ADD VIRTUAL MACHINES“,

clip_image028

V průvodci přidáním virtuálních strojů nejprve vybereme správný vCenter server. Na základě výběru vCenter serveru, se nám načte seznam virtuálních strojů. Upozornění: Seznam virtuálních strojů je ovlivněn standardním 15 minutovým oknem, v rámci kterého dochází k načítání dat z management serveru. Tedy pokud vytvoříte virtuální stroj a vzápětí jej budete chtít přidat, v seznamu virtuálních strojů jej neuvidíte. To lze řešit pomocí tlačítka „REFRESH“, viz také postup popsaný výše v článku. Zde je vidět, že je možnost vybrat pouze ty virtuální stroje, které jsou podporovány. Standardně to nejsou všechny virtuální stroje, které jsou vypnuté. Což je logické, protože PROCESS SERVER, potřebuje vzdáleně na tyto virtuální servery instalovat Mobility service. Vybereme konkrétní podporované virtuální stroje a dále musíme souhlasit s tím, že jsme si vědomi náročnosti replikace a jejího dopadu na naši infrastrukturu.

clip_image030

Na další kartě pak vybereme PROCESS SERVER, který bude replikaci řídit a dále vybereme Storage Account v Azure, kam budou nově vzniklé .vhd soubory ukládány.

clip_image032

Na další kartě průvodce pak vybereme pověření pro námi vybrané virtuální stroje, které nám umožní instalaci Mobility service.

clip_image034

Zde pak ukázka obsahu storage account, kam jsou replikovány virtuální stroje.

clip_image036

Vidíme, že na storage accountu je uložen vhd disk virtuálního stroje replikovaného z On-premise prostředí. Tento soubor se pak použije v případě Test Failover, nebo Failover operace.

Níže pak vidíte VHD location string disku virtuálního stroje Server1, který je ve stavu Unplaned Failover.

https://azuresiterecoverystorage.blob.core.windows.net/wahva57979713b95c88373/copied-%7B2057439281%7D.vhd

clip_image038

Jakmile je virtuální stroj přidán do PROTECTION GROUP, dojde k sekci „JOBS“ ke spuštění úlohy, která se pokusí s nastavenými pověřeními o instalaci Mobility service na vybrané virtuální stroje.

clip_image040

Pokud se má instalace Mobility service povést, musí být v případě podporovaného Windows operačního systému správně nastaven Firewall. Tedy musí být pro aktivní Firewall profil povoleno „File and Printer Sharing“ a dále povoleno pravidlo pro „Windows Management Instrumentation (WMI)“. Následně pak musí být povolen port TCP 9443, pro komunikaci a přenos dat mezi Mobility service a PROCESS SERVEREM.

clip_image042

clip_image044

Zde je pak ukázka úspěšně dokončené úlohy

clip_image046

V sekci „PROTECTED ITEMS“, „PROTECTION GROUPS“, vstupte do konkrétní skupiny. A dále vstupte do vlastností konkrétního virtuálního serveru.

clip_image048

Jakmile je úspěšně dokončena instalace Mobility service, dochází k replikaci dat do Azure. Na obrázku je podrobně vidět jaké disky se replikují, kdo je zdroj dat a jaký proces server tyto data zpracovává.

clip_image050

Je samozřejmě možné do stávající skupiny přidat další virtuální stroje. Stačí, když vstoupíte do konkrétní skupiny a v dolní části okna vyberete tlačítko „ADD MACHINES“.

clip_image052

clip_image054

Na obrátku pak vidíte ukázku toho, že ASR si detekuje i různé stavy virtuálních strojů v On-premise prostředí. V tomto případě nemůžeme přidat do skupiny virtuální stroj, protože na neplatnou IP adresu.

clip_image056

Z výpisu IP konfigurace na tomto virtuálním stoji je patrné, že nebyl schopen získat IP adresu z DHCP serveru a proto si nastavil APIPA IP adresu. Která ovšem není routovatelná.

clip_image057

Azure Site Recovery – VMWARE(2)

Vytisknout E-mail

Jakub Heinz Datum zveřejnění: 4. 4. 2016 8:10 Zobrazeno: 776
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

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 instalací a konfigurací management serveru a všech jeho komponent.

1. Instalace VM ve VMWARE

Na vašem VMWARE ESXi serveru, nebo prostřednictvím VMWARE vSphere si vytvořte virtuální stroj, na který pak budou nainstalovány potřebné komponenty. Musí se jednat o operační systém Windows 2012 R2 v anglické verzi. Jaké prostředky má mít tento virtuální server k dispozici závisí od toho, kolik virtuálních, či fyzických serverů budete replikovat do Microsoft Azure.

Například, pokud budete replikovat do 100 virtuálních strojů, pak níže v tabulce vidíte příklad požadavků na HW, které by měl mít management server k dispozici:

Management server - počet CPU

Operační paměť

Cache disk - velikost

Předpoklad- množství změněných dat

Max. počet replikovaných serverů

8 vCPUs (2 sockets * 4 cores @ 2.5GHz)

16 GB

300 GB

500 GB nebo méně

100

2. Instalace VMWARE PowerCLI 6.0

https://developercenter.vmware.com/tool/vsphere_powercli/6.0

Pro stáhnutí instalačního souboru potřebujete mít k dispozici jakýkoli účet u VMWARu. Nebo jsi jej založte.

https://my.vmware.com/web/vmware/registration

Po instalaci PowerCLI je nutné ještě před instalací On-Premise komponent pro SRV provést restart virtuálního serveru!

clip_image002

„Next >“ , „Install“

3. Stáhnutí registration key a instalačního souboru a samotná instalace

Nyní si ukážeme samotnou instalaci komponent do On-Premise prostředí. Tedy v rámci původního Azure portálu přejdeme v levém menu do sekce „RECOVERY SERVICES“ a dále vybereme námi vytvořený Azure Site Recovery Vault. Poté klikneme hned na první ikonu. Zde v rámci možností „SETUP RECOVERY“, vybereme volbu „Between an on-premise site with VMWARE/physical servers and Azure“.

clip_image004

Nyní u kroku jedna klikněte na odkaz „Download and install On-Premise Components“ pro stáhnutí instalačního souboru MictosoftAzureSiteRecoveryUnifiedSetup.exe. A dále klikněte na odkaz „Download a registration key“ pro stažení registračního klíče, který vám umožní registrovat On-Premise ASR Management server (Windows 2012 R2 virtuální stroj běžící na VMWARE ESXi serveru) v samotném Azure Site Recovery Vault.

clip_image006

Následně na virtuálním stroji spustíme samotnou instalaci všech potřebných komponent. Na obrázku pak vidíme samotný instalační soubor MictosoftAzureSiteRecoveryUnifiedSetup.exe a dále registrační klíč.

clip_image008

Po spuštění instalačního souboru na první kartě vyberte volbu „Install the configuration server and proces server“ a pokračujte dále pomocí tlačítka „Next“. Pozn.: Ve skutečnosti dojde zároveň i k instalaci „Master target serveru“.

clip_image010

Na další kartě musíte akceptovat licenční podmínky pro instalaci MySQL databáze. MySQL databáze slouží mimo jiné pro ukládání různých pověření, se kterými pak pracuje Process server. Například prověření lokálního administrátora na virtuální stroje, kam má automaticky Process server instalovat Agenta (Mobility service). Tyto pověření jsou ukládána pouze do databáze MySQL a nejsou replikována do ASR. Poznámka: Proto, aby instalační program mohl automaticky naistalovat MySQL databází, musí z management serveru existovat konektivita na portu TCP 80 do „Internetu“. Což lze otestovat tak, že kliknete na odkaz „Direct Download Link“. Samozřejmě navíc doporučuji tuto MySQL databázi pravidelně separátně zálohovat (http://dev.mysql.com/doc/refman/5.7/en/mysqldump.html)

clip_image012

Na další kartě vyberte typ konektivity do „Internetu“. Pomocí protokolu TCP 443 jsou data zasílána do Azure (Storage Account). Pokud používáte proxy a je nutná autorizace, vyberte poslední volbu a vyplňte potřebné údaje. Přejděte na další kartu pomocí tlačítka “Next”.

clip_image014

Na této kartě se provede ověření pre-rekvizit, potřebných pro úspěšnou instalaci všech komponent. Povšimněte si, že poslední test, týkající se volného místa na disku skončil s varováním. Důrazně již v tuto chvíli doporučuji toto varování neignorovat a připojit k virtuálnímu stroji nový datový disk o kapacitě alespoň 600 GB (v nejhorším případě Thin Disk). Jinak nebude možné později povést Failback! Dle doporučení firmy Microsoft, je vhodné připojit takový datový virtuální disk, kde VMDK soubor leží na rychlých discích odpovídajících konfiguraci RAID 10 a diskům typu SAS 10K.

clip_image016

Na další kartě zde musíte zvolit heslo pro instalovanou MySQL databázi a to konkrétně pro uživatele root. Poznámka: Součástí hesla musí být znak „_“, nebo „!“, nebo „@“, nebo „#“ ..atd. Toto heslo si dobře uschovejte, protože jej můžete později potřebovat například pro dump mysql databáze pro účely zálohy databází.

clip_image018

Tato karta je velmi důležitá. Pokud máte v úmyslu replikovat virtuální stroje z VMWARE do Azure, musíte zvolit možnost „Yes“.

clip_image020

Na další kartě vyberte, kam mají být instalovány sw komponenty management serveru. Můžete ponechat výchozí volbu. Tedy instalaci na disk C:

clip_image022

Dále vyberte virtuální síťový adaptér, přes který bude na Process server přicházet replikační komunikace. Tedy data přicházející z Agentů (Mobility service), což jsou data samotných virtuálních strojů replikovaných do Azure. Poznámka: Výchozí port je pak TCP 9443 a lze jej případně změnit. Nelze v tomto případě použít port TCP 443, neboť ten je rezervován pro komunikaci a replikaci dat do samotného Microsoft Azure.

clip_image024

Na další kartě vyberte pomocí tlačítka „Browse“ registračni klíč, který jsme již dříve stáhnuly.

clip_image026

Zde pak na předposlední kartě klikneme na tlačítko „Install“, pro instalaci všech potřebných komponent.

clip_image028

Po dokončení instalace je nutné provést restart virtuálního management serveru.

clip_image030

clip_image032

Ještě před ukončením samotného instalátoru dojde k vygenerování tzv. „Configuratiom Server Connection Passphrase“. Doporučuji si tento „kód“ uschovat. Bude zapotřebí ve chvíli, kdy například v Microsoft Azure budete přidávat/vytvářet další Process server. Pro spárování On-Premise Process serveru, resp. konfiguračního serveru a Process serveru/konfiguračního serveru v Azure budete potřebovat tento „kód“.

clip_image034

Pokud se následně přesuneme do původního Azure Portálu, pak v rámci vytvořeného Azure Site Recovery Vault s názvem TEST, v sekci „SERVERS“ – „CONFIGURATION SERVERS“ vidíme úspěšně registrovaný management server „ONPREMISEPS“.

clip_image036

Pokud se podíváme do vlastností samotného management serveru „ONPREMISEPS“, můžeme vidět řadu detailů, které se i průběžně mění. V sekci „proces servers“ vidíme seznam proces serverů. Je zde navíc server „ASRPS1“, což je právě proces server vytvořený v Azure a pomocí „kódu“ spárovaný s On-Premise process serverem. Ale to si ukážeme až později. Dále je zde v sekci „master target servers“ vidět seznam master target serverů. Alespoň jeden master target server musí existovat a být dostupný v On-Premise prostředí, jinak nebude možný Failback! Poznámka: V případě, že některá z komponent má problém, nebo není dostupná, změní se ukazatel ze statusu „Healthy“ na „Warning“, nebo „Error“. Přičemž kliknutím na tento ukazatel zobrazíte podrobnosti o stavu konkrétní komponenty. Stav se zjišťuje/mění v pravidelných intervalech jednou za 15 minut. Toto lze uspíšit kliknutím na tlačítko „REFRESH“, viz také dále v článku.

clip_image038

4. Nastavení Konfiguračního serveru

Poté co jsme úspěšně nainstalovaly všechny potřebné komponenty, je nutné ještě před samotnou replikací virtuálních strojů do Azure provést nastavení konfiguračního serveru. Najdeme a spustíme soubor „cspsconfigtool.exe“, který se standardně nachází v adresáři C:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystem\bin a spustíme.

clip_image040

Na poslední záložce máme možnost nastavit komunikační porty, například pro komunikaci s Mobility service.

clip_image042

Na první záložce pak spravujeme, nebo přidáváme účty pro přístupy. Je bezpodmínečně nutné zadat v této fázi minimálně účet s dostatečnými právy pro přístup k VMWARE ESXi serveru, nebo lépe k VMWARE vSphere. A dále účet s právy lokálního administrátora, který má práva na virtuální stroje, které chceme replikovat do Azure. Důvodem je pak automatická vzdálená instalace Mobility service pod tímto pověřením. Tedy klikněte na tlačítko „Add Account“ a přidejte příslušná pověření.

clip_image044

Zde pak ukázka přidání účtu s právy administrátora.

clip_image046

Je třeba si uvědomit, že zde zadané pověření nejsou nikdy replikovány do Azure. Pouze položka „Friendly name“. Zde provedené změny se standardně projeví v Azure až za 15 minut!

clip_image048

Pokud potřebujeme načítání dat, ať už pověření, nebo informací o management serveru urychlit a nechceme čekat 15 minut, můžeme vynutit načtení dat. Tedy v mém případě v ASR s názvem TEST, v sekci „SERVERS“ – „CONFIGURATION SERVERS“ pouze vyberu (neklikat na odkaz!) konkrétní management server.

clip_image050

A následně v dolní části okna kliknu na tlačítko „REFRESH“.

clip_image052

V sekci „JOBS“ se spustí úloha, která se pokouší načíst data z On-Premise management serveru „ONPREMISEPS“.

clip_image054

Azure Site Recovery – VMWARE(1)

Vytisknout E-mail

Jakub Heinz Datum zveřejnění: 30. 3. 2016 10:04 Zobrazeno: 751
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

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ěd 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/

 

clip_image002

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.

clip_image004 clip_image006

clip_image008 clip_image010

clip_image012 clip_image014

clip_image016 clip_image018

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

clip_image020

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

clip_image022 clip_image024

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

clip_image026

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.

clip_image028

clip_image030 clip_image032

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

clip_image034

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

clip_image036

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

clip_image038

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

clip_image040

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

clip_image042

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

clip_image035

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.

clip_image044

 

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"

Traffic Manager, Externí a Interní load balancer

Vytisknout E-mail

Jakub Heinz Datum zveřejnění: 10. 3. 2016 14:32 Zobrazeno: 1050
1 1 1 1 1 1 1 1 1 1 Rating 0.00 (0 Votes)

V rámci Microsoft Azure, existuje mnoho částí/komponent IaaS (Infrastructure as a Service) infrastruktury, které poskytují zajímavou funkcionalitu z hlediska nasazení širokého spektra různých aplikací. V tomto článku se budeme postupně zabývat nasazením Externího Load Balancingu, Interního Load balancingu a Traffic Managera. S tím, že nakonec společně skombinujeme Externí Load Balancing s Traffic Managerem. Všechny tyto „komponenty“ pak souvisejí se síťovou částí IaaS.

Vysvětlení pojmů:

(Poznámka: Postupy jsou platné pro virtuální stroje první generace)

VIP:

V případě, že vytváříme v rámci IaaS virtuální stroj, pak z hlediska nastavení síťové části vytvářeného virtuálního stroje můžeme rovnou v průvodci definovat tzv. VIP IP adresu a to buď Dynamickou, nebo Rezervovanou. V případě VIP se jedná o veřejnou (“internetovou”) IP adresu z rozsahu veřejných IP adres ve vlastnictví společnosti Microsoft. Přičemž výchozí volbou je Dynamická VIP. To tedy znamená, že tato veřejná IP adresa není přidělena natrvalo a může se změnit! Například pokud vypnete virtuální stroj do stavu „Stopped (deallocated)“ (tedy standardní způsob vypnutí) dojde k dealokování všech zdrojů, které v tu danou chvíli virtuální stroj spotřebovává a to včetně dealokování VIP IP Adresy. Pokud posléze virtuální stoj zapnete, je zde velká pravděpodobnost, že se VIP IP adresa změní. Což představuje komplikaci např. v případě, pokud jste přesměrovaly záznamy z vaší veřejné DNS zóny na tuto VIP IP adresu. Kupříkladu pokud jste záznam typu „A“ www.strankymojefirmy.cz přesměrovaly na tuto VIP. V případě, že vybereme volbu „Reserved“, dochází k rezervování dané veřejné IP adresy „napořád“. Aktuální výchozí limit pro konkrétní subskripci je pak 20 rezervovaných VIP IP adres. Dále je třeba upozornit na to, že si nelze rezervovat konkrétní veřejnou IP adresu. Vždy v případě rezervace veřejné IP adresy dojde k přidělení náhodné volné veřejné IP adresy, ale opravdu natrvalo. Také je třeba říci, že VIP IP adresa, i když se zadává při vytváření virtuálního stroje, je ve skutečnostech navázána na Cloud Service*. Cloud Service si lze představit jako jakýsi kontejner, ve kterém se nachází jeden a více virtuálních strojů. Zde je pak ceník veřejných VIP IP adres:

https://azure.microsoft.com/cs-cz/pricing/details/ip-addresses/

clip_image002

Jednoduché schéma asociované VIP IP adresy

Příklad rezervace VIP IP adresy pomocí PowerShellu

$reservedIP =

New-AzureReservedIP -ReservedIPName "Moje nova VIP" -Label "NovaVIP" -Location "West Europe"

Tedy na tomto příkladu jsem provedl vytvoření rezervace veřejné VIP IP adresy s označením „Moje nová VIP“ a to v lokalitě Západní Evropa.

V tomto příkladu pak za jednotlivé proměnné dosadíme hodnoty, přičemž nás zajímá v tuto chvíli parametr „–ReservedIPName”, který říká, že při vytváření virtuálního stroje bude použita toto konkrétní rezervovaná VIP.

New-AzureVM -ServiceName $serviceName -VNetName $vnetname -VMs $vm1 -ReservedIPName $reservedIP -Location $location

* … To se týká ovšem jen virtuálních strojů první generace. U virtuálních strojů druhé generace je to jinak!

DIP:

Jedná se o interní IP adresu související s danou vNET. Platí, že při vytváření virtuálního stroje je vhodné definovat interní síť tzv. vNET. Součástí vNET je i definice samotných subnetů. Pak v daném subnetu je „umístěn“ virtuální stroj a z daného subnetu pak získá interní IP adresu. IP adresu lze v tomto případě získat dvěma způsoby. Získáním IP adresy z DHCP serveru, který běží skrytý na pozadí a který není možné spravovat. Pak ale může nastat situace, že po opětovném spuštění virtuální ho stroje získá virtuální stroj jinou DIP. Což se například nehodí v případě, kdy v Azure běží doménový řadič (Active Directory) a zároveň je zde instalována služba DNS, na kterou se odkazují kvůli překladu interních DNS zón jiné virtuální stoje (dns klienti). Nebo druhá metoda „Static“, resp. pseudo static, kdy je IP adresa sice stále přidělována z DHCP serveru, ale formou rezervace dané IP adresy.

Je důležité říci, že je možné rezervovat interní IP adresu v daném subnetu až od IP adresy „xxx.xxx.xxx.4”. IP adresy xxx.xxx.xxx.1 až xxx.xxx.xxx.3 jsou rezervovány pro interní účely. Samozřejmě při vytváření interní Azure sítě vNET je možné sítě definovat pouze z rozsahů definovaných dle RFC. A není možné interně definovat síť z veřejného rozsahu IP adres.

clip_image003

Jednoduché schéma asociované DIP IP adresy

Příklad rychlého vytvoření virtuálního stroje, kde v tomto případě nás zajímá přepínač „Set-AzureStaticVNetIP -IPAddress 10.0.0.10“. Na tomto příkladu je vytvořen virtuální stroj v síti „TestVnet“, zařazen do subnetu „Subnet-1“ a dostane přidělenu preudo statickou interní IP adresu „10.0.0.10“.

New-AzureService -ServiceName TestService -Location “West Europe”

$image = Get-AzureVMImage|?{$_.ImageName -like “*RightImage-Windows-2012R2-x64*”}

New-AzureVMConfig -Name TestVM -InstanceSize Small -ImageName $image.ImageName `

| Add-AzureProvisioningConfig -Windows -AdminUsername adminuser -Password P@ssw0rd123

| Set-AzureSubnet –SubnetNames Subnet-1 `

| Set-AzureStaticVNetIP -IPAddress 10.0.0.10 `

| New-AzureVM -ServiceName “TestService” –VNetName TestVnet

EndPoint:

V případě VIP, je nutné navíc definovat pro daný virtuální stroj tzv. EndPoint. Neboli definici interního portu a externího portu, na který bude komunikace směrována, a která přichází na danou VIP.

Přičemž externí i interní port nemusí být stejný. Tedy například externí port může být TCP 80, ale interní port, na kterém například na virtuálním stroji poslouchá webová služba TCP 8080. Dále platí, že v případě, že existují v Cloud Service dva a více virtuální stroje, nemohou být tyto definice portů duplicitní. Tedy převedeno do praxe. Pokud je definován pro jeden virtuální stroj (Linux) SSH EndPoint na standardním externím portu TCP 22 a interním portu rovněž TCP 22, další stoj v Cloud Service nemůže použít tyto již obsazené porty, a to jak pro interní, tak pro externí definici portů.

clip_image005

Jednoduché schéma definice EndPointů

Příklad přidání SSH endpointu pro daný virtuální stroj v PowerShellu

$prot = "tcp"

$localport = 22

$pubport = 22

$endpointname = "SSH Daemon"

Get-AzureVM -Name $vmname -ServiceName $serviceName | Set-AzureEndpoint -Name $endpointname -Protocol $prot -LocalPort $localport -PublicPort $pubport | Update-AzureVM

Definice prostředí:

V tomto článku použiju již vytvořené existující virtuální stoje viz. obrázek a tabulka níže.

clip_image007

 

Název VM

Veřejné DNS jméno

Interní IP Adresa

Operační systém

susewesteu1

susewesteu.cloudapp.net

192.168.150.50

SUSE LINUX

susewesteu2

susewesteu.cloudapp.net

192.168.150.51

SUSE LINUX

susewestus1

susewestus.cloudapp.net

192.168.152.50

SUSE LINUX

Susewestus2

susewestus.cloudapp.net

192.168.152.51

SUSE LINUX

wrksusewesteu

wrksusewesteu.cloudapp.net

192.168.150.11

SUSE LINUX

wrksusewestus

wrksusewestus.cloudapp.net

192.168.152.11

SUSE LINUX

wrkswesteu

wrkswesteu.cloudapp.net

192.168.150.10

WINDOWS

wrkswestus

wrkswestus.cloudapp.net

192.168.152.10

WINDOWS

External Load Balancer

Co je externí load balancer? Jedná se o možnost vyvažovat/balancovat komunikaci na určitém externím portu a to na více jak jeden virtuální stroj. Tedy typickým příkladem je webová služba běžící na dvou a více virtuálních strojích a je zde potřeba tuto komunikaci, například na portu TCP 80 distribuovat na dva a více těchto webových serverů. Opět typickým důvodem je snaha vyřešit vysokou dostupnost webové služby. Pokud jeden ze serverů bude mít problém, komunikace je přesměrována automaticky na druhý server. Tedy Externí Load Balancer lze využít nejen pro případ Load Blancingu, ale také pro případ Failoveru.

clip_image009

Jednoduché schéma zapojení Externího load balanceru

Poznámka: Veškeré nastavení se děje skrze grafickou webovou konzoli pro zprávu Microsoft Azure a to na adrese – https://portal.azure.com

Přistoupíme tedy samotné praktické implementaci Externího Load Balanceru. Na obrázku vidíme v tomto případě vytvoření samotného virtuálního stroje první generace (Classic) „susewestus1“. Kde virtuálnímu stroji definuji rezervovanou VIP a presudo statickou DIP. A dále říkám, že tento virtuální stroj bude umístěn do virtuální sítě „susewestus“ a do subnetu „westus“ s rozsahem interních IP adres 192.168.152.4-192.168.152.254.

clip_image011

Zde pak zařazení virtuálního stroje do správného storage accountu. A což je důležitější, je zde ukázáno, že skutečně je virtuální stroj vytvořen v lokalitě West US.

clip_image013 clip_image015

Na obrázku vidíme v tomto případě vytvoření samotného virtuálního stroje první generace (Classic) „susewestus2“. Kde u virtuálnímu stroje použiji již existující stejnou rezervovanou VIP a jinou presudo statickou DIP. A dále říkám, že tento virtuální stroj bude umístěn do stejné virtuální sítě „susewestus“ a do stejného subnetu „westus“ s rozsahem interních IP adres 192.168.152.4-192.168.152.254.

clip_image017

Ve stejném duchu opět na obrázku vidíme vytvoření samotného virtuálního stroje první generace (Classic) „susewesteu1“. Kde virtuálnímu stroji definuji rezervovanou VIP a presudo statickou DIP. A dále říkám, že tento virtuální stroj bude umístěn do virtuální sítě „susewesteu“ a do subnetu „westeu“ s rozsahem interních IP adres 192.168.150.4-192.168.150.254.

clip_image019

A opět na obrázku vidíme vytvoření samotného virtuálního stroje první generace (Classic) „susewesteu2“. Kde u virtuálního stroje použiji již existující stejnou rezervovanou VIP a jinou presudo statickou DIP. A dále říkám, že tento virtuální stroj bude umístěn do stejné virtuální sítě „susewesteu“ a do subnetu „westeu“ s rozsahem interních IP adres 192.168.150.4-192.168.150.254.

clip_image021

Nyní, když už máme vytvořeny všechny čtyři virtuální stroje, je možné přistoupit k vytvoření a nastavení samotného Externího Load Balanceru. Tedy v rámci nastavení již existujícího virtuálního stroje klikneme na volbu „Load balanced sets“ a klikneme na tlačítko „Join“. Dále si vybíráme mezi mezi Public/Veřejným Load Balancerem a Internal/Interním Load Balancerem. Následně je nutné definovat parametry nastavení samotného Load Balanced setu a kliknout na volbu „Load balanced set“. Zde navíc nastavuje interní port, na kterém budou poslouchat virtuální stroje a to „Private port“.

clip_image023

Zde již vidíme samotné parametry, které lze nastavit. Jednak Load balanced set pojmenujeme. V ném případě „HTTP“. A dále vydefinujeme Public/Veřejný port, Probe protocol, Probe port. Zbylé nastavení můžeme ponechat nezměněno. Přičemž „Probe“ je „sonda“, která zjišťuje, zda jsou jednotlivé koncové body (virtuální stroje) stále dostupné. V případě, že sonda zjistí, že některý z koncových bodů není dostupný, automaticky komunikaci přesměruje na koncové body, které jsou aktuálně dostupné.

clip_image025

Na obrázku pak vidíte dva již vytvořené Load Balanced sety a to pro porty TCP 80 a TCP 443 a to pro virtuální stroj „susewesteu1“.

clip_image027

V případě dalšího virtuálního stroje, v tomto případě „susewesteu2“ stačí jen daný virtuální stroj zařadit do stejného Load balanced setu. Jak je vidět při dokončení vytváření Load balancing setu je možné definovat „Private/Privátní“ Port. To tedy znamená, že komunikace bude přicházet například na port TCP 80, ale bude interně na virtuální port přeměřována například na port TCP 81. Tedy platí, že „Public port“ a „Private Port“ nemusí být stejné.

clip_image029

Výsledek přidání virtuálního stroje „susewesteu2“ do společných Load balanced setů

clip_image031

Stejným způsobem pak vytvoříme load balanced set pro virtuální stroj „susewestus1“ a do tohoto load lanaced setu zařadíme rovněž virtuální stroj „susewesteu2“

clip_image033

Příklad vytvoření Externího Load balancingu pomocí PowerShellu. Platí, že ve společném Cloud Service musí existovat minimálně dva virtuální stroje, aby to mělo význam. A toto platí jen pro virtuální stroje první generace.

Get-AzureVM -ServiceName "wrksusewestus" -Name "wrksusewestus" | Add-AzureEndpoint -Name "HTTPS" -Protocol "TCP" -PublicPort 443 -LocalPort 443 -LBSetName "Web-Farm" -DefaultProbe | Update-AzureVM

Internal Load balancer

Interní Load Balancer funguje na stejném principu jako Externí load balancer. S tím rozdílem, že cílem je balancovat porty ne na veřejné IP adrese, ale na specifické interní IP adrese. Opět z hlediska praktického použití. Představte si situaci, kdy máte „více vrstvou/multi-tier“ aplikaci, kde webové servery mají nastaven External Load balanced set a interní aplikační servery mají nastavený interní load balanced set.

clip_image035

Jednoduché schéma zapojení Interního load balanceru

A opět postup přidání virtuálního serveru „susewestus1“ do interního load balanced setu což je takřka totožné jako v případě externího load balanced setu. Nejprve vybereme, že chceme vytvořit „Internal“ load balanced set a dále definuji název pro EndPoint a privátní port na kterém bude load balancing probíhat. V mém případě interní port TCP 8080. Dále je třeba nastavit zbylé parametry kliknutím na volbu „Load balanced set“.

clip_image037

Zde pak definujeme v jaké sítí a na jaké interní IP adrese bude load balancer naslouchat. V mém případě na IP adrese 192.168.152.100. Přičemž veřejný port, tedy TCP 8080 je stejný jako definovaný interní port.

clip_image039

Zde již vidíte v seznamu Load balanced setů nově vytvořený Internal load balanced set.

clip_image041

A opět stejný postup v případě dalších virtuálních strojů, které mají být součástí interního load balaced setu. Tento další virtuální stroj stačí přidat do již existujícího.

clip_image043

Zde pak výsledek přidání interního load balanced setu na virtuálním stroji „susewestus2“

clip_image045

Příklad vytvoření Internal Load Balanceru v PowerShellu

Načtení informací o virtuálním stroji do proměnné

$vm1 = Get-AzureVM -ServiceName wrksusewestus -Name wrksusewestus

Přidání interního load balanceru k již existujícímu virtuálnímu stroji

Add-AzureInternalLoadBalancer -ServiceName wrksusewestus -InternalLoadBalancerName "App01ILB" -SubnetName "westus" -StaticVNetIPAddress "192.168.152.200"

Přidání Ednpointu

$vm1 | Add-AzureEndpoint -Name "WEB" -Protocol tcp -LocalPort 80 `

-PublicPort 80 -LBSetName "weblbset" `

-InternalLoadBalancerName "App01ILB" `

-DefaultProbe

Update konfigurace virtuálního stroje

$vm1 | Update-AzureVM

Příklad odstranění EndPointu

$vm1 | Remove-AzureEndpoint -Name HTTP

Testování:

Na virtuálních stojích „susewestus1“ a „susewestus2“ již běží webový server APACHE. Ten je nastaven tak, že poslouchá na portu TCP 80 pro externí komunikaci a dále poslouchá na portu TCP 8080 pro interní komunikaci na síťi 192.168.152.0/24

Přihlásil jsem se na virtuální stoj „wrksusewestus“ který je rovněž zařazen do sítě 192.168.152.0/24. A zde spustil Firefox. Do pole pro zadání URL adresy jsem zadal http://192.168.152.100:8080, tedy IP adresu, na které poslouchá interní load balancer. Jak je z obrázku patrné, zobrazila se mi jednoduchá webová stránka. Pokud jsem pak provedl „refresh“ stránky, došlo k zobrazení této stránky jednou z virtuálního serveru „susewestus1“ a jednou z „susewestus2“. Tedy výsledkem je, že interní load balancer úspěšně funguje.

clip_image047

Pokračujeme tedy v nastavení interního load balanceru na virtuálních strojích v lokalitě WEST EUROPE.

Níže pak vidíte postup při přidání virtuálního serveru „susewesteu1“ do interního load balanced setu. Nejprve vybereme, že chceme vytvořit „Internal“ load balanced set a dále definuji název pro EndPoint a tentokrát privátní port na kterém bude load balancing probíhat. V mém případě interní port TCP 8080. Dále je třeba nastavit zbylé parametry kliknutím na volbu „Load balanced set“. Zde pak definujeme v jaké sítí a na jaké interní IP adrese bude load balancer naslouchat. V mém případě na IP adrese 192.168.150.100. Přičemž veřejný port, tedy TCP 8080 je stejný jako definovaný interní port.

clip_image049

Zde pak výsledek přidání interního load balanced setu na virtuálním stroji „susewesteu1“

clip_image051

Zde pak výsledek přidání interního load balanced setu na virtuálním stroji „susewesteu2“

clip_image053

Testování:

Na virtuálních stojích „susewesteu1“ a „susewesteu2“ již běží webový server APACHE. Ten je nastaven tak, že poslouchá na portu TCP 80 pro externí komunikaci a dále poslouchá na portu TCP 8080 pro interní komunikaci na síťi 192.168.150.0/24

Přihlásil jsem se na virtuální stoj „wrksusewestus“ který je rovněž zařazen do sítě 192.168.152.0/24. A zde spustil Firefox. Do pole pro zadání URL adresy jsem zadal http://192.168.150.100:8080, tedy IP adresu, na které poslouchá interní load balancer. Jak je z obrázku patrné, zobrazila se mi jednoduchá webová stránka. Pokud jsem pak provedl „refresh“ stránky, došlo k zobrazení této stránky jednou z virtuálního serveru „susewestus1“ a jednou z „susewestus2“. Tedy výsledkem je, že interní load balancer úspěšně funguje.

clip_image055

Příklad z praxe:

clip_image057

Jednoduché schéma ukázky implementace 3 tierové aplikace

Se souhlasem společnosti E.ON Česká republika, s.r.o. , zde uvádím příklad praktické implementace 3 tierové aplikace v Microsoft Azure za pomocí Interního i Externího load balancingu a běžící kompletně na Linuxovém operačním systému.

clip_image059

Traffic Manager

Traffic manager neprovádí například Traffic shaping, jak by se dalo i z jeho názvu očekávat, ale provádí globální a to slovo je opravdu velmi důležité, globální směrování určitého síťového provozu. Představme si situaci, kdy potřebujeme mít například dostupné webové stránky, nebo určitou aplikaci a to i v případě, že dojde ke kompletnímu selhání jednoho z datacenter firmy Microsoft. A bohužel to bude zrovna datacentrum, kde nám jako firmě běží naše kritické aplikace, nebo webové služby. A právě Traffic Manager slouží mimo jiné pro účely přesměrování síťového provozu i v těchto případech. Později pak popíšu, že metod jak lze provoz směrovat je více. Na obrázku níže je pak obecné schéma, na jakém je znázorněn princip fungování Traffic Managera. Zde v kombinaci s metodou přesměrování na základě času odezvy.

Tedy klient (dns klient) se doptá svého DNS serveru, ať mu vrátí název suseexperdays.trafficmanager.net. Nebo lépe v praxi si představte situaci, kdy z vašeho lokálního DNS serveru (např. u poskytovatele připojení, nebo tam kde dns zónu hostujete) je nastaven záznam typu ALIAS ve formátu www.mojefiremnistranka.cz, mířící na DNS záznam suseexperdays.trafficmanager.net. Lokální DNS server se zeptá Traffic Managera a ten provede vyhodnocení celé situace a to na základě zvolené metody směrování síťového provozu a na základě dostupnosti jednotlivých koncových bodů (virtuálních strojů). Následně lokálnímu DNS serveru vrátí informaci s plným názvem Cloud Service (jen v případě virtuálních strojů první generace).

Na obrátku je vidět, že klient se nachází v lokalitě WEST US. A zvolená metoda je na základě času odezvy. Proto Traffic Manager vrátí název Cloud Service odpovídající lokalitě/datovému centru firmy Microsoft - WEST US. Klient se pak následně napřímo pokusí spojit, v našem případě zobrazit webovou stránku.

clip_image061

Zde je pak ukázka jednotlivých webových stránek, tak jak se zobrazují. Každý server v každé lokalitě je zobrazen jak jinou barvou, tak je zobrazen název webového serveru, ze kterého jsou aktuálně stránky zobrazeny.

clip_image063 clip_image065

clip_image067 clip_image069

Vytvoření Traffic Managera:

V portálu klikněte na „+ New“, a vyberte „Networking“ – „Traffic Manager profile

clip_image071

Zde zadáme název budoucího Traffic Managera. Výsledné DNS jméno pak bude <name>.trafficmanager.net. Dále vybereme routovací metodu. Máme na výběr ze tří možností.

Performace“ – tato metoda zaručuje, že Traffic Manager na pozadí provádí měření dostupnosti jednotlivých Endpointů. Tedy měření rychlosti odezvy v milisekundách a udržuje si tabulku s naměřenými hodnotami. Rovněž si udržuje tabulku odezvy pro různé „siťové body“ po celém světě. Pokud zjistí, že klient, tedy jeho DNS požadavek přišel z určité sítě, porovná tabulky s odezvami a vrátí klientovy, resp. jeho lokálnímu DNS serveru název Cloud Service z lokality s nejmenší odezvou vůči jeho lokálnímu DNS serveru.

Weighted“ – tato metoda využívá principu Round Robin. Tedy Traffic Manager se pokouší rovnoměrně vyvažovat routování komunikace, tak aby se jednotlivé Endpointy neustále střídaly a to bez ohledu na dobu odezvy apod.

Priority“ – toto metoda využívá principu Failover, tedy Traffic Manager nabízí nejprve Endpointy s nastavenou vysokou prioritou a jen v případě, „selhání/nedostupnosti“ Endpointu s vysokou prioritou, je až poté nabídnut Endpoint z nižší prioritou.

My vybereme metodu „Performance“.

clip_image073

clip_image075

Zde pak naleznete detailní popis jednotlivých routovacích metod

https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-routing-methods/

Po vytvoření Traffic Managera je nutné přidat samotné Endpointy. Tedy klikneme na „All settings

clip_image077

Zde pak klikneme na volbu „Endpoints“ a dále klikneme na tlačítko „+ Add

clip_image079

Při definici samotného Endpointu máme rovněž na výběr z několika možností. Buď se může jednat o Endpoint v samotném Microsoft Azure, nebo se může jednat o externí Endpoint. My vybereme volbu „Azure endpoint“. Dále je zde možnost vybrat „Target resource type“. Máme na výběr buď „Cloud Service“ – pro virtuální stroje první generace, nebo „App Service“ – což jsou například samostatné webové, nebo aplikační servery. Typicky spravované pomocí Visual Studia. A nakonec „Public IP address“ – slouží pro přidání Endpointů souvisejících s virtuálními stroji druhé generace. V našem případě vybereme volbu „Cloud Service“

clip_image081 clip_image083

Následně klikneme na volbu „Target resource“ a je nám nabídnut seznam všech Cloud Service.

clip_image085

My přidáme Cloud Service s názvem „susewesteu“ a „susewestus“ a stejně tak pojmenujeme i nově vytvořené Endpointy.

clip_image087 clip_image089

Zde pak vidíme již přidané Endpointy.

clip_image091

Příklad vytvoření Traffic Manager profile pomocí PowerShellu.

$profile = New-AzureRmTrafficManagerProfile –Name TM01 -ResourceGroupName "Group-1" -TrafficRoutingMethod Performance -RelativeDnsName tm01 -Ttl 30 -MonitorProtocol TCP -MonitorPort 80 -MonitorPath "/"

Identifikace klasického Cloud Service, který chceme přidat jako Endpoint a uložení do proměnné

$cloudService = Get-AzureRmResource -ResourceName susewesteu -ResourceType "Microsoft.ClassicCompute/domainNames" -ResourceGroupName "Group-1"

Přidání samotného Endpointu do profilu Traffic Managera

New-AzureRmTrafficManagerEndpoint –Name susewesteu –ProfileName TM01 -ResourceGroupName "Group-1" –Type AzureEndpoints -TargetResourceId $cloudService.ResourceId –EndpointStatus Enabled

Testování:

Přihlásil jsem se na testovací stanici „wrksusewesteu“

clip_image093

Zde v prohlížeči Firefox jsem zadal jako URL adresu: http://mylocation.org. Služba správně určila, že přístupový „internetový“ bod, ze kterého se připojuji je město Amsterdam, tedy WEST EUROPE datové centrum firmy Microsoft.

clip_image095

Dále jsem do prohlížeče, resp. URL adresy zadal název mého Traffic Managera. Tedy http://suseexpertdays.trafficmanager.net. Jak je patrné díky zvolené metodě „Performance“ se mi zobrazila webová stránka nacházející se na webovém serveru v lokalitě WEST EUROPE.

clip_image097

Přihlásil jsem se na testovací stanici „wrksusewestus“

clip_image099

Zde v prohlížeči Firefox jsem zadal jako URL adresu: http://mylocation.org. Služba správně určila, že přístupový „internetový“ bod, ze kterého se připojuji je město San Francisco, tedy WEST US datové centrum firmy Microsoft.

clip_image101

Dále jsem do prohlížeče, resp. URL adresy zadal název mého Traffic Managera. Tedy http://suseexpertdays.trafficmanager.net. Jak je patrné díky zvolené metodě „Performance“ se mi zobrazila webová stránka nacházející se na webovém serveru v lokalitě WEST US.

clip_image103

Následně jsem provedl změnu metody routování z „Performance“ na „Weighted“

clip_image105

Dále jsem v prohlížeči do adresy URL opětovně zadal http://suseexpertdays.trafficmanager.net. Tentokrát se po vynuceném „refresh“ stránky zobrazují střídavě webové stránky ze všech webových serverů a to z obou lokalit.

clip_image107

clip_image109

Poznámka: V případě, pokud by stránky správně nefesreshovaly, je zde možnost jak situaci případně vyřešit. A to pustit v Linuxu konzoli a pomocí příkazu „sudo rcnscd restart“ situaci vyřešit.

clip_image111

Užitečné odkazy:

https://azure.microsoft.com/en-us/services/traffic-manager/

https://azure.microsoft.com/cs-cz/documentation/articles/traffic-manager-powershell-arm/

https://azure.microsoft.com/cs-cz/documentation/articles/load-balancer-get-started-internet-arm-ps/

https://azure.microsoft.com/cs-cz/documentation/articles/virtual-machines-load-balance/

Azure Recovery Services

Vytisknout E-mail

Josef Vágner Datum zveřejnění: 1. 3. 2016 10:00 Zobrazeno: 880
Azure Recovery Services - 4.0 out of 5 based on 1 vote
1 1 1 1 1 1 1 1 1 1 Rating 4.00 (1 Vote)

Zřejmě jste se již někdy setkali s pojmem Azure Recovery Services a asi víte, že pod ně spadají služby Azure Backup a Azure Site Recovery, které vám umožní v Azure jednoduše zprovoznit Backup-as-a-Service a Disaster Recovery-as-a-Service. Pojďme si podívat, o co se vlastně jedná, pro koho je služba vhodná a také se zaměříme na novinky, které se objevily na přelomu tohoto roku.

Azure Backup

Pojďme se nejprve podívat na Azure Backup a jeho možnosti zálohovat systémy on-premise, tak i virtuální stroje, běžící v cloudu Azure. Azure Backup je v podstatě odlehčená varianta DPM (Data Protection Manager, který je součástí System Center suity) a který je určen především pro scénář zálohování lokálních dat do cloudu pro SMB zákazníky, nemající licenci na DPM či System Center. Druhý scénář je určen spíše pro Enterprise zákazníky, kteří se chtějí zbavit zálohování na pásky a zálohy si chtějí odkládat do cloudu nebo kteří si potřebují ochránit virtuální stroje, které provozují v Azure.

Pokud si nainstalujeme agenta Azure Backupu přímo na server, který chceme zálohovat, jedná se o scénář zálohování souborového serveru, kdy se záloha ukládá nejprve na disk tohoto serveru a poté jeho kopie do cloudu. Druhá (nová) možnost je, že se agent Azure Backupu nainstaluje na samostatný server (tzv. Azure Backup server), který potom svým prostřednictvím komunikuje s ostatními chráněnými servery, na kterých je instalován agent Backupu (je to v podstatě agent DPM). V tomto scénáři lze zálohovat z disku na disk (v on-premise), nebo z disku na disk a poté jde další záloha do cloudu (D-D-C). Lze zálohovat jak fyzické tak i virtuální servery (a to jak Hyper-V, tak i VMware) a workloady pro Exchange, SQL Server či SharePoint. Mohou být chráněny všechny podporované virtuální stroje na daném virtualizačním serveru, tj. i linuxové VM. Pod Windows lze zajistit konzistenci dat na aplikační úrovni, pod Linuxem na úrovni souborové konzistence dat.

Alternativně lze (po instalaci agenta Azure Backupu na DPM server) ukládat kopie záloh do Azure pro zákazníky, používající System Center Data Protection Manager.

clip_image002

Obr.1: Zálohování on-premise serverů pomocí Azure Backupu.

Podrobnější seznámení a postupy pro nasazení najdete na Get started with Azure Backup (https://azure.microsoft.com/en-us/trial/get-started-backup/) nebo Preparing to back up workloads using Azure Backup Server (https://azure.microsoft.com/en-us/documentation/articles/backup-azure-microsoft-azure-backup/)

Pokud provozujete hybridní infrastrukturu a potřebujete chránit i své virtuální stroje běžící v prostředí Azure, lze i je jednoduše a efektivně chránit pomocí Azure Backupu. Tím své prostředí zabezpečíte před ztrátou či poničením dat, ochráníte před náhodným smazáním VM (i administrátor je jen člověk a může se utnout J) resp. lze takto jednoduše vyřešit kopírování VM. Azure Backup musí (logicky) ukládat zálohy do stejného regionu, kde běží vlastní VM. Jsou podporovány VM až se 16 datovými disky (plus disk pro OS), lze zálohovat běžící VM stejně tak jako v off-line módu.

clip_image004

Obr.2: Zálohování virtuálních strojů v Azure

Pozn.: Zatím není možné zálohovat stroje, běžící na tzv. premium storage (=SSD), ani šifrované VM (ale pracuje se na tom).

Pro sizing můžete použít kalkulačku Storage capacity planner (https://gallery.technet.microsoft.com/Azure-Backup-Storage-a46d7e33).

Vše lze pochopitelně automatizovat pomocí PowerShellu. Více viz Back up Azure virtual machines (https://azure.microsoft.com/cs-cz/documentation/articles/backup-azure-vms/) nebo Deploy and manage backup to Azure for Windows Server/Windows Client using PowerShell (https://azure.microsoft.com/en-us/documentation/articles/backup-client-automation/).

Zálohy jsou zabezpečeny (po předchozí komprimaci, která dokáže snížit objem dat o 50-70 procent) šifrováním AES 256. Šifrovací klíč se vygeneruje na lokálním stroji a je chráněn tzv. PassPhrase (PEK) o délce 16-1024 znaků. Klíče si musí správce pečlivě uschovávat (u sebe nebo v Azure Key Vault – viz např. Get started with Azure Key Vault - https://azure.microsoft.com/en-us/documentation/articles/key-vault-get-started/). Takto zašifrovaná data jsou poté přenesena pomocí protokolu HTTPS do cloudového úložiště a zde zůstávají vložena v nezměněné (zašifrované) podobě. Azure Backup vyhovuje normě ISO 27001 (Information Security Management) a také řadě dalších jako je HIPAA aj., více viz. Azure Trust Center.

Zbývá odpovědět, jak že se vlastně Azure Backup licencuje. I zde nastala menší změna – poplatky se skládají ze dvou částí, jednak je potřeba mít licencovány všechny chráněné instance pomocí licence na Azure Backup, a jednak se platí standardní poplatek za využité místo na Azure Storage. Licenční poplatek se liší podle velikosti instance (do 50 GB je to 5 USD/měsíc, 50-500 GB za 10 USD/měsíc, pro instance větší než 500 GB navíc inkrement po 500 GB opět za 10 USD). A co se počítá do oné velikosti instance? Je to buď celková velikost souborů a složek (pro Windows klienta či server), nebo celková velikost instance, databáze a obsahové (content) farmy pro aplikační servery, případně celková velikost VHD disků pro virtuální stroj. Cena za Azure Storage se samozřejmě liší podle toho, zda jsme si vybrali pro ukládání dat do LRS (3 kopie dat) nebo GRS (3+3 kopií dat ve dvou regionech). Pozor, tuto volbu nelze později změnit, je nutno si předem vybrat konkrétní typ již při vytváření úložiště. Příjemné je, že za Azure Backup již dále neplatíte žádné další poplatky za obnovování dat, transakce či přenosy dat.

Azure Site Recovery

Druhou službou v rámci Azure Recovery Services je služba Azure Site Recovery (ASR). Ta umožňuje zajistit automatizované přepnutí (failover) na záložní datové centrum resp. po odstranění původní závady automatizovat návrat zpět do primárního datového centra (failback). Takovéto přepnutí je možné docílit v řádu minut a tím radikálně snížit RTO (Recovery Time Objective), neboli dobu, za kterou lze po výpadku pokračovat v práci a rovněž snížit RPO (Recovery Point Objective), tj. o kolik dat přijdeme.

Azure Site Recovery umí pracovat ve dvou režimech – jako koordinační jednotka mezi dvěma zákaznickými datovými centry nebo (pokud zákazník nemá k dispozici záložní datové centrum) Azure může být tímto záložním datovým centrem, do kterého se systémy po výpadku přepnou. Takto lze ochránit virtuální servery s Hyper-V, VMware či fyzické servery.

Dvě datová centra a ASR

Pojďme si nejprve projít první variantu se dvěma DC:

V případě Hyper-V serveru musí být obě datová centra (primární i záložní) vybavena System Center Virtual Machine Managerem, který komunikuje se službou Site Recovery. Datová centra jsou spolu propojena (LAN či VPN) a tímto kanálem probíhá vlastní replikování dat na úrovni hostů.

clip_image005

Obr.3: Azure Site Recovery pro dvě datová centra s Hyper-V

Replikace dokonce může být realizována na úrovni SAN storage, která zabezpečí takřka nulové RPO (NetApp, HP 3PAR, EMC VMAX – viz. http://social.technet.microsoft.com/wiki/contents/articles/28317.deploying-azure-site-recovery-with-vmm-and-san-supported-storage-arrays.aspx). ASR potom orchestruje vlastní přepínání (failover/failback) pomocí protokolu HTTPS.

clip_image006

Obr.4: Dvě DC s Hyper-V a replikací na úrovni storage

Poněkud jiná situace je v případě, kdy v obou datových centrech je virtualizaci řešena pomocí VMware. V tomto případě je replikace mezi datovými centry realizována technologií Scout, která díky pomocným serverům zajišťuje komunikaci mezi primárním datovým centrem (s VMware a/nebo fyzickými servery) a záložním datovým centrem (s VMware). Tato replikace zajišťuje takřka nulové RPO. Kanál mezi Azure a datovými centry slouží pouze ke stažení agenta a zajišťování stavu licencí.

clip_image007

Obr.5: ASR a dvě datová centra s VMware

Jedno datové centrum a Azure

Druhý typ scénáře pokrývá situaci, kdy zákazník disponuje pouze jedním datovým centrem, ale přesto potřebuje zajistit nízké hodnoty RTO/RPO. Zde Azure zároveň poskytuje i službu záložního datového centra, do kterého při failoveru překlápějí zákaznické aplikace.

První varianta je pro Hyper-V virtualizaci (ať již s nebo bez VMM), kdy se změny VM replikují pomocí protokolu HTTPS do příslušných Azure Storage kontejnerů, které v případě výpadku slouží jako virtuální disky pro VM, které se rozběhnou v prostředí Azure. Teprve po failoveru se v Azure nastartují virtuální stroje a řídící logika na ně přesměruje klienty. Varianta bez VMM je určena buď pro SMB zákazníky nebo pro pobočková řešení větších zákazníků (mající VMM v centru).

clip_image008

Obr.6: ASR a replikace Hyper-V do Azure

Novější varianta ASR pro VMware (nebo fyzický server) s jedním datovým centrem se proti původní zjednodušila tím, že v Azure je již připravena kompletní infrastruktura a na straně on-premise lze použít jediný pomocný server, který zajistí veškerou komunikaci pro replikování dat i řízení přepínací logiky.

clip_image009

Obr.7: Vylepšené ASR pro replikaci VMware do Azure

ASR umí zajistit i aplikační konzistenci dat (AD, IIS, RDS, VDI, FS, SQL, SharePoint, Exchange, Oracle, SAP). SQL Sever a jeho technologie HA/DR se skvěle doplňují s ASR, SQL AlwaysOn Availability Groups jsou synchronizovány s recovery plány ASR (viz Protect SQL Server with SQL Server disaster recovery and Azure Site Recovery - https://azure.microsoft.com/en-us/documentation/articles/site-recovery-sql/#integration-with-sql-alwayson-to-azure resp. Configure AlwaysOn Availability Groups in Azure VM (GUI) - https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-alwayson-availability-groups-gui/). Oracle je na tom podobně díky využití jeho technologie Oracle Data Guard, která si rozumí i s ASR (viz Configuring Oracle Data Guard for Azure - https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-configuring-oracle-data-guard/). Exchange Server je již sám o sobě připraven na vysokou dostupnost, jeho DAG je možné snadno integrovat s ASR. Více informací najdete např. v článku What workloads can you protect with Azure Site Recovery? (https://azure.microsoft.com/en-us/documentation/articles/site-recovery-workload/).

clip_image010

Obr.8: ASR a SQL – replikace do Azure

Pro správný chod ASR je zapotřebí zajistit dostatečnou kapacitu připojení k Internetu (VPN) nebo přímého připojení pomocí zařízení ExpressRoute. Kapacitu lze určit pomocí Azure Site Recovery Capacity Planner (https://gallery.technet.microsoft.com/Azure-Recovery-Capacity-d01dc40e). Informace o integraci s ExpressRoute lze najít na odkazu ExpressRoute + ASR = Efficient DR solution (https://blogs.technet.microsoft.com/virtualization/2014/07/20/expressroute-asr-efficient-dr-solution/). Objem přenosu dat lze podstatně snížit (až o 3/4) použitím vhodného WAN traffic shaperu, např. SteelHead: Optimizing Azure Site Recovery (ASR) with Riverbed® SteelHead™ WAN Optimizers (https://www.microsoft.com/en-us/download/details.aspx?id=44571).

Licencování ASR se samozřejmě liší podle toho, zda funguje ve scénáři s jedním nebo dvěma datovými centry. Pro dvě DC je cena licence samozřejmě nižší než v případě jednoho centra, kdy ještě navíc musíme počítat s cenou za spotřebovaný storage a cenu za běh VM v případě failoveru. Je příjemné, že prvních 31 dnů máte ASR k dispozici zdarma.

Při vyžívání služeb Azure Recovery Services musí mít zákazník k dispozici buď vlastní předplatné na Azure nebo využívá služeb Azure od partnera, který má uzavřenu s Microsoftem smlouvu v rámci tzv. Cloud Solution Programu (a má tím možnost přeprodávat služby Azure třetí straně). První varianta bude asi častější pro větší zákazníky nebo firmy, které již do cloudu investovali. Druhá bude asi zajímavější pro menší firmy, pro které není výhodné uzavírat předplatné s variantou Pay-as-you-go či se vázat k odběru služeb v určité hodnotě. Při využívání partnerského modelu totiž zákazník platí měsíčně jen za to, co využívá a nemusí se nijak zavazovat k určité velikosti odběru.

Závěr

Jak je vidět, služby Backup-as-a-Service a/nebo DR-as-a-Service se dají poměrně jednoduše a relativně levně nasadit i u zákazníků, kteří předtím o takovémto řešení ani neuvažovali. Výhodou je především široká škála scénářů, které pokrývají a rychlost a snadnost nasazení. Důležitým aspektem je i podpora většiny důležitých aplikací. Pro řadu zákazníků též může být značným pozitivem průběžné placení za užívání služby bez potřeby velké počáteční investice.

Slovníček pojmů
Disaster Recovery

Pojem Disaster Recovery znamená obnovu po havárii. Přesněji řečeno, jedná se o předem připravený scénář, který vede k obnově infrastruktury po nastalé (někdy jen simulované) havárii – ať již fatální havárii hardware nebo software, problému způsobeného lidským faktorem, živelnou katastrofou případně jiným selháním.

Příprava správného scénáře Disaster Recovery není triviální, protože by mělo dojít i k ověření jeho správnosti obnovou celé infrastruktury v jiné lokalitě. Vysoká náročnost takovéto (byť zkušební) obnovy (zejména z pohledu finančních i lidských prostředků) často vede k podcenění významu nebo dokonce k absenci takového scénáře.

Business Continuity

Sada aplikovaných procesů v organizaci, které vedou ke snížení nebo eliminaci následků havárie jednotlivých komponent IT infrastruktury či infrastruktury jako celku na fungování organizace.

V posledních letech se zejména díky možnostem virtualizace stala v podnicích fenoménem a díky cenové dostupnosti jejích výhod již dnes dokážou využívat i podniky z oblasti malého a středního podnikání.

Na druhé straně se však s rostoucím počtem pořizovaných dat objevuje jiné riziko v oblasti business continuity, kterým je doba trvání zálohovacích procedur a v návaznosti na to i doba obnovy zálohovaných dat (tzv. RTO). Stále větší důraz je kladen na jiné geografické umístění záloh (tj. mimo hlavní lokalitu) a následnou možnost rychlého zprovoznění infrastruktury i v případě havárie hlavní lokality.

Retenční politika

Nastavením správné retenční politiky chráníte vaši organizaci před ztrátou dat, která by konvenční záloha dávno nenávratně přepsala.

Retenční politika se objevila společně s příchodem snapshotů a deduplikačních metod do oblasti zálohování. „Retenční politikou“ nebo též „politikou rentence dat“ stanovujeme počet záloh daného stáří, které se v zálohovacích archivech udržují.

Retenční politika chrání organizaci před ztrátou dat, u kterých se tato ztráta nebo poškození projeví až poté, co proběhne standardní zálohovací procedura (např. full-backup) a v konvenčním zálohovacím režimu by byly nenávratně ztraceny přepsáním staré zálohy novou, která již tato data neobsahuje.

Můžete takto stanovit například politiku zachovávat 24 hodinových záloh, dále 7 denních, 52 týdenních, 2 roční. Díky tomu jste schopni obnovit data z předchozích 24 hodin s přesností jedné hodiny, data až 7 předchozích dnů s granularitou den atd.

Politiku retence dat by měla definovat organizace nebo by o ní měl mít povědomí management, aby byl zaručen soulad s právními požadavky a potřebami.

RPO – Recovery Point Objective

RPO popisuje stáří dat, která mám k dispozici v pravidelné záloze. Havárie v průběhu dne může znamenat nutnost obnovy z noční zálohy. Např. pravidelné noční zálohování znamená RPO v řádu hodin. Pokud nastane v průběhu dne havárie, kvůli níž je nutná kompletní obnova dat z noční zálohy, dojde ke ztrátě dat pořízených v průběhu celého dne.

Moderní trendy zálohování v IT proto zkracují RPO až do řádu několika minut. Pracují na principu snapshotů, tedy rozdílových změn od poslední zálohy. Tím zkracují dobu nutnou pro zálohování (přenáší se jen změněné datové bloky) a mohou si proto dovolit spouštění zálohy několikrát za den nebo dokonce i několikrát za hodinu.

RTO – Recovery Time Objective

RTO popisuje dobu nutnou k obnovení dat ze zálohy. Nevhodně nastavené procesy mohou znamenat délku obnovy několik hodin i dnů.

RTO vyjadřuje dobu obnovení dat nebo systémů ze zálohy. V oblasti zálohování se jedná o zásadní kritérium, které je společně s RPO směrodatným ukazatelem, jak jsou nastaveny procesy Disaster Recovery a jaké mohou mít dopady na fungování organizace v případě výpadku.

Standardní obnova dat ze zálohy může trvat několik hodin i dnů – administrátor musí najít správný zdroj zálohy (např. pásku) a data ze zdroje načíst a rozbalit do požadovaného umístění. Moderní trendy zálohování a přípravy na obnovu (snapshoty, virtual stand-by) zkracují RTO téměř na nulu, tj. v případě havárie lze spustit systémy okamžitě na jiném HW, případně lze připojit sdílený nebo virtuální disk s předchozí zálohou téměř okamžitě.

PowerShell Remoting

Vytisknout E-mail

Josef Vágner Datum zveřejnění: 24. 2. 2016 10:03 Zobrazeno: 1084
PowerShell Remoting - 5.0 out of 5 based on 1 vote
1 1 1 1 1 1 1 1 1 1 Rating 5.00 (1 Vote)

PowerShell je velmi silný a efektivní způsob skriptování, který se postupně rozšířil nejen pro ovládání všech novějších produktů Microsoftu, ale i produktů od jiných výrobců (https://en.wikipedia.org/wiki/Windows_PowerShell#Application_support). Od verze 2.0 lze PowerShell používat i pro vzdálené volání powershellových příkazů. Tzv. remoting umožňuje vzdálená volání procedur z lokálního počítače včetně paralelního zpracování dotazů. Veškerá komunikace je šifrovaná.

Remoting lze iniciovat příkazem

Invoke-Command…

Druhou možností je připojit se ke vzdálené konzoli příkazem

Enter-PSSession –ComputerName <jméno vzdáleného počítače>

První verze ještě v některých příkazech nepoužívaly čistý remoting založený na WS-Management (implementován pomocí WinRM), ale pro některé parametry (např. -ComputerName) se volaly RPC nebo DCOM procedury. Od verze 3.0 se jedná o čisté volání webových služeb. Od Windows Serveru 2012 je na serveru již PowerShell Remoting automaticky zapnut. Po správnou funkčnost je ale nutno ještě nastavit několik dalších věcí. Tato nastavení se budou lišit podle toho, zda je lokální počítač ve stejné doméně, jako je vzdálený server, nebo zda se bude jednat o počítač, který je začleněn jen v pracovní skupině.

Pozn.: Více o remotingu např. ve free e-knize Secrets of PowerShell Remoting https://www.penflip.com/powershellorg/secrets-of-powershell-remoting.

Počítače v doméně

Pokud jsou oba počítače v doméně, je práce na zprovoznění remotingu poměrně jednoduché. Stačí iniciovat příkaz

Enable-PSRemoting [–Force]

Ten vám spustí službu WinRM a nastaví její automatické spouštění. Dále nastaví listener, aby poslouchal na všech IP adresách a nastaví na firewallu vyjímky pro WS-Management (ale jen pro protokol HTTP).

Pozn. Powershellový příkaz Enable-PSRemoting je v zhruba ekvivalentní příkazu winrm quickconfig.

Většinu těchto činností lze nastavovat pomocí skupinové politiky. Viz nastavení Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service, Computer Configuration\Policies\Windows Settings\Security Settings\System Services a Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security.

Počítač v pracovní skupině

HTTP

Méně bezpečný, ale jednodušší způsob, je využít protokolu HTTP (přenos se šifruje jen symetrickým klíčem). V tomto případě musíme nejprve zaktualizovat seznam TrustedHosts. Nejprve se přesvědčíme, zda jsou zde již některé počítače vyjmenovány, a to konkrétně příkazem

Get-Item –Path WSMan:\localhost\Client\TrustedHosts

clip_image001

Příkazem

Set-Item –Path WSMan\localhost\Client\TrustedHosts –Value "<název vzdáleného počítače>"

přidáme další počítač(e). Případně pro ulehčení (alespoň na počátku nebo při testech) lze zadat hvězdičku, čímž povolíme remoting pro veškeré počítače. To ale pořád ještě nebude stačit. Pokud je síťová karta nastavena na Public, musíme na vzdáleném serveru spustit příkaz

Enable-PSRemoting -SkipNetworkProfileCheck [-Force]

clip_image002

čímž obejdeme případné chybové hlášení (The WinRM client cannot process the request…).

Poslední věcí, kterou musíme udělat, tentokráte na lokálním počítači, je přidání IP adres(y) vzdáleného server(ů) do seznamu TrustedHosts (analogicky jako jsme udělali u vzdáleného serveru), případně zde lze zadat hvězdičku.

Použijeme opět příkaz

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "<IP adresa>" [-Force]

clip_image004

Aby se změny promítly, restartujte službu WinRM

Restart-Service WinRm

Nakonec i zde spusťte příkaz

Enable-PSRemoting

HTTPS

Druhý (bezpečnější) způsob je využít pro přenos protokolu HTTPS. V tuto chvíli se navíc zašifruje komunikace SSL pomocí asymetrického klíče z certifikátu a zároveň se ověří identita obou koncových bodů. Pro tento scénář je ale nutnost použít SSL certifikátu. Samozřejmě lze využít i komerčních certifikátů, ale pro testovací účely ho asi pokaždé nebudeme mít k dispozici. V tom případě lze využít i tzv. self-signed certifikátů, které si můžeme sami (a zdarma) vytvořit. Nemusíte se obávat ani složitého procesu instalace různých pomocných SDK či toolkitů, neboť PowerShell to od verze 4 umí sám. Stačí použít příkazu

$Cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName "<FQDN vzdáleného počítače>"

clip_image006

Můžeme si to zkontrolovat v MMC konzoli s add-inem pro certifikáty ve složce Personal\Certificates. Vyexportujeme si certifikát do souboru, buď přímo z MMC konzole nebo powershellovým příkazem

Export-Certificate -Cert $Cert -FilePath C:\temp\<název certifikátu>

clip_image007

Poté spustíme příkaz

Enable-PSRemoting -SkipNetworkProfileCheck [-Force]

čímž eliminujeme případné problémy se sítí typu Public. Příkaz také spustí listener, ale pouze pro HTTP. Zkontrolovat si to můžeme příkazem

dir wsman:\localhost\listener

Pokud chcete elminovat HTTP listener, můžete to udělat příkazem

Get-ChildItem WSMan:\Localhost\listener | Where -Property Keys -eq "Transport=HTTP" | Remove-Item -Recurse

Případně lze příkazem

Remove-Item -Path WSMan:\Localhost\listener\listener* -Recurse

odstranit veškeré listenery.

Přidání HTTPS listeneru uskutečníte příkazem

New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $Cert.Thumbprint [–Force]

clip_image009

Poslední věc, kterou je nutno udělat, je přidání vyjímek pro firewall pro HTTPS

New-NetFirewallRule -DisplayName "Windows Remote Management (HTTPS-In)" -Name "Windows Remote Management (HTTPS-In)" -Profile Any -LocalPort 5986 -Protocol TCP

clip_image011

Případně lze pro zvýšení bezpečnosti odstranit vyjímku na firewallu pro HTTP komunikaci

Disable-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)"

Nyní se přesuneme na stranu klienta, kde naimportujeme na server vygenerovaný certifikát, buď pomocí MMC (do složky Trusted Root Certification Authorities\Certificates) nebo příkazem PowerShellu

Import-Certificate -Filepath "C:\temp\<název certifikátu>" -CertStoreLocation "Cert:\LocalMachine\Root"

clip_image013

Pozn. Pokud použijeme komerční certifikát, stačí namísto předchozích příkazů spustit příkaz

Set-WSManQuickConfig –UseSSL

Remoting

Nyní lze vyzkoušet remoting příkazem

Enter-PSSession -ComputerName <název serveru> [-UseSSL] -Credential (Get-Credential)

clip_image015

nebo

Invoke-Command -ComputerName <název serveru> [-UseSSL] -ScriptBlock {Get-Process} -Credential (Get-Credential)

Pro název serveru můžete použít jeho FQDN nebo IP adresu. V druhém případě musíte samozřejmě přidat do souboru hosts dvojici IP adresy a název server. Nebo pomocí PowerShellu příkazem

Add-Content $Env:SystemRoot\system32\drivers\etc\hosts "<IP adresa> <název serveru>"

Pozn.: Pokud se budete připojovat k VM v Azure, nezapomeňte zde ještě povolit příchozí port 5985 pro HTTP resp. 5986 pro HTTPS komunikaci (pro PowerShell verze 4.0 a vyšší).

clip_image017

Pozn.: Pokud potřebujete jednoduše přemisťovat soubory z nebo do Azure, můžete využít free utility od Veeamu FastSCP for Microsoft Azure (https://www.veeam.com/fastscp-azure-vm.html), která využívá pro komunikaci PowerShell remotingu. Na rozdíl od RDP nemá limit 2 GB na soubor, dá se pravidelně spouštět včetně pre- a post- skriptů atd. Aplikace je ale jen pro 64-bitový OS.

clip_image019

clip_image021

clip_image023

Happy remoting!

Strana 1 z 3

Přihlašovací formulář