Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
SERVEROVÁ VIRTUALIZACE V PROSTŘEDÍ NETAPP A VMWARE
Diplomová práce
Autor :
Bc. Michal Frýda Informační technologie a management
Vedoucí práce:
Praha
Ing. Vladimír Beneš
duben, 2012
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 Praze, 1.4.2012
Michal Frýda
2
Poděkování: Rád bych tímto poděkoval vedoucímu své diplomové práce panu Ing. Vladimíru Benešovi za konzultace a odborné vedení při tvorbě této práce, škole, zaměstnavateli, své přítelkyni a rodině.
3
Anotace práce Cílem práce je nejprve obecný popis virtualizace a virtualizačních technologií, se zaměřením na VMware vSphere, v současnosti nejpokročilejší virtualizační produkt. Dále pak NetApp a jejich enterprise-level disková pole FAS, principy fungování vysoké dostupnosti, použitý hardware a software a v praktické části pak využití popsaných technologií v IT společnosti, migrace serverů a aplikací na virtuální infrastrukturu, výhody takového řešení. Klíčová slova: Virtualizace, VMware, NetApp, Vysoká dostupnost, Zálohování
Annotation The aim of this thesis is general description of virtualization and virtualization technologies focusing on VMware vSphere as currently the most advanced virtualization product. Furthermore NetApp and their enterprise-level disk arrays FAS, principles how high availability works, description of their hardware and software. In the practical part of the thesis we used technologies described previously, when migration of servers and applications to virtual infrastructure in the IT Company, benefits of this solution. Keywords: Virtualization, VMware, NetApp, High availability, Backups
4
OBSAH Úvod ........................................................................................................................................... 7 1
2
Virtualizace obecně ............................................................................................................ 8 1.1
Co je to virtualizace ..................................................................................................... 8
1.2
Počátky virtualizace ..................................................................................................... 9
1.3
Klady virtualizace ...................................................................................................... 10
1.4
Virtualizační technologie ........................................................................................... 13
1.4.1
Nativní virtualizace ............................................................................................ 13
1.4.2
Paravirtualizace .................................................................................................. 15
1.4.3
Virtualizace na úrovni operačního systému........................................................ 16
1.4.4
Emulace a simulace ............................................................................................ 17
1.4.5
Virtualizace pracovních stanic............................................................................ 18
1.4.6
Aplikační virtualizace ......................................................................................... 22
Disková pole NetApp. ...................................................................................................... 24 2.1
Historie společnosti NetApp ...................................................................................... 25
2.2
Hardware .................................................................................................................... 25
2.2.1
Řešení vysoké dostupnosti ................................................................................. 27
2.2.2
Flash Cache ........................................................................................................ 30
2.3
3
Software ..................................................................................................................... 32
2.3.1
Data ONTAP ...................................................................................................... 32
2.3.2
Raid-DP .............................................................................................................. 33
2.3.3
SyncMirror ......................................................................................................... 40
2.3.4
WAFL ................................................................................................................. 41
2.3.5
Snapshot ............................................................................................................. 42
2.3.6
FlexClone ........................................................................................................... 45
2.3.7
FlexShare ............................................................................................................ 45
2.3.8
Deduplikace ........................................................................................................ 45
VMware vSphere .............................................................................................................. 47 3.1
Historie společnosti VMware .................................................................................... 47
3.2
VMware ESX, VMware ESXi ................................................................................... 47
3.3
VMware tools............................................................................................................. 48
3.4
vCenter Server ........................................................................................................... 49
3.5
vStorage Virtual Machine File System ...................................................................... 49
5
4
3.6
Thin Provisioning ...................................................................................................... 50
3.7
Update Manager ......................................................................................................... 50
3.8
High Availability ....................................................................................................... 51
3.9
Data Recovery............................................................................................................ 52
3.10
Fault Tolerance (FT) .............................................................................................. 53
3.11
vMotion .................................................................................................................. 53
3.12
Storage vMotion ..................................................................................................... 54
3.13
DRS ........................................................................................................................ 54
3.14
Storage DRS ........................................................................................................... 55
3.15
vStorage Thin Provisioning.................................................................................... 55
3.16
vCenter Converter .................................................................................................. 57
Případová studie, využití v praxi ...................................................................................... 58 4.1
Charakteristika společnosti ........................................................................................ 58
4.2
IT infrastruktura ......................................................................................................... 58
4.3
Cíle společnosti v oblasti IT ...................................................................................... 61
4.4
Výběr řešení ............................................................................................................... 61
4.5
Harmonogram implementace ..................................................................................... 63
4.5.1
Výběr dodavatelů hardwaru, licencí a instalačních medií .................................. 63
4.5.2
Konfigurace diskového pole NetApp a zařízení pro zálohy NetGear ................ 64
4.5.3
Instalace hypervisoru VMware ESXi na servery Hawlett Packard .................... 66
4.5.4
Instalace hardwaru v datacentru ......................................................................... 69
4.5.5
Instalace VMware vCenter server do virtuálního prostředí................................ 70
4.5.6
Instalace a konfigurace služeb VMware HA, DRS, Data Recovery .................. 70
4.5.7
Testování a zahoření celé infrastruktury ............................................................ 72
4.5.8
Migrace serverů a aplikací do virtuálního prostředí ........................................... 72
4.5.9
Instalace a konfigurace NetApp Snap Manager ................................................. 74
4.5.10
Nastavení záloh virtuálních serverů službou VMware Data Recovery .............. 74
4.5.11
Instalace VMware ESXi server na původní server TS ....................................... 75
4.5.12
Migrace doménového řadiče CNS1 na ESXi server v sídle společnosti ............ 75
4.6
Zhodnocení řešení ...................................................................................................... 76
4.6.1
Zvýšení kontinuity činnosti společnosti ............................................................. 76
4.6.2
Zjednodušení a zrychlení zálohování a následné obnovy po havárii ................. 77
4.6.3
Snížení energetické náročnosti celé infrastruktury ............................................. 77
4.6.4
Snížení nákladů na údržbu infrastruktury........................................................... 78
4.6.5
Rozšiřitelnost infrastruktury ............................................................................... 79
6
5
Závěry a doporučení ......................................................................................................... 80
6
Seznam použité literatury a zdrojů ................................................................................... 81
7
Seznam použitých symbolů a zkratek .............................................................................. 84
8
Seznam použitých obrázků ............................................................................................... 86
9
Seznam použitých tabulek ................................................................................................ 88
7
Úvod Virtualizace je v současné době moderním trendem téměř každé společnosti, kde toto řešení přináší dříve nevídané technologické možnosti, ale také možnost úspory nákladů spojených se správou a chodem IT ve společnosti. Virtualizace, tedy virtuální, je něco nehmotného, něco na co si nelze sáhnout, přesto víme, že „to“ máme, a že se na „to” můžeme spolehnout. Virtualizace v současné době prostoupila všechna IT odvětví, síťovou infrastrukturu, servery, datová úložiště, aplikace a v poslední době také samotné koncové stanice uživatelů. V této práci si kladu za cíl nejprve obecně popsat situaci v oblasti virtualizace, jakým způsobem, respektive jaké technologie lze pro virtualizaci použít a co se vlastně v současné době nejčastěji virtualizuje, ať už se jedná o servery, desktopy nebo například samotné aplikace. Podrobněji pak popisuji virtualizační produkt od společnosti VMware, konkrétně VMware vSphere, jejich ESXi server, služby pro dosažení vysoké dostupnosti serverů a na nich běžících aplikací, zálohování a obnova takového prostředí. Pro využití pokročilých funkcí a vlastností virtualizace je v infrastruktuře potřeba sdílené úložiště dat, diskové pole. Zde popisuji diskové pole NetApp FAS, jeho hardwarovou část, zapojení v konfiguraci vysoké dostupnosti, jakým způsobem je konfigurován RAID, jak funguje obnova dat v případě výpadku fyzických disků a v neposlední řadě, jak na těchto systémech funguje snapshotovací technologie. V praktické části pak představím řešení virtualizace, na základě znalostí a produktů představených v předcházející teoretické části. Jedná se o použité řešení, které jsme provedli ve společnosti, kde pracuji a její jméno není v práci záměrně uvedeno. Součástí praktické části je tak popis předchozího stavu serverové infrastruktury, cíle, které jsme si před samotnou virtualizací vytyčili, harmonogram a průběh samotné migrace s konfigurací služeb vysoké dostupnosti, nastavení záloh celého prostředí, ověření funkčnosti.
7
1 Virtualizace obecně 1.1 Co je to virtualizace O virtualizaci by se dalo říci, že už se u tohoto slova jedná o takzvaný "buzzword", avšak myšleno v dobrém slova smyslu. Nenajdeme snad aktuálně časopis nebo jiné informační medium, zabývající se IT technologiemi, kde by nebyla alespoň zmínka o slovech jako je Cloud computing, nebo právě virtualizace, která je s Cloudem téměř vždy nějak spjata. Virtualizační technologie nám umožňují souběžně provozovat jeden či více virtuálních strojů, ať už serverů, desktopů nebo třeba aplikací, nad jedním fyzickým host serverem, nebo i celou farmou host serverů, kdy virtualizovaný systém ani nemusí být od jednoho stejného výrobce. Na jednom serveru tak můžeme provozovat operační systémy Windows od Microsoftu, různé linuxové distribuce, unix nebo FreeBSD. To co, respektive jaký operační systém smíme ve virtualizačním prostředí používat, závisí na virtualizačním produktu, který si zvolíme. Na trhu v současnosti najdeme několik velice pokročilých systémů pro virtualizaci, jako jsou například Hyper-V od Microsoftu, ESX server respektive vSphere od VMwaru, Xen server od Citrixu, VM Virtual Box od Oraclu nebo třeba Kernel based Virtual Machine - KVM. Mnoho společností už své servery a desktopy přesunulo do virtuálního prostředí, kde běží současně na jednom nebo několika serverech, umožňující lépe využít hardwarových prostředků fyzických serverů, využít služeb vysoké dostupnosti, kterou nám virtualizace umožňuje, zjednodušené a rychlejší zálohování či ideální prostředí pro vývoj aplikací, testování bezpečnosti nových produktů a bezpečnostních patchů.
8
1.2 Počátky virtualizace Virtualizace je ověřený koncept, který byl poprvé použit v šedesátých letech společností IBM jako logická cesta a způsob rozdělení rozsáhlých mainframů na jednotlivé nezávislé virtuální stroje. Toto rozdělení umožňovalo využít mainframe pro multitasking, kdy nám běží více aplikací a procesů souběžně ve stejném čase. Z důvodu vysoké finanční náročnosti mainframe bylo takové rozdělení cestou k maximálnímu využití investice.1 Od virtualizace bylo opuštěno během osmdesátých a devadesátých let, když trh ovládly levné počítače a servery architektury x86 a klient-server aplikace. Raději nežli sdílení a přerozdělování výkonu centrálně, používaly společnosti levné systémy pro vybudování infrastruktury s dostatečným výkonem. Po zavedení Microsoft Windows a objevení Linuxu jako serverového operačního systému byla serverová architektura x86 zavedena jako standard. Po takovém nárůstu x86 serverových a desktopových instalací se na poli IT objevily nové výzvy a potřeby s takovým nárůstem spojené: Nízké využití infrastruktury – Typické nasazení x86 serveru dosahuje v průměru vytížení pouhých 10 % až 15 % celkové kapacity. Společnosti často používají jeden server pro jednu aplikaci. Chtějí se tak vyhnout problémům spojených s náchylností aplikací, kdy na jednom serveru může jedna aplikace ovlivňovat bezproblémový chod druhé aplikace. Zvyšování finančních nákladů na fyzickou infrastrukturu – Náklady na běh a podporu fyzické infrastruktury se neustále zvyšují a většina výpočetního hardwaru běží nonstop, což se odráží ve zvýšené spotřebě energií, potřebě dostatečně chladit a budovat tak stále nákladnější infrastrukturu, kdy finanční nároky se nám zvyšují, ale vytížení nám zůstává na stále stejné úrovni. Zvyšující se náklady na správu – Jak se systémové prostředí stává více a více složité, zvyšuje se i potřeba na kvalifikaci a vzdělání IT specialistů starajících se o tyto systémy. S tím jsou pak samozřejmě spojeny i personální náklady. Organizace potřebuje neúměrně času a prostředků na vykonání manuálních úkonů spojených s údržbou tohoto prostředí. Je tak třeba více personálu, čímž se opět zvyšují náklady na plnění těchto úkolů. Nedostatečný failover a ochrana před havárií – Společnosti jsou stále více ovlivňovány prostoji při nefunkčnosti kritických serverů a nedostupnosti koncových stanic uživatelů.
1
History of Virtualization. ALL-IN-ONE NETWORK SOLUTIONS. All-In-One Network Solutions [online]. 26.1.2009 [cit. 2011-11-11]. Dostupné z: http://www.aiosolutions.com/what_is_virtualization.php
9
Nebezpečí bezpečnostních útoků, přírodních pohrom nebo selhání hardwaru vyústilo v nutnost a zvýšenou potřebu plánování kontinuity činností a souhrn aktivit zaměřených na snížení rizika vzniku havárie a omezení dopadů havárie na kritické podnikové procesy. Jedním z hlavních výstupů tohoto procesu je plán zachování kontinuity činností “Business Continuity Plan“. Kvalitní plány kontinuity činností jsou schopny minimalizovat následky mimořádných událostí a zároveň umožňují urychlené uvedení serverů i koncových stanic do normálního provozního stavu. Vysoké náklady na údržbu koncových stanic – Správa, údržba a zabezpečení koncových stanic přináší mnoho úkonů s tím spojených. Mnoho patchů a upgradů musí být aplikováno na prostředí koncových uživatelů pro eliminaci bezpečnostních hrozeb a nestability. Jejich kontrola a aplikace při nutnosti neomezit uživatele v jeho práci je komplexní a nákladnou činností.
1.3 Klady virtualizace O virtualizaci se dá říci, že nám přináší mnoho výhod. Ve velkých podnicích a organizacích už se stala víceméně standardem, pro spoustu menších společností je to však stále ještě tabu, případně management není přesvědčen o výhodách virtualizačních technologií z důvodu neznalosti výhod, které nám tyto relativně nové technologie přinášejí. Oblastí, kterých se výhody dotýkají, existuje několik, dá se ale tvrdit, že všechny vedou k úspoře prostředků. Efektivnější využívání serverové infrastruktury - Typický nevirtualizovaný x86 server dosahuje v průměru vytížení pouhých 10 % až 15 % jeho výpočetní kapacity. V takovém prostředí firmy často používají jeden fyzický server pro jednu aplikaci, toto je naprosto běžná praxe především enterprise prostředí, kdy instalace a běh aplikace může negativně ovlivňovat aplikaci jinou. Klíčem k efektivnějšímu využívání hardwarových prostředků serverů je serverová konsolidace. Ve virtualizovaném prostředí lze dlouhodobě, bez negativního vlivu na stabilitu nebo odezvy systémů, dosáhnout až k devadesáti procentům vytížení fyzického serveru, na každý takový server lze v praxi nainstalovat několik současně provozovaných virtuálních serverů. U desktopové virtualizace to pak mohou být i desítky virtuálních desktopů na jednom fyzickém serveru, ušetříme také na nákladech za pořízení pracovních stanic, které nahradíme relativně levnými terminály. Na následujícím obrázku pak vidíme jednoduché schéma, kdy na levé straně máme server a jeho hardware, na kterém je nainstalován operační systém a v něm pak nějaké aplikace, v pravé části pak stejný fyzický 10
server, kde máme nějakou virtualizační vrstvu a až nad ní virtualizované operační systémy s nainstalovanými aplikacemi.
Obrázek č. 1: Fyzický a virtualizovaný server a OS
Zdroj: http://software.intel.com/en-us/articles/the-advantages-of-using-virtualizationtechnology-in-the-enterprise/
Úspora na pořízení a obnovu hardwaru společnosti - hardware respektive kompletní serverová infrastruktura není zrovna levnou záležitostí, licence jsou často vázány na konkrétní hardware a tak je výhodné prvně investovat do kvalitnějšího hardwaru s dostatečnou rezervou výkonu a být tak schopen servery provozovat po delší období. Virtualizací dosáhneme konsolidace serveru, jeden fyzický server, ač kvalitnější, nám obslouží několik serverů virtuálních a případná výměna hardwaru se tak týká menšího množství serverů. S tím jsou však spojeny i podpory ze strany výrobců, které nejsou zadarmo a často tvoří nemalou část výdajů za hardware. Opět zde můžeme říci, že méně serverů nás stojí méně peněz za podporu. Energetické úspory – ceny energií stále stoupají a prognózy vývoje cen v energetice napovídají, že tento trend bude i nadále pokračovat. Moderní procesory a vlastně celé servery už se “nehoní“ pouze za co největším výkonem, ale i optimalizacemi právě pro úspory elektrické energie. Redukcí počtu fyzických serverů tak logicky dochází k úspoře, méně serverů rovná se méně potřebné energie. S počtem fyzických serverů jsou ale spojeny i nároky na udržení podmínek optimálních pro jejich chod, jako je udržení konstantní teploty
11
a vlhkosti, kdy je jednotka klimatizace nezbytnou nutností. Její energetická náročnost také není zanedbatelná. Rychlejší a bezpečnější obnovy a zálohy - problematika zálohování se netýká pouze fyzických serverů, ale stejně tak je potřeba se touto otázkou zabývat i v prostředí virtualizace. Jedná se o důležitou součást návrhu a následně implementace celého řešení virtuální infrastruktury. V současnosti je k dispozici mnoho kvalitních nástrojů pro zálohování a obnovu dat v případě havárie, jednotlivé produkty nabízejí rozličné funkce, které opět vyzdvihnou kvalitu virtuálního prostředí nad fyzickým. Ať už je to například v případě havárie serveru, který hostuje virtuální stroje, možnost jejich obnovy na jiný hardware, do virtuálního, fyzického prostředí, možnost vytvořit snapshot (obraz) živého prostředí, případně jeho pravidelné vytváření, méně potřebného času pro obnovu celého serveru, nebo například jednoduchost migrace systému na nový hardware. Testování a vývoj - pro společnosti zabývající se vývojem aplikací může být virtualizace velkým přínosem. Představme si aplikaci v konkrétním prostředí, které jako virtuální server dokážu
naklonovat
jednotlivým
programátorům.
Nebo
třeba
aplikace
patchů
a aktualizačních balíčků pro operační systémy, snadno si naklonuju živý produkční server a na něm pak takový patch otestuju bez rizika poškození produkčních dat. Business continuity – výpadek dodávky elektrické energie, lidská chyba, přírodní katastrofa nebo selhání hardwaru.2 Toto jsou nečastější příčiny výpadků informačních systémů, respektive IT infrastruktury, jejichž následky a škody tímto způsobené mohou vést od obrovských finančních ztrát až k likvidaci postižené společnosti. Z těchto důvodů ve společnostech vzniká stále častěji Business Continuity Model (Management) BCM, který se snaží identifikovat potenciální hrozby, včetně těch týkajících se IT infrastruktury a systémů, a ve společnosti pak vytvořit prostředí a postupy, které zajistí kontinuitu a obnovu klíčových procesů a činností organizace, na předem stanovené úrovni. Před integrací virtualizačních technologií bylo pro společnosti často téměř nereálné splnit dané časy obnovy kritických systémů a jejich dostupnosti z důvodu závislosti operačního systému na hardwaru serveru. S virtualizací nám toto odpadá a postižený systém můžeme relativně snadno s pomocí současných technologií “nastartovat” na jiném hardwaru. Virtualizační nástroje nám
2
The State of Disaster Recovery Preparedness. DINES. Disaster Recovery Journal [online]. 2011-02-16 [cit. 2011-12-06]. Dostupné z: http://www.drj.com/images/surveys_pdf/forrester/2011Forrester_survey.pdf
12
pak tyto nároky ještě více usnadňují existencí součástí systému právě k těmto účelům určených, jako jsou například funkce Fault tolerance, High availability nebo vMotion u VMware vSphere. Toto však nejsou všechny výhody, dá se však říci, že pouze ty nejdůležitější, které se týkají každé
implementace
virtualizace.
Další
výhody
už
jsou
závislé
na
tom,
co od virtualizace očekáváme, co je jejím primárním účelem. Například virtualizace desktopů, nebo aplikační virtualizace. U první jmenované je to obrovská úspora diskového prostoru pro takto virtualizované operační systémy koncových uživatelů, naprosto snadná správa, kdy si na úrovni virtualizační platformy nastavíme parametry takové koncové stanice. Snadné zálohování, kdy veškerá data uživatelů mám ve virtuálních desktopech, čímž při záloze dat diskového pole nezálohujeme pouze virtuální servery na něm běžící, ale i desktopy a jejich data. Při spojeni virtuálních desktopů a virtuálních aplikací tu pak máme snadnou politiku toho, jaký uživatel smí využívat jaké aplikace, tím zjednodušená správa licencí a kontroly nad tím, co si který uživatel instaluje na svůj desktop, případně jak moc využívá dané aplikace.
1.4 Virtualizační technologie K virtualizaci můžeme použít několik technik nebo technologií, které jsou od sebe relativně vzdálené svou funkčností, tím jak umožňují virtuálním serverům přistupovat k hardwaru, jak řeší přístup k procesorům, paměti a jakým způsobem řeší přístup k vstupně výstupním zařízením. V této části si popíšeme rozdíly mezi nativní nebo také Hypervisor virtualizací, Paravirtualizací, virtualizací nad operačním systémem, emulací a simulací, dále pak virtualizaci desktopů a aplikací.
1.4.1 Nativní virtualizace Nativní virtualizace (Native virtualization) je známá také pod názvy Virtualizace s hardwarovou asistencí (Hardware Assisted Virtualization) nebo také Hypervisor virtualizace. Nativní virtualizaci lze popsat jako systém, kdy je ovladač virtuálních systémů vložen mezi hardwarové a virtuální systémy. Tento ovladač pak nepracuje nad operačním systémem třetí strany, od kterého by získával prostředky pro potřeby své a pro potřeby nad tímto ovladačem běžících operačních systémů, ale sám o sobě běží nad hardwarovými prostředky, stará se o ně a přerozděluje je jednotlivým virtuálním systémům. Takový ovladač
13
nazýváme Hypervisor a takovou virtualizaci pak Hypervisor virtualizací.
3
Jedná se vlastně
o simulaci hardwaru. Každý hostovaný virtuální stroj má svůj vlastní procesor, paměť, síťové karty, diskový prostor a všechny další periferie pro běh stroje, operačního systému potřebné. Tyto prostředky však řídí, kontroluje a rozděluje jednotlivým virtuálním strojům právě hypervisor. Při použití hypervisor virtualizace je zdrojový kód z hostovaného operačního systému
interpretován
hostujícímu
operačnímu
systému,
hypervisoru,
který pak sám vykonává požadované instrukce, případně je předává ke zpracování přímo fyzickému procesoru. Právě proto musí být u hypervisor virtualizace přímá podpora virtualizačních technologií a instrukční sady procesoru. Tyto už máme v procesorech Intel i AMD od roku 2005. U společnosti Intel se tato technologie nazývá Intel Virtualization Technology (VT) 4, u společnosti AMD je to pak AMD-Virtualization (AMD-V)5. Nevýhodou nativní virtualizace jsou relativně vysoké vstupní náklady, ať už je to na pořízení hardwaru, který musí být virtualizační platformou certifikovaný, jako vhodný pro danou hypervisor virtualizaci, a také to jsou poměrně vysoké ceny samotného hypervisoru, respektive ceny licencí doplňkových funkcí. Jedni z největších konkurentů na poli nativní virtualizace, VMware i Microsoft už vydali základní verze zdarma. Tyto nám však nenabízí veškeré ty úžasné technologie a funkce, kvůli kterým právě chceme virtualizovat.
3
4
SHIELDS, Greg. REALTIME PUBLISHERS. Selecting the right virtualization solution [online]. 2008 [cit. 2011-12-12]. ISBN 1931491755, 9781931491754. Dostupné z: http://books.google.cz/books/about/The_Shortcut_Guide_to_Selecting_the_Righ.html?id=hNrs6eBUiwC&redir_esc= Hardware-Assisted Virtualization Technology. Intel [online]. 2012 [cit. 2011-12-18]. Dostupné z: http://www.intel.com/content/www/us/en/virtualization/virtualization-technology/hardware-assistvirtualization-technology.html
5
AMD Virtualization (AMD-V™) Technology. AMD [online]. 2012 [cit. 2011-12-18]. Dostupné z: http://sites.amd.com/uk/business/it-solutions/virtualization/Pages/amd-v.aspx
14
Obrázek č. 2: Nativní virtualizace
Zdroj: http://msdn.microsoft.com/en-us/library/dd430340.aspx
1.4.2 Paravirtualizace Poměrně rozšířená je představa, že nativní virtualizace s hardwarovou asistencí moderních x86 a x86-64 procesorů je to nejlepší řešení pro virtualizaci. Paravirtualizace nám řeší jisté nedostatky spojené s nutností emulace veškerého hardwaru pro virtuální stroj, když virtuálnímu stroji podkládá virtuální hardware, který je podobný fyzickému hardwaru serveru na kterém virtualizujeme. Tento virtuální hardware neboli infrastruktura je však pro virtualizaci optimalizována právě kvůli nutnosti sdílení hardwaru mezi jednotlivé virtuální stroje. Guest operační systém si je na rozdíl od nativního virtualizovaného prostředí vědom toho, že pracuje nad virtuálním prostředím a s virtualizační vrstvou proto dokáže efektivně pracovat. Nevýhodou takového přístupu je však potřeba úpravy operačního systému hostovaného systému, což je bez přístupu ke zdrojovým kódům nerealizovatelné. Nejpoužívanější operační systémy jsou však pro takové úpravy uzpůsobeny a tak pro ně není problém běh v paravirtualizovaném prostředí. Problémem však může být nějaký specifický, proprietární, méně rozšířený nebo specificky upravený operační systém. Moderní virtualizační softwary proto paravirtualizaci kombinují s plnou virtualizací. Často je to tak, že virtualizaci procesoru a pamětí obstarává plná virtualizace a o většinu ostatního hardware, jako jsou I/O zařízení se stará právě paravirtualizace.
15
Obrázek č. 3: Paravirtualizace
Zdroj: http://msdn.microsoft.com/en-us/library/dd430340.aspx
1.4.3 Virtualizace na úrovni operačního systému Technika virtualizace na úrovni operačního systému je naprosto odlišná od ostatních virtualizačních technik. Nedochází zde ani k virtualizaci ani k simulaci celého virtuálního stroje, ale dochází k využití jednoho společného hardwaru, na kterém máme běžící operační systém, ať už systémy Linux, UNIX nebo systémy od společnosti Microsoft. Na nich pak vytváříme jednotlivé na sobě nezávislé a jeden od druhého izolované virtuální systémy. Každý takový systém má svou vlastní IP adresu, souborový systém a konfiguraci, dochází tak vlastně k virtualizaci prostředí pro instalované aplikace. O separaci procesů a prostředků a jednotlivých virtuálních strojů se zde stará jádro hostujícího operačního systému. Produkty založené na této virtualizační architektuře jsou například Microsoft Virtual PC, Microsoft Virtual Server, VirtualBox, VMware server a VMware Player.
16
Obrázek č. 4: Virtualizace na úrovni OS
Zdroj: http://msdn.microsoft.com/en-us/library/dd430340.aspx
1.4.4 Emulace a simulace Fungování emulace a simulace je založeno na vytvoření celého virtuálního stroje softwarovými prostředky host systému. Celý hostovaný systém tak není potřeba jakkoliv upravovat. Velikou výhodou takového řešení je možnost takto provozovat i aplikace pro jinou architekturu než má hostující systém, což najde využití například pro programátory, kteří toto prostředí využívají pro tvorbu softwaru pro procesory, které v systému nejsou fyzicky přítomny. Příkladem tohoto přístupu z poslední doby je Android SDK 6, což je emulace android platformy na x86 hardwaru, respektive v prostředí Microsoft Windows, Max OS X nebo Linux. Nevýhodou tohoto přístupu je relativně veliká hardwarová režie. Každou instrukci je nutno buď interpretovat stavovým automatem představující virtuální procesor, nebo přeložit do instrukční sady kompatibilní s procesorem respektive instrukční sadou hostujícího systému. Podobný princip se pak používá i pro simulaci nebo emulaci I/O prostředků a operační paměti.
6
Google
Projects
for
Android.
Google
[online].
http://code.google.com/android/
17
2011
[cit.
2011-12-18].
Dostupné
z:
Obrázek č. 5: Emulace a simulace
Zdroj: http://msdn.microsoft.com/en-us/library/dd430340.aspx
1.4.5 Virtualizace pracovních stanic Když se řekne virtualizace pracovních stanic, nebo virtualizace desktopů, většině z těch, kteří se v problematice alespoň trochu pohybují, nebo se o ní zajímají, se vybaví zkratka VDI, neboli virtual desktop infrastructure. Ve skutečnosti je však VDI pouze jednou ze součástí nebo možností jak virtualizovat uživatelské stanice. Virtualizace je vlastně rozdělení počítače na fyzickou a logickou část, u virtualizace desktopů je to pak oddělení hardwaru, stanice, notebooku, tabletu, od logické části, kterou nám představuje operační systém, nějaký MS Windows, Mac OS nebo například Linux. Z tohoto pohledu je pravda, že VDI skutečně zapadá do této definice, ale není to pouze VDI, ale například to jsou Terminálové služby, nebo služby na bázi Citrixu, kdy taktéž poskytujeme uživateli přístup k desktopu, ale je přitom oddělený od hardwaru, ať už tenkého klienta nebo terminálu. Z pohledu uživatele vlastně nelze ani rozeznat, zda se jedna o desktop pracující jako VDI nebo jako desktop terminálového serveru. Virtualizace pracovních stanic je známa pod několika dalšími pojmy, jako například: Serverbased Computing, Client-Virtualization, Client/Server-Hosted Virtual Desktop (HVD), Virtual Desktop, Desktop as a Service, Enterprise Desktop Virtualization (EDV) a další. Virtualizaci desktopů tak lze rozdělit na remote hosted desktops, remote hosted dedicated virtual desktops a local virtual OS. 7
7
MADDEN, Brian. Desktop virtualization is more than VDI. SearchVirtualDesktop [online]. 2009-04-08 [cit. 2011-12-19]. Dostupné z: http://searchvirtualdesktop.techtarget.com/news/1353117/Desktopvirtualization-is-more-than-VDI#
18
Na obrázku číslo 6 je zobrazené schéma remote desktop services (RDS), známých spíše pod starším názvem Terminal services, nebo-li terminálových služeb. Terminálové služby spadají právě
do
první
zmiňované
kategorie,
remote
hosted
desktops.
Tato
role
je instalovatelná na Microsoft Windows servery a poprvé byla služba dostupná na Microsoft Windows NT 4.0 Terminal server Edition již v roce 1998. Od momentálně poslední dostupné serverové verze operačního systému Windows je tato služba, role přejmenována na výše zmíněné Remote desktop services. Operační systém, pro uživatele vlastně desktop, je nainstalován pouze v jedné kopii, pokud se nejedná o clusterové instalace za účelem vyšší dostupnosti nebo rozložení zátěže, na kterou se připojují jednotliví uživatelé. Stejně tak jednotlivé aplikace je zde nainstalovány pouze v jedné kopii a nikoliv co uživatel to instalace. Pro připojení k terminálovému serveru slouží Microsoft terminal services client (mstsc.exe), v české lokalizaci "Připojení ke vzdálené ploše", který je součástí operačního systému Microsoft Windows. Existují však klientské aplikace (connection broker software) i pro další operační systémy jako je Linux, Android, Max OS a další, což může být další velikou výhodou tohoto řešení, kdy uživatel může využívat korporátní klientské aplikace nainstalované na terminálovém serveru, aniž by sám musel mít na svém zařízení prostředí operačního systému MS Windows.
Obrázek č. 6: Schéma terminálových služeb
Zdroj: http://www.iwi.unihannover.de/upload/lv/wisem0910/Virtualisierung/webseite/alexander/desktop.htm
19
Local virtual operating systems pak reprezentuje obrázek číslo 7, kdy na samotném hardwaru počítače máme nainstalovaný operační systém, a až v tomto systému máme virtualizační aplikaci, která nám umožňuje na tomto systému provozovat systémy další. Výhoda tohoto řešení je, že můžeme používat virtualizovaný systém bez toho, abychom měli připojení na nějaký ať už terminálový server, nebo server poskytující dedikované virtuální servery. Využití pak může být například v případě, že potřebujeme spustit aplikaci, která nám běží pouze v prostředí Linux, ale na samotném počítači nebo notebooku máme MS Windows nebo Max OS. Pro tento druh virtualizace pak slouží produkty jako je VMware workstation, VMware player, VMware Fusion, Microsoft Virtual PC, Microsoft Virtual PC a další.
Obrázek č. 7: Schéma lokální virtualizace desktopu
Zdroj: http://www.iwi.unihannover.de/upload/lv/wisem0910/Virtualisierung/webseite/alexander/desktop.htm
Poslední zmiňovanou kategorií virtualizace pracovních stanic je remote hosted dedicated virtual desktops, spíše známé jako VDI, nebo li Virtual desktop infrastructure. Největším rozdílem od ostatních desktopových virtualizací je v tom, že u VDI dochází ke spuštění isolovaného uživatelského virtuálního systému na k tomu určeném serveru. Takový systém se pro ostatní síťová zařízení v síti tváří jako separátní fyzický počítač, ve skutečnosti však běží podobně jako virtuální servery nad virtualizační vrstvou, hypervisorem. Pro připojení k takovému desktopu se používá specializovaný klient, tak zvaný connection broker,
20
který poskytne připojení a validaci uživatele. Uživatelské rozhraní, například plochu nebo terminál pak uživatel získává pomocí standardních protokolů TCP/IP.
Obrázek č. 8: Schéma VDI
Zdroj: http://www.iwi.unihannover.de/upload/lv/wisem0910/Virtualisierung/webseite/alexander/desktop.htm
Virtual desktop infrastructure VDI pak můžeme dále rozdělit na 3 způsoby, jakými lze desktop uživateli přidělit a jak takový desktop posléze funguje. Nejpoužívanější variantou neperzistentní desktop, kdy se uživateli spouští pokaždé obecný systém bez jakýchkoliv uživatelových modifikací týkajících se systému jako takového, pouze má k dispozici své aplikace a uživatelská data (user profile data). Nespornou výhodou této varianty jsou jednoduchost správy takových desktopů a nízké nároky na diskový prostor, protože uživatelské desktopy se generují z jednoho "obecného", předem definovaného desktopu, kdežto jejich data jsou umístěna zvlášť. Další dvě varianty jsou již poměrně odlišné, u obou variant má uživatel už svůj konzistentní desktop, to znamená trvalý, při odhlášení a opětovném přihlášení zůstávají i povolené systémové změny. Jedna varianta poskytuje uživateli uživatelský desktop, který je vlastně samostatným virtuálním strojem, což je velmi náročné na diskovou kapacitu, každý uživatel tak má celý systém a veškerá data se tak zbytečně duplikují, ta výhodnější varianta spočívá v tom, že po prvním přihlášení se uživateli vytvoří klon obecného desktopu a každé další přihlášení pak probíhá právě k tomuto klonu. 21
Na obrázku číslo 9 pak vidíme, jak probíhá připojení uživatele k virtuálnímu desktopu.
Obrázek č. 9: Relace uživatele k VDI
Zdroj: http://www.iwi.unihannover.de/upload/lv/wisem0910/Virtualisierung/webseite/alexander/desktop.htm
1.4.6 Aplikační virtualizace Na rozdíl od tradičních aplikací, které jsou nainstalovány přímo v operačním systému, jsou virtualizované aplikace nainstalovány nad nějakou nadstavbou, nazývá se často "Application virtualization layer", neboli aplikační virtualizační vrstva. Je to vlastně tradiční aplikace, jejíž součástí a obsahem jsou veškeré sdílené softwarové komponenty potřebné pro její běh, jako jsou dll knihovny, klíče v registrech, systémové soubory, součásti GUI atd. Application virtualization layer je tak vrstva mezi aplikací a operačním systémem, který může klidně sám o sobě být také virtualizovaný. Výhoda takového řešení, tedy aplikační virtualizace je, že jednotlivé virtualizované aplikace se neinstalují do samotného operačního systému a zabraňuje se tak konfliktům mezi aplikací a host operačním systémem nebo mezi jednotlivými aplikacemi vzájemně. Například hypotetická situace, instalace jednoduché aplikace, která pro svůj běh potřebuje .NET framework ve verzi 3.0. Pokud nebude aplikace virtualizována, bude tento framework nainstalován přímo do operačního systému a k němu daná aplikace. Uživatel však potřebuje další aplikaci, která již ke svému běhu potřebuje jinou verz .NET frameworku a s tou původní je nějaký konfigurační problém a nová aplikace je s již instalovanou verzí nekompatibilní. Pokud v tomto případě použijeme aplikační virtualizaci, nainstalujeme nový .NET framework včetně aplikace nad tuto virtualizační
22
vrstvu a jak už jsme popsali, taková aplikace pak nemá žádný vliv na aplikace již nainstalované nebo na samotný chod operačního systému, nijak jej nemodifikuje. Na jednom stroji tak lze provozovat obě aplikace, což by jinak nebylo možné, nebo by to bylo techniky velmi náročné, ideální pak bude mít obě aplikace virtualizované. Je tu však i jisté omezení, protože jsou i softwarové produkty, které v současných verzích virtualizovat nelze, a u kterých je tak potřeba instalace do samotného operačního systému. Nejznámější a v současnosti asi nejpoužívanější aplikační virtualizace jsou XenApp od Citrixu, ThinApp od společnosti VMware a Microsoft Application virtualization.
Obrázek č. 10: Aplikační virtualizace
Zdroj: http://msdn.microsoft.com/en-us/library/dd430340.aspx
23
2 Disková pole NetApp. NetApp vytváří inovační produkty, systémy pro ukládání dat a software, který pomáhá zákazníkům a společnostem po celém světě ukládat, řídit, chránit a udržet si jednu ze svých nejcennějších aktiv, jejich data. NetApp je celým IT odvětvím vnímán jako společnost, která neustále posouvá hranice dnešních technologií tak, aby zákazníci nikdy museli volit mezi úsporou financí a ziskem technologií a schopností, které potřebují, aby byli úspěšní. Vždy se najde způsob, jak umožnit našim zákazníkům dělat věci, které by svou funkčností a
rychlostí
dříve
nikdo
nepovažoval
za
možné,
reálné.
NetApp
spolupracuje
s technologickými lídry v IT oboru, aby mohl vytvořit co nejúčinnější a nákladově efektivní řešení optimalizované pro IT potřeby zákazníků a mohl tyto dodávat a podporovat globálně na celém světě. S těmito technologiemi, jsou zákazníci schopni: snížení energetické náročnosti datového centra až o 50 %, optimalizace využití úložišť až o 200 %, zvýšení výkonu storage systému až o 400 %, až 166 % návratnost investic v důsledku transformace dat centra. NetApp poskytuje odborné služby a globální podporu pro jejich produkty s cílem maximalizovat jejich hodnotu pro zákazníka a udržovat tyto systémy v provozu. Hlavním cílem či mottem společnosti NetApp je pomáhat zákazníkům uspět.8
8
Go further, faster with NetApp: Our Innovation Helps Lower Your IT Costs and Accelerate Your Business. NetApp [online]. 2011 [cit. 2011-12-22]. Dostupné z: http://www.netapp.com/us/company/our-story/
24
2.1 Historie společnosti NetApp Společnost NetApp, Inc. (dříve Network Appliance, Inc.) byla založena Davidem Hitzem, Jamesem Lau a Michaelem Malcolmem v Sunnyvale, Californii, USA. Od svého vzniku v roce 1992 se soustředí na vývoj datových úložišť a v této oblasti je mezi výrobci jednoznačně ve světové špičce. Poptávka po datových úložištích stále stoupá z důvodu stále se zvyšujícímu se objemu dat, která jsou ukládána na datová úložiště různých typů. Díky jednoduchosti ovládání, spolehlivosti, bezpečnosti, širokému portfoliu produktů a výkonu datových úložišť společnosti NetApp dokáží jejich datová úložiště uspokojit potřeby každého zákazníka, od nejmenších firmiček s potřebou malých datových úložišť s kapacitou do 4 TB, přes enterprise podniky a úložiště s kapacitou kolem 100 TB, až po nadnárodní giganty, které mohou využít zařízení s kapacitou až 14 000 TB. Kde však společnost NetApp znatelně převyšuje ostatní z řady výrobců, jsou technologické funkcionality a softwarové vybavení diskových polí, které přinášejí velkou přidanou hodnotu do všech myslitelných řešení. Tohoto dosahují i spoluprací a partnerstvím s předními IT společnostmi jako jsou BMC, Brocade, Cisco, Citrix, Microsoft, SAP AG, Oracle Incorporation, Symantec, Apple, VMware a další.9
2.2 Hardware Ačkoliv sami zaměstnanci o společnosti NetApp tvrdí, že pracují v softwarové společnosti, je nutné si uvědomit, že bez hardwaru, který NetApp používá, by nebylo ani sofistikovaného softwaru, který nad hardwarovou vrstvou běží. Hardware, respektive storage systém pro ukládání dat se u NetAppu nazývá Filer, obchodně známý jako NetApp Fabric-Attached Storage (FAS). V případě, že se jedná o zařízení připojené přes síťové rozhraní, je to NetApp NetworkAttached Storage (NAS). NetApp svou nabídku v oblasti systémů pro ukládání dat. FAS funkce podnikové třídy Storage Area Networks (SAN) a síťových úložišť zařízení. NetApp Filer může sloužit i pro práci s daty pomocí síťových souborových protokolů, jako jsou NFS, CIFS, FTP, TFTP a HTTP, ale zároveň umožňují poskytovat data také přes blokový přístup jako je Fibre Channel (FC), Fibre Channel over Ethernet (FCoE) a iSCSI. Co je specialitou hardwaru společnosti NetApp je, že opravdu každý Filer je hardwarově připraven 9
History
of
NetApp.
NetApp
[online].
2011
http://www.netapp.com/us/company/new2netapp/history.html
25
[cit.
2011-12-22].
Dostupné
z:
pro připojení všemi umíněnými protokoly, jediné co je potřeba, je mít daný protokol zalicencován. Jeden jediný kus hardwaru tak mohu použít místo Windows serveru a přistupovat na něj jako k souborovému serveru pomocí protokolu CIFS, připojit k němu servery přes Fibre Channel či iSCSI a spouštět z něj samotné virtuální servery, dle potřeb zákazníka. Většina NetApp FAS systémů jsou specializované servery běžící na procesorech Intel nebo AMD, kdy každý FAS využívá paměť NVRAM, která mu umožňuje efektivně zapisovat na úložiště, respektive na samotné fyzické disky. V případě zápisu většího množství dat jsou tato data uložena nejprve právě do této paměti a až následně zapsána na fyzické disky. Uživatel tak nemusí čekat, než se jeho data zapíšou s prodlevou z důvodu čekání na relativně pomalé disky, porovnáme-li je s rychlostí právě NVRAM. Zároveň nám tento "opožděný" zápis umožňuje efektivně na disk zapisovat, kontrolovat paritu zapisovaných dat. V případě výpadku diskového pole, bychom však mohli přijít o data, která máme uložena právě v této rychlé paměti, ale která ještě nebyla zapsána na fyzické disky. Z tohoto důvodu je tato paměť jištěna interní baterií, která data udrží i v případě kompletního výpadku storage systému. Touto baterií jištěnou pamětí disponuje každý FAS systém od společnosti NetApp. Na diskových systémech NetApp jsou podporovány SATA disky, Fibre Channel disky nebo SAS disky, z kterých pak v operačním systému, který nad hardwarem běží definujeme jednotlivé RAID groups (RAID skupina) (Redundant Array of Inexpensive Disks / Redundant Array of Independent Disks). Každá taková RAID skupina se může skládat až z osmadvaceti pevných disků, kdy šestadvacet jich je datových a dva paritní. Ve starších modelech byly disky pomoci SCSI připojovány přes externí diskové police, od roku 2009 byl pak u nových modelů SCSI nahrazen Fibre Channel nebo SAS protokolem. V příloze číslo 1 pak máme jednotlivé modely ať už ty podporované, nebo ty, které se již dávno nevyrábí a podpora na ně není. Je zde krásně vidět, jak nám narůstá kapacita storage systémů a s tím v přímé úměře i výkonnost procesorů, velikost RAM a NVRAM.
26
2.2.1 Řešení vysoké dostupnosti V současnosti společnosti vyžadují vysokou dostupnost dat a aplikací a vynakládají nemalé prostředky, aby toho dosáhly. Základem pro dosažení těchto cílů je pak kvalitní návrh a následný výběr komponent infrastruktury, počínaje kvalitním diskovým polem, které by mělo splňovat takzvané “nondisruptive operations (NDO)” nebo také “No data outages”, česky pak data bez výpadku. Z pohledu hardwaru pak od takových diskových polí očekáváme: Výkonnost – z pohledu dostupnosti dat lze na výkonnost diskového systému nahlížet dvěma způsoby. První je, že zákazník má jasně dáno, jakou výkonnost od diskového systému očekává a jaká minimální hodnota aplikace uspokojí. Výpadkem dostupnosti dat je pak v tomto případě myšlena i situace, kdy diskový systém sice odpovídá na požadavky a na pozadí provádí I/O operace, ale s mnohem nižší prostupností, nežli očekávají aplikace na storage systému závislé. Druhý pohled nebo způsob nedostupnosti dat z pohledu výkonnosti pak je, pokud je systém natolik zatížen, že přestane odpovídat a vykonávat I/O operace. Odolnost – z pohledu dostupnosti dat je odolností myšlena schopnost diskového systému v degradovaném režimu fungovat a zpracovávat I/O operace i při výpadku jedné nebo vícera komponent. Návratnost – návratností nebo obnovitelností je v tomto případě myšlena schopnost diskového systému automaticky udržet funkčnost i při výpadku některé z jeho součástí, takže schopnost vykonávat I/O operace na diskovém poli i při výpadku části hardwaru, kdy v pozadí diskového systému dochází k obnovujícím operacím. NetApp nabízí robustní řešení se zaměřením na vysokou dostupnost dat pro prostředí, kde je dostupnost a bezpečnost dat jednou z nejdůležitějších priorit. Řešením u NetAppu je konfigurace, kdy máme dva identické diskové řadiče, které v normálním režimu, nezávisle jeden na druhém, obstarávají diskové operace pro jimi svěřené disky či celé diskové police. V případě výpadku jednoho z těchto diskových řadičů jsou operace a data, která by měl číst či zapisovat převedena na druhý řadič, který funguje bez problému. Toto řešení NetApp nazývá HA pair controller configuration. V praxi to pak funguje tak, že každý tento diskový řadič, který je nakonfigurovaný v prostředí vysoké dostupnosti monitoruje status a dostupnost řadiče druhého. Kontroluje takzvaný
27
heartbeat, český doslovný překlad by byl tlukot srdce, pomocí k tomu určených interních sběrnic, které jsou spolu fyzicky propojeny. Prvnímu z těchto storage procesorů říkáme local node a druhému pak partner node. Každý z nich je fyzicky připojen jak je svým diskům, tak k diskům druhého nodu, každý z nich musí obsahovat identickou verzi firmwaru a operačního systému Data ONTAP. Každý diskový řadič je sám o sobě proti výpadku chráněn pamětí NVRAM, která zajišťuje konzistenci dat před jejich skutečným zapsáním na fyzické disky. Data z NVRAM jsou do systémové paměti kopírována přes DMA - Direct Memory Access, v případě výpadky jednoho z diskových řadičů jsou jeho nejaktuálnější data uložena právě v této baterií chráněné NVRAM a integrita je tak zachována a souborový systém ochráněn. V prostředí vysoké dostupnosti si každý diskový procesor (node) rezervuje polovinu kapacity NVRAM pro partnerský řadič, respektive pro jeho data, takže obsah této paměti je identický jak na local nodu tak na partner nodu. Výkonnost je tímto omezením kapacity této specializované paměti pro každý node snížena dle společnosti NetApp o cca 2 až 3 procenta. Ve chvíli výpadku jednoho z nodů pak ten fungující převezme funkci toho nefunkčního. Nejdříve si zajistí kontrolu nad disky nefunkčního nodu a poté data z jeho NVRAM na fyzické disky zapíše.
Na následujícím obrázku číslo 11 vidíme schéma zapojení diskového systému NetApp FAS v režimu vysoké dostupnosti. Na schématu je vidět právě zapojení NVRAM, kdy každý storage procesor sdílí obsah své paměti s druhým storage procesorem, a fyzicky je připojen k diskům svým i druhého FASu. Oba dva jsou funkční a je zde tedy režim vysoké dostupnosti, hardwarové ochrany proti fyzickému selhání jednoho z nich. Ze schématu to může vypadat, že k řešení vysoké dostupnosti, je zapotřebí dvou identických NetApp FAS systémů, ale ve skutečnosti lze každý FAS systém vybavit dvěma storage procesory, takže jeden samotný systém může být vysoce bezpečný. U nižších řad systémů NetApp jako je například FAS 2020 je však potřeba počítat s tím, že každý procesor pro svou funkci potřebuje pro svou funkčnost nějakou kapacitu na diskovém poli a z důvodu implementace raidu šest, respektive Raidu-DP další dva disky jako disky paritní, a další disk jako spare. U systému s dvanácti disky to je pak relativně značné omezení dostupné kapacity pro uživatelská data, se kterým je nutné dopředu kalkulovat.
28
Obrázek č. 11: Schéma HA zapojení FAS
Zdroj: http://media.netapp.com/documents/tr-3450.pdf
Na obrázku číslo 12 vidíme schéma zapojení FASu při výpadku jednoho z diskových procesorů. Zde pak veškeré žádosti o diskové operace přebírá primární řadič, veškerá data jdou přes jeho NVRAM do systémové paměti a pak na fyzické disky obou systémů, ať na své, nebo na disky s nefunkčním storage procesorem.
29
Obrázek č. 12: Schéma HA zapojení FAS - nefunkční jeden z řadičů
Zdroj: http://media.netapp.com/documents/tr-3450.pdf
2.2.2 Flash Cache NetApp Flash Cache, známý také pod názvem PAM - Performance acceleration Module, je hardwarové zařízení do x8 PCI Express slotu, které nám umožňuje optimalizovat a zvýšit výkonnost úložného systému NetApp FAS, bez nutnosti navyšovat počet fyzických pevných disků, nebo jejich výměnu za rychlejší, to znamená také bez nutnosti řešit napájení další diskové police, optimalizování chlazení a taktéž fyzický prostor v rackové skříni nutný pro takové zařízení. Tato přídavná paměť je momentálně dostupná ve velikostech 256 GB,
30
512 GB a nejnověji i 1 TB, kdy do nejvyšších řad systémů FAS lze umístit až 16 modulů, to znamená 16 TB flash paměti.
Obrázek č. 13: NetApp Flash Cache
Zdroj: http://media.netapp.com/images/pam-II-flash-cache-2.jpg Tato přídavná paměť dodá úložnému systému výkonnost podobnou současným solid state disks (SSDs), bez nutnosti nějaké migrace dat, které již na storage systému máme uložena. Aktivní, používaná data jdou automaticky přes tuto paměť, protože každý svazek a LUN je v této rychlé paměti "cached". Zároveň zde máme možnost volby priorizace, kdy si můžeme určit, který svazek nebo LUN má být touto rychlou pamětí přednostně používán. Energetická náročnost této karty je v průměru pouze 18 W a v maximu pak 25 W, používat ji lze pro všechny používané typy pevných disků, od SATA, SAS až po FC disky. Další výhodou je pak podstatně nižší přístupová doba na toto medium, nežli je na pevné disky, tak jak je to zobrazeno na obrázku číslo 14.
Obrázek č. 14: NetApp Flash Cache - přístupová doba
Zdroj: http://media.netapp.com/images/pam-II-flash-cache-2.jpg 31
2.3 Software NetApp je primárně softwarová společnost, dodávající však i hardware, nad kterým pak provozují jejich specializovaný software. Základem každého hardwarového úložiště, NetApp FASu (Fabric Attached Storage), je operační systém Data ONTAP a s ním spolupracující software se specializuje na oblasti jako je správa dat, řešení zálohování a obnovy dat, strukturou dat a souborů.
2.3.1 Data ONTAP Základem každého NetApp FASu je operační systém Data OnTap, který je nejnověji ve verzi 8. O systému Data OnTap se dá říci, že vychází z operačního systému UNIX, konkrétně bylo použito část kódu Berkeley Net/, což byla jedna z prvních open source verzí UNIXu. 10 Tento systém, který si NetApp upravil dle svých potřeb, původně podporoval pouze protokol NFS (Network File System), protože NetApp byl původně výrobcem pouze NAS řešení. V pozdějších verzích však přibyly i další protokoly jako je CIFS (Common Internet File System), iSCSI (Internet Small Computer System Interface) a FC (Fibre Channel) včetně FCoE (Fibre Channel over Ethernet) protokolu. Celý systém má poměrně intuitivní ovládání pomoci GUI, které NetApp nazývá FilerView, jenž je dostupné z webového prohlížeče, některé složitější příkazy však nelze z tohoto prostředí provádět a je potřeba využít NetApp CLI (command line interface) neboli příkazovou řádku podobnou té, kterou známe z unixových a linuxových systémů.
10
Is Data ONTAP Based On UNIX?. In: HITZ, Dave. NetApp [online]. 2007-04-27 [cit. 2012-03-29]. Dostupné z: https://communities.netapp.com/community/netapp-blogs/dave/blog/2007/04/27/is-dataontap-based-on-unix
32
Obrázek č. 15: NetApp GUI - Operations manager
Zdroj: Vlastní úprava
2.3.2 Raid-DP Od roku 2003 a od verze operačního systému Data ONTAP 6.5 používá NetApp defaultně na svých úložných systémech RAID s dvojitou paritou, takzvaný RAID-DP. Důvodem pro použití raidu s dvojitou paritou je především zvýšení odolnosti proti poruchám, ve srovnání s raidem s jednoduchou paritou, v tomto případě především proti výpadku jednoho z pevných disků. RAID-DP je vlastně modifikovaný RAID 4, který pracuje na úrovni bloků, používá ě a více disků vyhrazených pro data a pak jeden vyhrazený disk pro paritní informace. V případě havárie jednoho z datových disků v RAIDu 4 je tento disk právě z paritních informací dopočítán. Jak je vidět na obrázku číslo 16, parita je zde počítána horizontálně součtem jednotlivých "proužků" v horizontální rovině. Pro příklad, paritou je zde suma (3 + 1 + 2 + 3 = 9). V případě poruchy jednoho z datových disků potřeby rekonstrukce jeho dat je pak postup obrácený. Například v případě výpadku prvního disku pak data odečítáme z paritních informací, tedy (9 - 3 - 2 - 1 = 3).
33
Obrázek č. 16: Parita u RAID 4
Zdroj: https://communities.netapp.com/docs/DOC-12850
Obrázek nám zároveň napovídá, že tento typ raidového pole nás chrání pouze proti výpadku jednoho z disků, pokud si představíme výpadek dvou pevných disků, nemáme jejich data z čeho dopočítat. NetApp však používá ochranu dvojitou paritou, kdy první paritní disk je počítán stejně jako u RAIDu 4, avšak druhý paritní disk ukládá paritu počítanou z proužků diagonálně, jak znázorňuje obrázek číslo 17.
Obrázek č. 17: Druhá (diagonální) parita u RAID DP
Zdroj: https://communities.netapp.com/docs/DOC-12850
Na obrázku 18 je pak znázorněna standardní parita jako u RAIDu 4 doplněná paritou diagonální. Z obrázku je pak jasně vidět, že každý výpočet diagonální parity vynechává 34
ve svém výpočtu vždy pouze jeden z disků, každá jiná diagonála, výpočet jiné diagonální parity, vynechá jiný disk, viz jednotlivé barevné proužky na obrázku. Zároveň z obrázku vidíme, že jedna z diagonál, v tomto případě ta označená proužky s bílou barvou, nemá diagonální paritu uloženou na disku označeném jako DP, na rozdíl od ostatních diagonál, to však nemění nic na možnosti rekonstrukce takového diskového pole v případě výpadku dvou pevných disků. Je třeba si uvědomit, že v reálném nasazení může mít taková implementace diskového pole desítky pevných disků a na nich pak miliony horizontálních řádků, a toto slouží pouze k jednoduššímu zobrazení toho, jak RAID DP vlastně ve skutečnosti funguje. Ve skutečnosti probíhají výpočty úplně stejně, jako je to zde zobrazeno.
Obrázek č. 18: Barevné znázornění výpočtu parity Raidu DP
Zdroj: https://communities.netapp.com/docs/DOC-12850
Na obrázku číslo 19 pak simulujeme diskové pole NetApp chráněné RAID DP, na kterém vidíme výpadek prvních dvou datových disků. U standardního RAIDu 4 nebo RAIDu 5 by toto automaticky znamenalo rozpadnutí takového pole a ztrátu dat, duální parita nám však data v tomto případě ochrání.
35
Obrázek č. 19: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
V případě takového výpadku RAID DP vyhledá, kde začíná řetězec, odkud by mohl začít vypočítávat rekonstrukci dat. V tomto případě nám rekonstrukce začne od modrého proužku. Z obrázku číslo 20 je vidět, že nám chybí pouze jeden modrý blok z pěti. Z výpočtu diagonální parity, která má hodnotu dvanáct tak odečteme čtyři známé bloky a dostaneme tím hodnotu modrého proužku z druhého poškozeného datového disku. (12 - 7 - 2 - 2 = 1).
Obrázek č. 20: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
36
Dále jednoduše dopočítáme první chybějící proužek fialové barvy z prvního datového disku jak je vidět na obrázku číslo 21. K výpočtu použijeme horizontální výpočet parity, od kterého odečteme tři ze čtyř známých hodnot horizontálních proužků. (9 - 3 - 2 - 1 = 3 )
Obrázek č. 21: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
Na obrázku číslo 22 pak vidíme, jak diagonální parity dopočítáme poslední chybějící blok z fialové diagonály, zde díky předchozí rekonstrukci opět známe čtyři z pěti prvků (7 - 2 - 1 - 3 = 1)
Obrázek č. 22: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
37
Obrázek číslo 23 pak znázorňuje dopočet pomocí horizontální parity, dopočítáváme první bílý proužek, u kterého neznáme diagonální paritu.
Obrázek č. 23: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
Kdybychom chtěli pokračovat s rekonstrukcí dat tak jako doposud, narazili bychom na problém, kdy neznáme výpočet diagonální parity bílých proužků. Pomůžeme si proto a dopočítáme poslední chybějící oranžový proužek. (12 - -8 - 1 - 2 = 1)
Obrázek č. 24: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
38
Díky oranžovému proužku nám pak chybí pouze jeden proužek ve čtvrtém řádku, který tak snadno dopočítáme pomocí horizontální parity (7 - 2 - 3 - 1 = 1)
Obrázek č. 25: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
Opět použijeme diagonální paritu a rekonstrukcí dat tak získáme poslední červený proužek (11 - 5 - 3 - 1 = 2)
Obrázek č. 26: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
39
Poslední bude rekonstruován bílý proužek, který vypočteme pomocí horizontální parity, tak jako bychom rekonstruovali u RAIDu 4. Byla tak rekonstruována veškerá data, včetně všech bílých proužků, u kterých jsme neměli diagonální paritu na disku označeném jako DP.
Obrázek č. 27: Raid DP výpadek svou disků dopočet dat na discích
Zdroj: https://communities.netapp.com/docs/DOC-12850
Toto je ukázka toho, jakým způsobem RAID DP rekonstruuje data v případě výpadku dvou fyzických disků současně. Tato situace sice není příliš pravděpodobná, ale stát se může, povětšinou pokud se tak skutečně stane, dojde k závadě nejdříve na jednom disku, který začne RAID DP přepočítávat standardně pomocí horizontální parity. V tuto chvíli jsou všechny disky pod vyšší zátěží a tak se může stát, že ještě než je první závadný disk nahrazen a jeho data rekonstruována, dojde k závadě dalšího, což nám stále pokryje právě ochrana pomocí RAID DP.
2.3.3 SyncMirror Pokud nám nestačí ochrana dat a odolnost diskového systému jakou nabízí NetApp HA v kombinaci s RAID DP, nabízí NetApp další, vyšší stupeň ochrany, kterou nám poskytuje SyncMirror, ať už v lokální nebo Metro Cluster konfiguraci. Lokální konfigurace SyncMirroru umožňuje synchronní zrcadlení svazku nebo agregátu v rámci jednoho storage procesoru, čímž nám garantuje, že data máme duplikovaná. Tato
40
funkce je dostupná na NetApp FAS diskových polích s operačním systémem Data ONTAP 6.2 a vyšším. SyncMirror tak rozděluje data mezi dvě zrcadlená disková pole, kterým se pak říká " plex", což poté funguje podobně jako RAID 0, zvýší se výkonnost v případě čtení dat z disků. SyncMirror společně s RAID DP nám poskytují skutečně vysokou dostupnost dat, a odolnost proti chybám, o data nepřicházíme ani při simultánním výpadku až pěti pevných disků.
2.3.4 WAFL Pod zkratkou WAFL se skrývá anglicky Write Anywhere File Layout, což bychom mohli volně přeložit jako systém souborů se zápisem na náhodné místo na raidovém poli nebo disku. Nejedná se však pouze o souborový systém v pravém slova smyslu, tak jak bychom tento výraz vysvětlili dříve. WAFL je podobný jako jiné UNIXové souborové systémy, jako například Berkeley Fast File System (FFS) a TransArc's Episode file systém.11 Kombinuje se zde správce souborového systému a správce oddílů, což dnes již umí i další souborové systémy, jako například ZFS nebo BTRFS, ale při uvedení WAFL to byl poměrně revoluční počin. WAFL používá nefragmentovaný blokový zápis a soubory jsou ukládány do bloků o velikosti právě 4 KB. Těmto blokům říkáme "inode", což je datová struktura souborovém systému, která popisuje jeden jediný soubor. Obsahuje však informace jako jsou přístupová práva k tomuto souboru, kdo je vlastníkem, kdo soubor naposledy změnil, ale především, kde se soubor v souborovém systému nachází. Obvykle, když vytvoříme nějaký souborový systém, je dle jeho velikosti označen daný počet bloků na disku a ten je tomuto souborovému systému přidělen. Při snaze o zapsání dat pak dochází k zápisu právě do těchto označených bloků. Souborový systém WAFL však funguje spíše na konceptu rozptýlených souborů v UNIXu. Když je takový soubor vytvořen, meta data jsou aktualizována (updated) jako u klasického souboru, ale bloky obsahující prázdné místo aktualizovány nejsou. Skutečná velikost souboru a domnělá velikost tak bude rozdílná. Skutečná velikost souboru se mění, jak jsou data zapsána nebo naopak ze souboru smazána, ale domnělá velikost souboru tak jak se zobrazuje souborovému systému je stále stejná. Diskový oddíl v souborovém systému
11
HITZ, Dave, James LAU a Michael MALCOLM. File System Design for and NFS Server Appliance. Sunnyvale, CA, USA, 2005, 13 s. Dostupné z: http://media.netapp.com/documents/wp_3002.pdf
41
WAFL funguje obdobně. Když vytvoříme diskový oddíl, metadata jsou aktualizována, aby došlo k promítnutí existence tohoto oddílu, ale specifické bloky na diskovém poli nejsou tomuto oddílu přiřazena až do chvíle, kdy je potřebujeme pro zápis skutečných dat. Takto můžeme vytvořit i více než jen jeden diskový oddíl, dokonce jim přiřadit více diskového prostoru, než na agregátu skutečně máme k dispozici. Této funkcionalitě se pak říká "Thin provisioning". Administrátor tak může na agregátu o kapacitě 100 GB vytvořit oddíl, který se uživatelům bude ukazovat jako třeba 200 GB a je pouze na něm, aby si pak ohlídal, zda mu reálná data nezaberou více, než má skutečný dostupný prostor na diskovém poli.
2.3.5 Snapshot Snapshot technologie (Snímkování pevného disku) je jednou z nejpodstatnějších a nejdůležitějších technologií, kterou NetApp na svých diskových polích má. Dalo by se říci, že technologii snímkování disku nabízí vícero výrobců storage systémů, ale ne každý provádí snapshotování disku stejným způsobem. NetApp používá tuto technologii jako základ pro další software sloužící k ochraně a zálohování dat. Snapshot je vlastně vytvoření kopie pevného disku, nebo souborového systému v nějakém konkrétním čase (point in time). Podobně jako u databází používá souborový systém WAFL ukazatele (pointers) na aktuální datové bloky na disku, ale na rozdíl od databází WAFL existující datové bloky nepřepisuje. Nová data jsou zapsána do nových prázdných bloků a souborový systém tak změní pouze pointer s daty právě na tento blok. Vytvoříme li snapshot pevného disku na diskovém poli NetApp, nestane se tak vlastně nic jiného, než že WAFL jednoduše změní právě tyto ukazatele, čímž vytvoří ke čtení určený (read only) snímek disku, respektive diskového oddílu. WAFL pak umožní aplikacím přístup k těmto snímkům, tedy
neaktuálním kopiím dat
na
disku bez
potřeby
nějakého
specializovaného
doprogramování takovéto funkcionality. Z tohoto je nám jasné, že aktuální data nejsou zkopírována, jsou pouze změněny ukazatele, takže veškerá nová data se zapisují do nových, nepoužitých a volných diskových bloků, čímž je takový diskový obraz vytvořen velmi rychle a zároveň bez extrémní náročnosti na diskový prostor. Nezávisle na velikosti diskového oddílu, nebo aktivitě uživatelů na právě snímkovaném disku se takový snapshot vytvoří v řádech vteřin, obvykle je to však méně než jedna vteřina. Poté, co je snímek oddílu vytvořen, změněná data se reflektují do aktuální kopie objektu,
42
jako bychom žádný snapshot vůbec neměli. Aktuálně měněná data se nám tak zapisují na disk, ale předchozí snímek nám zůstává kompletně nezměněn. Tato technologie nám umožňuje až 255 snímků diskového oddílu bez toho, abychom pocítili nějaký úbytek či nedostatek výkonu. Všechny tyto snímky máme dostupné jako kopie ke čtení. Schéma na obrázku číslo 28 nám znázorňuje soubor skládající se ze tří bloků uložený na oddílu pevného disku, na který aplikujeme snapshot. Jak je z obrázku vidět, v blocích, které obsahují samotný soubor, se vůbec nic nezměnilo, pouze zde máme ukazatele (pointers) ze snímku disku nazvaného Snap 1. Obrázek č. 28: WAFL - První snapshot
Zdroj: http://media.netapp.com/documents/ds-2477.pdf Na tomto obrázku číslo 29 jsme do souboru zapsali nějaké změny. Jak vidíme, změna se týká pouze jednoho bloku, který se však na pevném disku nepřepíše, ale pozměněný blok se zapíše do dalšího volného bloku na diskovém oddílu. Ukazatelé ze snímku Snap 1 se nám nezměnily, změnil se pouze jeden ukazatel souboru, ukazující na reálný blok na disku. Obrázek č. 29: WAFL - Změna dat po prvním snapshotu
43
Zdroj: http://media.netapp.com/documents/ds-2477.pdf Na posledním obrázku, týkajícího se Snapshot technologie, číslo 30, jsme na diskových polích společnosti NetApp vytvořili další snímek disku s názvem Snap 2 nad diskovým oddílem se změněným souborem, který se projevil změnou jednoho bloku na disku a jednoho pointeru souboru. Na prvním snímku Snap 1 se tímto nezměnilo vůbec nic, na blocích souboru na disku také ne, pouze samotný Snap 2 si vytvořil ukazatele na bloky snímkovaného souboru na disku.
Obrázek č. 30: WAFL - Druhý snapshot se změnou dat
Zdroj: http://media.netapp.com/documents/ds-2477.pdf
Tímto způsobem lze nad jedním diskovým oddílem vytvořit až 255 diskových snapshotů, kdy se nám na samotném disku mění pouze data skutečně změněná, snapshotem se tak nic zbytečně nekopíruje a stále se mění pouze jednotlivé pointery, ať je to snapshot první nebo třeba dvou stý. Na technologii snapshotů je pak postaven způsob, jakým lze využít software od společnosti NetApp k řešení ochrany dat. Toto snímkování pevného disku pak využívají produkty SnapManager, SnapMirror, SnapProtect, SnapRestore a SnapVault, všechno produkty NetApp, zajišťující užitnou hodnotu, výkonnost a funkcionalitu enterprise řešení diskového pole. Partneři pak dodávají snímkovací technologii NetApp přizpůsobené aplikace pro zálohu a obnovu dat na diskovém poli. Například SnapManager for Exchange nám umožní vytvořit aplikačně konzistentní snímek diskového oddílu, kdy máme zajištěno, že exchange databáze je skutečně v konzistentním stavu a lze ji například odzálohovat, nebo, bez nutnosti výpadku či odstavení systému a jeho nedostupnosti pro uživatele, to vše v řádu jednotek vteřin. 44
2.3.6 FlexClone NetApp FlexClone je software umožňující klonování a replikaci datových souborů a diskových svazků bez nároků na diskový prostor ve chvíli vytvoření. Každý takový klonovaný soubor, LUN nebo diskový svazek je transparentní, virtuální kopií využitelnou k testování, opravám chyb v softwaru, vytváření kopií serverů a uživatelských stanic, nebo třeba k simulacím mnohonásobných připojení k databázím. Perfektní využitelnost je pro virtualizaci desktopů, kdy FlexClone umí zkopírovat jak celý VMware datastore, nebo jednotlivé VMDK soubory, čímž dokážeme během vteřiny vypublikovat z jedné originální instalace operačního systému například tisíc uživatelských virtuálních stanic bez potřeby rozšíření diskového pole.
2.3.7 FlexShare FlexShare je software, pracující nad NetApp Data ONTAP operačním systémem, který nám zajišťuje QoS - Quality of Service (kvalita dodávaných služeb). Umožňuje nám přidělovat priority jednotlivým systémům, respektive diskovým svazkům konsolidovaným na jednom diskovém systému. Nejvyšší prioritu tak můžeme nastavit business critical systémům (nepostradatelným pro běh podniku nebo společnosti), například nějakým databázovým, backup nebo aplikačním serverům.
2.3.8 Deduplikace Deduplikace je jistě jedním z oblíbených termínů výrobců diskových polí, u NetAppu tomu není jinak. NetApp nabízí na rozdíl od většiny ostatních výrobců deduplikaci na primárním diskovém poli, konkurence dost často deduplikaci také nabízí, ale třeba pouze na sekundárním poli, kde jsou umístěny zálohy. Data uložená na v souborovém systému WAFL jsou rozdělena na 4 KB bloky. deduplikace zde neprobíhá online, ale pouze plánovaně, třeba v hodinách kdy není pole tolik vytěžováno. Deduplikace je právě jedním z aplikací, který nelze nastavit přes FilerView, ale je k tomuto potřeba využít příkazový řádek, k samotnému nastavení pak slouží příkaz SIS. WAFL na diskovém poli nedělá nic jiného, než že snaží porovnávat jednotlivé 4 KB bloky a hledat ty, které jsou shodné. Na disku pak zůstává uložen pouze jeden takový blok, na každý další pak existují pouze metadata, pointer na ten jeden uložený. 45
Veliká výhoda deduplikace je při virtualizaci, pokud máme několik virtualizovaných serverů se stejným operačním systémem, například Microsoft Windows Serverem, má samotná instalace operačního systému 10 GB až 20 GB. Pokud máme takových serverů třeba sto, jedná se o kapacitu 1 TB až 2 TB a dle samotného NetAppu je v takovém prostředí úspora až 70 %, u záloh pak až 90 % 12 NetApp je si se svými diskovými úložišti, respektive technologiemi úspory potřebné kapacity, že garantuje, že budete ve virtualizovaném prostředí potřebovat o 50 % menší diskovou kapacitu než na tradičním diskovém poli. Pokud se toto nepodaří ani po analýze a doporučeních experta ze společnosti NetApp, potřebná kapacita bude poskytnuta zcela zdarma.
12
SCHERER, Rick. Case Study: Boosting Storage Efficiency with Deduplication, Thin Provisioning, and FlexClone. NetApp [online]. 2011 [cit. 2011-12-24]. Dostupné z: http://www.netapp.com/us/communities/tech-ontap/tot-sddpc.html
46
3 VMware vSphere 3.1 Historie společnosti VMware Společnost byla založena roku 1998 a její hlavní sídlo je v Palo Alto v Kalifornii, dále pak výzkumná centra v Cambridge a v New Yorku. Od roku 2004 je VMware vlastněn společností EMC. Jejich produkty lze od počátku provozovat na systémech Linux a Microsoft a od roku 2006 i na Mac OS X. Prvním produktem byl VMware Workstation pro virtualizaci pracovních stanic, na serverový trh pak přišel v roce 2001 VMware GSX server založený na OS virtualizaci, tedy fungující nad již nainstalovaným operačním systémem a VMware ESX server, který již využívá svůj vlastní hypervisor. V roce 2003 pak VMware představuje produkty VMware Virtual Center a technologie VMware VMotion a Virtual SMP. O rok později pak přichází podpora 64bitových systémů. V současnosti má společnost více než 150000 zákazníků, roční tržby okolo 2 miliard amerických dolarů a zaměstnává více než 7000 zaměstnanců ve více než čtyřiceti pobočkách po celém světě. 13
3.2 VMware ESX, VMware ESXi VMware ESX server již v aktuální produktové řadě nenajdeme, jeho vývoj už byl zastaven a společnost tak dále vyvíjí pouze ESXi verzi produktu. Poslední dostupnou verzí byl ESX Server 4.1. Oba dva produkty nám nabízejí virtualizační možnosti, největším rozdílem mezi oběma produkty byla přítomnost service console (konzole pro správu) založená na Red Hat Enteprise Linuxu. Z této konzole jsme mohli instalovat různé softwarové agenty jiných výrobců, spouštět skripty a nastavovat prostředí ESX serveru. Tato konzole byla z ESXi serveru odstraněna, respektive v nejnovějších verzích už ani nebyla implementována, čímž VMware dosáhl optimalizace otisku kódu hypervisoru (hypervisor code-base footprint), kdy samotný hypervisor ESX serveru měl přibližně 2 GB, kdežto ESXi má méně než 150 MB.
13
VMware Milestones. VMware Media Resource Center [online]. 2011 [cit. 2012-12-24]. Dostupné z: http://www.vmware.com/company/mediaresource/milestones.html
47
VMware ESXi je momentálně dostupný ve verzi 5.0, celým názvem, je to pak VMware vSphere Hypervisor (ESXi). Jedná se o produkt, který je nabízen kompletně zdarma, jediné co je pro běh hypervisoru potřeba, je zaregistrovat se na stránkách vmware.com, kde si stáhnete instalační ISO image a získáte instalační klíč. Před samotnou instalací je třeba podle HCL (hardware compatibility list) ověřit, že máte podporovaný typ hardwaru, v případě migrace z ESX serveru pak ještě, zda zálohovací software a management programy podporují verzi ESXi, a nejsou nějak závislé na servisní konzole. Poté stačí ze staženého ISO souboru provést jednoduchou instalaci, čímž získáme základní hypervisor virtualizaci od VMwaru. Bez licence, která však už je zpoplatněna nám takovýto server nabízí skutečně základní možnosti, přidat a nainstalovat virtuální servery a stanice, nastavit jejich konfiguraci, od procesoru, přes diskové úložiště, síťové karty až třeba k nastavení množství operační paměti. Pokud máme zájem o další specializované funkcionality, o kterých si řekneme v následujících kapitolách, potřebujeme k tomu již nějakou z placených licencí. Dalším krokem je pak instalace VMware vSphere klienta, který je nutný pro správu, tento klient se instaluje do prostředí, ze kterého budeme ESXi server spravovat. Druhou variantou pak je verze klienta, která pro svůj běh nepotřebuje instalaci, z webových stránek vmware.com se stáhne pouze EXE soubor, tak zvaný Thinapped vSphere Client, který je však stále dostupný pouze jako Technical preview (Technical Preview je označení pro takovou verzi softwaru, která má známé problémy, ale ve většině situací plní své funkce.). Bohužel momentálně neexistuje žádná verze klienta pro jiný operační systém než je Microsoft Windows, ani pro Mac OS, ani pro některou z distribucí OS linux.
3.3 VMware tools VMware tools je soubor aplikací a utilit sloužící k zvýšení výkonnosti a zlepšení správy hostovaných virtuálních serverů a stanic. Řeší problémy spojené s nízkým video rozlišením a nízkou barevnou hloubkou, nefunkční zvuk, nekorektní a omezený pohyb kurzoru myši a nekorektní zobrazování rychlosti sítě. Do systému tak nainstaluje ovladače, ovládací panel právě pro VMware tools a službu zajišťující jejich běh.
48
3.4 vCenter Server Tento produkt je ve starších verzích 3.5 a nižších včetně známý jako virtual center. VMware vCenter Server je virtualizační prostředí pro komplexní správu virtuální infrastruktury. K tomuto serveru se připojujeme, stejně jako u jednotlivého ESXi serveru, pomocí VMware vSphere klienta, který si stáhneme přímo z tohoto serveru. Z jediné konzole se pak spravují jak samotné ESXi servery, virtuální servery a desktopy, konfigurují se clustery, diskové datastory, ale i například zálohy a obnovy virtuálních strojů. Z jedné konzole lze takto spravovat a konfigurovat až deset tisíc virtuálních strojů. Díky vCenter serveru můžeme konfigurovat a kontrolovat klíčové možnosti VMware vCenter infrastruktury, jako jsou služby vSphere vMotion, DRS (Distributed Resource Scheduler), HA (High availability) a Fault Tolerance. Bez použití vCenter Serveru tyto služby nakonfigurovat a používat nelze. Otevřené API (Application Programming Interface) pak administrátorům umožňuje integraci enterprise řešení pro management infrastruktury, spolupráce VMwaru s partnery pak rozšíření o pokročilé nástroje správy jako jsou capacity management (kapacitní plánování), compliance management (soulad činností organizace například s právní normou), business continuity (řízení kontinuity činností organizace) a storage monitoring (monitoring diskového pole).14
3.5 vStorage Virtual Machine File System VMware vStorage Virtual Machine File System (VMFS) je clusterový souborový file systém, jenž umožňuje efektivní sdílení a řízení konkurenčních přístupů virtualizovaných serverů a uživatelských stanic k diskovému úložišti. Až do aktuální verze VMware vSphere 5 bylo používáno file systému VMFS verze tři. S jistými modifikacemi to bylo již od Virtual Infrastructure 3, přes verzi 3,5 až k vSphere 4. V aktuální verzi tak přichází nový souborový systém verze pět, který uživatelům přináší hned několik novinek a vylepšení. Prvně je třeba zmínit, že upgrade z VMFS verze 3 na VMFS verze 5 lze provést za chodu, bez poškození dat, na jednom datastoru je možné mít až 100000 souborů, dříve to bylo pouze 30000, zvýšila se maximální velikost LUN na 60 TB, zůstala však maximální velikost VMDK
14
VMware vCenter Server. VMware [online]. 2011 [cit. 2011-12-26]. Dostupné z: http://www.vmware.com/products/vcenter-server/overview.html
49
souboru 2 TB. Velmi podstatnou změnou je pak sjednocení velikosti bloků, kdy v předchozí verzi byla velikost bloku 1,2,4 a 8 MB, u VMFS 5 je toto sjednoceno na 1 MB. VMFS 5 umí vytvářet velké virtuální disky i s právě 1 MB velkými bloky. Pokud je VMFS migrován z verze 3 na verzi 5, velikost jednotlivých bloků se nemění a zůstanou jako v původním VMFS, všechny nově vytvořené už však mají standardní 1 MB velikost bloku.
3.6 Thin Provisioning VMware vStorage Thin Provisioning je systém pracující nad VMFS, který nabízí dynamicky přidělit kapacitu jednotlivým virtuálním strojům, respektive jejich datovému úložišti, tedy diskům. Například na file serveru, který má momentálně obsazenou kapacitu 50 GB s tím, že výhledově se může dostat až na dvojnásobek, tedy 100 GB, není nutné na diskovém poli alokovat pro takový systém hned od počátku celých 100 GB diskového prostoru, ale lze využít právě funkci vStorage Thin Provisioning, který si z disku bere skutečně jen kapacitu, kterou potřebuje. Výhodou takového řešení je, že tímto oddálíme výdaje související s nákupem dalších pevných disků do serverů nebo diskových polí, nevýhodou je nutnost kontroly diskového prostoru na takových datastorech, kde hrozí zaplnění prostoru jedním serverem například na úkor druhého.
3.7 Update Manager VMware vSphere Update Manager je software sloužící k zjednodušení, automatizaci patch managementu hostů a virtuálních stanic. Tato služba provede kontrolu aktuálního stavu aktualizací a patchů na jednotlivých serverech a výsledek porovná se základním standardem nastaveným administrátorem. Pokud na takovém serveru nějaké z definovaných aktualizací chybí,
jsou
tyto
doinstalovány,
aby
bylo
dosaženo
požadovaného
standardu.
Tímto se dramaticky zjednodušuje a snižuje náročnost patch managementu, zároveň jsou data a programy lépe chráněny proti chybám a bezpečnostním hrozbám. Aplikace aktualizací na samotné virtualizované servery sebou přináší rizika s tím spojená, jako je nekompatibilita některého z provozovaných aplikací nebo softwaru po aplikaci nějakého patche. Pro minimalizaci takových rizik je zde možnost automatického snímku
50
(snapshot) virtualizovaného prostředí, před samotnou aplikací aktualizace, s možností definice jak dlouho takový snímek virtuálního stroje na disku zůstane a jak dlouhý čas tedy bude nějaký aplikační administrátor mít na odhalení možného problému s aktualizací spojeného. Pro eliminaci výpadků infrastruktury z důvodu odstavení host serverů umí vSphere Update Manager využívat pokročilé služby jako jsou DRS a vMotion, kdy nejprve přemigruje na host serveru běžící virtuální servery, následně uvede ESXi server do maintenance mode (stav údržby) provede aktualizace dle potřeby a až poté server spustí a zpět na něj přemigruje virtuální servery, to vše bez výpadku kteréhokoliv za systémů.
3.8 High Availability VMware vSphere High Availability (HA) je produkt, který poskytuje failover ochranu pro servery
a
operační
systémy
a
jejich
aplikace
ve
virtualizovaném
prostředí.
Dochází k monitorování jednotlivých virtuálních strojů a hardwaru, na kterém jsou provozovány a v případě poruchy fyzického host serveru pak k přesunu a restartu takového virtuálního stroje na jiném ESXi serveru. Na obrázku číslo 31 máme znázorněno selhání fyzického ESXi serveru a následné spuštění na něm běžících virtuálních serverů na serveru jiném, funkčním.
Obrázek č. 31: VMware High Availability - selhání jednoho z ESXi serverů
Zdroj: http://www.vmware.com/files/images/diagrams/VMW-DGRM-vSPHRHighAvailability_lg.jpg
51
3.9 Data Recovery VMware Data Recovery je relativně jednoduchá aplikace pro zálohu a obnovu virtuálních serverů a stanic v prostředí VMware vSphere. Tento produkt je plně integrován s VMware vCenter Serverem a umožňuje kompletní zálohu a případnou obnovu celého virtuálního stroje, nebo jednotlivých souborů dle potřeby. Je to tak zvaná disk-based backup, to znamená, že záloha je ukládána na nějaké diskové pole, nelze tedy použít například páskovou jednotku. Software po uložení dat, provedení záloh tyto zálohy deduplikuje, minimalizuje tak diskový prostor nutný pro zálohy, které lze nastavit, jak mají být dlouho udržovány, kolik kopií má na discích být uloženo. Na obrázku 32 je pak jednoduše znázorněno, jak taková záloha funguje. Na fyzickém serveru máme nainstalovaný VMware ESX nebo ESXi server a na něm tři běžící virtuální servery. V rámci VMware vCenter serveru uděláme snapshot těchto virtuálních serverů, který je pak zkopírován do deduplikovaného diskového úložiště.
Obrázek č. 32: VMware Data Recovery - záloha virtuálních serverů
Zdroj: http://www.vmware.com/files/images/diagrams/DataRecovery_1.jpg
52
3.10 Fault Tolerance (FT) VMware Fault Tolerance (FT) je software sloužící k maximalizaci dostupnosti aplikace, respektive virtuálního serveru, na kterém je provozována. FT je závislé na technologii vLockstep, která nám zajišťuje, že máme běžící virtuální kopii primárního systému. Tato kopie je provozována na jiném ESXi hostu než-li systém, který je primární, provádí naprosto stejné instrukce jako primární systém a v případě výpadku primárního systému je tento schopen převzít jeho funkce, bez ztráty dat nebo přerušení dostupnosti služeb, který takový server poskytuje. Rozdíl mezi oběma systémy je v provádění diskových operací, kdy primární systém odpovídá na síťové požadavky a provádí skutečné zápisy na disk, sekundární toto sice také provádí, ale hypervisor tyto akce přebírá na sebe a zakazuje. Samotná aktivace ochrany virtuálního stroje pomocí technologie FT je velmi jednoduchá, vybereme si virtuální stroj, který chceme touto technologií ochránit a na něm aktivujeme tuto funkci. Na druhém host serveru, druhém ESXi se nám vytvoří identická kopie serveru, s identickým nastavením, vše řízeno a prováděno VMware Hypervisorem, nad těmito virtuálními servery je deaktivována technologie DRS, aby se nám nestalo, že nám oba běží na stejném hostu, kdy by nás tato technologie neochránila právě při výpadku host serveru.
3.11 vMotion VMware vMotion byla a stále ještě je průlomovou službou v portfoliu virtualizačních produktů společnosti VMware. Tato technologie je dle studie z roku 2011, kterou provedl VMware u svých zákazníku, využívána u 80 % z nich. vMotion nám umožňuje přesunovat jednotlivé běžící virtuální stroje z jednoho fyzického hosta, ESXi serveru, na druhý, bez jakéhokoliv výpadku, bez toho, aby toto mohl uživatel zaznamenat. K provozu VMware vMotion je potřeba mít minimálně dva ESXi servery, společné datové úložiště a nakonfigurovaný VMware vCenter Server. Tuto technologii pak dále využívá služba Distributed Resource Scheduler, kdy přesunujete dle výkonnostní potřeby jednotlivé virtuální servery. Další využití je v případě nutnosti odstavení některého z fyzických serverů, například z důvodu hardwarových změn, nebo jen údržby. Hostované virtuální servery prostě jen z jednoho fyzického serveru přesuneme za chodu na druhý a host server pak můžeme, bez nutnosti omezení funkčnosti infrastruktury nebo některé z kritických aplikací, bez starostí vypnout.
53
Obrázek č. 33: VMware vMotion
Zdroj: http://www.vmware.com/files/images/diagrams/VMW-DGRM-vSPHR5-vmotionlg.jpg
3.12 Storage vMotion VMware storage vMotion je služba podobná té předchozí, jak však z názvu vyplývá, nejedná se o migraci virtuálních serverů z jednoho fyzického serveru na druhý, ale k migraci datových disků virtuálních serverů z jednoho úložiště na jiné. I zde je celá operace přesunu virtuálních disků virtuálních serverů naprosto bez omezení funkčnosti serverů a aplikací na nich běžících. Využití najdeme například, pokud je potřeba nějaká údržba diskových polí, pokud je nějaké pole přetíženo, jednoduše část zátěže přesuneme jinam, nebo také pokud prostě jen obměňujeme pole za jiné, výkonnější.
3.13 DRS VMware Distributed Resource Scheduler (DRS) je služba, která pracuje s dostupnými hardwarovými prostředky vSphere prostředí, jako je výpočetní výkon procesorů a množství operační paměti všech ESXi serverů a mezi tyto dynamicky rozděluje zátěž jednotlivých virtuálních serverů. Dle potřeby tak pomocí technologie vMotion přesouvá virtuální stroje na jednotlivé fyzické host servery dle aktuální potřeby. Tato funkcionalita se objevila už ve VMware Infrastructure 3, lze ji nastavit na plně automatickou, nebo ji lze nastavovat manuálně. Nastavujeme si tak zvané resource pools
54
(fond zdrojů), do kterých můžeme přidělovat jednotlivé virtuální servery, dle potřeby je můžeme měnit, přidávat nebo reorganizovat. Pokud se potřeba prostředků pro některý virtuální stroj změní a na daném hostu není pro jeho bezproblémový běh dostatek prostředků, je takový stroj přemigrován na jiný, v případě obráceně, pokud je v prostředí několik serverů, které prostředky nevyužívají, mohou se tyto konsolidovat na některý z dalších, běžících ESXi serverů a ten, který pak žádný virtuální stroj nehostuje, se dočasně vypne a zapne se zas, až pokud DRS vyhodnotí, že ve stávajícím resource poolu není dostatek zdrojů. Tímto můžeme určit priority, které servery mají přednost a vždy musí mít dostatek zdrojů pro svůj chod, dokážeme také šetřit energie, jak na běh serverů, které se nám mohou dynamicky vypínat a zapínat dle potřeby, optimalizovat využití hardwarových prostředků dle aktuálních potřeb, a pak také centralizovaný pohled na celkový objem dostupných a využitých zdrojů v rámci celé infrastruktury.
3.14 Storage DRS VMware Storage Distributed Resource Scheduler (SDRS) je novinkou v prostředí vSphere a byl představen až ve verzi 5. Jedná se o rozšíření VMware DRS, které využívá nový objekt dostupný právě od této verze, zvaný Data store cluster, který sumarizuje veškerá disková úložiště na bázi VMFS verze 5 a publikuje je jako jeden cluster. Při vytvoření nového virtuálního stroje je tento automaticky umístěn na vhodný storage, s ohledem jak na potřebnou datovou velikost takové VM, tak z pohledu I/O operací, které bude vykonávat.15 Stejně tak jako u služby DRS, která v případě potřeby, respektive z důvodu nedostatku zdrojů, přesouvá virtuální stroj pomocí technologie vMotion na jiný fyzický ESXi server, tak technologie SDRS využívá Storage vMotion v případě potřeby nebo nedostatku zdrojů a virtuální storage přesune na jiné fyzické úložiště.
3.15 vStorage Thin Provisioning Za pomoci VMware vStorage Thin Provisioning je funkcionalita, která nám optimalizuje dostupný diskový prostor. Tato funkcionalita je také známa pod výrazem Thin provisioning,
15
What is I/O Virtualization?. CRUMP, George. Storage Switzerland [online]. 2010-06-21 [cit. 2011-1228]. Dostupné z: http://www.storageswitzerland.com/Articles/Entries/2010/6/21_What_is_I_O_Virtualization.html
55
jedná se vlastně o mechanismus, který virtualizovanému serveru umožní vidět a myslet si, že využívá více kapacity, než jakou má ve fyzickém prostředí skutečně alokovanou. Skutečná fyzická kapacita je serveru přidělena až ve chvíli, kdy aplikace nějaká data na disk skutečně zapíše, což nám umožňuje flexibilně a hlavně efektivně využívat dostupný diskový prostor. Na obrázku 34 je datastore o celkové velikosti 100 GB, v němž máme tři virtuální disky pro tři virtuální servery. První virtuální server z leva má k dispozici tak zvaný thick disk, což je standardní disk, tak jak ho známe u normálního fyzického serveru, velikost oddílu je 20 GB a celý tento oddíl je na datastoru alokován. Druhý virtuální server pak používá vStorage Thin Provisioning, systém vidí, že má přidělený oddíl o velikosti 40 GB, reálných dat má 20 GB a v datastoru jeho 40 GB velký oddíl s 20 GB dat zabírá pouze těch 20 GB. Třetí virtuální server pak má oddíl o velikosti 80 GB a 40 GB dat na něm, díky thin provisioningu v datastoru zabírá reálně právě 40 GB. Pokud sečteme velikosti oddílů všech tří oddílů virtuálních serverů, zjistíme, že mají dohromady velikost 20 GB + 40 GB + 80 GB = 140 GB, což je o 40 GB více, než mají kapacitu disky v datastoru, ve skutečnosti však máme k dispozici stále ještě 20 GB diskového prostoru, který si mohou aplikace, respektive jednotlivé virtuální servery alokovat. Pokud bychom v tomto případě nepoužili vStorage Thin Provisioning, museli bychom rozšiřovat kapacitu datastoru, respektive diskového pole, třetí virtuální server by se nám sem již nevešel, kapacita by musela být o 40 procent větší než současná, a to bez jakékoliv rezervy.
Obrázek č. 34: VMware vStorage Thin Provisioning
Zdroj: http://www.vmware.com/files_inline/images/tech_increased-storage.gif 56
3.16 vCenter Converter VMware vCenter Converter je produkt, který dokáže automatizovat a především zjednodušit migraci serverů a stanic z fyzického prostředí do prostředí virtuálního. Za pomoci intuitivního klienta lze migrovat několik strojů současně, mohou to být jak servery z prostředí Microsoft Windows, tak linux, ale lze i konvertovat z jiných virtuálních systémů jako jsou Microsoft Hyper-V, Microsoft Virtual PC a Microsoft Virtual Server. Dále lze použít zálohy Symantec Backup Exec System Recovery a Norton Ghost pro jejich import právě do prostředí VMwaru.
Obrázek č. 35: VMware vCenter Converter
Zdroj: http://www.vmware.com/files/images/diagrams/vmw_vC_converter_600x600.jpg
57
4 Případová studie, využití v praxi 4.1 Charakteristika společnosti Společnost se zabývá informačními technologiemi, konkrétně se specializuje na komplexní IS/ICT služby, jako je outsourcing IT služeb, hostování fyzických i virtuálních serverů, správa a výstavba LAN sítí, ale i vývojem softwaru a optimalizací výpočetní techniky. Jedná se společnost s dlouholetou tradicí v regionu, se snahou zaměřit se jak na lokální firmy, tak i na společnosti v rámci České republiky a centrální Evropy. Klientela se skládá jak z organizací státní správy, tak ze soukromého sektoru, roční obrat společnosti je okolo 30 mil. Kč a společnost zaměstnává 10 zaměstnanců. Jméno společnosti zde není záměrně uvedeno.
4.2 IT infrastruktura Kompletní IT infrastruktura společnosti se nachází na centrále pobočky a společnost veškerou techniku vlastní. Všechny operační systémy jsou nainstalovány na fyzických serverech bez virtualizačních technologií, virtualizace je využívána pouze jako testovací prostředí. Serverová infrastruktura je založena na serverech od společnosti Hawlett Packard, konkrétně x86 servery Proliant. Síťové prvky jsou od Hawlett Packard, routery a firewall od společnosti Cisco a diskové síťové úložiště pro ukládání záloh od společnosti NetGear. Uživatelské stanice a notebooky jsou také od společnosti Hawlett Packard a jsou zařazeny do lokální domény. Na serverech jsou nainstalovány serverové operační systémy od společnosti Microsoft, doménový řadič ve verzi Microsoft Windows 2003 Server, ostatní servery pak Windows 2008 Server. Jeden server pak má nainstalován operační systém linux a slouží jako FTP server. Používaná linuxová distribuce je Debian linux. Na všech stanicích pak jsou nainstalovány operační systémy Microsoft Windows 7. Dále je využíván Microsoft SQL server, který slouží jako databázový server a je základem pro podnikový informační systém Soft 4 Sale. Pro běh tohoto IS je nutná instalace klienta na koncové stanici a rychlost celého systému nebyla přes lokální síť ideální a proto byl do podnikového prostředí nasazen Microsoft Terminal Server, nově Remote desktop services, který je využíván právě pro běh firemního IS. Další výhodou tohoto řešení je možnost
58
autorizovaných uživatelů spouštět a přistupovat do firemní databáze ze vzdálených lokalit, což v předchozí konfiguraci nebylo možné.
Tabulka č. 1: Přehled serverů ve společnosti DNS název serveru
Operační systém
Role
Windows 2003 Server 32bit
Řadič domény ESET Remote Administrator Tiskový server Souborový server
Windows 2008 Server R2 64bit Windows 2008 Server R2 64bit
Poštovní server - Exchange Terminálový server - MS RDS
TECH
Windows 2008 Server R2 64bit
Řadič domény Monitoring Interní web server - Sharepoint
CNS2 NAS
Debian linux 32bit
FTP server
Debian linux 32bit
Úložiště záloh
CNS1 EX TS
Zdroj: Vlastní zpracování
Veškeré servery i stanice jsou připojeny metalicky ke gigabitovému síťovému přepínači HP ProCurve 1810G-24, jehož podporované stupně datových přenosů jsou 10 / 100 / 1000 Mbit/s na každém z dostupných portů. CNS1 je původní, nejstarší server ve společnosti, na kterém kdysi běžely veškeré služby, které byly postupně migrovány na separátní servery. Strategie mít jeden výkonný server a jeden systém, na kterém jsou nainstalovány veškeré služby a aplikace, které jsou ve společnosti používány, byla opuštěna a jednotlivé role přemigrovány na jiné servery v síti. Na serveru tak zůstal souborový server, tiskový server, administrační konzole ESET Remote Administrator, a především pak řadič domény, a s ním spojené služby jako jsou Active Directory, DNS, DHCP a služba ověřování v internetu (IAS). Operační systém je 32 bitový Microsoft Windows Server 2003 Standard a hardware pak server Hawlett Packard Proliant ML150 třetí generace s dvou jádrovým procesorem Intel Xeon 5130, 4 GB operační paměti DDR2-667 a třemi disky zapojenými v RAIDu 5. EX je založen na Microsoft Windows Server 2008 R2 a slouží jako firemní mail server. Původní instalaci s Microsoft Windows 2008 serverem a Microsoft Exchange Server 2007 nahradil právě zmiňovaný R2 server a nejnovější Microsoft Exchange 2010, ke kterému se lze
59
připojit klientským Microsoft Outlookem, přes webové rozhraní nebo mobilním zařízením přes ActiveSync. Jako hardware je opět použit server Hawlett Packard Proliant ML150 třetí generace s dvou jádrovým procesorem Intel Xeon 5130, 4 GB operační paměti DDR2-667 a třemi disky zapojenými v RAIDu 5. TS je asi nejvýkonnější server ve firmě, jedná se o Hawlett Packard Proliant ML350 páté generace s čtyř-jádrovým Intel Xeon E5320 procesorem, 12 GB operační paměti a RAID 5 ze čtyř rychlých disků 72 GB Serial Attached Storage SCSI (SAS) 15K. Jako operační systém byl použit Microsoft Windows Server 2008 R2, na němž jsou nainstalovány MS SQL Server a Remote Desktop Services, kdy každý uživatel se na server připojuje pomocí klienta a firemní aplikaci tak nespouští na své stanici nebo notebooku, ale právě na výkonném serveru. TECH je server sloužící jako další, záložní řadič domény a zároveň jako intranetový portál, založený na IIS a Microsoft Sharepoint Services, který slouží primárně jako technet. Dále je na serveru provozován monitorovací systém, který sleduje jak servery a síťová zařízení společnosti, tak servery a síťová zařízení smluvních zákazníků. Toto běží na Microsoft Windows Server 2008 R2 a fyzickém serveru Hawlett Packard Proliant ML150 třetí generace s dvoujádrovým procesorem Intel Xeon 5130, 4 GB operační paměti DDR2-667 a třemi disky zapojenými v RAIDu 5. CNS2 je starší linuxový server založený na distribuci Debian, který původně sloužil jako souborový a FTP server, a na kterém byly profilové složky uživatelů, ale nakonec slouží pouze jako firemní FTP a SSH server. Jako hardware zde slouží starý Hawlett Packard Proliant DL380. NAS je záložní diskové úložiště od společnosti NetGear, konkrétně se jedná o NetGear ReadyNAS NV+. Jedná se o zařízení se čtyřmi hotplug ( za chodu vyměnitelnými ) SATA a SATA II disky, nad kterými lze vytvořit RAID 0, 1 nebo 5. ReadyNAS NV+ je postavené na procesoru IT3107, 256 MB PC2700 DDR-SDRAM paměti, 64 MB flash paměti, na které je operační systém založený na distribuci Debian linuxu a s 10 / 100 / 1000 Mbit/s síťovém rozhraní. Podporuje síťové protokoly CIFS / SMB, AFS, NFS, HTTP, HTTPS, FTP,
60
FTPS a RSYNC.16 Na tento NAS (network attached storage) jsou zálohovány veškerá data a servery společnosti.
4.3 Cíle společnosti v oblasti IT S rostoucím počtem fyzických serverů ve společnosti, kdy z důvodu stability jednotlivých aplikací je nutné mít jednotlivé funkce - role nainstalovány na oddělených serverech, si vedení společnosti začalo uvědomovat rostoucí náklady s tím spojené, a to jak na provoz těchto serverů, ale i jejich údržbu, jejich zálohování a obnovu, a také zajištění smluvního servisu pro případ hardwarové poruchy některého ze serverů, které jsou ve společnosti kryty placenou službou HP Care Pack.17 Z těchto důvodů bylo potřeba změnit stávající architekturu IT společnosti, tak aby byly splněny jednotlivé dílčí cíle: Zvýšení kontinuity činnosti společnosti. Zjednodušení a zrychlení zálohování a následné obnovy po havárii. Snížení energetické náročnosti celé infrastruktury. Snížení nákladů na údržbu infrastruktury. Rozšiřitelnost infrastruktury, využitelnost pro hostování zákaznických serverů / služeb.
4.4 Výběr řešení Na základě cílů a požadavků na budoucí infrastrukturu společnosti byla jedinou možnou volbou virtualizace celého serverového IT prostředí. Současně bylo rozhodnuto, že veškeré serverové řešení, mimo jednoho doménového řadiče, bude přemístěno do
16
The Definitive Guide to the ReadyNAS NV+. In: NetGear ReadyNAS Community [online]. 2008 [cit. 2012-01-05]. Dostupné z: http://www.readynas.com/?p=331#Specifications
17
HP Care Pack Services. Hawlett Packard [online]. 2012 [cit. 2012-01-12]. Dostupné z: http://www8.hp.com/uk/en/support-drivers/carepack/hp-carepack.html
61
firemního datacentra a se sídlem společnosti bude propojena transparentní virtuální privátní sítí. Hardwarové řešení na straně serverů bylo rozhodnuto téměř okamžitě. Vzhledem k tomu, že doposud byla na straně serverů použita značka Hawlett Packard, se kterou nebyli žádné problémy jak po stránce výkonnostní, dostupnosti dílů a smluvního servisu, bylo rozhodnuto využívat opět tuto značku. Dalším plusem v této volbě byla znalost produktů HP Proliant řady DL
18
technickými pracovníky společnosti, kteří se o servery této značky starali doposud.
Výběr produktů je poměrně rozsáhlý a volba nakonec padla na servery Hawlett Packard ProLiant DL360. Jedná se o server, který lze osadit dvěma procesory, zde byl použit čtyř jádrový Intel Xeon E5504, vyráběný 45 nm technologií s podporou virtualizačních technologií, maximální spotřebou 80 W a s frekvencí jader 2 GHz, 19 16 GB operační paměti. Servery byly zakoupeny bez pevných disků, čímž dojde k snížení energetické náročnosti takového serveru, bootování virtualizačního hypervisoru bude na jednotlivých serverech z flash disku instalovaného uvnitř každého ze serverů. Firma je v partnerském programu společnosti NetApp, konkrétně silver partner, kde jednou z podmínek pro získání tohoto stupně partnerství je mít vyškolené technické a obchodní pracovníky, kteří znají problematiku diskových polí FAS, umí je konfigurovat a starat se o ně, případně nabídnou vhodnou konfiguraci potencionálním zájemcům, respektive zákazníkům. Partneři navíc mají možnost získat produkty NetApp za zvýhodněné akční ceny, a tak volba diskového pole byla relativně jednoznačná. Otázkou tak byla pouze volba modelu FAS a jeho osazení disky. Z důvodů dosažení maximální dostupnosti dat byl zvolen systém FAS2020 s dvěma storage procesory a deseti rychlými 300 GB 15K SAS disky. Další otázkou bylo jakou technologii, respektive jakým protokolem virtuální servery připojit, zda pomoci NFS, iSCSI nebo Fibre Channel. Nakonec z důvodu jednoduchosti konfigurace a finanční nenáročnosti celého řešení byl zvolen protokol NFS.20 Pro zálohy byl vybrán produkt od
18
Servery HP ProLiant DL. Hawlett Packard [online]. 2012 [cit. 2012-01-12]. Dostupné z: http://h10010.www1.hp.com/wwpc/cz/cs/sm/WF02a/15351-15351-3328412.html?dnr=1
19
Intel® Xeon® Processor E5504. Intel [online]. 2012 [cit. 2012-01-12]. Dostupné z: http://ark.intel.com/products/40711/Intel-Xeon-Processor-E5504-(4M-Cache-2_00-GHz-4_80-GTsIntel-QPI)
20
Network File System (NFS). NetApp [online]. 2012 [cit. 2012-01-12]. Dostupné z: http://www.netapp.com/us/products/protocols/nas/nfs.html
62
společnosti NetGear, ReadyNAS 210021 se čtyřmi 2 TB disky v RAIDu 5, což je téměř 6 TB volného diskového prostoru. Dále bylo nutno zvážit jakou cestou, respektive jaký virtualizační produkt bude pro požadavky firmy nejvhodnější a nejvýhodnější. Do finálního výběru jsme zařadili virtualizaci od společnosti Microsoft, konkrétně jejich Hyper-V hypervisor a pak produkt vSphere 4.1 od společnosti VMware. Pro produkt Microsoft hrál fakt, že víceméně veškeré firemní servery fungují právě na produktech MS Windows, pro správu jsou používány stejné nástroje pro fyzické i virtuální prostředí a techničtí pracovníci jsou ve windows serverové technologii znalí. Na druhou stranu VMware je technologický leader v oblasti virtualizace, jeho produkt VMware vSphere nabízí funkce, které konkurence ještě neumí nabídnout, avšak cena je vyšší. Nakonec padla volba na VMware vSphere a jejich hypervisor ESXi společně se serverem VMware vCenter Server.
4.5 Harmonogram implementace Pro bezproblémový přechod infrastruktury společnosti bylo nutné vhodně naplánovat harmonogram
implementace
jednotlivých
dílčích
úkonů
s
tím
spojených
tak,
aby došlo k minimu výpadků, a aby migrace serverů a aplikací z fyzického do virtuálního prostředí nepřinesla neočekávané problémy.
4.5.1 Výběr dodavatelů hardwaru, licencí a instalačních medií Dalším krokem po výběru celkového řešení a konkrétního hardwaru, který bude pro realizaci serverové virtualizace použit, je výběr dodavatele serverů a aktivních prvků Hawlett Packard a diskových polí NetApp a NetGear. Cílem bylo samozřejmě získat hardware za co nejnižší cenu s maximální možnou podporou a zárukou od výrobce. Servery Hawlett Packard ProLiant DL360 byly poptány u několika standardních firemních dodavatelů a nakonec nejlepší nabídku a tudíž i nejnižší cenu nabídla společnost AT Computers a.s. s cenou 32640 Kč bez DPH za kus se standardní dvouletou zárukou
21
Úložné zařízení ReadyNAS 2100 (4 x 2 TB). NetGear [online]. 2012 [cit. 2012-01-13]. Dostupné z: http://www.netgear.cz/business/products/zalohovani/xx00/RNRX4420.aspx
63
a podporou Hawlett Packard Carepack - Next Business Day za 6370 Kč bez DPH za jeden server. U diskového NetApp FAS2020 byla volba jednoznačná a produkt včetně všech softwarových licencí byl zakoupen napřímo od zastoupení společnosti zde v České republice za cenu 243049 Kč bez DPH. Diskové pole NetGear ReadyNAS 2100 dodala společnost ABC Data s.r.o. za cenu 49788 Kč bez DPH. Licence VMwaru byly zakoupeny opět napřímo od zastoupení VMware v české republice za cenu 55339 Kč bez DPH.
Tabulka č.2: Náklady na virtuální infrastrukturu Zboží HP ProLiant DL360G6 HP SW iLO Advanced Pack Netgear ReadyNAS 2100 8 TB NetApp FAS2020, HA, 12x300 GB VMware vSphere 4 Essentials +
Cena za kus bez Kusů DPH 2 32640 2 6370 1 49788 1 243049 1 55339 Celkem bez DPH :
Cena bez DPH celkem 65280 12740 49788 243049 55339 426196
Zdroj: Vlastní zpracování
Veškerá instalační média a licence jsou dostupná na webových portálech výrobců v digitální podobě, není tak do tohoto potřeba zbytečně investovat finance, a ještě pak čekat nežli budou média a licence doručeny.
4.5.2 Konfigurace diskového pole NetApp a zařízení pro zálohy NetGear Naše diskové pole NetApp FAS2020 je vybaveno dvěma storage procesory, každému jsme přiřadili jedinečnou IP adresu, přes kterou bude následně každý z procesorů konfigurován, první storage procesor 10.10.1.130 a druhý 10.10.1.140. Na prvním byl vytvořen aggregate (agregát) z deseti disků v konfiguraci RAID DP, sedmi datových, dvou paritních a jedním spare diskem. Na tomto agregátu pak budou hostována primární data všech virtuálních serverů, vytvořili jsme na něm proto dva volumy (diskové oddíly), jeden o velikosti 1TB, 64
a druhý zabírající zbytek dostupného prostoru. Velikost 1 TB na prvním volumu nebyla zvolena náhodou, je to totiž právě maximální velikost, na které lze na NetApp FAS 2020 použít službu deduplikace. Druhý volume pak má velikost 66 GB a jsou na něm uložena tak zvaná root data, to znamená data o systému NetApp, jednotlivých agregátech a volumech, která jsou shodná s root daty na druhém storage procesoru. Tento volume není v žádném dalším směru v naší infrastruktuře využíván.
Obrázek č. 36: Agregát na prvním storage procesoru
Zdroj: Vlastní úprava
Na druhém storage procesoru byl vytvořen agregát ze zbývajících dvou volných disků. Nastaven byl jako RAID 4, kdy na jednom disku jsou data, na druhém je parita. Na tomto agregátu je vytvořen jeden volume s velikostí 215 GB a na něm jsou pak opět uložena root data o systému NetApp FAS a dále sdílená složka, na které jsou uchovávány instalační media a instalace softwaru ve formátu ISO, který společnost využívá.
65
Obrázek č. 37: Agregát na druhém storage procesoru
Zdroj: Vlastní úprava
Jako úložiště pro zálohy jsme nakonfigurovali NetGear ReadyNAS 2100. Jedná se o zařízení pracující s procesorem Intel. 1 GB operační paměti a integrovaným 128 MB flash diskem, na kterém je nainstalován operační systém, založený na Linuxu. Dále je zde řadič pro čtyři Serial ATA II disky, v naší konfiguraci pak čtyři 2 TB disky v RAID 5 konfiguraci. Zařízení má dvě síťové rozhraní, dostala IP adresu 10.10.1.110 a jsou ve fail over konfiguraci.
4.5.3 Instalace hypervisoru VMware ESXi na servery Hawlett Packard Na servery byl nainstalován VMware ESXi server 4.1 modifikovaný společností Hawlett Packard, kdy přímo do instalačního ISO image jsou integrovány ovladače a především pak HP CIM providers, což je vlastně poskytovatel informací od fyzického serveru ESXi hostu, respektive VMware vCentru. Díky tomu víme, jaký je stav fyzického hardware, lze používat management software jako je například HP System Insight Manager.22 Servery byly dodány bez pevných disků, proto se přímo do nitra serveru vložil flash disk, který slouží jako systémový a z kterého VMware ESXi servery bootují. Instalace VMware ESXi serveru je jednoduchá a probíhá v několika základních krocích. Na serveru jsme správně nastavili BIOS, povolili EM64T a Intel Virtualization Technology (VT), nastavili bootování z DVD-ROM mechaniky, kde je vloženo instalační médium s VMware ESXi serverem.
22
HP Systems Insight Manager. HP SIM [online]. 2012 [cit. 2012-01-24]. Dostupné z: http://h18013.www1.hp.com/products/servers/management/hpsim/index.html?jumpid=go/hpsim
66
Po restartu serveru a po bootu z DVD se nám zobrazí základní nabídka instalace, kde zvolíme Enter pro novou instalaci.
Obrázek č. 38: Instalace VMware ESXi
Zdroj: Vlastní úprava
Dalším krokem je potvrzeni VMware End User Licence agreementu (EULA). Dále zvolíme, kam se bude instalace VMware ESXi serveru instalovat, respektive na které dostupné úložiště, v našem případě tomu bylo na flash disk, který byl v serverech instalován.
67
Obrázek č. 39: Instalace VMware ESXi - výběr úložiště pro instalaci
Zdroj: Vlastní úprava
Poté probíhá kopírování souborů a samotná instalace VMware ESXi serveru, po jejímž úspěšném dokončení jsme vyzváni k restartu serveru. Po restartu už máme plně funkční server.
68
Obrázek č. 40: Instalace VMware ESXi - defaultní obrazovka serveru po instalaci
Zdroj: Vlastní úprava
Následně provedeme základní konfiguraci, stiskneme klávesu F2, přihlásíme se pomocí uživatele root s prázdným heslem, nastavíme si nové heslo, DNS název serveru a dle potřeby nastavíme síťové rozhraní. V našem případě se servery jmenují ESXPHA1 a ESXPHA2 a jejich IP adresy jsou 10.10.1.10 a 10.10.1.20. Tímto je serverová instalace VMware ESXi serverů připravena pro připojení k VMware vCenter Serveru.
4.5.4 Instalace hardwaru v datacentru Veškeré instalační a konfigurační práce spojené s novou infrastrukturou byly prováděny na technickém oddělení v sídle společnosti. Dalším krokem po úspěšné konfiguraci bylo potřeba veškerý hardware přemístit do datacentra společnost v Praze, kde je dostupný vysokorychlostní internet s rychlostí 1 Gbit/s se záložní linkou v případě nedostupnosti primárního připojení, celé datacentrum je jištěno záložním bateriovým zdrojem, popřípadě diesel agregátem a samozřejmostí je klimatizace a hasicí systém.
69
4.5.5 Instalace VMware vCenter server do virtuálního prostředí Kvůli snížení celkové ceny za infrastrukturu jsme se rozhodli, že vCenter nebude zvlášť na fyzickém serveru vyhrazeném pouze pro VMware vCenter server, ale bude běžet jako virtuální server na jednom z VMware ESXi serverů. Dle VMware best practices23 jsme na jednom z VMware ESXi serverů vytvořili virtuální server s 3 GB operační paměti, dva virtuální procesory a 40 GB pevný disk, který je umístěn na diskovém poli NetApp. Vzhledem k velikosti infrastruktury, respektive k počtu host serverů a virtuálních serverů na nich běžících, že s největší pravděpodobností značná část zdrojů vyhrazených pro tento server nebude nikdy využívána, a že později provedeme analýzu využití a zdroje upravíme dle potřeb. VMware vCenter server 4.1 jsme nainstalovali na tento virtuální server, kde základem je Microsoft Windows 2008 R2, po instalaci jsme do jeho správy zařadili oba host servery, VMware ESXi server ESXPHA1 a ESXPHA2.
4.5.6 Instalace a konfigurace služeb VMware HA, DRS, Data Recovery Služba VMware High Availability je naprosto klíčovou službou pro dosažení jednoho z klíčových požadavků na virtualizovanou infrastrukturu společnosti, vysokou dostupnost serverů, respektive služeb a aplikací na nich hostovaných. Pro konfiguraci VMware HA, DRS a Data Recovery je nezbytné mít servery spravované VMware vCentrem, což jsme již měli nastaveno a samotná aktivace HA a DRS je pak otázka několika kliknutí a víceméně zaškrtnutí dvou checkboxů, viz obrázek 41.
23
BHATIA, Nikhil, Chirag BHATT a Lei CHAI. VMware vCenter Server Performance and Best Practices. [online]. 2010 [cit. 2012-02-04]. Dostupné z: http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_VC_Best_Practices.pdf
70
Obrázek č. 41: Povoleni služeb VMware HA a DRS
Zdroj: Vlastní úprava
V nastavení pravidel jsme si pak nastavili, které servery nemají být na jednom společném ESXi host serveru, což je vhodné například pokud je v infrastruktuře více doménových řadičů, tak mít každý na jiném host serveru, aby byl alespoň jeden z nich vždy dostupný v případě hardwarové poruchy. Veškerá tato pravidla a omezení je v rámci služby DRS možno nastavit. Druhým krokem byla instalace VMware Data Recovery. Toto už není součástí prvotní instalace VMware ESXi serverů nebo vCenter serveru, ale je nutné si z webových stránek wmvare.com stáhnout příslušné instalační medium, které jsme nainstalovali do prostředí VMware vCenter serveru. Po úspěšné instalaci jsme spustili vCenter klienta a naimportovali OVF template, což je vlastně předpřipravený virtuální server, stačilo tak zadat nové jméno virtuálního serveru, vybrat na kterém ESXi hostu bude běžet, a kde bude mít své datové
71
soubory, a tím byla instalace dokončena. Posléze jsme spustili nově naimportovaný virtuální server, založený na Linuxu CentOS. Přes webové rozhraní jsme se pak připojili na tento virtuální server a nastavili si síť, v našem případě IP adresu 10.10.3.100. V dalším kroku jsme server restartovali a přiřadili nový virtuální disk o velikosti 1 TB pro zálohy, který je umístěn na diskovém poli určeném pro zálohy, NetGear ReadyNAS. Tento disk jsme pak z prostředí vCenter naformátovali, aby na něj mohl server zálohovat virtuální servery, které jsme později přemigrovali.
4.5.7 Testování a zahoření celé infrastruktury Kompletní virtuální infrastrukturu jsme měli v tuto chvíli nakonfigurovanou a před migrací produkčních serverů bylo potřeba infrastrukturu otestovat. Jednalo se především o testy výkonnosti a služeb vysoké dostupnosti, a to jak na úrovni diskového pole NetApp, tak na úrovni VMware High Availability. Na host ESXi servery jsme proto nainstalovali několik virtuálních serverů, včetně testovacího Remote Desktop Services (RDS) s podnikovým informačním systémem Soft 4 Sale s aktuální SQL databází a nastaveným přístupem pro všechny uživatele, pro maximalizaci reálnosti skutečného provozu infrastruktury. Za chodu všech virtuálních serverů jsme tak simulovali výpadek jednoho ze storage procesorů na diskovém poli NetApp, výpadek jednoho z ESXi serverů a následnou aktivaci VMware High Availability s následným spuštěním virtuálních systémů na funkčním VMware ESXi serveru. Dalším krokem pak bylo nastavení záloh testovacích virtuálních systémů, jejich zazálohování na diskové pole NetGear určené pro zálohy, pomocí VMware Data Recovery a následná obnova serverů z této zálohy zpět na diskové pole NetApp.
4.5.8 Migrace serverů a aplikací do virtuálního prostředí Rozhodli jsme se, že stávající server CNS1 jakožto doménový řadič nebude migrován do datacentra mimo sídlo společnosti. V případě problému s konektivitou do internetu, respektive při problému s virtuální privátní sítí, která spojuje sídlo společnosti s datacentrem, by byl problém v nedostupnosti alespoň jednoho doménového řadiče a uživatelé by nebyli schopni autorizovat se a přihlásit se tak do systému. Proto bude server CNS1 migrován pouze
72
lokálně ze staršího hardwaru na novější server s ESXi hypervisorem, který získáme po přesunutí služeb remote desktop serveru TS. Remote desktop server TS jsme nakonec nemigrovali pomocí aplikace VMware vCenter Converter, ale proběhla nová instalace operačního systému a nová instalace remote desktop services, kde již byla umožněna služba RemoteApp. Uživatel má v tomto případě na svém desktopu pouze zástupce aplikace, kterou chce z remote desktop serveru spouštět, nepozná tak vlastně rozdíl mezi aplikací spouštěnou lokálně a pomocí této služby. Zároveň došlo i k upgradu firemního informačního systému na vyšší verzi, takže instalaci tohoto softwaru bychom museli absolvovat tak jako tak, i kdybychom celý server migrovali pomocí produktů VMware. Linuxový server CNS2, který ve společnosti slouží jako FTP server byl migrován offline pomocí aplikace VMware vCenter Converter. Fyzický server byl v tomto případě restartován a nabootován z vCenter Converter Boot CD a z něj pak naimportován do virtuálního prostředí VMware vSphere. Po úspěšné migraci bylo na virtuální server nutno nainstalovat VMware tools pro správné fungování operačního systému nad virtuální infrastrukturou. Další servery, mimo doménový řadič CNS1 byly servery EX, což je poštovní server a TECH, což je doménový řadič, monitoring server a server hostující intranetový portál postavený na Microsoft Sharepoint Services. Migrace těchto serverů byla spojena s další činností, u mail serveru EX bylo potřeba změnit DNS MX záznamy a reverzní záznamy s ohledem na příchozí poštu z internetu, respektive z důvodu změny IP adresy, na které bude mail server po migraci dostupný, u serveru TECH se pak jednalo především o konfiguraci firewallů u zákazníků, přes které monitorovací systém z nové IP adresy bude prostupovat. Oba servery byly migrovány o víkendu, kdy je minimální provoz, avšak za chodu. Ze serveru VMware vCenter, na který jsme si nainstalovali VMware vCenter Converter Client, jsme z vCenter klienta zvolili volbu Import machine, zde zvolili volbu Powered-on machine (server, který je spuštěn), zadali jeho IP adresu, administrátorské jméno a heslo a "rodinu" z které systém je, jako například Windows, linux atp. Poté se Converter na cílovém serveru ověří a nainstaluje si na něj klienta. Následně jsme zvolili na který ESXi server se má naimportovat, jaké má mít server ve VMwaru jméno a jaký má pro něj použít datastore. Oba servery jsme migrovali na datastore diskového pole NetApp. Další volbou pak bylo zvolit kolik má mít který server operační paměti, kolik procesorů, kolik diskového prostoru, případně jaké diskové oddíly se mají migrovat, kolik má mít systém síťových rozhraní. Následně už probíhá samotná migrace serveru z fyzického na virtuální, po přenesení všech dat, ještě servery 73
přenesou změny, které proběhly během přenosu, vypnou server původní a zapnou nový, virtuální.
4.5.9 Instalace a konfigurace NetApp Snap Manager Společnost NetApp je jak o sobě sami říkají především softwarová společnost a nekladou tak důraz, respektive nechlubí se hardwarem, na kterém jejich disková pole běží, ale především softwarem, nad hardwarovou vrstvou. Jako prvotní zálohy všech virtuálních serverů v infrastruktuře jsme proto využili právě jejich softwarový produkt, NetApp Snap Manager for Virtual Infrastructure. Jak sám název produktu napovídá, jedná se o produkt, který má na úrovni diskového pole, případně i za pomoci VMwaru a "snapshotovací" technologie NetApp, provádět zálohy virtuálních serverů na NetApp FASu běžících. Nastavit lze dva způsoby zálohování, první nevyužívá VMware a NetApp Snap Manager vlastně neudělá nic jiného, než že pošle diskovému poli instrukci k tomu, aby provedl snapshot. K tomuto není potřeba VMware a takto snapshotem odzálohovaný server se po obnově tváří jako "cold rebooted server", tedy jako server, který nebyl korektně vypnut, jako server, který vypneme fyzicky tlačítkem power off. Nebezpečí v tomto případě je v případě databází, které nemusí po takovém restartu být konzistentní, avšak záloha jakkoliv velikého virtuálního serveru je v řádech vteřin, v našem prostředí nikdy více jak 5 vteřin. V našem případě jsme proto použili způsob zálohy, kdy je VMware Snap Manager for Virtual Infrastructure instalován a integrován do VMware vCenter serveru. Funguje opět za pomoci snapshotovací technologie NetApp s tím rozdílem, že pokud zde vyvoláme zálohu, dojde nejprve k vytvoření konzistentního snímku virtuálního serveru na úrovni VMwaru, a až tento snímek je pak zálohován snapshotem na úrovni diskového pole. Zde pak máme jistotu konzistentní zálohy i v případě SQL databází, exchange serveru a dalších.
4.5.10 Nastavení záloh virtuálních serverů službou VMware Data Recovery Virtuální servery, respektive aplikace a jejich data jsme v tuto chvíli měli chráněny RAIDem DP, takže bychom o ně nepřišli ani v případě výpadku dvou pevných disků současně v jeden moment, v diskovém poli máme dva storage procesory, takže v případě výpadku jednoho z nich jeho funkci přebírá druhý a nad to ještě na úrovní diskového pole zálohujeme veškeré virtuální servery pomoci NetApp Snap Manageru pro virtuální servery. Všechny tyto vyjmenované prvky ochrany našich dat jsou však závislé na robustním, enterprise diskovém 74
poli NetApp, avšak žádná záloha mimo toto pole neexistovala. Z tohoto důvodu bylo nutné nakonfigurovat zálohy pomocí služby VMware Data Recovery, který jsme nakonfigurovali, aby zálohoval veškeré virtuální servery vždy o víkendu a to na k tomu určené diskové pole NetGear. Toto bylo nutné nakonfigurovat až poté, co budou na VMware ESXi serverech běžící virtuální stroje, které chceme zálohovat.
4.5.11 Instalace VMware ESXi server na původní server TS Po migraci serveru TS, který sloužil jako remote Desktop Services, do virtuálního prostředí, byl tento server Hawlett Packard Proliant ML350, díky tomu, že byl nejvýkonnější a nejnovější, vyhrazen k tomu, aby v sídle společnosti zůstal a běžely na něm aplikace a služby, které není možné, nebo spíše není vhodné mít ve vzdálené lokalitě připojené přes virtuální privátní síť, jako je například domain controller (řadič domény). S ohledem na snahu zachovat homogenní prostředí napříč celou společností byl na tento server, stejně jako na novou infrastrukturu, nainstalován VMware ESXi Server 4.1, v tomto případě pouze nelicencovaná, registrovaná verze zdarma. Správa virtuálního prostředí tak bude probíhat z jedné jediné konzole VMware vCenter, kde budou připojeny a spravovány jak licencované servery v datacentru společnosti, tak tento server v sídle firmy. Připojeni tohoto ESXi serveru k správě proběhlo bez jakýchkoliv problémů a server je tak spravovatelný z VMware vCenter.
4.5.12 Migrace doménového řadiče CNS1 na ESXi server v sídle společnosti Po instalaci VMware ESXi serveru verze 4.1 byl server důkladně otestován, zda nedošlo k nějakému problému instalací virtuálního prostředí, respektive hypervisoru, z důvodu stability a výkonnosti. Na server byly nainstalovány virtuální servery a spuštěny zátěžové testy a až následně, kdy bylo vše ověřeno a vyhodnoceno, došlo na migraci serveru CNS1. Před samotnou migrací byl server zálohován pomocí aplikace Acronis True Image Server 9.124, který bude i následně používán k denní záloze, na úrovni snímku celého serveru, respektive jeho pevného disku. K samotné migraci byl použit nástroj VMware vCenter Converter, který umožňuje migraci serveru bez nutnosti výpadku provozu. Tento nástroj si 24
Acronis True Image Server 9.1. [online]. 2007 [cit. 2012-01-24]. Dostupné z: http://www.acronis.com.uy/documentos/pdf/trueimageserver9.1_ug.en.pdf
75
udělá snímek celého disku a následně začne celý disk po síťovém rozhraní migrovat do virtuálního prostředí VMware ESXi serveru. Poté co jsou veškerá data přenesena, přenese i rozdíly, které vznikly od chvíle, kdy byl pořízen první snímek, po moment, kdy došlo k jeho přenos na cílový server. Veškeré služby spojené se serverem CNS1 jako jsou active directory domain services, domain services, DHCP server a tiskový server byly ihned po migraci funkční, nebylo tak potřeba cokoliv na serveru měnit či přenastavovat. Virtuální server je tak nainstalován na hardwaru, který už není pod zárukou, nebo chráněn HP care pack, což může znamenat jisté riziko v kontinuitě běhu v sídle firmy v případě nějakého výpadku. Z tohoto důvodu je server, mimo každodenních záloh pomocí produktu Acronis, ještě klonován na síťové úložiště NetGear ReadyNAS NV+ v sídle společnosti. V případě selhání serveru tak stačí pouze import tohoto klonu a veškeré jeho služby mohou být znovu nastartovány v řádu několika minut.
4.6 Zhodnocení řešení Cíle, které si společnost před samotnou migrací firemní IT infrastruktury do virtuálního prostředí shrnula do pěti základních bodů, byly potřeba vyhodnotit, zda-li virtualizací a použitým řešením došlo k jejich splnění.
4.6.1 Zvýšení kontinuity činnosti společnosti Jedním z nejdůležitějších úkolů celého projektu bylo dosažení maximální kontinuity činnosti IT infrastruktury, respektive pro společnost kritických systémů a aplikací. Tento úkol byl splněn na všech úrovních infrastruktury, na úrovni diskového pole NetApp FAS, které je vybaveno dvěma storage procesory s funkcí vysoké dostupnosti, kdy jeden storage procesor přebírá funkci druhého v případě výpadku, vysoce zabezpečeným diskovým polem chráněným za pomoci RAID DP doplněný spare diskem. Na úrovni serverů máme dva servery Hawlett Packard, které jsou od výrobce chráněny pomocí smlouvy HP Care Pack, v případě výpadku jednoho z fyzických serverů se na druhém, běžícím serveru, za pomoci služby VMware High Availability automaticky nastartují virtuální servery, které do chvíle selhání fungovali na původním serveru. Datacentrum je pak chráněno proti výpadku dodávek elektrické energie za pomocí bateriových ochran a diesel agregátů, integrovaným systémem
76
klimatizace, z důvodu dostupnosti má dvě na sobě nezávislé internetové konektivity. Stejně tak v sídle společnosti, jsou dvě internetová připojení od dvou poskytovatelů.
4.6.2 Zjednodušení a zrychlení zálohování a následné obnovy po havárii Zálohováni a obnova všech virtuálních systémů je provozována na dvou úrovních, na úrovni diskového pole NetApp a na úrovni VMware Data Recovery, které virtuální stroje zálohuje na další úložiště NetGear. Diskové pole NetApp FAS2020 zálohuje virtuální servery pomocí snapshotovací technologie a pomocí aplikace NetApp Snapshot Manager for Virtual Infrastructure. Tyto zálohy jsou proveditelné v řádech vteřin, obnova virtuálního serveru pak v řádech minut, v případě selhání celého storage systému by však za použití pouze této varianty záloh nebyla žádná data k dispozici a proto je tato záloha kombinována s druhou úrovní, což je služba VMware Data Recovery, která pravidelně zálohuje všechny servery na datové úložiště NetGear ReadyNAS.
4.6.3 Snížení energetické náročnosti celé infrastruktury Původní servery, které nebyly virtualizovány měly spotřebu od 95 W do 165 W za 1 hodinu, při nonstop běhu to za jeden rok činí 7095 kWh, což při průměrné ceně okolo 4,50 Kč za 1 kWh činí náklady cca 32000 Kč. V této ceně pak není zahrnuta cena nutná pro klimatizování těchto serverů, která také není zanedbatelná, a při menším počtu serverů bude samozřejmě nižší.
Tabulka č. 3: Spotřeba energií původních serverů Název serveru CNS1 EX TS TECH CNS2 NAS
Spotřeba W/h 165 165 165 165 95 55
Roční spotřeba kWh 1445.4 1445.4 1445.4 1445.4 832.2 481.8
Zdroj: Vlastní úprava
77
Virtualizováním infrastruktury jsme sice snížili počet fyzických serverů a nové servery jsou výrazně úspornější, ale začlenili jsme nově dvě diskové pole, z nichž NetApp FAS2020 má vysokou spotřebu okolo 400 W za hodinu. Ročně pak celá infrastruktura, včetně serveru CNS1, který zůstal v sídle společnosti, spotřebuje cca 7227 kWh, což pří ceně 4,50 Kč za 1 kWh odpovídá 32500 Kč za rok.
Tabulka č. 4: Spotřeba energií virtualizované infrastruktury Název serveru CNS1 ESXPHA1 ESXPHA2 NetApp FAS NetGear NAS
Spotřeba W/h 165 65 65 400 75 55
Roční spotřeba kWh 1445,4 569,4 569,4 3504 657 481,8
Zdroj: Vlastní úprava
Při pohledu na spotřebu energií před a po virtualizaci by se mohlo zdát, že se nám úkol snížit energetickou náročnost IT infrastruktury nezdařil, když před migraci jsme za energie zaplatili 32000 Kč a po migraci 32500 Kč. Rozdíl to není veliký a skutečně spotřeba je vyšší, ale je třeba si uvědomit, že kapacita této infrastruktury není vyčerpána a s rostoucím počtem virtuálních serverů spotřeba poroste jen minimálně, na rozdíl od scénáře, kdybychom přidávali nový fyzický server. Na infrastrukturu bylo později přemigrováno a nainstalováno několik zákaznických serverů, takže se dá říci, že i tento bod byl splněn.
4.6.4 Snížení nákladů na údržbu infrastruktury Náklady na údržbu infrastruktury jsou převážně finance spojené s nutnou obměnou serverů. Pokud jsme měli serverů pět, znamená to, že v případě obměny bylo potřeba nakoupit pět serverů a provést veškeré práce s tím spojené, jako jsou reinstalace operačních systémů na serverech běžící, znovu nastavit veškeré zálohy, ověřit zda vše funguje jako před obměnou. Po virtualizaci máme místo 5 fyzických serverů, servery 3 což jen v cenách hardwaru je poměrně vysoká úspora v případě obměny, nepočítaje instalační práce spojené s virtuálními 78
servery, které nám úplně odpadnou. Virtuální servery za chodu přemigrujeme pomocí VMware vMotion na druhý server, následně server bez virtuálních strojů vypneme, nahradíme novým host serverem a virtuální stroje na něj zase zpět přesuneme, bez jakéhokoliv výpadku, uživatelé tak ani nezaznamenají, že prostředí ve kterém pracují je najednou na úplně jiném hardwaru. Zálohy probíhají stále na úrovni diskového pole NetApp a VMwaru, není tak potřeba nic nově konfigurovat. Diskové pole s funkcí deduplikace pak také snižuje nutnost investice do jejího dalšího rozšíření, funkčnost v našem prostředí je vidět na následujícím obrázku.
Obrázek č. 42: Deduplikace na diskovém poli NetApp FAS2020
Zdroj: Vlastní úprava
4.6.5 Rozšiřitelnost infrastruktury Dalším cílem očekávaným od virtuální infrastruktury byla možnost snadné rozšiřitelnosti a využitelnost pro hostování zákaznických serverů a služeb. Veškeré námi použitá infrastruktura je snadno rozšiřitelná, diskové pole lze v případě potřeby rozšířit o další polici s disky, v případě nedostatku výkonu doplnit o Flash Cache, v případě serverů lze pak snadno do infrastruktury zařadit nový host VMware ESXi server. Krátce po nasazení virtuální infrastruktury postavené na technologiích HP, VMware a NetApp se nám podařilo přesvědčit několik našich zákazníků a přemigrovat některé jejich servery a aplikace do našeho virtuálního prostředí. V současné době by nejspíš bylo vhodné použít slovo Cloud, zákazník se nestará o server, dostává aplikace ve formě služeb, svá data nemá na svých serverech a diskových polích, není vlastníkem licencí.
79
5 Závěry a doporučení Svou diplomovou práci jsem věnoval jak po teoretické tak praktické stránce problematice virtualizace. Při zpracovávání jsem si uvědomil rozsáhlost celé problematiky, kdy virtualizace se v několika posledních letech stala nejrychleji se rozvíjejícím oborem v informačních technologiích, že není možné podrobně obsáhnout vše tak, jak bych si představoval, v rozsahu diplomové práce. V první části jsem se snažil především o obecný popis problematiky virtualizace, co lze virtualizovat a jakým způsobem, jaké jsou výhody při virtualizaci firemních serverů a aplikací. Na to jsem navázal virtualizaci za využití produktů společnosti VMware a diskových polích NetApp, kdy jsem u obou produktů popsal jejich základní funkčnost a některé nadstandartní možnosti obou řešení spojené s virtualizací. V praktické části jsem pak popsal realizaci takového řešení v reálné společnosti při využití právě produktů VMware a NetApp, od určení cílů, které od virtualizace a konsolidace firemní infrastruktury očekáváme, výběru řešení a pořízení softwaru a hardwaru, přes implementaci a následné vyhodnocení celé migrace, zda a jak byly splněny předem dané cíle. Veškeré odkazy na externí zdroje uvedené v této práci byly v době tvorby aktuální a platné a doufám, že čtenáři má práce pomůže pochopit a případně úspěšně realizovat podobný projekt.
80
6 Seznam použité literatury a zdrojů [1]
Acronis True Image Server 9.1. [online]. 2007 [cit. 2012-01-24]. Dostupné z: http://www.acronis.com.uy/documentos/pdf/trueimageserver9.1_ug.en.pdf
[2]
AMD Virtualization (AMD-V™) Technology. AMD [online]. 2012 [cit. 2011-12-18]. Dostupné z: http://sites.amd.com/uk/business/it-solutions/virtualization/Pages/amdv.aspx
[3]
BHATIA, Nikhil, Chirag BHATT a Lei CHAI. VMware vCenter Server Performance and Best Practices. [online]. 2010 [cit. 2012-02-04]. Dostupné z: http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_VC_Best_Practices.pdf
[4]
Hardware-Assisted Virtualization Technology. Intel [online]. 2012 [cit. 2011-12-18]. Dostupné z: http://www.intel.com/content/www/us/en/virtualization/virtualizationtechnology/hardware-assist-virtualization-technology.html
[5]
History of NetApp. NetApp [online]. 2011 [cit. 2011-12-22]. Dostupné z: http://www.netapp.com/us/company/new2netapp/history.html
[6
]
History of Virtualization. ALL-IN-ONE NETWORK SOLUTIONS. All-In-One Network Solutions [online]. 26.1.2009 [cit. 2011-11-11]. Dostupné z: http://www.aiosolutions.com/what_is_virtualization.php
[7]
HP Care Pack Services. Hawlett Packard [online]. 2012 [cit. 2012-01-12]. Dostupné z: http://www8.hp.com/uk/en/support-drivers/carepack/hp-carepack.html
[8]
HP Systems Insight Manager. HP SIM [online]. 2012 [cit. 2012-01-24]. Dostupné z: http://h18013.www1.hp.com/products/servers/management/hpsim/index.html?jumpid =go/hpsim
[9]
Go further, faster with NetApp: Our Innovation Helps Lower Your IT Costs and Accelerate Your Business. NetApp [online]. 2011 [cit. 2011-12-22]. Dostupné z: http://www.netapp.com/us/company/our-story/
[10]
Google Projects for Android. Google [online]. 2011 [cit. 2011-12-18]. Dostupné z: http://code.google.com/android/
[11]
HITZ, Dave, James LAU a Michael MALCOLM. File System Design for and NFS Server Appliance. Sunnyvale, CA, USA, 2005, 13 s. Dostupné z: http://media.netapp.com/documents/wp_3002.pdf
81
[12]
Intel® Xeon® Processor E5504. Intel [online]. 2012 [cit. 2012-01-12]. Dostupné z: http://ark.intel.com/products/40711/Intel-Xeon-Processor-E5504-(4M-Cache-2_00GHz-4_80-GTs-Intel-QPI)
[13]
Is Data ONTAP Based On UNIX?. In: HITZ, Dave. NetApp [online]. 2007-04-27 [cit. 2012-03-29]. Dostupné z: https://communities.netapp.com/community/netappblogs/dave/blog/2007/04/27/is-data-ontap-based-on-unix
[14]
MADDEN, Brian. Desktop virtualization is more than VDI. SearchVirtualDesktop [online]. 2009-04-08 [cit. 2011-12-19]. Dostupné z: http://searchvirtualdesktop.techtarget.com/news/1353117/Desktop-virtualization-ismore-than-VDI#
[15]
Network File System (NFS). NetApp [online]. 2012 [cit. 2012-01-12]. Dostupné z: http://www.netapp.com/us/products/protocols/nas/nfs.html
[16]
SCHERER, Rick. Case Study: Boosting Storage Efficiency with Deduplication, Thin Provisioning, and FlexClone. NetApp [online]. 2011 [cit. 2011-12-24]. Dostupné z: Case Study: Boosting Storage Efficiency with Deduplication, Thin Provisioning, and FlexClone
[17]
Servery HP ProLiant DL. Hawlett Packard [online]. 2012 [cit. 2012-01-12]. Dostupné z: http://h10010.www1.hp.com/wwpc/cz/cs/sm/WF02a/15351-153513328412.html?dnr=1
[18]
SHIELDS, Greg. REALTIME PUBLISHERS. Selecting the right virtualization solution [online]. 2008 [cit. 2011-12-12]. ISBN 1931491755, 9781931491754. Dostupné z: http://books.google.cz/books/about/The_Shortcut_Guide_to_Selecting_the_Righ.html ?id=hN-rs6eBUiwC&redir_esc=
[19]
The Definitive Guide to the ReadyNAS NV+. In: NetGear ReadyNAS Community [online]. 2008 [cit. 2012-01-05]. Dostupné z: http://www.readynas.com/?p=331#Specifications
[20]
The State of Disaster Recovery Preparedness. DINES. Disaster Recovery Journal [online]. 2011-02-16 [cit. 2011-12-06]. Dostupné z: http://www.drj.com/images/surveys_pdf/forrester/2011Forrester_survey.pdf
[21]
Úložné zařízení ReadyNAS 2100 (4 x 2 TB). NetGear [online]. 2012 [cit. 2012-0113]. Dostupné z: http://www.netgear.cz/business/products/zalohovani/xx00/RNRX4420.aspx
82
[22]
VMware Milestones. VMware Media Resource Center [online]. 2011 [cit. 2012-1224]. Dostupné z: http://www.vmware.com/company/mediaresource/milestones.html
[23]
VMware vCenter Server. VMware [online]. 2011 [cit. 2011-12-26]. Dostupné z: http://www.vmware.com/products/vcenter-server/overview.html
[24]
What is I/O Virtualization?. CRUMP, George. Storage Switzerland [online]. 2010-0621 [cit. 2011-12-28]. Dostupné z: http://www.storageswitzerland.com/Articles/Entries/2010/6/21_What_is_I_O_Virtualization.html
83
7 Seznam použitých symbolů a zkratek AMD-V
Advanced Micro Devices Virtualization
BCM
Business Continuity Plan - plánování a řízení kontinuity podnikání
Cache
Vyrovnávací, rychlá paměť
CIFS
Common Internet File System
CLI
Command Line Interface
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System
DRS
Distributed Resource Scheduler – služba pro dynamické rozdělování zdrojů
EULA
End User License Agreement
FAS
Fabric Attached Storage
FC
Fibre Channel
FcoE
Fibre Channel over Ethernet
FT
Fault Tolerance
FTP
File Transfer Protocol
GUI
Graphical User Interface – grafické uživatelské rozhraní
HA
High Availibility – vysoká dostupnost
HTTP
HyperText
Transfer
Protocol
–
internetový
protokol
hypertextových dokumentů ve formátu HTML I/O
Input/Output – vstupně-výstupní operace
IAS
Internet Authentication Service
Image
Digitální obraz/kopie disku
Intel VT
Intel Virtualization Technology
iSCSI
Rozhraní pro připojení paměťových zařízení prostřednictvím sítě
ISO
Obraz, digitální otisk disku
LUN
Logical Unit Number 84
pro
výmenu
NAS
Network Attached Storage – síťové datové úložiště
NDO
Nondisruptive operations / No data outages - data bez výpadku.
NFS
Network File System - internetový protokol pro přístup k souborům přes síť
OS
Operating System - operační systém
PAM
Performance acceleration Module – NetApp Flash Cache
Partition
Diskový oddíl, slouží k rozdělení fyzického disku na oddíly
Patch
Oprava při aktualizaci softwaru
QoS
Quality of Service – termín označující obvykle řízení a rezervaci datových toků
RAID
Redundant array of independent/inexpensive disks – vícenásobné diskové pole nezávislých/levných disků, např RAID0, RAID1, RAID5 …
RDS
Remote desktop services/server – vzdálená plocha
RSYNC
Nástroj pro synchronizaci souborů a adresářů
SAN
Storage area network - síť, která slouží pro připojení datových zařízení
Snapshot
Obraz/kopie systému
SQL
Structured Query Language – dotazovací databázový jazyk
SSD
Solid State Disk
VDI
Virtual desktop infrastructure – využití vzdáleného centralizovaného prostředí
VDR
VMware Data Recovery – zálohovací program
VM
Virtual Machine
VMDK
Virtual Machine Disk
VMFS
Virtual Machine File Systém – používá VMware, clusterový file systém
WAFL
Write Anywhere File Layout – souborový systém
ZFS
Zettabyte File System – souborový systém
85
8 Seznam použitých obrázků Obrázek č. 1:
Fyzický a virtualizovaný server a OS
Obrázek č. 2:
Nativní virtualizace
Obrázek č. 3:
Paravirtualizace
Obrázek č. 4:
Virtualizace na úrovni OS
Obrázek č. 5:
Emulace a simulace
Obrázek č. 6:
Schéma terminálových služeb
Obrázek č. 7:
Schéma lokální virtualizace desktopu
Obrázek č. 8:
Schéma VDI
Obrázek č. 9:
Relace uživatele k VDI
Obrázek č. 10:
Aplikační virtualizace
Obrázek č. 11:
Schéma HA zapojení FAS
Obrázek č. 12:
Schéma HA zapojení FAS - nefunkční jeden z řadičů
Obrázek č. 13:
NetApp Flash Cache
Obrázek č. 14:
NetApp Flash Cache - přístupová doba
Obrázek č. 15:
NetApp GUI - Operations manager
Obrázek č. 16:
Parita u RAID 4
Obrázek č. 17:
Druhá (diagonální) parita u RAID DP
Obrázek č. 18:
Barevné znázornění výpočtu parity Raidu DP
Obrázek č. 19:
Raid DP výpadek svou disků dopočet dat na discích
Obrázek č. 20:
Raid DP výpadek svou disků dopočet dat na discích
Obrázek č. 21:
Raid DP výpadek svou disků dopočet dat na discích
Obrázek č. 22:
Raid DP výpadek svou disků dopočet dat na discích
Obrázek č. 23:
Raid DP výpadek svou disků dopočet dat na discích
Obrázek č. 24:
Raid DP výpadek svou disků dopočet dat na discích
Obrázek č. 25:
Raid DP výpadek svou disků dopočet dat na discích 86
Obrázek č. 26:
Raid DP výpadek svou disků dopočet dat na discích
Obrázek č. 27:
Raid DP výpadek svou disků dopočet dat na discích
Obrázek č. 28:
WAFL - První snapshot
Obrázek č. 29:
WAFL - Změna dat po prvním snapshotu
Obrázek č. 30:
WAFL - Druhý snapshot se změnou dat
Obrázek č. 31:
VMware High Availability - selhání jednoho z ESXi serverů
Obrázek č. 32:
VMware Data Recovery - záloha virtuálních serverů
Obrázek č. 33:
VMware vMotion
Obrázek č. 34:
VMware vStorage Thin Provisioning
Obrázek č. 35:
VMware vCenter Converter
Obrázek č. 36:
Agregát na prvním storage procesoru
Obrázek č. 37:
Agregát na druhém storage procesoru
Obrázek č. 38:
Instalace VMware ESXi
Obrázek č. 39:
Instalace VMware ESXi - výběr úložiště pro instalaci
Obrázek č. 40:
Instalace VMware ESXi - defaultní obrazovka serveru po instalaci
Obrázek č. 41:
Povoleni služeb VMware HA a DRS
Obrázek č. 42:
Deduplikace na diskovém poli NetApp FAS2020
87
9 Seznam použitých tabulek Tabulka č. 1: Přehled serverů ve společnosti Tabulka č. 2: Náklady na virtuální infrastrukturu Tabulka č. 3: Spotřeba energií původních serverů Tabulka č. 4: Spotřeba energií virtualizované infrastruktury
88
Příloha č. 1 Přehled FAS zařízení NetApp
Model
Uvedeno
CPU
Paměť
NVRAM
Kapacita
FASServer 400
Jan 1993
50 MHz Intel i486
? MB
4 MB
14 GB
FASServer 450
Jan 1994
50 MHz Intel i486
? MB
4 MB
14 GB
FASServer 1300
Jan 1994
50 MHz Intel i486
? MB
4 MB
14 GB
FASServer 1400
Jan 1994
50 MHz Intel i486
? MB
4 MB
14 GB
FASServer
Jan 1995
50 MHz Intel i486
256 MB
4 MB
? GB
F330
Sept 1995
90 MHz Intel Pentium
256 MB
8 MB
117 GB
F220
Feb 1996
75 MHz Intel Pentium
256 MB
8 MB
? GB
F540
June 1996
275 MHz DEC Alpha 21064A
256 MB
8 MB
? GB
F210
May 1997
75 MHz Intel Pentium
256 MB
8 MB
? GB
F230
May 1997
90 MHz Intel Pentium
256 MB
8 MB
? GB
F520
May 1997
275 MHz DEC Alpha 21064A
256 MB
8 MB
? GB
F630
June 1997
500 MHz DEC Alpha 21164A
512 MB
32 MB
? GB
F720
Aug 1998
400 MHz DEC Alpha 21164A
256 MB
8 MB
464 GB
F740
Aug 1998
400 MHz DEC Alpha 21164A
512 MB
32 MB
928 GB
F760
Aug 1998
600 MHz DEC Alpha 21164A
1 GB
32 MB
1.39 TB
F85
Feb 2001
256 MB
64 MB
648 GB
F87
Dec 2001
256 MB
64 MB
576 GB
F810
Dec 2001
512 MB
128 MB
1.5 TB
733 MHz Intel P3 Coppermine
1
F820
Dec 2000
733 MHz Intel P3 Coppermine
1 GB
128 MB
3 TB
F825
Aug 2002
733 MHz Intel P3 Coppermine
1 GB
128 MB
3 TB
F840
Aug 2000
733 MHz Intel P3 Coppermine
3 GB
128 MB
6 TB
F880
July 2001
Dual 733 MHz Intel P3 Coppermine
3 GB
128 MB
9 TB
FAS920
May 2004
2.0 GHz Intel P4 Xeon
2 GB
256 MB
7 TB
FAS940
Aug 2002
1.8 GHz Intel P4 Xeon
3 GB
256 MB
14 TB
Aug 2002
Dual 2.2 GHz Intel P4 Xeon
6 GB
256 MB
28 TB
Jan 2004
Dual 2.8 GHz Intel P4 Xeon MP 2 MB L3
8 GB
512 MB
50 TB
Jan 2004
600 MHz Broadcom BCM1250 dual core MIPS
512 MB
64 MB
4 TB
FAS270
Jan 2004
650 MHz Broadcom BCM1250 dual core MIPS
1 GB
128 MB
16 TB
FAS2020
June 2007
2.2 GHz Mobile Celeron
1 GB
128 MB
68 TB
FAS2040
Sept 2009
1.66 GHz Intel Xeon
4 GB
512 MB
136 TB
FAS2050
June 2007
2.2 GHz Mobile Celeron
2 GB
256 MB
104 TB
FAS2240
November 2011
1.66 GHz Intel Xeon
6 GB
FAS3020
May 2005
2.8 GHz Intel Xeon
2 GB
512 MB
84 TB
FAS960
FAS980
FAS250
2
FAS3040
Feb 2007
Dual 2.4 GHz AMD Opteron 250
FAS3050
May 2005
Dual 2.8 GHz Intel Xeon
4 GB
512 MB
168 TB
Nov 2006
Dual 1.8 GHz AMD dual core Opteron
8 GB
512 MB
504 TB
June 2008
Single 2.4 GHz AMD Opteron Dual Core 2216
4 GB
512 MB
420 TB
FAS3160
Dual 2.6 GHz AMD Opteron Dual Core 2218
8 GB
2 GB
672 TB
FAS3170
June 2008
Dual 2.6 GHz AMD Opteron Dual Core 2218
16 GB
2 GB
840 TB
FAS3210
Nov 2010
Dual 2.3 GHz Intel Xeon(tm) Processor (E5220)
8 GB
2 GB
480 TB
FAS3240
Quad 2.33 GHz Intel Nov 2010 Xeon(tm) Processor (Harpertown)
16 GB
2 GB
1,200 TB
Nov 2010
Dual 3.0 GHz Intel Xeon(tm) Processor (E5240)
32 GB
4 GB
1,920 TB
Mar 2006
Dual 2.6 GHz AMD Opteron
32 GB
512 MB
840 TB
FAS3070
FAS3140
FAS3270
FAS6030
3
4 GB
512 MB
336 TB
FAS6040
FAS6070
FAS6080
FAS6210
FAS6240
FAS6280
2.6 GHz Dec 2007 AMD dual core Opteron Mar 2006
Quad 2.6 GHz AMD Opteron
4 to 8 2.6 GHz Dec 2007 AMD dual core Opteron Nov 2010 4x 2.53 GHz Nov 2010 Intel Xeon(tm) Processor E5540 4x 2.93 GHz Nov 2010 Intel Xeon(tm) Processor X5670
Legenda
16 GB
512 MB
840 TB
64 GB
2 GB
1,008 TB
64 GB
4 GB
1,176 TB
48 GB
8 GB
2,400 TB
96 GB
8 GB
2,880 TB
192 GB
8 GB
2,880 TB
Vyráběno Nevyráběno
Zdroj: http://www.netapp.com/us/products/
4