Serverová konsolidace a virtualizace

Transkript

1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Serverová konsolidace a virtualizace Diplomová práce Autor: Bc. Marek Hlaváč Informační technologie a management Vedoucí práce: Ing. Vladimír Beneš, Ph.D. Praha duben, 2014

2 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Českých Budějovicích dne 25. dubna 2014 Marek Hlaváč

3 Poděkování: Děkuji vedoucímu diplomové práce Ing. Vladimíru Benešovi, Ph.D. za vstřícnost a cenné rady, kterými mi byl nápomocen.

4 Anotace Diplomová práce analyzuje jádro podnikové IT infrastruktury, navrhuje řešení serverové konsolidace a virtualizace tohoto jádra a následně popisuje implementaci vytvořeného návrhu. Součástí práce je řešení konkrétních implementačních problémů, popis virtualizační platformy Hyper-V a popis stěžejních prvků a nástrojů týkajících se Hyper-V. Závěrem této diplomové práce je infrastruktura zhodnocena a jsou navrhnuta možná infrastrukturní zlepšení, která by mohla být předmětem budoucích investic. Klíčová slova: virtualizace, serverová konsolidace, Hyper-V, Windows Server 2012 Annotation This Diploma thesis analyzes the core of the company's IT infrastructure, designs solution of the server consolidation and virtualization of this core and subsequently describes the implementation of the created design. The thesis contains solutions of specific implementation problems, describtion of the Hyper-V virtualization platform and a description of crucial elements and tools regarding the Hyper-V. In the conclusion of this thesis, the infrastructure is evaluated and possible infrastructure improvements, which could be the subject of future investments, are proposed. Key words: virtualization, server consolidation, Hyper-V, Windows Server 2012

5 Obsah Úvod Virtualizace Výhody virtualizace Testování Simulace Škálovatelnost Typy virtualizace Hypervisor nad OS (Type 2 hypervisor) Hypervisor nad hardwarem (Type 1 hypervisor) Hyper-V Architektura Hyper-V Komponenty Hyper-V Analýza původní IT infrastruktury Hardware Software Velké množství fyzických serverů Požadavky na novou IT infrastrukturu Návrh nové infrastruktury Hardware Software Koncepce Realizace nové IT infrastruktury Konfigurace úložišť Základní nastavení Konfigurace sítě Konfigurace iscsi Další nastavení Konfigurace serverů System Setup Připojení úložiště

6 5.2.3 Instalace a konfigurace OS Instalace a konfigurace Hyper-V Antivirus Migrace serverů Konfigurace virtuálních strojů Příprava šablon Migrace pomocí nástroje Disk2vhd Zapnutí, vypnutí, UPS Obecně o Hyper-V Migrace za provozu (live migration) Replikace Nastavení replikace virtuálního stroje Virtuální disky Typy virtuálních disků Operace s virtuálními disky Export/Import virtuálního počítače Snímky/kontrolní body Komplikace a nedostatky Replikace Řešení RDS shadowing Řešení Problémy s úložištěm Serverové disky JBODy Nástroje PowerShell Základní nastavení Užitečné příkazy (cmdlety) Zálohování Volume Shadow Copy Service (VSS) Sledování prostředků (nástroj Windows)

7 9 Zhodnocení nové infrastruktury Výkonnostní (CPU, RAM, IOPS) CPU Paměť Úložiště Konceptuální Možná infrastrukturní zlepšení Investice 1: Ochrana dat Investice 2: Datová úložiště Investice 3: Rozšíření infrastruktury Failover Cluster Závěr Seznam použité literatury Seznam použitých obrázků

8 Úvod Svět informačních technologií je oblast, ve které střídá jeden trend druhý a vývoj jde ohromným tempem kupředu. Některé technologie jsou záhy zapomenuté, další setrvávají a v průběhu času se transformují. Jiné technologie jsou zapomenuty, aby se s odstupem času vrátily zpět. Toto je také případ virtualizace. Počátky virtualizace sahají až do poloviny šedesátých let, do dob mainframů od IBM. Již v této době několik počítačů využívalo virtualizaci. Šlo zejména o stroje IBM M44/44X, kde bylo možné spouštět více virtuálních strojů za použití hardwarové a softwarové abstrakce. Zde můžeme mluvit o počátcích virtualizace. V tomto historickém okamžiku se také zrodil výraz virtuální stroj, který přetrval dodnes.[[1]] Asi nikoho by tehdy nenapadlo, že tento koncept přežije a po desítkách let se vrátí v reinkarnované podobě zpět, a to v ohromném měřítku. Virtualizace a cloud computing vládnou dnešnímu binárnímu světu. Zaplavují datacentra, serverovny a setkáme se s nimi i v prostředí desktopů či u mobilních zařízení. Tyto technologie mají své nesporné výhody, tudíž se stávají den ode dne využívanější. Čím dál tím více společností (od velkých mezinárodních korporací až po malé podniky) si tyto koncepty začíná osvojovat. V této práci se budu zabývat pouze virtualizací, avšak vzhledem k faktu, že je virtualizace základním kamenem cloud computingu, lehce se dotknu i tohoto tématu. Virtualizací se budu zabývat zejména ve spojení s malými a středně velkými podniky. I pro tuto sféru je virtualizace velkým přínosem. Avšak každé firemní prostředí je specifické, a tudíž nelze úplně generalizovat. V této práci se budu zabývat všeobecnými principy virtualizace a dále pak zejména virtualizační technologií vyvinutou společností Microsoft, a to technologií Hyper-V. Analyzuji jádro podnikové IT infrastruktury jedné konkrétní společnosti, navrhnu vhodné řešení serverové konsolidace za pomoci virtualizace a toto řešení implementuji. Popíši jednotlivé kroky implementace a uvedu také některé stěžejní technologie spojené s tímto virtualizačním řešením. Též budou popsány případné komplikace při implementaci a jejich řešení. Přechod k virtuální infrastruktuře, jež tato práce obsahuje, byl v praxi realizován v jedné nejmenované společnosti. Celý proces trval řádově několik měsíců, zahrnoval testování a vyžadoval také spolupráci několika společností, které v této firmě převedly jimi nasazený specializovaný software ze starých serverů a zastaralých operačních systémů do nového virtualizovaného prostředí na nové operační systémy. Jak jsem již uvedl, proces zahrnoval také testování, a to poměrně komplexní. Byla testována jak konfigurace 8

9 dílčích prvků této infrastruktury, tak infrastruktura jako celek. Cílem bylo definování optimální konfigurace, která by umožnila dosáhnout co nejvyššího výkonu a stability s využitím dostupných prostředků. Konfigurace měla také splňovat specifika této firmy. Testování probíhalo zejména v laboratorním prostředí, přičemž se optimální konfigurace zdokumentovala a podle této dokumentace se implementovalo řešení pro produkční nasazení. Některé virtuální servery s nově nasazenými systémy bylo také nutné otestovat nejdříve na vzorku uživatelů a až po tomto úspěšném testování byl realizován přechod veškerých uživatelů těchto systémů v rámci celé společnosti na nové virtualizované servery. Závěrem této práce zhodnotím nový stav jádra IT infrastruktury a navrhnu možná zlepšení, která by mohla být předmětem budoucích investic. Návrh serverové konsolidace na bázi virtualizace v této společnosti je samozřejmě omezen určitým rozpočtem. Zajisté by se dala navrhnout lepší, sofistikovanější a v rámci udržení vysoké dostupnosti systémů či bezpečnosti dat lepší řešení, avšak toto je dáno výší investic, které je konkrétní podnik ochotný vynaložit. Samozřejmě, že tuto výši také v určité míře ovlivňuje předmět podnikání dané společnosti. Společnost, jejíž chod je na výpočetních technologiích zcela závislý, zpravidla investuje do IT infrastruktury více, aby co nejlépe zajistila zmíněnou vysokou dostupnost svých systémů a nastavila dostatečnou úroveň bezpečnosti dat. Pomalé zotavení podnikových systémů po havárii či ztráta dat může být pro podnik, který je vysoce závislý na výpočetních systémech, likvidační záležitostí. 9

10 1 Virtualizace Koncept virtualizace způsobil v prostředí informačních technologií převrat a mnoho lidí by si již svět jedniček a nul bez této technologie nedokázalo představit. Tato kapitola bude malým úvodem do virtualizace a také úvodem do technologie Hyper-V, která je stěžejním prvkem této práce. 1.1 Výhody virtualizace Výhody virtualizace budou částečně nastíněny v části Analýza původní IT infrastruktury v souvislosti s analýzou, proto bych tuto kapitolu pojal spíše jako doplňující, ačkoliv zmíněné kapitole předchází. Výhody virtualizace jsou poměrně značné, také se na tuto problematiku dá nahlížet z mnoha úhlů, tudíž zde zmíním pouze některé aspekty Testování Testování je velmi důležitým procesem ať již například při vývoji softwaru, či při implementaci nejrůznějších systémů. Tomuto procesu je virtualizace obrovským přínosem, jelikož ho výrazným způsobem zjednodušuje. Pomocí virtualizace je možné například testovat software na několika operačních systémech najednou za použití jediného fyzického stroje. Virtualizace také umožňuje ukládat stavy virtuálních strojů (vytvářet snímky), tudíž lze za normálních okolností nevratné kroky velmi rychle vracet zpět, a mnoho dalšího Simulace Ve virtuálním prostředí je možné vytvářet celé počítačové sítě. S minimálními náklady a úsilím je možné testovat například nejrůznější síťové nástroje či nasimulovat určitý segment sítě. Virtualizace otevírá i v tomto směru nové možnosti Škálovatelnost Jednou z největších výhod virtualizace je škálovatelnost. V případě potřeby lze výkon virtuálního stroje adekvátně přizpůsobit požadavkům a navýšit množství alokovaných hardwarových prostředků. Zde se dostávám ke zmíněnému cloudu. Koncept virtualizace umožňuje například využívat některou z cloudových služeb a platit pouze za spotřebovaný výkon, který je variabilní dle požadavků. Není nutné periodicky platit konstantní částku za 10

11 určité množství dostupných hardwarových prostředků ať již byly využity, či ne. Je možné mít dostupné teoreticky neomezené hardwarové zdroje a platit pouze za prostředky, které byly opravdu využité. 1.2 Typy virtualizace Na virtualizaci lze nahlížet z různých úhlů a rozlišovat různé druhy virtualizací. Avšak za základní rozdělení lze považovat rozdělení na základě umístění hypervisoru. Hypervisor či VMM (Virtual Machine Monitor) je, dá se říci, srdcem virtualizační architektury. Toto rozdělení je opravdu rozdělení na nejnižší úrovni. Mým úmyslem je pouze demonstrovat, na jaké úrovni Hyper-V pracuje Hypervisor nad OS (Type 2 hypervisor) Tento typ hypervisoru se využívá spíše na uživatelských počítačích a není vhodný pro produkční nasazení. Jak je patrné z obrázku, hypervisor pracuje až nad operačním systémem a nemá přímý přístup k hardwaru. Hypervisor je instalován na operačním systému jako běžná aplikace, a tudíž virtuální stroje na tomto VMM běžící mají komplikovanější přístup k hardwaru. Veškerý přístup virtuálních strojů k hardwaru je prováděn skrze hypervisor a operační systém, tudíž je zde určitá režie. Virtualizační řešení tohoto typu jsou například: Windows Virtual PC, Oracle VM VirtualBox, VMware Workstation a další. Obrázek 1: Type 2 hypervisor Zdroj: autor 11

12 1.2.2 Hypervisor nad hardwarem (Type 1 hypervisor) Hypervisor tohoto typu běží ve vrstvě přímo nad hardwarem a kontroluje přístup k tomuto hardwaru. Veškerá správa (management) běží na stejné úrovni jako virtuální stroje. Tento typ hypervisoru je vhodnější pro produkční nasazení. Degradace výkonu virtuálních strojů běžících nad tímto hypervisorem je výrazně menší než v předchozím případě. Obrázek 2: Type 1 hypervisor Zdroj: autor Hypervisorem tohoto typu je například hypervisor ESXi od společnosti VMware či Hyper-V od Microsofu, kterým se budu v této práci zabývat. Dalším produktem na bázi hypervisoru prvního typu je Citrix XenServer. 1.3 Hyper-V Hyper-V je hypervisor od společnosti Microsoft. První verze tohoto hypervisoru byla uvedena s produktem Windows Server Druhá verze Hyper-V byla součástí Windows Server 2008 R2. Některá vylepšení přinesl Service Pack Windows Server 2008 R2 SP1 a třetí verze Hyper-V spatřila světlo světa spolu s Windows Server Tato poslední verze může být v několika ohledech nazývána revoluční. Hypervisor od Microsoftu však nemusí být zakoupen pouze s produkty Microsoft Windows, je také dostupný samostatně zdarma jako takzvaný Microsoft Hyper-V Server. Tato edice je, jak již bylo řečeno, zcela zdarma a obsahuje pouze hypervisor spolu s potřebnými nástroji. Součástí produktu Microsoft Hyper-V Server není grafické rozhraní. 12

13 1.3.1 Architektura Hyper-V Při klasickém nasazení operačního systému Windows jsou instrukce rozdělené do čtyř privilegovaných úrovní přístupu v procesoru zvaných Rings. Nejvíce privilegovaný je Ring 0 s přímým přístupem k hardwaru, kde sídlí Windows Kernel. Ring 3 je zodpovědný za hostování uživatelské úrovně, kde běží většina běžných aplikací, a má nejméně privilegovaný přístup. [[1]] Obrázek 3: Windows before Hyper-V Zdroj: [1] V okamžiku, kdy je Hyper-V instalováno, potřebuje vyšší oprávnění, než nabízí Ring 0. Také musí mít výhrazený přístup k hardwaru. Toto je možné skrze nové schopnosti procesorů vytvořených Intelem a AMD, které jsou navývány Intel-VT a AMD-V. Tyto technologie umožní vytvoření pátého kruhu zvaného Ring -1. Hyper-V využívá tento kruh k přidání svého hypervisoru. Tímto má vyšší privilegia, běží pod kruhem zvaný Ring 0 a kontroluje veškerý přístup k fyzickým komponentám, jak je patrné z diagramu: [[1]] 13

14 Obrázek 4: Windows after Hyper-V Zdroj: [1] Architektura operačního systému utrpí několik změn po instalaci Hyper-V. Po prvním bootování soubor zavaděče operačního systému (winload.exe) zkontroluje procesor, který je používán, a zavede obraz hypervisoru do Ring -1 (využívá soubory Hvix64.exe pro procesory Intel a Hvax64.exe pro procesory AMD). Poté je inicializován operační systém Windows Server nad hypervisorem a každý virtuální stroj, který běží vedle něj. [[1]] Komponenty Hyper-V Hyper-V obsahuje mnoho komponent. Na následujících řádcích budou vysvětleny alespoň nejdůležitější z nich. Tyto komponenty jsou zobrazeny na ilustračním obrázku níže. Hypervisor Malý Hyper-V hypervisor (necelých 20 MB) je zodpovědný za obsluhu, oddělení a řízení přístupu všech oddílů/částí (partitions). Také má na starosti izolovat jednotlivé oddíly (partitions) od sebe se zajištěním vysoké bezpečnosti a spolehlivosti. [[1]] 14

15 Oddíly (Partitions) Pokud server disponuje hypervisorem Hyper-V, operuje hostující operační systém na stejné úrovni jako virtuální stroje. Hostující operační systém a virtuální stroje mají stejný přístup a práva k hypervisoru a oba tyto celky jsou v terminologii virtualizace nazývány oddíly (partitions). Avšak hostující operační systém na rozdíl od hostovaného virtuálního stroje disponuje nástroji správy, a tudíž je nazýván parent partition nebo management OS a virtuální stroje jsou nazývány child partitions či guests OS.[[1]] Virtualization stack Tvorba a obsluha virtuálních strojů je prováděna několika virtuálními zařízeními a softwarovými komponentami zvanými virtualization stack, které jsou spouštěny v prostředí parent partition. Tyto komponenty spolupracují s hypervisorem. VSP (Virtualization Service Provider) je softwarová komponenta, která v parent partition kontroluje vstupně výstupní operace na základě požadavků virtuálních strojů. Sběrnice VMBus (Virtual Machine Bus) tvoří komunikační kanál mezi poskytovateli VSP a klienty VSC (Virtualization Service Clients). VSP využívá sběrnici VMBus ke komunikaci s child partitions s cílem uspokojit požadavky na přístup k hardwaru skrze syntetické ovladače běžící v child partitions. Pro každý virtuální stroj, který je spuštěn, je vytvořen takzvaný Worker Process v parent partition. Worker process a VMMS (Virtual Machine Management Service) jsou komponenty, které umožňují prostřednictvím parent partition vytvářet, spouštět, zastavovat, ukládat či mazat virtuální stroje. Tyto úlohy jsou koordinovány ovladačem virtuální infrastruktury (VID - Virtual Infrastructure Driver), který obsluhuje komunikaci mezi parent a child partitions. [[1]] Enlightened vs emulated Komunikace mezi oddíly a hypervisorem je tvořena takzvanými Hypercalls. Tato volání zajišťují přístup virtuálních strojů k hardwaru prostřednictvím komponent, jako jsou VID, VMBus, VSCs a VSPs. Tyto mechanismy jsou dostupné skrze integrační sluţby (IC - Integration Components). Zmíněné komponenty mají některé operační systémy zabudované přímo v jádře. Virtuální stroje běžící na takovýchto operačních systémech nazýváme Enlightened VMs (Virtual Machines). Operační systémy, které těmito komponentami nedisponují, trpí značnou degradací výkonu a omezeným přístupem 15

16 k hardwaru. V případě takovýchto OS, operační systém správy (parent partition) působí jako most, zachytává komunikaci těchto virtuálních strojů a emuluje volání zvaná Hypercalls.[[1]] Obrázek 5: Hyper-V Architecture Zdroj: [1] 16

17 2 Analýza původní IT infrastruktury Rozhodnutí o inovaci jádra počítačové infrastruktury předcházela důkladná analýza stávajících systémů. Tato analýza se týkala jak operačních systémů a aplikací na těchto systémech běžících, tak hardwaru, u nějž byl sledován zejména stav, stáří a výkon. Tato analýza však nemusela být příliš rozsáhlá a důkladná vzhledem k faktu, že celé infrastrukturní jádro bylo na první pohled zastaralé a nevyhovující. Stav jádra IT infrastruktury daného podniku byl nevyhovující z několika hledisek, a proto bylo rozhodnuto infrastrukturní jádro inovovat. Důvody, které vedly k tomuto kroku, jsou uvedeny v této kapitole. 2.1 Hardware Většina serverů byla nevyhovující již vzhledem ke svému stáří. Pokud společnost provozuje na serverech služby kritické pro její podnikání a je na nich vysoce závislá, mělo by se haváriím předcházet a ať už servery, tak jiné prvky IT infrastruktury včetně prvků síťových po určitém časovém intervalu (který je daný typem zařízení, politikou společnosti či zárukou výrobce) měnit a předcházet jejich selhání. Většina serverů je na hranici toho intervalu, tudíž již z tohoto pohledu začal být stav jádra infrastruktury nevyhovující. Dalším důvodem byl nevyhovující výkon. V průběhu několika let se společnost rozrostla, přijala nové zaměstnance využívající systémy běžící na firemních serverech, některé aplikace postoupily o několik verzí kupředu a zvýšily se jejich hardwarové požadavky a také došlo k významnému nárůstu dat, která je třeba uchovávat a nad nimiž se často provádí složité hardwarově náročné operace. V souvislosti s uchováváním dat je také nutné podotknout, že pevné disky v serverech byly staré a jejich AFR (Annualized Failure Rate) dosahovalo vysokých hodnot. 2.2 Software Operační systémy běžící na podnikových serverech byly zastaralé a měly svá omezení. Nemálo z těchto serverů využívalo pouze 32bitové operační systémy, které mají poměrně významná omezení, a to zejména z pohledu paměti RAM. Tato omezení byla značně nevyhovující ať už z pohledu nárůstu hardwarových nároků určitých programů, tak z pohledu 17

18 nárůstu uživatelů na 32bitových terminálových serverech. Dalším faktorem byla končící nebo již žádná podpora operačních systémů na těchto stávajících serverech nainstalovaných. Vzhledem k jejich stáří bylo také poměrně problematické nakupovat nová periferní zařízení, která by tyto systémy podporovala. 2.3 Velké mnoţství fyzických serverů Velké množství fyzických serverů má několik nevýhod. Více serverů spotřebuje větší množství elektrické energie a také vyprodukuje více tepla. V serverovně je nutné udržovat adekvátní konstantní teplotu, tudíž více vyprodukovaného tepla se odrazí také v nákladech na provoz klimatizace. Jelikož je nutné ošetřit také případný výpadek elektrické energie, více serverů využije více záložních zdrojů UPS, z čehož plynou další náklady. Virtualizací lze tyto náklady snížit a také přispět ke zmenšení uhlíkové stopy. Virtualizace z globálního hlediska má poměrně velký vliv na zmenšení této stopy. Vezmeme-li v úvahu, že z pohledu dřívější koncepce byl jeden server opravdu jeden server a dle best practice by měl mít jeden server pouze jednu roli (toto je nutné brát s rezervou, samozřejmě záleží na konkrétním prostředí a dalších faktorech), velké množství serverů bylo využito pouze z několika procent z hlediska výkonu. Virtualizační platforma nabízí obrovské zefektivnění využití strojového času jednotlivých fyzických serverů. Nyní je možné využívat strojový čas jednoho fyzického serveru mnoha servery virtuálními. Virtualizace tudíž v celosvětovém měřítku znamená ohromné množství uspořené elektrické energie. Z pohledu monitoringu a správy je též jednodušší spravovat infrastrukturu virtuálních serverů než serverů fyzických, a to hned z několika hledisek. Mezi stěžejní benefity lze zařadit například lehkou přenositelnost virtuálních strojů, škálovatelnost či údržbu. Také správa je jednodušší, jelikož je možné servery spravovat z jednoho centrálního bodu (například skrze Správce technologie Hyper-V ). Výhodou je také například možnost replikací či jednoduché zálohování celých virtuálních serverů, jejich relativně jednoduché obnovení ze zálohy a mnoho dalšího. 18

19 3 Poţadavky na novou IT infrastrukturu Požadavky na novou IT infrastrukturu nebyly příliš omezené z technického hlediska, avšak poměrně značné omezení se týkalo hlediska finančního. Cílem bylo navrhnout finančně akceptovatelné řešení, které zajistí jistý stupeň redundance hardwarových prvků, aby bylo možné pokračovat v provozu (nikoliv však bez dočasného výpadku) v případě selhání jednoho z prvků této infrastruktury, a též bylo cílem navrhnout řešení, které zajistí určitý stupeň ochrany dat. Bohužel vedení společnosti nechtělo investovat částku, která by zajistila vysokou dostupnost systémů v případě výpadku jakéhokoliv hardwarového prvku. Jsou si vědomi rizika a akceptují fakt, že vzhledem k nedostatečným investicím do jádra IT infrastruktury může nastat situace, kdy dojde ke ztrátě dat a systémy budou po určitou dobu nedostupné. Cílem tudíž bylo navrhnout a realizovat takové řešení, které by co nejvíce minimalizovalo možnost ztráty dat v případě havárie a též by v takovémto případě minimalizovalo dobu nedostupnosti systémů důležitých pro chod společnosti. V požadavcích na nové řešení byl kromě finančního limitu dán také nárok na řešení vycházející ze softwarových produktů společnosti Microsoft. Je také nutné zajistit dostatečnou kapacitu úložišť pro firemní data s možností tuto kapacitu dle potřeb navýšit. Jelikož pokrok v oblasti informačních technologií nabral poměrně značné tempo, je vhodné navrhnout infrastrukturní jádro způsobem, který by umožnil v případě potřeby toto jádro posílit jak z pohledu výpočetní síly, tak z pohledu datových úložišť. 19

20 4 Návrh nové infrastruktury Dle specifikovaných požadavků na novou IT infrastrukturu jádra počítačové sítě byl sestaven návrh řešení. Tento návrh zahrnuje konkrétní hardware, software a koncepci. 4.1 Hardware Návrh zahrnuje dva výkonné servery DELL a dvě síťová úložiště od společnosti QNAP Systems. Následující řádky obsahují základní parametry těchto hardwarových prvků. SERVERY (dva identické stroje) název a typ cpu paměť řadič pevné disky síťové adaptéry DELL PowerEdge R720 2x Intel Xeon E GHz, 20 MB cache 192 GB (DDR3, 1600 MHz) PERC H710 INTEGRATED RAID CONTROLLER 2x Seagate Savvio 15K.3 300GB, 2,5", 15k RPM, SAS II, 64 MB cache Intel Ethernet 10G 2P X540-t (2 porty) Broadcom 5720 QP 1Gb NETWORK DAUGHTER CARD (4 porty) DATOVÁ ÚLOŢIŠTĚ (dva identické stroje) název a typ cpu paměť pevné disky síťové adaptéry QNAP TS-EC1279U-RP Quad Core Intel Xeon E v2 Processor 3.2 GHz 8 GB DDR3 ECC RAM 12x WD RE 4TB 3,5", 7200 RPM, SATA 6.0Gb/s, 64 MB Cache 2 x Gigabit RJ-45 Ethernet port 1 x dual-port 10Gb network card 20

21 4.2 Software Dle zadání vychází řešení z produktů společnosti Microsoft. Servery DELL budou pro svůj chod využívat Windows Server 2012 Datacenter. Na tomto nosném systému bude instalována pouze jedna serverová role, a to Hyper-V. Pro virtuální servery budou na základě licence Datacenter použity systémy Windows Server 2012 Standard. Při použití licence Datacenter na hostujícím serveru je možné na tomto serveru instalovat a provozovat neomezené množství virtuálních strojů se systémem Windows Server Je však nutné zakoupit správný počet licencí Windows Server 2012 Datacenter. Tento počet se odvíjí od počtu procesorů tohoto serveru. Vzhledem k faktu, že DELL PowerEdge R720 disponuje dvěma procesory, bylo nutné zakoupit dvě licence Windows Server 2012 Datacenter. Pro každý server jednu. Pokud by však server DELL PowerEdge R720 disponoval více než dvěma procesory, nebyla by jedna licence Windows Server 2012 Datacenter dostačující. Kromě licencí operačních systémů bylo nutné zakoupit také takzvané klientské přístupové licence zvané RDS CAL. Tyto licence umožňují určitému počtu uživatelů přistoupit k terminálovému serveru. PŘEHLED ZAKOUPENÝCH LICENCÍ Licence Windows Server 2012 Datacenter Windows Server 2012 CAL (Client Access License) (tyto licence umožní uživatelům přistupovat k terminálovému serveru) pozn.: Windows Server 2012 CAL jsou použitelné také pro Windows Server 2012 R2 Počet 2x 300x 4.3 Koncepce Dva servery DELL budou zaujímat roli hostů pro virtuální servery. Výkon těchto serverů je dostatečně vysoký, aby v případě selhání jednoho serveru mohl druhý server poskytnout prostředí pro běh virtuálních strojů tohoto hosta. Samozřejmě, že nebude možné dosáhnout téhož výkonu jako za normálních okolností se dvěma fyzickými servery, avšak pro havarijní režim bude výkon jednoho stroje dostačující. V havarijní situaci bude také 21

22 možné odstavit některé servery, které nejsou kritické pro běh společnosti jako například server WSUS (Windows Server Update Services). Řešení infrastrukturního jádra je koncipováno způsobem znázorněným na obrázku. Dva servery budou mezi sebou propojeny 10Gbit ethernetem a stejně tak budou připojena úložiště k serverům. Tímto lze dosáhnout vysoké rychlosti při replikaci virtuálních serverů z jednoho úložiště na druhé (ačkoliv musím podotknout, že 10Gbit linka k úložištím QNAP je příliš, jelikož takovou rychlostí tato úložiště zajisté nebudou schopna data ukládat či číst). Kapacitu datových úložišť bylo nutné patřičně naddimenzovat, jelikož je nezbytné, aby byla schopná pojmout virtuální disky veškerých virtuálních serverů, ačkoliv pouze polovina z nich bude běžících. Druhou polovinu budou tvořit repliky virtuálních serverů z druhého úložiště. Úložiště budou mít také zapojena po jednom rozhraní do lokální sítě pro potřeby managementu. V každém ze serverů bude kromě 10Gbitové síťové karty po čtyřech rozhraních, která budou seskupena v jedno. Tato rozhraní budou tvořit spojení do lokální sítě. Na obrázku je také vidět jeden z doménových řadičů, který je nutný pro správný chod veškerých služeb. Obrázek 6: Koncepce Zdroj: autor 22

23 Každý server a datové úložiště budou mít také svůj záložní zdroj energie v podobě zařízení UPS. Tyto záložní zdroje budou sloužit pouze jako prostředky, které zajistí bezpečné vypnutí serverů a virtuálních serverů na těchto hostech běžících, pokud do jedné minuty od výpadku nedojde k obnově dodávky elektrické energie. Fyzické servery budou nakonfigurovány tak, že i po obnově této dodávky zůstanou vypnuté. Toto zajistí, že pokud by docházelo k opakovaným výpadkům v elektrické síti, nemůže dojít k neregulérnímu vypnutí serverů, které by případně mohlo způsobit například ztrátu či narušení některých dat. 23

24 5 Realizace nové IT infrastruktury Pokud by tato práce někomu posloužila byť jen jako vodítko při implementaci podobného či totožného řešení, rozhodně bych doporučil nejprve instalaci a následné testování v laboratorním prostředí včetně simulace nejrůznějších možných komplikací či havárií. Po tomto testování je nutné uvést vše do továrního (výchozího) nastavení a vše nakonfigurovat a nainstalovat znovu. Také bych doporučil instalaci a konfiguraci zdokumentovat. Tato dokumentace může být následně při správě velmi důležitým opěrným bodem. Může být též velice užitečná, pokud by bylo žádoucí stávající prvky rozmnožit či na jiném místě použít totožné řešení. 5.1 Konfigurace úloţišť Jako disková úložiště byla zvolena již zmíněná zařízení od společnosti QNAP Systems. Nyní popíši konfiguraci, která byla zvolena pro obě tato úložiště Základní nastavení Společnost QNAP Systems poskytuje na svých webových stránkách nástroj zvaný QNAP Finder. Tento nástroj umí vyhledávat zařízení QNAP a také skrze něj lze přistoupit k prvotní konfiguraci. Již po spuštění detekuje nové nenakonfigurované zařízení a po odsouhlasení konfigurace se spustí průvodce v internetovém prohlížeči. Tento průvodce umožňuje také automatickou konfiguraci, ale v tomto případě je nutné spustit konfiguraci manuální. V průběhu počáteční konfigurace prostřednictvím tohoto průvodce je nutné nakonfigurovat přihlašovací údaje k webovému rozhraní, údaje týkající se data a času, síťové rozhraní, služby a také diskové pole. Toto pole bylo sestaveno ze všech dvanácti pevných disků a byl zvolen RAID 10. V tomto konfiguračním průvodci je nastavování diskového pole velice jednoduché. Dále se již úložiště konfiguruje ve webovém rozhraní na nově nastavené IP adrese Konfigurace sítě Úložiště jsou osazena dvěma dvouportovými gigabitovými síťovými kartami a jednou dvouportovou 10Gbit ethernetovou síťovou kartou. Na této síťové kartě byl nastaven Jumbo 24

25 Frame na Samozřejmostí je nastavení IP adres na konkrétních síťových adaptérech. Také je žádoucí na síťových adaptérech určených pro management vypnout službu iscsi Konfigurace iscsi Dále je nutné nastavit iscsi Target. V příslušné nabídce byla povolena tato služba a byl vytvořen iscsi Target spolu s iscsi LUNem. Tento LUN byl vytvořen přes celé RAID 10 diskové pole. Je možné se setkat s tvrzeními, že je optimálnější vytvořit několik menších LUNů místo jednoho velkého, avšak toto má své nevýhody. Zejména jde o fakt, že při vytvoření více menších LUNů dochází k neefektivnímu využívání prostoru diskového úložiště. Na každém LUNu je totiž nutné nechat adekvátně velký volný prostor, čímž v případě vytváření několika takovýchto LUNů lze přijít o poměrně velké množství diskového prostoru. V případě, jako je tento, kdy LUN slouží k uchovávání virtuálních disků virtualizovaných serverů, a zvláště pak v případě, kdy se navíc využívá replikace či snímků virtuálních serverů respektive kontrolních bodů, je často nutné vyhradit poměrně velké množství diskového prostoru. Pokud je toto opomenuto, může nedostatek místa na LUNech způsobit zastavení všech serverů na těchto LUNech běžících. Při využívání zmíněných technologií (replikace, snímky virtuálních strojů) lze často pozorovat velký nárůst dat, zvláště pak u serverů, u nichž dochází k častým velkým změnám v datech. Proč je tomu tak, bude vysvětleno později Další nastavení Zajisté je žádoucí nakonfigurovat SMTP server a zasílání varovných zpráv či upozornění prostřednictvím u. Též bylo nakonfigurováno zařízení UPS. Zde je nutné stanovit adekvátně dlouhou dobu, za kterou se má úložiště vypnout. Nesmí se stát, aby se úložiště vypnulo dříve než server. Posledním krokem je vypnutí veškerých nepotřebných služeb. Poměrně mnoho v tomto případě nepotřebných služeb je ve výchozím nastavení zapnutých. Samozřejmě je nutné úložiště po připojení prostřednictvím iscsi inicializovat (GPT), vytvořit diskový oddíl a naformátovat (NTFS). 5.2 Konfigurace serverů S konfigurací by se mělo začínat odspodu, tudíž od BIOSu. Prvním krokem by mělo být načtení výchozího či optimalizovaného nastavení. Toto pravidlo bylo aplikováno na 25

26 veškerá nastavení obsažená v základním systémovém nastavení BIOSu (System Setup). Další konfigurace záleží již na konkrétním scénáři. V tomto případě nebyla nutná žádná další konfigurace System Setup Následující řádky se týkají základní konfigurace serverů v systémovém nastavení ( System Setup ). Do prostředí System Setup lze vstoupit stisknutím příslušné klávesy po zapnutí serveru. V tomto rozhraní byly nakonfigurovány následující komponenty: idrac (integrated Dell Remote Access Controller) Nakoupené servery obsahují takzvaný idrac ve verzi Express. idrac umožňuje vzdálené připojení k serveru prostřednictvím HTTPS a získání celkového přehledu o stavu a kondici jednotlivých hardwarových prvků, o teplotách, napětí a podobně. idrac je možné nakonfigurovat jednoduchým způsobem, a to vybráním síťové karty, nastavením IP adresy, masky, brány, DNS serveru a nakonec zadáním uživatelského jména a hesla. idrac je možné také provozovat za příplatek ve verzi Enterprise. Tato verze používá vyhrazené síťové rozhraní a nabízí oproti verzi Express o mnoho více. Například umožňuje prostřednictvím webového rozhraní na dálku nainstalovat operační systém z ISO obrazu. Integrated RAID Controller (DELL PERC H710 MINI) Součástí serveru DELL PowerEdge R720 je řadič DELL PERC H710 MINI. Tento řadič byl nakonfigurován také z prostředí System Setup. Opět bylo vhodné před konfigurací vymazat veškerá nastavení. Následně byl vytvořen nový virtuální disk, který sestává ze dvou disků Seagate Savvio (viz kapitola 4.1 Hardware) v RAID 1. Dále byly nastaveny pouze dva parametry, a to Strip Element Size a Write Policy. Strip Element Size Problematika týkající se optimalizace výkonu diskových polí, s níž souvisí také parametr Strip Element Size, je poměrně komplikovaná a mimo rozsah této práce. V tomto případě byla na základě testování a zkušeností zvolena hodnota 256KB. Write Policy Write Back Tento mód funguje následujícím způsobem: V okamžiku, kdy jsou odeslána řadiči data k zapsání na disk, řadič tato data zapíše nejprve do cache a odešle 26

27 zpět potvrzení, že data byla úspěšně zapsána. Toto chování přináší určité výkonové zlepšení, avšak nese s sebou také riziko, pokud cache nemá záložní baterii (BBU neboli Battery Backup Unit). V případě, že cache není vybavena touto baterií, může dojít při selhání napájení ke ztrátě dat. Servery DELL použité při této implementaci disponují zmíněnými bateriemi, tudíž byl zvolen tento mód. Write Through V módu Write Through data prochází skrze cache a potvrzení o zápisu na disk je zasláno až v okamžiku, kdy jsou data opravdu uložena na pevném disku. Force Write Back Force Write Back je nastaveno v případě, pokud chceme vynutit mód Write Back. Mód Write Back obsahuje mechanismus, který v případě selhání záložní baterie přepne mód na Write Through. Nastavením Force Write Back lze toto chování potlačit a vynutit Write Through i v případě, že je baterie poškozená či není žádná baterie nainstalovaná Připojení úloţiště Prostřednictvím iniciátoru iscsi byl připojen iscsi Target síťového úložiště. Následně bylo toto úložiště inicializováno (samozřejmě bylo zvoleno GPT) prostřednictvím nástroje správy disků a naformátováno na NTFS Instalace a konfigurace OS Samotná instalace operačního systému Windows Server 2012 Datacenter nebyla o nic složitější než instalace jakéhokoliv jiného operačního systému Windows. Je velmi málo scénářů, při kterých lze narazit na problémy. Například pokud se budete snažit instalovat operační systém na harddisk větší než 2TB, instalátor automaticky použije pro systémový disk MBR, který má kapacitní limit 2TB. Pro instalaci systému na pevný disk větší než 2TB je nutné použít GPT. Po instalaci přišla na řadu konfigurace. Aktivace systému, instalace aktualizací a podobné úkoly jsou samozřejmostí, proto bych se rád zaměřil na specifičtější oblasti konfigurace. Síťové karty Pro komunikaci s okolím servery využívají každý po šesti ethernetových rozhraních. Čtyři rozhraní Gigabit ethernet a dvě rozhraní umožňující 10Gb Ethernet. Ačkoliv operační systém Windows Server 2012 zahrnuje velké množství ovladačů a zahrnoval také ovladače 27

28 pro tato rozhraní, bylo v tomto případě opravdu nezbytné instalovat alespoň pro 10 Gigabit ethernetovou síťovou kartu poslední dostupné ovladače z webových stránek výrobce, aby byla zajištěna její plná funkčnost, a to například také včetně takzvané volby Jumbo Packet. Tento Jumbo Packet byl nastaven ve vlastnostech síťové karty, kde byla zvolena hodnota Toto bylo nastaveno na všech 10Gb rozhraních na obou serverech. Může být poněkud matoucí, že na serveru byl nastaven Jumbo Packet (zde totéž jako Jumbo Frame ) na 9014 a na úložišti na Jde však pouze o výrobce, jak toto pojme. Někteří výrobci do velikosti Jumbo Packetu respektive Jumbo Frame započítávají také 14 bajtů velký ethernetový rámec a někteří ne. Zda je toto nastavení Jumbo Packetu opravdu funkční, je možné zjistit následujícím příkazem: ping IP_ADRESA -f -l 8000 Za IP_ADRESA je nutné dosadit IP adresu úložiště či druhého serveru. Parametr -f nastaví flag nefragmentovat a parametr -l určuje velikost paketu. Dále byl vytvořen takzvaný NIC TEAM. Toto bylo provedeno v rozhraní Správce serveru, kde pod položkou Místní server lze nalézt Seskupování síťových adaptérů. Toto je jedna z věcí, které by se daly tomuto operačnímu systému vytknout, jelikož zde umístěné nastavení týkající se seskupování síťových adaptérů je dle mého názoru neintuitivní a očekával bych ho spíše v Centru síťových připojení a sdílení u síťových adaptérů. Každopádně zde byl vytvořen takzvaný NIC TEAM ze čtyř gigabitových síťových adaptérů. Na síťových adaptérech byly samozřejmě nastaveny také IP adresy. Na rozhraní pro iscsi komunikaci by neměly být zaškrtnuté žádné protokoly, kromě následujících: protokol výrobce (pokud je zde přítomen) IPv4 IPv6 Nezaškrtnutí dalších protokolů brání jiné síťové komunikaci, než je iscsi.[[3]] V praxi jsem se mohl setkat se zvyky systémových administrátorů, kteří zakazují protokol IPv6, pokud jej nepoužívají. Toto bych však nedoporučoval, jelikož tento protokol využívají některé systémové protokoly a služby a zakázáním tohoto protokolu na síťové kartě může dojít k narušení některých funkčností. 28

29 5.2.4 Instalace a konfigurace Hyper-V Hyper-V bylo nainstalováno běžným způsobem skrze průvodce přidání rolí serveru. Nutnou podmínkou je v BIOSu zapnutá podpora virtualizace (například Intel VT-x či AMD-v). Při instalaci role Hyper-V se také vybírají síťová rozhraní, pro která se mají vytvořit virtuální přepínače. Tyto přepínače jsou nutné k tomu, aby mohly virtuální servery komunikovat s okolím. Virtuální přepínač lze vytvořit jak v tomto okamžiku, tak později pomocí Správce technologie Hyper-V. V tomto případě však nebylo nutné s vytvoření přepínače čekat, tudíž bylo zvoleno nakonfigurované rozhraní NICTEAM1234. V dalším kroku se konfigurovala migrace virtuálních počítačů, kterou lze též nakonfigurovat později. Avšak stejně jako v případě konfigurace virtuálních přepínačů nebylo nutné s tímto nastavením čekat, tudíž bylo zaškrtnuto Povolit tomuto serveru posílat a přijímat živé migrace virtuálních počítačů a také Použít protokol Kerberos. Poslední krok před instalací slouží k definování výchozích umístění pro soubory virtuálních pevných disků a pro konfigurační soubory virtuálních počítačů. Zde bylo zvoleno vyhrazené úložiště připojené přes iscsi, tudíž cesty k těmto souborům vypadají následovně: Pro soubory virtuálního pevného disku: Pro konfigurační soubory virtuálního počítače: D:\Hyper-V\Virtual Hard Disks D:\Hyper-V V těchto umístěních si již Hyper-V automaticky vytvoří adresářovou strukturu pro nejrůznější konfigurační soubory, soubory virtuálních disků, pro snímky virtuálních počítačů a podobně. Co se týče diskových oddílů, je nutné je vytvořit adekvátně velké, jelikož v opačném případě si lze zadělat na nemalé problémy (bude vysvětleno později). Také je vhodné vyhnout se uchovávání virtuálních disků na svazcích obsahujících operační systém. Za jistých okolností může dojít k vyčerpání volného místa na systémovém disku a takový scénář povede k nemalým problémům. Zvolit jiné umístění je vhodné také z hlediska výkonu. Migrace za provozu Po spuštění Správce technologie Hyper-V je vhodné v Nastavení technologie Hyper-V nakonfigurovat Migrace za provozu (jedna z velmi užitečných funkcí). Při tomto nasazení byl zvolen bezpečnější typ ověřování prostřednictvím Kerbera, který vyžadoval také konfiguraci na doménovém řadiči, a také byla nastavena IP adresa sítě určující, z jaké sítě mohou být migrace přijímány. U položek Souběžné migrace za provozu a Souběžné 29

30 migrace úložišť byl zvolen limit na dvě paralelní migrace, aby nedocházelo k přílišnému zatěžování diskových úložišť. Konfigurace replikace Při konfiguraci replikace bylo zvoleno také ověřování pomocí Kerbera. Replikace jsou přenášeny nešifrovaně skrze výchozí port 80. Repliky virtuálních serverů není nutné šifrovat, jelikož jsou přenášeny po vnitřní síti mezi servery, které jsou přímo propojeny. Šifrovaný přenos replik a ověřování prostřednictvím certifikátů (HTTPS) bychom volili například v případě zasílání replik na server hostovaný v datacentru. Bylo také nutné nastavit výchozí umístění pro ukládání replik. Tímto umístěním je konkrétně D:\Hyper-V\Virtual Hard Disks. V tomto umístění se automaticky vytvořila složka Hyper-V Replica, která obsahuje strukturu adresářů pro ukládání kompletních replik virtuálních serverů. Dále bylo nutné povolit na firewallu příchozí pravidlo Naslouchací proces protokolu HTTP repliky Hyper-V (TCP-In). Poslední krok konfigurace replikace se týkal konfigurace serveru na doménovém řadiči. Postup této konfigurace bude upřesněn v následující kapitole. Hyper-V a Active Directory Nová architektura jádra počítačové infrastruktury jak byla navržena, počítá se zapojením veškerých serverů (včetně hostitelských serverů) do domény AD (Active Directory). Active Directory přináší mnoho výhod, avšak je nutné ji řádně nakonfigurovat a držet se určitých pravidel. Například je nevhodné mít doménový řadič pouze jako virtuální server, pokud je samotný hostitelský server připojený do domény. V takovém případě nemá hostitelský server dostupnou doménu při svém startu a to s sebou přináší nejednu komplikaci. Proto je nutné zahrnout do návrhu také fyzický doménový řadič. Jak již bylo podotknuto, aby byla konfigurace replikace a migrace kompletní, je nutné provést určitá nastavení na doménovém řadiči. Tato nastavení se týkají konkrétně delegování. Nastavení delegování: 1) Na doménovém řadiči otevřeme konfigurační rozhraní zvané Uživatelé a počítače služby Active Directory. 2) V tomto rozhraní otevřeme nejprve vlastnosti prvního serveru (SERVER1), kde přejdeme na záložku Delegování. 30

31 3) Zde zvolíme možnost Důvěřovat tomuto počítači pro delegování pouze určeným službám a dále vybereme Používající pouze protokol Kerberos. 4) Nyní klikneme na tlačítko Přidat, vybereme druhý server (SERVER2), zvolíme následující služby: cifs, Hyper-V Replica Service a Microsoft Virtual System Migration Service a poté volbu potvrdíme. 5) Toto nastavení je nutné udělat křížem, aby bylo možné replikovat a migrovat servery z prvního serveru na druhý a naopak. Tudíž nyní otevřeme vlastnosti druhého serveru, otevřeme záložku Delegování a postupujeme stejně jako u prvního serveru, avšak nyní volíme delegování pro SERVER1. Tímto způsobem byl nakonfigurovaný doménový řadič, aby bylo možné replikovat a migrovat virtuální stroje mezi servery Antivirus Rozhodování, zda mít či nemít nainstalovaný antivirus na Hyper-V hostu, bylo poměrně složité. Z hlediska bezpečnosti by každý specialista přes počítačovou bezpečnost striktně prosazoval antivirový software všude bez výjimky. Avšak pohled systémových administrátorů může být poněkud odlišný. Antivirový software, zvláště pak ten, který nemá povědomí o virtualizaci, může napáchat poměrně velké škody. Také nasazení antivirového softwaru, který si je vědom přítomnosti hypervisoru, často nemusí být úplně bezproblémové. Špatný antivirový software, chyba v jeho konfiguraci či jiný podobný faktor může například způsobit poškození konfiguračních souborů virtuálních počítačů, znemožnit tvorbu nových virtuálních strojů, přerušit běh spuštěných virtuálních strojů či zapříčinit podobné komplikace (viz Někteří systémoví administrátoři tudíž zastávají názor, že pro instalaci antivirového softwaru na Hyper-V hosta za určitých okolností není žádný pádný důvod, tudíž ho vzhledem ke zmíněným rizikům v některých případech raději neinstalují. Určitými okolnostmi mám na mysli například stav, kdy je k hostujícímu serveru omezený přístup, samotný host nemá přístup na internet, jeho systém je pravidelně aktualizovaný, Hyper-V je jedinou instalovanou rolí a za jiným účelem než za účelem správy virtuálních serverů se k tomuto stroji nepřistupuje. Ačkoliv nasazené servery DELL splňují výše zmíněné požadavky, které radikálním způsobem minimalizují riziko virové infekce, bylo rozhodnuto pro instalaci antivirového softwaru. Velkou roli v tomto rozhodování hrál fakt, že byl k dispozici antivirový software od společnosti ESET již otestovaný na Hyper-V hostech jak v laboratorním prostředí, tak 31

32 v produkčním prostředí při hostování virtuálních serverů, které nevyžadovaly vysokou dostupnost. Při instalaci antivirového softwaru bylo však nutné nastavit výjimky a vyloučit následující cesty z prohledávání antivirového programu: C:\ProgramData\Microsoft\Windows\Hyper-V\*.* C:\Windows\System32\vmms.exe C:\Windows\System32\vmwp.exe D:\ *.*[4] Všechna umístění obsahující soubory virtuálních disků či konfigurační soubory virtuálních počítačů musí být vyloučena z prohledávání antivirového programu. V tomto případě je to celý svazek D:\. 5.3 Migrace serverů Ačkoliv je možné servery migrovat z fyzických strojů do virtuálního prostředí bez nutnosti reinstalace prostřednictvím nástroje Disk2vhd, postrádal by tento způsob konsolidace serverů smysl, jelikož v tomto případě bylo žádoucí dosáhnout infrastruktury na platformě Windows Server Jsou však případy, kdy je takováto migrace dostačující či slouží jako první krok před následným postupným přechodem jednotlivých serverů na novější operační systémy. Tímto způsobem byly v tomto případě migrovány terminálové servery, u kterých nebylo možné ihned přejít na novější operační systém z důvodu komplikací, které budou popsány později v práci Konfigurace virtuálních strojů V této kapitole bych rád shrnul konfigurace virtuálních strojů. Možností je zde poměrně mnoho, tudíž bych uvedl zejména nejpoužívanější a nejdůležitější volby. Při vytváření virtuálního stroje je pomocí průvodce nastaveno jen několik základních parametrů virtuálního počítače. Další konfigurace se již provádí zvolením konkrétního virtuálního stroje ve správci technologie Hyper-V a kliknutím na volbu Nastavení v pravém menu či v nabídce, která se zobrazí po stisknutí pravého tlačítka myši na konkrétním virtuálním stroji. 32

33 Přidat hardware Prostřednictvím této nabídky lze přidávat virtuálnímu stroji další virtuální hardware. Zejména se jedná o možnost přidání dalšího řadiče iscsi, síťového adaptéru či staršího síťového adaptéru (legacy network adapter). BIOS V položce BIOS lze nalézt pouze položku pro zapnutí Num Lock po startu virtuálního stroje a také zde lze definovat pořadí spouštění ( boot order ). Toto pořadí určuje pořadí zařízení, z nichž se bude systém pokoušet zavádět operační systém (bootovat). Paměť Existují dva přístupy k nastavování paměti virtuálního počítače. Paměť lze nastavit staticky či dynamicky: Statická virtuální paměť Je-li paměť nastavena staticky, je celá alokována ihned po startu virtuálního stroje. Virtuální server má tudíž garantované množství virtuální paměti. Toto nastavení je také vhodnější, pokud jde o architekturu NUMA (o této problematice se zmíním v kapitole týkající se konfigurace procesoru virtuálního stroje). Nevýhodou je, že při nastavení statické virtuální paměti nelze škálovat jako v případě nastavení paměti dynamické. Dynamická virtuální paměť Zvolením dynamické virtuální paměti lze dosáhnout především lepší škálovatelnosti virtuálních strojů. V případě dynamického přidělování se paměť koriguje parametry: Minimální velikost paměti RAM, Maximální velikost paměti RAM, Vyrovnávací paměť a také lze nastavit váhu paměti. Tato poslední volba je též dostupná při konfigurování statické virtuální paměti, avšak většího využití najde ve scénáři s dynamickou virtuální pamětí. Mezi nevýhody lze zařadit možnost výskytu takzvaného NUMA spanningu, který způsobuje degradaci výkonu. Tato problematika bude rozvedena v části týkající se konfigurace procesoru virtuálního stroje. Poznámka: Je nutné brát v potaz také operační systém. Pokud je virtualizován 32bitový operační systém, platí zde stejná omezení týkající se maximální hodnoty využitelné paměti jako v případě fyzického serveru. 33

34 Procesor Srdcem každého počítače je samozřejmě procesor a i zde je konfigurace procesoru virtuálních strojů velmi důležitá. Na následujících řádcích bych rád uvedl některé základní informace týkající se této problematiky: Počet virtuálních procesorů Ve výchozím nastavení je každému virtuálnímu stroji přiřazen jeden virtuální procesor. Jeden virtuální procesor se rovná jednomu logickému procesoru. Například server DELL PowerEdge R720 má dva osmijádrové procesory, celkem 16 jader, která ve výsledku dávají 32 logických procesorů. Při nastavování počtu virtuálních procesorů je nutné si uvědomit, že každý operační systém má své limity. Limity počtu virtuálních procesorů pro operační systémy lze nalézt zde: (Hyper-V Overview). Řízení prostředků Toto nastavení slouží, jak již napovídá příslušný popis této položky (v nastavení virtuálního stroje), k vyvážení prostředků mezi virtuálními počítači. Řízení prostředků zahrnuje tři parametry: o Vyhrazení pro virtuální počítač (procenta) Tímto parametrem lze nastavit, kolik procent ze strojového času virtuálních procesorů, které byly konfigurovanému virtuálnímu stroji přiřazeny, je vyhrazeno tomuto konkrétnímu virtuálnímu serveru. Pod touto položkou lze nalézt pole, které ukazuje, kolik procent z celkového množství systémových prostředků bylo přiřazeno. o Limit virtuálního počítače Tento parametr je opakem parametru předchozího. Umožňuje definovat, kolik procent ze strojového času virtuálních procesorů, které byly tomuto virtuálnímu stroji přiřazeny, je možné maximálně využít. Pod touto položkou lze opět nalézt pole, které ukazuje porovnání nastavené hodnoty s celkovým množstvím systémových prostředků. o Relativní váha Rozsah tohoto parametru je , ve výchozím nastavení má parametr hodnotu 100. Pokud dojde k soupeření virtuálních strojů o strojový čas, tento parametr rozhoduje, který z nich dostane více strojového času. Virtuální server s vyšší relativní váhou má přednost. NUMA (Non-Uniform Memory Access) NUMA architektura je koncepce využívaná u procesorů s mnoha jádry. Tyto procesory mohou být navrženy tak, aby umožňovaly přímý paralelní přístup k různým paměťovým modulům jako na obrázku níže. Na obrázku je zobrazen osmijádrový procesor, v němž první 4 jádra jsou přímo 34

35 propojena s pamětí a tvoří jeden uzel NUMA (NUMA Node) a druhá polovina jader procesoru je propojena s jinou pamětí a tvoří druhý uzel NUMA. Přístup k paměti v rámci jednoho uzlu NUMA je výrazně rychlejší, a Hyper-V se tudíž snaží přidělovat paměť z jednoho uzlu. Avšak pokud již není k dispozici dostatek paměti v jednom NUMA uzlu, přijde na řadu proces zvaný NUMA node spanning. Tento proces přidělí paměť NUMA uzlu jiného. Tato paměť nebude dostupná přímo, ale nepřímým přístupem skrze jádra druhého uzlu, tudíž v takovém případě bude výkon degradován. NUMA node spanning může vyvolat například dynamické přidělování paměti virtuálním strojům. Proces NUMA node spanning lze úplně zakázat, pokud je v menu Nastavení technologie Hyper-V pod položkou Pokrývání uzlů NUMA zrušeno zaškrtnutí Povolit virtuálním počítačům pokrývat fyzické uzly NUMA. Počet a velikost uzlů NUMA závisí na procesoru a na umístění a velikosti pamětí na základní desce. Tudíž pokud je migrován virtuální počítač na jiný server, který má rozdílnou velikost a počet uzlů NUMA, zůstane virtuální počítač nastaven na NUMA architekturu předchozího serveru a je vhodné toto nastavení upravit. Kliknutím na Použít hardwarovou topologii v NUMA nastavení příslušného virtuálního stroje lze přizpůsobit konfiguraci topologie NUMA virtuálního stroje aktuálnímu serveru.[[2]] Obrázek 7: NUMA Zdroj: autor 35

36 Řadiče V případě řadiče jsou dostupné dvě alternativy. Řadič IDE a řadič SCSI. Každý z těchto řadičů má svá specifika: Řadič IDE Virtuální počítač má dva řadiče IDE. K těmto řadičům lze připojit maximálně čtyři virtuální pevné disky (pokud odebereme jednotku DVD, která je ve výchozím stavu k jednomu z IDE řadičů připojena). Ke zmíněné jednotce DVD lze připojovat soubory bitových kopií či fyzická média vložená do mechaniky na hostitelském serveru. Zavádět operační systém je možné pouze z virtuálního pevného disku připojeného k řadiči IDE. Z virtuálního pevného disku připojeného k řadiči SCSI bootovat nelze. Situace je jiná v operačním systému Windows Server 2012 R2, kde již řadič IDE není. Řadič SCSI U každého virtuálního počítače je možné využívat až čtyři řadiče SCSI. Ke každému z těchto řadičů je možné připojit až 64 virtuálních disků. Toto ve výsledku znamená, že jeden virtuální počítač může mít až 256 virtuálních disků připojených prostřednictvím řadiče SCSI. Síťové adaptéry V prostředí virtuálních strojů lze využívat dva typy virtuálních síťových adaptérů, a to následující: Síťový adaptér (Synthetic network adapter) Každý nově vytvořený virtuální stroj disponuje tímto síťovým adaptérem. Tyto síťové adaptéry lze také virtuálním strojům přidávat. Jeden virtuální stroj může disponovat až osmi síťovými rozhraními tohoto typu, avšak aby mohl s těmito síťovými adaptéry pracovat, musí mít instalované integrační služby. Tento typ adaptéru má výrazně menší režii než takzvaný Starší síťový adaptér. Starší síťový adaptér (Legacy network adapter) Virtuální stroj může disponovat až čtyřmi těmito rozhraními. Avšak ve výchozím stavu není virtuální počítač tímto adaptérem vybaven. V případě nutnosti je potřeba stroj starším síťovým adaptérem vybavit pomocí volby Přidat hardware. Tento typ síťového adaptéru má větší režii než klasický síťový adaptér (Synthetic network adapter), avšak nepotřebuje ke své funkčnosti integrační služby, tudíž je vhodný zejména pro starší operační systémy. Výhodou tohoto rozhraní je, že oproti klasickému síťovému adaptéru podporuje funkci PXE boot. Jelikož však nepracuje s integračními službami, nedisponuje oproti 36

37 klasickému síťovému adaptéru některými funkcemi, například správou šířky pásma či technologiemi hardwarové akcelerace jako VMQ či SR-IOV. Replikace Poznámka: Technologie replikace bude objasněna později, tudíž nejste-li s touto funkčností obeznámen/a, je vhodné tuto kapitolu přeskočit a vrátit se k ní později. Při povolení a nastavení replikace u některého z virtuálních počítačů přibude v nastavení tohoto virtuálního stroje položka Replikace. V tomto podmenu lze nastavit totéž, co již bylo nastaveno prostřednictvím průvodce spuštění replikace vyjma opětovné synchronizace. Toto nastavení umožňuje specifikovat, kdy a jakým způsobem může být opětovná synchronizace spuštěna. Zda se má spouštět ručně, automaticky, či automaticky v konkrétním časovém rozmezí. Tato synchronizace je poměrně náročná, zvláště pak na datová úložiště, tudíž pokud nejsou virtuální disky uchovávány na velmi výkonných úložištích, je vhodné tuto synchronizaci provádět v době, kdy jsou virtuální servery nejméně zatíženy. Automatická synchronizace s nastavením vhodného časového rozmezí bývá často nejlepší volbou. Spustit opětovnou synchronizaci je nutné, pokud nastala událost, která mohla způsobit, že virtuální stroj již není korektně synchronizovaný s replikou tohoto virtuálního stroje. Proces opětovné replikace zkontroluje data repliky virtuálního stroje oproti primárnímu virtuálnímu serveru a zajistí jejich správnost. Automatická akce spuštění Toto podmenu umožňuje nastavit chování virtuálního stroje po spuštění fyzického počítače (hostitelského serveru). Je možné volit mezi třemi volbami. První volba nedefinuje žádnou akci. Druhá (výchozí) volba je Automaticky spustit, pokud byl spuštěn při zastavení služby známá také jako last state (poslední stav). Tato volba je většinou nejvhodnější. Poslední možností je Vždy spustit tento virtuální počítač. Také je zde možné nastavit Zpoždění spuštění v sekundách. Nastavením tohoto parametru je možné ovlivnit pořadí spouštění jednotlivých virtuálních strojů, jak je popsáno v kapitole Zapnutí, vypnutí, UPS. Také je touto volbou možné ovlivnit alokaci hardwarových prostředků jednotlivými virtuálními stroji. 37

38 Automatická akce zastavení Zde se konfiguruje reakce virtuálního stroje na vypnutí fyzického serveru (hostujícího serveru). Kromě voleb Uložit stav virtuálního počítače a Vypnout virtuální počítač je zde také volba Vypnout hostovaný operační systém. Tato poslední volba je v drtivé většině případů nejoptimálnější, avšak virtuální stroj musí mít instalované integrační služby. Zvolením této možnosti se virtuální stroj vypíná spolu s hostujícím serverem Příprava šablon Vytváření virtuálních serverů instalací a konfigurací každého z nich zvlášť by bylo velmi zdlouhavé a neefektivní. Je proto vhodné si připravit šablony virtuálních serverů, které bude možné kopírovat a upravovat dle potřeby. Vytvoření šablon lze dosáhnout prostřednictvím nástroje Sysprep, který je součástí operačního systému Windows Server Vytvoření šablony virtuálního stroje K vytvoření šablony virtuálního stroje nemusí být vždy použit specializovaný software. Pokud chcete vytvořit šablonu virtuálního stroje bez jakýchkoliv speciálních nástrojů, postupujte následovně: 1) V prvním kroku je vhodné si vyhradit složku pro šablony virtuálních strojů, jelikož jich ve většině případů bude zapotřebí vytvořit více. 2) Běžným způsobem vytvořte virtuální stroj s virtuálním diskem o kapacitě, kterou zpravidla využíváte pro systémový disk. V tomto nasazení jsem většinou používal systémové virtuální disky o kapacitě 80 GB, tudíž vytvořím takovýto disk a pojmenuji ho dle verze operačního systému, následného účelu a také uvedu, že se jedná o šablonu. Konvence pro názvosloví týkající se virtuálních serverů a disků se ve společnostech liší, tudíž zde nebudu příliš konkrétní. 3) Virtuálnímu serveru přiřaďte instalační médium a nainstalujte příslušný operační systém. Instalujte aktualizace, potřebné programy a server nakonfigurujte. Proveďte instalace a konfigurace společné pro skupinu serverů, které budou vycházet z této šablony. 4) Následně ve složce C:\Windows\System32\Sysprep nalezněte a spusťte aplikaci sysprep.exe. 38

39 5) Nastavte Zobrazit prostředí prvního spuštění počítače u volby Akce čištění systému. 6) Zaškrtněte Zobecnit. (Slouží k odstranění všech unikátních informací. Například dojde k odstranění Security ID, které je znovu vygenerováno při prvním spuštění.) 7) Nastavte Vypnout u Možnosti vypnutí. 8) Až Sysprep dokončí všechny operace, virtuální stroj se sám vypne a šablona je tímto vytvořena. Poznámka: Čas od času je vhodné tuto šablonu spustit, nainstalovat aktualizace jak operačního systému, tak případně jednotlivých programů a následně spustit Sysprep znovu. Při používání staré šablony může být proces aktualizace u každého nového virtuálního stroje vytvořeného z této šablony poměrně zdlouhavý. Použití šablony virtuálního stroje Pokud chcete vytvořit nový virtuální server z předem vytvořené šablony, postupujte následovně: 1) Zkopírujte šablonu virtuálního serveru do umístění dle zavedených konvencí (například do D:\Hyper-V\Virtual Hard Disks ). 2) Přejmenujte soubor virtuálního disku též dle zavedených konvencí. 3) Vytvořte virtuální server, avšak nevytvářejte nový virtuální disk, pouze připojte zkopírovanou šablonu. 4) Spusťte virtuální stroj. 5) Překontrolujte či případně nastavte pole týkající se země, jazyku aplikací či rozložení klávesnice. 6) Odsouhlaste licenční podmínky. 7) Zadejte nové administrátorské heslo. 8) V tomto kroku je průvodce dokončen a můžete začít s běžnou konfigurací serveru. 39

40 5.3.3 Migrace pomocí nástroje Disk2vhd Disk2vhd umožňuje převádět jednotlivé fyzické disky na disky virtuální. Velkou výhodou tohoto nástroje je, že umožňuje tento převod takzvaně za běhu. Nástroj Disk2vhd byl použit pro převod terminálových serverů do virtuálního prostředí. Jelikož provoz terminálových serverů na systému Windows Server 2012 provázely jisté komplikace, bylo rozhodnuto převést stávající terminálové servery běžící na operačních systémech Windows Server 2003 do virtuálního prostředí, dokud nebudou tyto komplikace vyřešeny a nedojde k přechodu na Remote Desktop Services bežících na operačním systému Windows Server Tímto mezikrokem bylo dosaženo úspory elektrické energie, výrazného zkrácení doby zotavení při případné havárii a také se dosáhlo mírného zvýšení výkonu těchto terminálových serverů. V době převodu terminálových serverů do virtuálního prostředí byla k dispozici pouze první verze nástroje Disk2vhd, která neposkytovala přímý převod do formátu VHDX. Nástroj vytvářel pouze dynamické virtuální disky staršího formátu VHD, tudíž byla nikoliv nutná, avšak vhodná následná konverze virtuálního disku na disk pevné velikosti novějšího formátu VHDX a také bylo vhodné zmenšení těchto virtuálních disků (viz kapitola o virtuálních discích). Zmenšit vytvořené virtuální disky bylo třeba z toho důvodu, že Disk2vhd vytváří virtuální disky stejné velikosti, jako byl daný oddíl na fyzickém serveru. Vzhledem k faktu, že na fyzických serverech byl většinou jeden oddíl přes celý, zpravidla 500 GB velký fyzický disk, docházelo by po migraci do virtuálního prostředí ke zbytečnému plýtvání prostorem při využívání disků pevné velikosti. Nyní je dostupná novější verze tohoto nástroje, která umožňuje přímý převod disku fyzického do formátu VHDX, tudíž odpadá případná konverze do tohoto formátu. Po vytvoření virtuálních disků z disků fyzických bylo nutné pouze vytvořit a nakonfigurovat virtuální stroje jako takové a po jejich spuštění doinstalovat do virtualizovaného terminálového serveru integrační služby. Nástroj Disk2vhd je jednoduchá, ale velmi užitečná utilita. Je dostupná zdarma na následující adrese: (Windows Sysinternals). 40

41 5.4 Zapnutí, vypnutí, UPS Je velmi důležité ochránit servery a disková úložiště před náhlými výpadky elektrické energie. Náhlý výpadek elektrického napájení může nejen způsobit dočasnou nedostupnost systémů, ale může také zapříčinit ztrátu dat. Proto je třeba tato zařízení připojit do sítě prostřednictvím UPS s dostatečnou kapacitou, aby byla v případě výpadku elektrické sítě zajištěna dodávka elektrické energie, dokud nedojde k vypnutí těchto zařízení. Nutné je však také dbát na správné pořadí vypínání zařízení. Nejprve je nutné vypnout samozřejmě servery a až poté disková úložiště. V rámci serveru (hostitelského serveru) by mělo být také určeno pořadí vypínání virtuálních strojů. Například doménový řadič by se měl vypínat vždy jako poslední. UPS by měly mít dostatečnou kapacitu, aby byly schopné udržet napájení dostatečně dlouho i se starší baterií. Toto by mělo být dobře otestováno. Disková úložiště i servery by měly zůstat vypnuté i po obnově elektrické energie. Toto je důležité, jelikož mohou nastat případy, kdy dojde k více za sebou jdoucím výpadkům. Pokud by taková situace nastala, UPS by již nedokázaly zajistit nepřetržitou dodávku elektrické energie a došlo by k neregulérnímu vypnutí. Nejen pořadí vypínání virtuálních strojů je důležité, ale také pořadí spouštění těchto strojů by nemělo být náhodné. Doménový řadič by se měl samozřejmě zapínat jako první a za ním by se měly s dostatečným odstupem spouštět další servery. Také často není vhodné spouštět patnáct serverů najednou, ale je vhodnější servery spouštět po skupinách s určitými rozestupy. Zapnutí například patnácti serverů najednou v tomto případě velmi zatíží disková úložiště a ve výsledku bude proces spouštění virtuálních strojů delší, než když se tyto servery spouštějí ve skupinách s určitými časovými rozestupy. 41

42 6 Obecně o Hyper-V V této kapitole popíši některé funkčnosti a možnosti Hyper-V, jako jsou migrace, replikace či snímky virtuálních strojů. Také popíši některé základní prvky, jako jsou virtuální disky. Vysvětlím také možnosti úprav těchto virtuálních disků. 6.1 Migrace za provozu (live migration) Migrace za provozu, nebo jak se také někdy říká za živa, je velmi přínosnou funkcí představenou v operačním systému Windows Server Tato funkce umožňuje za běhu přesunout server z jednoho hostitele na druhého (nelze pomocí migrace přesouvat soubory virtuálních serverů v rámci jednoho hostitele). Lze přesouvat celý virtuální stroj (včetně virtuálních disků, snímků či souborů inteligentního stránkování) nebo pouze virtuální disky konkrétního virtuálního serveru, přičemž lze volit cílové umístění jednotlivých komponent. Postup migrace je jednoduchý. Stačí ve Správci technologie Hyper-V zvolit u některého virtuálního serveru Přesunout, specifikovat, zda přesunout celý virtuální počítač, či pouze úložiště, a zvolit cílový server, případně cílové umístění jednotlivých komponent virtuálního serveru. Zbytek již obstará Hyper-V. 6.2 Replikace Replikace je jednou z velmi přínosných funkcí Hyper-V, i když má své nedostatky. Tyto nedostatky budou detailněji popsány později. Po povolení replikace u virtuálního stroje a přenesení prvotní repliky je tento virtuální počítač pravidelně replikován na druhý server (stranu repliky). Zde se zobrazuje spolu s ostatními virtuálními stroji ve správci technologie Hyper-V, avšak ve vypnutém stavu. Na straně primární se u virtuálního disku tohoto replikovaného serveru začnou tvořit takzvané replika logy. Takto se označují soubory s příponou.hrl, které evidují změny ve virtuálním disku od poslední provedené replikace. Interval replikace je ve Windows Server 2012 pevně nastaven na 5 minut. Tento nezměnitelný parametr mimochodem považuji za jeden z nedostatků této technologie. Ve Windows Server 2012 R2 je toto sice možné změnit, avšak pouze na předdefinované hodnoty (30 sekund, 5 minut, 15 minut). Čili ve Windows Server 2012 je tento interval nastaven na 42

43 5 minut, po jejichž uplynutí je log repliky po síti odeslán na server repliky, kde dojde k aplikaci těchto změn na virtuální disk repliky virtuálního stroje Nastavení replikace virtuálního stroje Nastavení replikace lze samozřejmě provést také pomocí PowerShellu příkazem Enable-VMReplication, avšak zde popíši klasickou cestu, tudíž povolení replikace skrze Správce technologie Hyper-V. Také zmíním volby, které byly vybrány pro replikaci virtuálních strojů v nově navrženém a implementovaném jádře podnikové IT infrastruktury. Postup povolení replikace u virtuálního stroje je následující: Nejprve je třeba vybrat konkrétní virtuální stroj a následně kliknout v pravém panelu na Povolit replikaci. Replikaci lze povolit také výběrem této volby z menu, které lze vyvolat pravým kliknutím na daný virtuální stroj. Zadání serveru repliky Výběr serveru, na který chceme replikovat. (Při povolování replikace na prvním serveru zadávám SERVER2 a obráceně.) Zadání parametrů připojení: o Typ ověřování Zde je zobrazena volba typu ověření a lze vybírat mezi ověřováním pomocí protokolu Kerberos (HTTP) či pomocí certifikátu (HTTPS). Možnost výběru je v tomto kroku pouze tehdy, pokud jsou v nastavení Konfigurace replikace povoleny oba tyto způsoby ověřování. (V tomto případě se bude využívat ověřování protokolem Kerberos, který byl v konfiguraci replikace povolen jako jediný.) o Komprimovat data přenášená přes síť Ve výchozím nastavení je tato volba zaškrtnutá. (Tuto volbu nechávám zaškrtnutou.) Výběr virtuálních pevných disků pro replikaci Ve výchozím nastavení jsou zvoleny všechny virtuální disky. (Zde nechávám zaškrtnuty všechny virtuální disky, nebyl důvod některý z disků vyloučit.) Konfigurace historie obnovení: o Pouze nejnovější bod obnovení Jak již plyne z názvu, na straně repliky se uchovává pouze stav virtuálního stroje v době poslední replikace. o Další body obnovení Pomocí této volby lze uchovávat několik dalších bodů obnovení (maximálně však 15). Tyto body obnovení jsou vytvářeny na principu snímků virtuálních strojů (viz kapitola 6.5 Snímky/kontrolní body) v rozestupu jedné hodiny. Průvodce také ukáže, kolik diskového prostoru tyto 43

44 další body obnovení obsadí. (Volil jsem dva další body obnovení pro každý virtuální server.) Replikovat přírůstkovou stínovou kopii svazku Tato volba je dostupná až po nastavení dalších bodů obnovení a umožňuje nastavit vytváření přírůstkových stínových kopií v rozmezí 1 12 hodin. Tyto přírůstkové kopie jsou aplikačně konzistentní a jejich vytváření je prováděno prostřednictvím služby zvané VSS (viz kapitola Volume Shadow Copy Service (VSS)). Tento proces je však poměrně náročný a může výrazně zatížit aplikace běžící na cílovém serveru. (Vytvářet přírůstkové stínové kopie svazku je vhodné například u serverů s nainstalovaným SQL Serverem.) Výběr metody počáteční replikace: o Metoda počáteční replikace: Poslat počáteční kopii přes síť (V případě tohoto nasazení samozřejmě volím tuto možnost jako metodu počáteční replikace, jelikož jsou hostitelské servery přímo propojené 10Gbit linkou.) Poslat počáteční kopii s pouţitím externích médií Počáteční kopie se exportuje na zvolené externí médium a na serveru repliky je poté importována. Jako počáteční kopii pouţít existující virtuální počítač na serveru repliky Tato možnost je volena v případě, pokud je žádoucí použít jako počáteční repliku virtuální stroj obnovený ze zálohy, exportovaný a následně importovaný virtuální stroj na serveru repliky či starší repliku virtuálního stroje. o Naplánovat počáteční replikaci Spustit replikaci ihned Spustit replikaci Zde je možné zvolit konkrétní datum a čas. 44

45 6.3 Virtuální disky Při virtualizaci se využívají takzvané virtuální disky, které reprezentují disky fyzické. Jde o speciální typy souborů, které mohou být několikerého typu. Před nástupem operačního systému Windows Server 2012 se využívaly disky formátu VHD. Spolu s operačním systémem Windows Server 2012 spatřil světlo světa také nový formát virtuálních disků, a to formát VHDX. Tento formát přináší mnohá vylepšení. VHDX umožňuje vytvářet o mnoho větší virtuální disky (až 64 TB) než starý formát VHD, zahrnuje také ochranu dat při selhání napájení, vylepšuje zarovnání virtuálních disků, které snižuje degradaci výkonu na pevných discích s velkými sektory, a mnoho dalšího.[5] Formáty virtuálních disků lze převádět, takže pokud byl virtuální pevný disk vytvořen ve formátu VHD, lze ho například pomocí Správce technologie Hyper-V převést do formátu novějšího. Avšak formát VHDX není podporován v operačních systémech starších než Windows Server Typy virtuálních disků Při vytváření virtuálního disku lze zvolit kromě formátu (VHD či VHDX) také jeho typ. Jaký typ zvolit, bude vždy záležet na konkrétním nasazení, jelikož každý má své výhody a nevýhody. Virtuální disk pevné velikosti Vytvořením virtuálního disku pevné velikosti se vytvoří VHDX soubor o velikosti, která byla zadána při jeho vytváření. Nezáleží na tom, kolik dat bude tento disk obsahovat, zabere vždy stejný prostor na disku. Toto má své výhody i nevýhody. Mezi nevýhody lze zařadit například fakt, že pokud bude tento virtuální disk kopírován či přesouván, může tato operace v závislosti na velikosti disku a jeho zaplnění trvat až několikrát déle než v případě disku dynamického, který je velký stejně jako souhrn dat v něm obsažených. Co se týče zálohování, nemá typ disku na tento proces až takový vliv, jelikož drtivá většina řešení pro zálohování virtuálních strojů umí pracovat s těmito virtuálními disky a zálohují pouze data na těchto discích obsažená. Z hlediska výkonu je virtuální disk pevné velikosti nejlepší volbou, tudíž jsem tento typ volil u všech virtuálních disků všech serverů. 45

46 Virtuální disk dynamicky se zvětšující Při vytváření tohoto typu virtuálního disku je volena maximální velikost, jaké může tento disk dosáhnout. VHDX soubor tohoto typu se dynamicky zvětšuje se zvyšujícími se nároky na diskový prostor. Ačkoliv se tento typ disku automaticky zvětšuje, při uvolnění místa se již automaticky nezmenšuje. Zmenšení je však možné provést manuálně způsobem, který bude objasněn v kapitole týkající se operací s virtuálními disky. Nevýhoda dynamicky se zvětšujícího virtuálního disku tkví zejména ve fragmentaci, ke které dochází při zvětšování VHDX souboru. Proto se tento typ disku nedoporučuje používat na systémech, kde dochází k velkému nárůstu dat malými přírůstky. Toto se může týkat například serveru s relační databází či mailserveru. Virtuální disk rozdílový Rozdílový virtuální disk je speciálním typem virtuálního disku. Princip tohoto disku lze srovnat například s vytvářením snímku virtuálního stroje. Také ho lze tímto způsobem použít. Rozdílový virtuální disk potřebuje ke své funkci již existující virtuální disk, který zastane funkci rodiče (takzvaný parent disk ). Při vytváření rozdílového virtuálního disku je vybrán tento nadřazený disk (rodič). Po vytvoření jsou data jako v případě snímku virtuálního disku čtena z nadřazeného disku a zapisována do nově vytvořeného rozdílového disku. Pokud je nutné číst data upravená či nově vytvořená, budou se též číst z rozdílového disku. Tento virtuální disk postupnými změnami či přírůstky dat postupně narůstá stejně jako soubor snímku virtuálního počítače. Způsobem nadřazený-podřazený disk je možné vytvářet celé struktury virtuálních počítačů. Ať už struktury stromové či typu vločka (snowflake). Pokud jsou však rozdílové virtuální disky v některé ze míněných struktur či jsou zřetězené, je nutné zapisovat pouze do virtuálních disků posledních v této struktuře (do disků, které již nejsou ve struktuře žádnému virtuálnímu disku nadřazené). Požadavkem na vytvoření rozdílového disku je, že musí být stejného formátu jako disk nadřazený. Tento typ virtuálního disku může mít uplatnění například v případě, kdy je potřeba rychle vytvořit více virtuálních strojů například pro potřeby testování. Dalším příkladem, jak je možné použít tento typ virtuálního disku, může být vytvoření několika rozdílových virtuálních disků s různými verzemi některého softwaru. Lze například jednoduchým způsobem vytvořit několik virtuálních strojů s různými verzemi internetového prohlížeče Internet Explorer pro potřeby vývojáře webových aplikací či několik virtuálních strojů pro 46

47 testování aplikací na Windows 7 s aktualizací SP1 (Service Pack 1) a na Windows 7 bez této aktualizace, jak ukazuje následující obrázek: Obrázek 8: Rozdílové virtuální disky Zdroj: autor Pass-through disk Tento typ disku není virtuální, ale pro kompletní přehled jsem jej zařadil. Pass-through disk představuje fyzický disk, diskový oddíl či LUN, který je celý přiřazen virtuálnímu stroji. Jsou zde určité výhody, avšak dle mého názoru převažují spíše nevýhody. Pokud je z nějakého důvodu nutné použít pro virtuální stroj disk větší než 64TB (toto je velikostní limit virtuálních disků formátu VHDX), nezbude nic jiného než zvolit pass-through disk. Dalším argumentem pro použití pass-through disku může být tvrzení, že nedegraduje výkon úložiště jako při použití virtuálních disků. Avšak virtuální disk pevné velikosti degraduje rychlost čtení/zápisu opravdu minimálně, tudíž bych se stále přikláněl k použití virtuálních disků 47

48 pevné velikosti formátu VHDX. A to například z důvodu mobility, možnosti používat snímky, replikaci a další užitečné funkce. Mimo jiné fyzický disk nelze připojit v Online režimu. Před připojením fyzického disku je nutné jej přepnout do režimu Offline v rozhraní Správa disků Operace s virtuálními disky S virtuálními disky lze provádět několik typů operací. Avšak nelze provádět tyto operace s virtuálními disky, které jsou přidružené k počítači s vytvořenými snímky, u nějž je povolena replikace či je spojen s rozdílovým virtuálním diskem. Nejproblematičtějším ze zmíněných požadavků je v produkčním prostředí samozřejmě nemožnost manipulovat s virtuálním diskem, který je replikován. Zrušení replikace a následně její opětovné povolení vyžaduje provedení iniciální replikace, jejíž proces může být často zdlouhavý, zvláště pokud jsou virtuální disky velké v řádu terabajtů. Samozřejmě, že lze za normálních okolností použít jako iniciální repliku původní virtuální disk repliky, který po zrušení replikace zůstal na svém místě, avšak toto lze provést pouze za předpokladu, že se jedná o stejný virtuální disk se stejnými parametry, jako má virtuální disk na primární straně. Komprimace Jak bylo popsáno v příslušné kapitole, dynamický virtuální disk s přibývajícími daty narůstá, avšak při redukci objemu dat na tomto virtuálním disku již svou velikost nezmenšuje. Prostřednictvím tohoto nástroje je možné dynamický virtuální disk zmenšit. Samotný proces zmenšení však mohou provázet komplikace. Virtuální disk v některých případech nemusí být možné zmenšit či může jít zmenšit pouze o zlomek volného místa. Tento problém mohou zapříčinit zejména stínové kopie. V takovém případě smažte veškeré stínové kopie a zkuste zmenšit virtuální disk znovu. Převod Virtuální disky je možné konvertovat mezi různými formáty (VDH, VHDX) a typy (pevné velikosti, dynamicky se zvětšující). Tento převod lze jako většinu operací provést v PowerShellu pomocí příkazu, respektive cmdletu Convert-VHD. 48

49 Zvětšení/Zmenšení Operace zvětšení či zmenšení velikosti virtuálního disku jsou poměrně hojně využívané operace. Zvětšení Operace zvětšení je vcelku triviální. Jde pouze o výběr požadovaného virtuálního disku a nastavení nové velikosti. Aby však bylo možné toto volné místo využít, je nutné zvětšit stávající diskový oddíl či vytvořit oddíl nový. Zmenšení Zmenšení virtuálního disku je o něco komplikovanější než předchozí operace. Virtuální disky lze zmenšovat pouze o místo, které není alokované. Tudíž před zmenšením virtuálního disku pomocí tohoto nástroje je ve většině případů nutné uvnitř tohoto konkrétního virtuálního disku zmenšit diskový oddíl a uvolnit tím požadované místo. V operačním systému Windows Server 2012 lze toto provést přímo v nástroji Správce disků, avšak například v operačním systému Windows Server 2003 toto možné není. V takovýchto případech je nutné použít software pro správu diskových oddílů, jakým je například program GParted. Po zmenšení diskového oddílu a uvolnění požadovaného místa je možné použít nástroj na zmenšení virtuálního disku. Proces zmenšení však mohou provázet komplikace stejně jako v případě komprimace. Zde je řešení stejné. Smažte stínové kopie a spusťte proces zmenšení znovu. Nástroj GParted je dostupný zdarma na následující adrese: (Gnome Partition Editor). 6.4 Export/Import virtuálního počítače Virtuální počítač je možné exportovat či importovat. Tato funkčnost umožní velmi jednoduchým způsobem přenést kompletní virtuální počítač například na externí pevný disk a importovat ho do jiného serveru. Export Export je velmi jednoduchou záležitostí. Stačí pouze vybrat konkrétní virtuální stroj, kliknout ve správci technologie Hyper-V na příslušnou položku a vybrat umístění, kam je žádoucí virtuální stroj exportovat. V tomto umístění se poté vytvoří struktura složek, do nichž se konkrétní virtuální stroj exportuje. Součástí exportu jsou virtuální disky, konfigurační soubory virtuálního počítače a také snímky tohoto virtuálního stroje. 49

50 Import Import virtuálního počítače provází několik kroků. Po vybrání složky s exportovanými konfiguračními soubory virtuálního stroje přichází na řadu volba, od níž se odvíjí například ID virtuálního stroje. Možnosti jsou následující: o Zaregistrovat Volbu zaregistrovat zvolíme v případě, pokud máme soubory virtuálního počítače na požadovaném místě a chceme začít virtuální počítač používat z aktuálního umístění (v tomto případě se ID počítače nemění). o Obnovit Tato volba také nechává ID počítače nezměněné, ovšem je možné zvolit umístění jednotlivých souborů virtuálního stroje. Do tohoto umístění jsou soubory nejprve nakopírovány a poté je virtuální počítač zaregistrován. o Zkopírovat Zkopírováním virtuálního stroje se vygeneruje nové ID počítače a je též možné ručně definovat umístění jednotlivých souborů. Tímto způsobem lze vytvářet nové virtuální stroje, dá se říci, zkopírováním ze šablony. 6.5 Snímky/kontrolní body Nejprve bych rád objasnil terminologii v této oblasti. Snímky (snapshots) či kontrolní body (checkpoints). Tyto termíny způsobily zmatek v mysli nejednoho člověka a přitom jde o dva různé termíny označující stejnou funkčnost. V Hyper-V v operačním systému Windows Server 2012 se používá termín snímek (snapshot), avšak v nástrojích Systém Center Virtual Machine Manager (SCVMM) pro tento operační systém se pro tuto funkčnost využívá termín kontrolní bod (checkpoint). Toto bylo velmi matoucí a lidé volali po nápravě. Byli vyslyšeni a ve Windows Server 2012 R2 termín snímek (snapshot) nahradil termín kontrolní bod (checkpoint). Zmatek může také nastat okolo formátů virtuálních disků a jejich typů. Hyper-V využívá speciální typ rozdílových disků zvaný advanced virtual hard disk, historicky označovaný jako soubor AVHD. [[2]] Máme dva formáty virtuálních disků ve Windows Server 2012 a máme dva druhy AVHD souborů jim odpovídající. Jakýkoliv virtuální disk typu VHD získá AVHD soubor AVHD formátu s.avhd souborovou příponou. Jakýkoliv virtuální disk typu AVHDX získá AVHD soubor AVHDX formátu s.avhdx souborovou příponou. Toto může být zprvu matoucí, jelikož AVHD je obecný pojem označující jak formát AVHD, tak formát AVHDX. [[2]] Snímky virtuálních strojů umožňují zachytit stav konkrétního virtuálního stroje v čase. Při vytvoření snímku virtuálního stroje je zachycen nejen stav virtuálního stroje jako 50

51 takového, ale také jeho konfigurace. Pokud například dojde po vytvoření snímku k navýšení paměti u virtuálního stroje a poté je daný snímek aplikován a virtuální stroj se vrátí do předchozího stavu, bude virtuální paměť tohoto stroje opět snížena. Při vytvoření snímku virtuálního stroje se u každého virtuálního disku tohoto stroje vytvoří soubor AVHDX a virtuální stroj začne používat tyto AVHDX soubory jako své virtuální disky. Toto si lze ověřit v nastavení virtuálního stroje, kde budou místo virtuálních disků připojeny soubory AVHDX. Tyto soubory jsou ve vztahu nadřazený-podřazený s virtuálními disky. První snímek virtuálního stroje má jako nadřazený disk virtuální pevný disk tohoto stroje. Další vytvářené snímky se budou řetězit, a to tím způsobem, že nově vytvořený snímek bude mít jako svůj nadřazený virtuální disk AVHDX soubor předchozího snímku. Toto chování je stejné jako u rozdílových virtuálních disků. Po vytvoření snímku jsou data čtena z umístění, které je dané časem vytvoření těchto dat. Budeme-li mít jeden snímek u virtuálního stroje, budou data vytvořená před pořízením snímku čtena ze souboru virtuálního disku a data pořízená po vytvoření snímku budou čtena ze souboru AVHDX. Veškerá data vytvořená po realizaci snímku budou zapisována do souboru AVHDX. Toto chování znázorňuje ilustrační obrázek níže.[2] Je možné vytvářet celé stromy snímků virtuálních počítačů. Jeden takový strom může být tvořen až padesáti snímky (toto je limit snímků jednoho virtuálního stroje). Důrazně se však doporučuje minimalizovat počet snímků u virtuálních počítačů a nepoužívat snímky v produkčním prostředí. Snímky degradují výkon virtuálního stroje a je s nimi také spojeno riziko, které pramení z jejich narůstající velikosti. Jelikož soubory AVHDX mohou neomezeně růst, může nastat situace (zvláště u serverů, kde dochází k velkým změnám dat), kdy AVHDX soubor zcela zaplní celý LUN a tím dojde k zastavení veškerých virtuálních strojů na tomto LUNu uložených. Snímky virtuálních strojů lze také samozřejmě mazat. Snímky je možné mazat jednotlivě nebo je možné smazat konkrétní větev či celý strom. Při mazání snímku dochází ke slučování dat v souborech AVHDX s virtuálními disky. Tuto operaci lze nově v operačním systému Windows Server 2012 provádět za běhu virtuálního stroje. Dříve bylo nutné virtuální stroj nejprve vypnout.[2] 51

52 Obrázek 9: Snímky/kontrolní body Zdroj: [2] 52

53 7 Komplikace a nedostatky Při implementaci navrženého řešení nastaly nejrůznější problémy, které bylo nutné řešit. Problémy, které se naskytly, bylo možné řešit dalšími investicemi do hardwaru či softwaru, avšak bylo žádoucí se těmto dalším investicím vyhnout zcela či je alespoň zásadně minimalizovat. 7.1 Replikace Replikace je velmi užitečnou funkcí Hyper-V, avšak poměrně náročnou na hardware, konkrétně na datová úložiště. V tomto scénáři se provádějí replikace křížem, ze serveru SERVER1 na server SERVER2 a naopak. Obrázek 10: Replikace Zdroj: autor Ve Windows Server 2012 je interval replikace stanoven na 5 minut. To znamená, že každých 5 minut se začnou odesílat změny provedené na konkrétním serveru na primární straně na server repliky. Na tomto serveru, jakmile jsou změny přijaty, začne proces slučování. Avšak není-li slučování dokončeno před dalším zasíláním změn, nastává problém, jelikož je proces sloučení přerušen a na serveru repliky se začínají hromadit data obsahující 53

54 změny na serveru na primární straně. Toto může vyústit až v zaplnění disků na straně repliky a v zastavení virtuálních serverů na tomto úložišti běžících. Samozřejmě, že zastavení serverů na straně repliky by bylo možné vyloučit rozdělením úložiště na dva LUNy, avšak toto by vedlo k poměrně velkému omezení flexibility v případě nutnosti migrace serverů a podobně. Je tu také další faktor, který znemožňuje provoz replikace tak, jak byla navržena. Jelikož tato architektura středu sítě, jak je navržena, zahrnuje pouze dvě úložiště pro více než 20 virtuálních serverů, je výkon těchto úložišť nedostačující při povolení replikace na všech virtuálních serverech. Proces slučování je velmi náročný a při slučování na více serverech téhož úložiště dochází k nárůstu fronty na vstupně-výstupní operace a k poměrně velké degradaci výkonu na běžících virtuálních serverech. Replikace jako taková je opravdu velkým plus technologie Hyper-V, zvláště pokud vezmeme v úvahu, že řešení replikace od třetích stran je velmi nákladná záležitost a v prostředí Windows Server 2012 je dostupná zcela zdarma. Avšak pro bezproblémový chod musí mít dostatečné prostředky. V tomto prostředí byla technologie replikace velmi žádoucí, jelikož poměrně výrazným způsobem umožňuje urychlit proces zotavení v případě havárie, ale nebylo možné ji implementovat tak, jak byla navržena. Replikace, která je součástí Hyper-V ve Windows Server 2012, není příliš konfigurovatelná. Některé možnosti přibyly ve Windows Server 2012 R2, avšak ani ty by zmíněný problém neřešily. V době implementace tohoto řešení také nebyl tento operační systém ještě na trhu Řešení Ačkoliv v nadpisu stojí řešení, nejde o řešení v pravém slova smyslu, avšak spíše o takzvaný workaround s kompromisem, jelikož toto řešení sice umožňuje provoz replikace, ale ve velmi prodloužených intervalech. Tohoto je dosaženo pravidelným spouštěním vytvořeného PowerShell skriptu. Tento skript se spouští jednou denně v noci, aby v denních hodinách neomezoval provoz na produkčních serverech. Pokud však budou v budoucnosti zakoupena další úložiště, je možné intervaly mezi replikacemi zkrátit a tím také zkrátit případnou dobu zotavení po havárii či skript úplně vyřadit a používat replikaci tak, jak byla navržena. Skript funguje následujícím způsobem: 1) Po spuštění skriptu je spuštěn příkaz Reset-VMReplicationStatistics. Toto je prováděno zejména z důvodu, aby bylo možné monitorovat úspěšně provedené replikace jednotlivých virtuálních strojů. 54

55 2) Následně je spouštěna replikace jednoho virtuálního stroje, který se replikuje, dokud není proveden určitý počet úspěšných replikačních cyklů dle požadavků. V tomto případě jsou to pouze dostačující dva replikační cykly. Až virtuální server dosáhne zmíněného počtu úspěšných replikací, je u tohoto serveru replikace pozastavena a následně je spuštěna replikace u následujícího serveru. Replikace se mohou spouštět tímto způsobem po jednom serveru nebo po skupinách o více serverech. Toto záleží na výkonnosti datových úložišť a také na propustnosti sítě. Počet úspěšných replikací lze zjistit následujícím příkazem respektive cmdletem (termín cmdlet je dle společnosti Microsoft korektní pojmenování příkazu pro PowerShell): Measure-VMReplication název_serveru Select SuccReplCount 3) Při vytváření funkce, která pozastavuje replikaci u konkrétních virtuálních serverů, je potřeba implementovat kontrolu, zda je replikace opravdu pozastavena. Toto lze zjistit následujícím příkazem (cmdletem): Measure-VMReplication název_serveru Select State 4) Při ukončení replikace posledního serveru je odesílán se statistikami replikací pro případnou kontrolu či analýzu. Tato data jsou generována opět pomocí příkazu Measure-VMReplication, který má velké množství parametrů, a tudíž lze o průběhu replikace zjistit poměrně mnoho informací. Více o tomto příkazu lze nalézt na následující adrese: Výstup tohoto cmdletu lze poměrně dobře formátovat pro potřeby u pomocí příkazu ConvertTo-Html (více na Takto vytvořený script již stačí pouze vložit do plánovače úloh a pravidelně spouštět. Do plánovače úloh je však nutné vložit cestu k tomuto scriptu jako argument a do cesty pro program, který má být spouštěn, vložit následující cestu k PowerShellu: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Toto chování je odlišné od spouštění dávkových souborů, které je možné prostřednictvím plánovače úloh spouštět přímo. 55

56 7.2 RDS shadowing Funkce shadow neboli stínování (shadowing) byla na terminálových serverech přítomna již od verze Windows Server Jedná se o velmi užitečnou a velice využívanou funkci. Shadowing umožňuje jednomu uživateli takzvaně stínovat relaci uživatele jiného. To v praxi znamená, že se jeden uživatel vzdáleně připojí k relaci jiného uživatele, aniž by tuto relaci převzal. Tato funkce je široce využívána v nejrůznějších společnostech, kde se používá například pro účely podpory. V operačním systému Windows Server 2012 došlo ke kompletnímu přetvoření koncepce terminálových služeb. Od této verze operačního systému je architektura terminálových služeb od základu změněna a nyní místo těchto služeb můžeme na serveru najít RDS (Remote Desktop Services) v poněkud odlišném pojetí. Více o těchto službách je možné nalézt například na (Remote Desktop Services Overview). S příchodem RDS však nastal v mnoha společnostech obrovský problém. Drtivá většina firem nakoupila nové operační systémy Windows Server 2012 a až posléze došly k zjištění, že v tomto operačním systému shadowing, který využívají desítky až stovky zaměstnanců, chybí. Těmto společnostem nezbývalo nic jiného než zůstat u starších operačních systémů nebo investovat další peníze do softwaru, který by tuto funkčnost nahradil. Tímto počinem Microsoft sklidil vlnu kritiky. Avšak netrvalo dlouho a na internetu se objevily zprávy o příchodu nového operačního systému Windows Server 2012 R2, v němž bude shadowing opět implementován. Windows Server 2012 R2 opravdu vyšel, shadowing se s ním vrátil, ale opět nenaplnil očekávání. Tento operační systém je dražší než Windows Server 2012, nebylo možné na něj pouze upgradovat stávající Windows Server 2012 a shadowing sice umožňuje, avšak umožňuje ho pouze administrátorům. Toto omezení je velmi limitující a bylo nutné nalézt řešení Řešení Ačkoliv se zdálo, že funkci shadow nebude možné zprovoznit pro běžné uživatele (bez oprávnění administrátora) bez softwaru třetí strany, řešení se našlo, ačkoliv bylo nutné dokoupit pro terminálové servery dva nové operační systémy Windows Server 2012 R2. 56

57 Velké díky patří člověku vystupujícímu pod přezdívkou TP [] na fóru společnosti Microsoft. Jeho příspěvek na TechNet fóru lze najít na této adrese: 0d f9d-accd-e2504e5f4908/ rds-2012-configure-permissions-for-remote-desktop-services-connections (RDS 2012 Configure Permissions for Remote Desktop Services Connections) Jak se můžete dočíst na zmíněném fóru, řešením problému s oprávněními je spuštění následujícího příkazu na serveru plnící funkci Remote Desktop Session Host: wmic /namespace:\\root\cimv2\terminalservices PATH Win32_TSPermissionsSetting WHERE (TerminalName="RDP-Tcp") CALL AddAccount "domain\group",2 Samozřejmě je nutné nahradit zvýrazněný název domény a skupiny. Po aplikování tohoto příkazu bude dostupné stínování relace nejen pro administrátory, avšak pouze prostřednictvím příkazového řádku, a to příkazem: mstsc /v:server /shadow:uživatel /control Místo parametru server je nutné napsat jméno terminálového serveru, na kterém chceme uživatele stínovat. Tuto část však lze vynechat, pokud chceme stínovat uživatele na stejném terminálovém serveru, jako se právě nacházíme. Místo uživatel je nutné napsat ID uživatele, kterého chceme stínovat. Toto ID je možné získat například pomocí příkazu quser. Ačkoliv se toto řešení může zdát jako dostačující, pro mnoho uživatelů je nevhodné. Například pro uživatele s menší počítačovou gramotností či uživatele vyžadující komfort grafického uživatelského prostředí. I toto se však dá řešit, a to prostřednictvím PowerShellu a Windows Forms. Windows Forms umožňují vytvoření frontendu jak k nejrůznějším aplikacím, tak například ke skriptům. Je možné využívat rozličné elementy od takzvaných checkboxů přes nejrůznější okna až po tlačítka. Možnosti jsou opravdu široké, avšak sestavení komplikovanějšího rozhraní určitého skriptu pouze prostřednictvím kódu může být poměrně složité. Jak vzhledem k pozicování určitých prvků, tak vzhledem k množství parametrů jednotlivých elementů. Je však možné použít software, který umožňuje takovýto frontend vygenerovat. Jedná se například o zdarma stažitelný nástroj od společnosti SAPIEN Technologies, Inc. zvaný PrimalFormsCE dostupný na následující webové adrese: Tento software umožňuje 57

58 vygenerovat editorem vytvořené prostředí. Jedná se o velmi jednoduchý nástroj, který však svůj účel splní, i když má své nedostatky. Komplexnější funkce nabízí například PowerShell Studio 2012 ( avšak tento nástroj je komerční. Konečné řešení spočívá v parsování výstupu příkazu quser, který vypisuje přihlášené uživatele na daném serveru, jejich ID a další údaje. Tato data tvoří základ pro nástroj na stínování uživatelských relací. Pomocí IDE PrimalFormsCE bylo vytvořeno rozhraní pro výpis přihlášených uživatelů na konkrétním serveru a volbu požadované funkce. Zbytek byl naprogramován pomocí PowerShellu. Z výsledného skriptu byl vygenerován exe soubor nástrojem PS2EXE, který lze nalézt na následující webové adrese: Vygenerování exe souboru by nebylo vysloveně nutné, avšak kód skriptu byl v poslední fázi upraven a obohacen o určité funkčnosti týkající se specifických aplikací běžících na terminálových serverech, které nejsou dostupné všem uživatelům, tudíž bylo vhodné kód skriptu skrýt. Vzniknuvší nástroj byl nejprve otestován skupinou počítačově gramotnějších lidí na vyhrazeném terminálovém serveru a po odlazení byl nasazen na všech terminálových serverech. Nástroj umí vypisovat přihlášené uživatele na jednotlivých terminálových serverech, umí tyto uživatele třídit či prohledávat, obsahuje funkce pro shadowing, umí také uživatele odhlašovat a bylo též naprogramováno několik funkcí specifických pro potřeby společnosti, v níž bylo toto řešení implementováno. Ve výsledku se dá říci, že tento nástroj přesahuje funkčnosti nástroje pro shadowing zabudovaného ve Windows. 7.3 Problémy s úloţištěm Po několika málo měsících provozu nastaly bohužel problémy se síťovým úložištěm. Zařízení QNAP se začalo samovolně restartovat v intervalech několika dnů. Po restartu však nebylo opět funkční, jelikož iscsi Target nebyl automaticky připojen a nebylo ho možné připojit ani ručně. Řešením bylo ruční restartování zařízení, po němž úložiště začalo opět správně pracovat. Toto však nebylo akceptovatelné v produkčním prostředí, tudíž se všechny virtuální servery z tohoto úložiště přesunuly na síťové úložiště druhé. Z kolabujícího úložiště byly vyjmuty pevné disky a úložiště bylo reklamováno. Vzhledem k faktu, že vyřešení reklamace je poměrně zdlouhavá záležitost, bylo vhodné zajistit zařízení, na něž by se daly replikovat servery nyní běžící na jediném úložišti. Z vyřazeného serveru, diskového řadiče LSI a disků vyjmutých z úložiště bylo sestaveno provizorní zařízení, na něž byly prováděny 58

59 repliky. Po necelých dvou měsících se úložiště vrátilo zpět s vyměněnou základní deskou. Bylo zařazeno zpět do infrastruktury a vše se vrátilo do původního stavu. Netrvalo však dlouho a scénář se opakoval. Další samovolné restarty zařízení vyústily v další reklamaci tohoto úložiště a opět byl zahájen provoz v havarijním režimu s provizorním úložištěm. Uplynulo několik týdnů a nastala další nepříjemná situace, kdy vyhořel jeden z pevných disků na druhém úložišti QNAP. Disk byl opravdu ohořelý a tudíž bylo poměrně velké štěstí, že nebyl poškozen backplane. Pevný disk byl vyměněn za jiný a díky RAID10 nedošlo k žádné ztrátě dat. Další problém, který se vyskytl v souvislosti s úložišti QNAP, se týkal disků v těchto úložištích. Čas od času zahlásilo úložiště u některého z disků Fatal or unknown error. či Read-I/O-error, UNRECOVERED READ ERROR. Tyto pevné disky však nevykazovaly žádné abnormální chování, natož pak známky poškození. Po vyjmutí a opětovném vložení do úložiště nedocházelo k žádné změně, avšak pokud byl pevný disk vyjmut, otestován nástrojem od výrobce (který neprokázal žádnou závadu) a vložen zpět do síťového úložiště, již nevykazoval žádné chyby. Poměrně problematickou bych také nazval situaci týkající se firmwaru zařízení od společnosti QNAP Systems. Výrobce například uvolnil novou verzi firmwaru, kterou musel vzápětí stáhnout kvůli mnoha problémům, s nimiž se uživatelé potýkali. Celkově bylo nasazení těchto úložišť poněkud nešťastné. Když pominu veškeré problémy s tímto úložištěm spojené a pohlédnu na funkce, jež toto zařízení od společnosti QNAP Systems nabízí, není určené pro tento typ použití. Obsahuje příliš mnoho z pohledu implementované architektury nepotřebných funkčností, jako je například web server, MySQL server, možnost nastavení sdílených složek a další. Pro tuto koncepci by bylo vhodnější zařízení jednodušší, které by disponovalo funkčnostmi, jež se týkají zejména monitoringu zařízení, notifikací či podporou protokolů, jako je iscsi Serverové disky Při první reklamaci úložiště QNAP, kdy na druhém úložišti běžely všechny servery, bylo možné pozorovat zhoršené odezvy virtuálních serverů na různé operace související se čtením či zápisem na diskové úložiště. Bylo nutné kalkulovat s faktem, že tento havarijní provoz související s reklamací úložiště může mít delší trvání či se bude opakovat, a tak bylo nutné nějakým způsobem odlehčit síťovému úložišti. Bylo tedy rozhodnuto o nákupu pevných disků pro servery DELL, jelikož každý z těchto serverů měl v tuto chvíli po šesti volných 59

60 diskových pozicích. Bylo nakoupeno dvanáct pevných disků, po šesti discích do každého serveru. Konkrétně šlo o následující pevné disky: 12x Seagate Cheetah 15K.7 600GB 2,5", RPM, SAS 6Gb/s, 16MB cache Tyto disky byly nakonfigurovány v rozhraní DELL System Setup stejným způsobem jako systémové pevné disky, avšak s tím rozdílem, že těchto šest disků tvoří jeden virtuální disk v RAID10 s 512KB Strip Element Size namísto RAID1 s 256KB Strip Element Size, jako je tomu v případě disků určených pro operační systém serveru. Tímto způsobem byly osazeny oba servery DELL. Tyto disky bylo opět nutné vyloučit podle cesty z prohledávání antivirovým programem a též byla na nich vytvořena adresářová struktura, jakou využívá Hyper-V pro ukládání virtuálních disků, konfiguračních souborů virtuálních strojů, snapshotů a podobně. Pokud bude všude dodržována stejná struktura ukládání těchto souborů, poměrně výrazným způsobem dojde ke zjednodušení správy virtuálních strojů. Například migrace virtuálních serverů je poté méně komplikovaná a přehlednější. Zkopírovat pouze adresářovou strukturu lze například pomocí nástroje robocopy v příkazovém řádku: robocopy (zdroj) (cíl) /e /z /xf * Samozřejmě, že pokud tato adresářová struktura již obsahovala nějaké virtuální stroje, bude potřeba ji pročistit. Řešení, kdy je pro ukládání zmíněných souborů využíváno stejných adresářových struktur, má však ještě jedno úskalí. Problém se projeví, pokud je potřeba vytvořit nový virtuální stroj na jiném úložišti, než na jaké je nastavena výchozí složka v Nastavení technologie Hyper-V. Do těchto složek lze virtuální stroj lehce importovat, ale již zde nelze korektně vytvořit s rozložením souborů do složek tak, jak je ve výchozím nastavení ukládá Hyper-V. Toto by mělo být v Hyper-V dle mého názoru řešeno lépe. Zmíněné chování lze obejít například dočasnou změnou výchozí složky v Nastavení technologie Hyper-V (toto však není zrovna čisté řešení) nebo si lze pro tento účel vytvořit script v PowerShellu. Druhá možnost je vhodnější a může také zlepšit efektivitu práce při vytváření virtuálních serverů. Takto vzniknuvší prostor poslouží jako poměrně výkonné úložiště pro vytíženější a prostorově méně náročné servery, jako jsou například terminálové servery. Tímto dojde také k rozložení zátěže mezi úložišti. Výsledná koncepce včetně zařízení QNAP vypadá následně takto: 60

61 Obrázek 11: Serverové disky Zdroj: autor JBODy Vzhledem ke komplikacím, které provázely provoz úložišť QNAP, bylo vhodné se poohlédnout po jiných zařízeních. Nákup nových zařízení měl také ulevit stávajícím úložištím rozložením zátěže na více prvků. Po zkušenostech s úložištěm QNAP bylo žádoucí najít co nejjednodušší řešení, které by bylo zároveň co nejspolehlivější. Z požadavku na jednoduchost vzešel jednoznačný vítěz a tím se stal JBOD. Toto řešení je dostatečně jednoduché, jelikož neobsahuje téměř nic navíc, a s trochou nadsázky lze JBOD označit jako krabici s disky. Tomuto také odpovídá označení JBOD, které je akronymem anglického slovního spojení Just a Bunch Of Disks. Na rozdíl od nejrůznějších síťových úložišť typu QNAP TS-EC1279U-RP, JBOD neobsahuje žádnou základní desku s procesorem či paměťmi stejně jako neobsahuje žádný operační systém. Nemá příliš mnoho komponent, tudíž se toho může o to méně pokazit. Dalším faktorem je cena, která je výrazně nižší například oproti úložišti QNAP. JBOD je úložiště typu DAS (Direct Attached Storage) a lze je označit jako finančně nejvýhodnější řešení, pokud je třeba rozšířit interní kapacitu serverů. Vzhledem ke kladným zkušenostem 61

62 s produkty společnosti SuperMicro a příznivé ceně JBODu od této společnosti padla volba na tento produkt. Konkrétně bylo zakoupeno: počet 2x 24x 2x 2x 2x 2x 2x komponenta SuperChassis 826BE16-R920LPB 2TB Toshiba MG03SCA RPM/SAS2 Supermicro AOC-S2208L-H8iR(2208) SAS2RAID(0/1/5/6/10) Supermicro BTR-0024L - SuperCap (CacheVault) Kit pro SAS RAID Remote Battery Mounting Kit pro LSI BBU SF-8087-> SF8088 (kabel 70cm + bracket k E16 backplane) Storage On / Off PWR Control Board Po koupi dvou JBODů SuperMicro dostala architektura jádra IT infrastruktury následující podobu: Obrázek 12: JBODy Zdroj: autor 62

63 V této konfiguraci jsou servery běžící na stroji SERVER1 (na fyzických discích hosta a na JBODu) replikovány na úložiště STORAGE2 a naopak. Úložiště QNAP jsou nyní z důvodu malé spolehlivosti využívána pouze pro repliky virtuálních strojů. Aby bylo možné tyto JBODy připojit, bylo nutné přidat do serverů DELL další diskové řadiče LSI s rozhraním SAS. Prostřednictvím tohoto rozhraní byly JBODy připojeny k serverům. Po instalaci řadičů do serverů však nastal problém. Po spuštění serveru se objevila zpráva Plug and play Configuration Error: Option ROM Shadow RAM Allocation error. a server odmítal nabootovat. Avšak tento problém byl jednoduše vyřešen. Síťové karty, jimiž servery disponují, mají ve výchozím nastavení zapnutou volbu PXE boot, která umožňuje zavádět operační systém skrze počítačovou síť. Tato funkčnost je však při tomto nasazení nepotřebná, a tak ji bylo možné na všech síťových kartách vypnout. Tímto bylo zamezeno načítání nepotřebných Option ROM síťových karet, čímž vznikl dostatečný prostor k tomu, aby byla Option ROM nového řadiče korektně načtena a systém byl spuštěn. Před samotným počátkem využívání těchto úložišť je bylo nutné nejprve nakonfigurovat. Konfigurace byla provedena stejně jako v případě interních disků serveru prostřednictvím prostředí System Setup. V tomto rozhraní je nyní možné konfigurovat také nový řadič LSI. Tudíž byl zvolen tento řadič a byl vytvořen nový virtuální disk v RAID10, u kterého byla nastavena Write Policy na Write Back a Strip Element Size na 512KB. Z dvanácti disků v RAID10 vznikl zhruba 11TB velký virtuální disk. Tento prostor byl stejně jako v případě ostatních úložišť, která byla konfigurována, inicializován (GPT), naformátován (NTFS) a také na něj byla zkopírována příslušná adresářová struktura. Též bylo nutné přidat výjimku do antivirového programu jako v případě ostatních úložišť virtuálních disků. 63

64 8 Nástroje V této kapitole bych rád zmínil některé nástroje, které mohou být při správě virtuálních serverů užitečné. Některé z uvedených nástrojů nejsou omezené pouze na virtuální prostředí a najdou využití i v klasickém nasazení. 8.1 PowerShell PoweShell je velmi mocným nástrojem. Pokud využíváte Windows Hyper-V Server, který neobsahuje grafické prostředí, neobejdete se bez něj. Pokud využíváte plnohodnotný operační systém Windows Server, například jako v tomto případě, PowerShell již bezpodmínečně nepotřebujete, avšak i tak může být velmi užitečným pomocníkem. Umožní vám nejen například automatizovat rutinní úlohy, ale také obsahuje některé nástroje a volby, které nejsou dostupné prostřednictvím grafického prostředí Základní nastavení Aby bylo možné spouštět vlastnoručně vytvořené skripty, které nejsou podepsané důvěryhodným vydavatelem, je nutné správně nastavit takzvanou execution policy příkazem Set-ExecutionPolicy. Více o tomto nastavení lze nalézt na stránkách Microsoftu: (Set-ExecutionPolicy) Uţitečné příkazy (cmdlety) Na adrese (Hyper-V Cmdlets in Windows PowerShell) lze nalézt seznam příkazů, v prostředí PowerShell zvaných cmdlets, týkajících se Hyper-V. Existuje mnoho užitečných cmdletů, jako například cmdlet Measure-VMReplication, který byl zmíněn v kapitole týkající se replikace. Vzhledem k jejich množství zde uvedu pouze několik příkazů týkajících se jednoho užitečného nástroje. Každopádně bych každému systémovému správci doporučil, aby na PowerShell nezanevřel. Nabízí některé funkčnosti, jež nejsou dostupné prostřednictvím grafického rozhraní, a dokáže rychle a elegantně řešit pestrou škálu úkolů či problémů. 64

65 Statistiky využití hardwarových zdrojů Pro optimální nastavení hardwarových zdrojů virtuálních strojů je nutné mít přehled o zdrojích, které tyto virtuální stroje využívají. K tomu může posloužit také takzvaný VMResourceMetering. Zapnutí této funkčnosti na všech virtuálních strojích daného hosta lze provést následujícím příkazem respektive cmdletem: Enable-VMResourceMetering VMName * nebo Get-VM Enable-VMResourceMetering Od okamžiku zapnutí této funkčnosti budou evidovány statistiky týkající se spotřeby hardwarových prostředků jednotlivých virtuálních strojů. Tyto statistiky lze zobrazit pomocí následujícího příkazu: Measure-VM -VMName * nebo Get-VM Measure-VM VÝSTUPNÍ POLOŢKY AvgCPU(MHz) AvgRAM(M) MaxRAM(M) MinRAM(M) průměrné vytížení procesoru (v MHz) průměrné množství alokované paměti RAM (v MB) maximální množství paměti RAM, které bylo alokováno (v MB) minimální množství paměti RAM, které bylo alokováno (v MB) Pokud je paměť přidělována staticky, mají tyto údaje vždy stejnou hodnotu, a to hodnotu paměti, jež byla přidělena. Tyto údaje mají tudíž vypovídající hodnotu zejména při dynamickém přidělování paměti. 65

66 TotalDisk(M) vyjadřuje množství alokovaného diskového prostoru (v MB) Tento údaj vykazuje množství diskového prostoru, který je alokován na úložištích. Údaj TotalDisk obsahuje sumu virtuálních disků daného virtuálního stroje. Nevykazuje však využití diskového prostoru v rámci samotných virtuálních disků v případě použití virtuálních disků pevné velikosti. NetworkInbound(M) NetworkOutbound(M) síťový datový tok příchozí (v MB) síťový datový tok odchozí (v MB) Jelikož je zpravidla potřeba získat tyto statistiky v určitém časovém horizontu, je zde také možnost vyresetování těchto statistik. Toto je možné provést následujícím příkazem: Reset-VMResourceMetering VMName * nebo Get-VM Reset-VMResourceMetering Toto byl základní pohled na tento nástroj. Samozřejmě, že umožňuje více. Například lze vypsat takzvaný NetworkMeteredTrafficReport konkrétního virtuálního stroje: (get-vm -VMName název_virtuálního_stroje Measure-VM).NetworkMeteredTrafficReport Nebo je možné zjistit konkrétní čas, po který je konkrétní virtuální stroj sledován. Toto je možné následujícím příkazem: (get-vm -VMName název_virtuálního_stroje Measure-VM).MeteringDuration Další informace týkající se příkazů (cmdletů) PowerShellu lze získat například na již zmíněných webových stránkách TechNetu. (Znak * u všech zmíněných příkazů lze samozřejmě nahradit názvem virtuálního stroje a povolit, měřit či resetovat pouze tento virtuální stroj.) 66

67 8.2 Zálohování Zálohování serverů je velmi důležitou a nezbytnou procedurou. Avšak v praxi je možné se čas od času setkat s lidmi, kteří tuto proceduru ne úplně dobře pochopili. Překvapivě poměrně často se objeví názory, že pokud například provozuji diskové pole a využívám RAID (nepočítám zde RAID 0), zálohování není třeba. Nebo pokud jsou servery prostřednictvím Hyper-V replikovány, jsou vlastně zálohované. Ani jedno z těchto tvrzení není pravdivé. Také se lze setkat s praktikami, kdy jsou snímky virtuálních disků používány jako nástroj zálohování. Toto je též velmi špatné počínání systémového administrátora. Snímky, resp. kontrolní body, nejsou v žádném případě vhodné pro zálohování. Zálohování by mělo probíhat na externí médium, které by mělo být uchováváno na bezpečném místě jak z pohledu ochrany před vnějšími vlivy, tak z pohledu ochrany před neoprávněným přístupem k těmto datům. Nebudu zde však uvádět konkrétní přístupy k zálohování či specifická řešení tohoto procesu, jelikož je tato problematika příliš rozsáhlá a není přímo předmětem této práce. Zmíním však alespoň službu zvanou Volume Shadow Copy Service neboli VSS Volume Shadow Copy Service (VSS) Volume Shadow Copy Service (VSS) je soubor COM API, jenž implementuje framework, který umožňuje provedení zálohy svazku, zatímco aplikace pokračují v zápisu na tyto svazky. VSS poskytuje konzistentní rozhraní, to umožňuje koordinaci mezi uživatelskými aplikacemi, jež upravují data na disku (writers), a těmi, co tyto aplikace zálohují (requesters). [6] Více o této službě lze nalézt například na následující webové adrese: (Volume Shadow Copy Service). Diagram na následující adrese poměrně přehledně zobrazuje proces zálohování prostřednictvím VSS: (Overview of Processing a Backup Under VSS). Tato služba je velmi užitečná, jelikož jak již bylo zmíněno, umožňuje zálohovat celé virtuální stroje za běhu. Toto je zcela zásadní funkčnost vzhledem k faktu, že většinou není možné každý den zastavit běh virtuálního stroje z důvodu běhu zálohovacího procesu. Nedá se říci, že všechny aplikace podporují VSS a mají implementovanou komponentu zvanou VSS writer, která umožňuje vytvoření konzistentní zálohy, avšak mnoho aplikací určených 67

68 pro podnikové nasazení těmito komponentami již disponuje. Tato funkčnost je velmi důležitá například u databázových systémů, jelikož konzistence je u databází stěžejní. Například Microsoft SQL Server zahrnuje komponentu zvanou VSS writer. 8.3 Sledování prostředků (nástroj Windows) Integrovaný nástroj Windows zvaný Sledování prostředků je velmi užitečnou utilitou, která může mnoho říci o aktuálním dění na serveru a diskových úložištích. Tento nástroj kromě přehledu nabízí čtyři oddělené záložky, které reprezentují procesor, paměť, disk a síť. Dle mých zkušeností byla záložka disk tou nejdůležitější. V tomto prostředí a nejen zde (lze mluvit všeobecně o dnešních zařízeních výpočetní techniky) lze mluvit o datových úložištích jako o nejslabším článku z hardwarových prostředků. Tudíž je více než žádoucí mít přehled o operacích na těchto prvcích probíhajících. V tomto nástroji lze sledovat jednotlivé vstupně-výstupní operace, jejich priority či odezvy. Také je zde možné pozorovat délku fronty jednotlivých úložišť. Tento nástroj může být velmi užitečným pomocníkem při identifikaci nejrůznějších problémů. 68

69 9 Zhodnocení nové infrastruktury V této kapitole zhodnotím infrastrukturu jak z hlediska výkonnostního, zda navržená hardwarová konfigurace splnila požadavky produkčního prostředí, tak z hlediska konceptuálního, zda se i po implementaci jeví tato koncepce jako správná. 9.1 Výkonnostní (CPU, RAM, IOPS) Nebudu zde uvádět žádná čísla či grafy, spíše bych výkon navrženého celku zhodnotil na základě dlouhodobějšího pozorování a testování CPU Dva servery DELL, každý se dvěma procesory (jeden o osmi jádrech), dávají dohromady dostatečný výkon pro provoz několika desítek virtuálních strojů, přičemž jejich zatížení zůstává minimální. Z tohoto pohledu je stav více než vyhovující a dává prostor k vytvoření dalších virtuálních strojů Paměť Z pohledu paměti je stav také vyhovující. Návrh byl v tomto ohledu vytvořen správně a předpoklady nároků virtuálních serverů se naplnily. Servery disponují potřebným množstvím paměti pro plynulý chod všech virtualizovaných serverů. Nejvíce paměti využije bezpochyby SQL server. Dále pak terminálové servery jsou poměrně náročné na paměť (avšak v porovnání s SQL serverem zanedbatelně) a zbytek serverů již spotřebuje průměrné množství RAM. Kvůli zmíněnému SQL serveru bych zde však přece jen navrhl určité vylepšení. Může nastat situace, kdy bude nutné migrovat tento server na jiného hosta a vzhledem k jeho ohromným nárokům na paměť již nebude na tomto cílovém serveru dostatek prostředků, aby bylo možné provést migraci za živa. Tudíž bude nutné tento server vypnout, snížit paměť tohoto virtuálního serveru, server opět zapnout a až poté migrovat. Tomuto výpadku lze zamezit navýšením paměti na hostujících serverech. Aktuální paměť jednoho serveru činí 192 GB, avšak vzhledem k faktu, že je zaplněna pouze polovina slotů z celkových 24, je tuto paměť možné navýšit. 69

70 9.1.3 Úloţiště Největší úzké hrdlo tvoří bezpochyby datové úložiště. Úložiště QNAP zakoupená spolu se servery by poskytovala dostatečný prostor a dá se říci i výkon pro provoz všech virtuálních serverů v tomto podniku, avšak jakékoliv další operace na těchto úložištích v provozu (v pracovních hodinách) by byly nepřijatelné. Těmito operacemi mám na mysli například přesouvání virtuálních strojů, vytváření virtuálních disků pevné velikosti, slučování virtuální disků a podobné úkony. Po rozšíření koncepce o JBODy a po vybavení serverů rychlými pevnými disky došlo k výraznému zlepšení. Dříve zmíněné operace je nyní možné provádět i za provozu. Tímto se také rozšířily možnosti správy virtuální infrastruktury v hlavním provozu a též došlo ke zvýšení odolnosti celého řešení, čímž mám na mysli menší omezení v případě havárie a také rychlejší zotavení po případné havárii. 9.2 Konceptuální Prvotně navržená koncepce byla správná a v praxi se osvědčila. Navzdory minimálním investicím do hardwaru se podařilo postavit poměrně výkonné a odolné jádro podnikové IT infrastruktury. Investice do hardwaru byly opravdu minimální vzhledem k velikosti podniku, počtu uživatelů, serverů a vzhledem k závislosti na tomto infrastrukturním jádře. Finanční prostředky vynaložené na hardware také tvořily pouze zlomek z celkové investice. Zbytek prostředků byl vynaložen za softwarové licence. Tato koncepce je dle mého názoru dobrým základem pro možné inovace či rozšíření tohoto řešení. Některé investiční návrhy uvedu v následující kapitole. 70

71 10 Moţná infrastrukturní zlepšení V této kapitole bych rád uvedl některé investiční návrhy, jež by posílily vybudované infrastrukturní jádro v nejrůznějších ohledech. Například z pohledu výkonu, odolnosti proti výpadku či z hlediska ochrany dat Investice 1: Ochrana dat Z důvodu ochrany dat bych doporučil datová úložiště QNAP vyhrazená pro repliky virtuálních strojů přesunout do jiné části podniku, dále od fyzických serverů. Toto opatření by mělo zajistit ochranu dat v případě havárie, jako je například požár v serverovně. Aby bylo možné tato úložiště přesunout do odlehlejší části podniku, je nutné, aby toto místo mělo vybudovaný adekvátní síťový spoj se serverovnou. Ideálně spoj optický, který by zajistil rychlý a spolehlivý přenos replikací virtuálních serverů napříč podnikem. Z této podmínky síťové konektivity plynou investice. Toto řešení samozřejmě neochrání data, pokud by například požár zachvátil celý podnik. I proti takovéto situaci však lze podniková data ochránit. Je možné například replikovat virtuální servery do datacentra, ale v takovém případě by bylo nutné zřídit kvalitní konektivitu do internetu, která by poskytla dostatečný upload pro přenos replik virtuálních strojů. Též by bylo nutné platit poplatky související s housingem datových úložišť v datacentru. V případě, kdy by se pro replikace virtuálních serverů využila obě zařízení QNAP, bylo by nutné platit poplatky za 4U v racku (velikost jednoho úložiště QNAP je 2U). Toto řešení by však vyžadovalo další investice, zejména paušálního charakteru. Z důvodu minimalizace paušálních nákladů za housing by bylo v tomto případě vhodné zvážit nákup jiného úložiště s dostatečným výkonem a prostorem pro repliky virtuálních strojů a zároveň s minimálními rozměry. 71

72 Obrázek 13: Ochrana dat Zdroj: autor 10.2 Investice 2: Datová úloţiště Datová úložiště jsou, jak jsem již zmínil, úzkým hrdlem tohoto řešení a nákup dalšího hardwaru by se tudíž měl jistě týkat těchto zařízení. Budeme předpokládat, že byla učiněna první investice a úložiště QNAP byla přesunuta od serverů na jiné místo v podniku z důvodu zajištění ochrany dat v případě havárie. V tomto případě jsou tudíž u serverů přítomny pouze JBODy. Lze využít možnosti řetězit JBODy a zakoupit ke každému serveru po jednom JBODu, který by byl identický s JBODem stávajícím z důvodu udržení co nejvyšší homogenity prostředí. V tomto případě by architektura středu sítě vypadala následovně: 72

73 Obrázek 14: Datová úložiště Zdroj: autor Přidání JBODů by zrychlilo diskové operace stávajících serverů, jelikož by se snížil počet vstupně-výstupních diskových operací na jednotlivých úložištích. Zlepšila by se škálovatelnost z pohledu diskové kapacity, a pokud by například došlo k selhání více pevných disků úložiště a rozpadnutí diskového pole, bylo by touto událostí dotčeno méně serverů Investice 3: Rozšíření infrastruktury Tato investice vychází z předpokladu, že byla realizována alespoň první investice týkající se ochrany dat a úložiště QNAP byla přesunuta. Za této situace, kdy jsou úložiště replik virtuálních serverů dostatečně vzdálena od hlavní serverovny, můžeme předpokládat, že tyto repliky zůstanou zachovány v případě například vypuknutí požáru v hlavní serverovně. Po havárii tudíž nedojde ke ztrátě všech virtuálních serverů, avšak dojde k situaci, kdy jsou 73