Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Virtualizace Vysoká dostupnost serverové infrastruktury Bakalářská práce
Autor:
Petr Oliva Informační technologie
Vedoucí práce:
Praha
Ing. Vladimír Beneš
červen, 2013
Prohlášení: Prohlašuji, ţe jsem bakalářskou 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, 26. 6. 2013
Petr Oliva
Velice děkuji vedoucímu mé bakalářské práce Ing. Vladimíru Benešovi Petrovickému za cenné rady a čas, který mé práci věnoval. Můj dík patří také mé rodině za poskytnutou podporu a mé ţeně za toleranci, trpělivost a tvrdý dohled. Petr Oliva
Anotace Bakalářská práce se zabývá technologiemi virtualizace a jejich přínosem pro firemní serverovou infrastrukturu z pohledu zajištění vysoké dostupnosti provozovaných sluţeb. První část práce je věnována představení jednotlivých virtualizačních technologií na trhu spolu s jejich vyhodnocením v reálném nasazení. Druhá část představuje konkrétní virtualizační technologie pro zajištění vysoké dostupnosti. Obsahem třetí části je vyhodnocení ekonomického přínosu nasazení virtuálního prostředí. Klíčová slova: virtualizace, vysoká dostupnost, VMware, vSphere, ESXi, vMotion, HA, Fault Tolerance, DRS, Hyper-V, Citrix, Xen
Annotation The thesis covers the virtualization technologies and their benefits for corporate server infrastructure from the perspective of ensuring high availability of operated services. The first part is introducing different virtualization technologies available on the market together with their assessment in real life deployment. The second part introduces specific virtualization technologies for high availability. Content of the third part evaluates economic benefits of virtual environment. Key words: virtualization, high availability, VMware, vSphere, ESXi, vMotion, HA, Fault Tolerance, DRS, Hyper-V, Citrix, Xen
Obsah Úvod ........................................................................................................................................... 6 1.
Hardwarová virtualizace ..................................................................................................... 7 1.1
VirtualBox ................................................................................................................... 9
1.2
Citrix Xen server ........................................................................................................ 12
1.3
Virtualizace Microsoft ............................................................................................... 16
1.3.1
Virtual PC.......................................................................................................................16
1.3.2
Virtual Server .................................................................................................................16
1.3.3
Hyper-V..........................................................................................................................17
1.4
1.4.1
VMware Workstation .....................................................................................................21
1.4.2
VMware ESX/ESXi Server ............................................................................................23
1.5 2.
3.
Virtualizace VMware ................................................................................................. 21
Shrnutí virtualizačních technologií ............................................................................ 29
Vysoká dostupnost serverové infrastruktury ..................................................................... 34 2.1
vMotion ...................................................................................................................... 36
2.2
Storage vMotion ........................................................................................................ 39
2.3
High Availability (HA) .............................................................................................. 41
2.4
Fault Tolerance (FT) .................................................................................................. 48
2.5
Distributed Resource Scheduler (DRS)...................................................................... 49
Ekonomické vyhodnocení ................................................................................................. 52
Závěr ......................................................................................................................................... 54 Seznam pouţité literatury ......................................................................................................... 55
5
Úvod Slovo „virtual“ by se z angličtiny dalo přeloţit jako „fiktivní“ nebo „zdánlivý“. Toto spojení by tedy mohlo evokovat zdání, ţe virtualizace je něco nereálného, či falešného. Faktem je, ţe princip této technologie je na fikci zaloţen. I přes to, ţe uvnitř jakéhosi obalu se dějí unikátní procesy, vně tohoto obalu se celek tváří jako něco úplně jiného, strukturou jasně definovaného. Kdokoliv nebo cokoliv je pak v interakci s takovýmto objektem, nepochybuje o jeho relevantnosti. Z pohledu zaměření této práce lze zjednodušeně říci, ţe virtualizace je systém sdílení zdrojů fyzického počítače mezi mnoho různých na něm běţících prostředí. Virtualizace je pojem, který se v posledních letech stal v oblasti informačních technologií pojmem velmi výrazným. Za nespornou výhodu této technologie je pokládáno především výrazné sníţení nákladů na správu a provozování serverové infrastruktury. Technologie jako taková však není pouze o virtualizaci serverů, případně klientských stanic, ale virtualizovat můţeme i jednotlivé aplikace. Existuje ještě celá řada dalších oblastí, které postupně doplňují virtualizační prostředí, například virtualizace celé síťové vrstvy nebo dokonce celá virtuální datacentra. V následujícím textu se však budeme podrobněji věnovat převáţně virtualizaci serverů a technologií pro zajištění vysoké dostupnosti sluţeb, které poskytují. V první kapitole práce se zaměřím na představení jednotlivých virtualizačních technologií a produktů. Detailněji se pak budu věnovat těm produktům, které mají na trhu významný podíl a jsou určeny pro podnikovou sféru. Kapitola bude shrnuta fakty o třech hlavních zástupcích serverové virtualizace, jejich postavení na trhu a názorů odborníků. Druhá kapitola jiţ bude zaměřena čistě na technologie zajišťující vysokou dostupnost provozovaných sluţeb na serverové infrastruktuře. Budou popisovány výhradně technologie z produkce společnosti VMware, jakoţto lídra na trhu virtualizací a předního technologického inovátora. Kromě detailního popisu jednotlivých funkcí také zmíním moţnosti jejich vyuţití v reálném nasazení. Ve třetí kapitole zhodnotím obecně ekonomický přínos virtualizačních technologií v podnikovém prostředí. Teoretickými výpočty nastíním představu o moţnostech úspor nákladů za provoz a podloţím reálnými čísli konkrétního případu z praxe.
6
1. Hardwarová virtualizace Hardwarovou virtualizaci chápeme jako vytvoření virtuálního stroje (dále VM), který se chová jako skutečný počítač s operačním systémem. Fyzický počítač, na kterém je VM umístěn, je nazýván hostitelským počítačem neboli HOSTem1. Operační systém tohoto počítače nemá vliv na pouţitý operační systém VM. Ve virtuálním stroji můţe být pouţit libovolný operační systém, který je virtuálním prostředím podporován. Operační systém a ostatní software na VM jsou odděleny od hardwarových zdrojů hostitelského počítače, který je emulován virtuálním prostředím. Hardwarovou virtualizaci bychom mohli dále rozdělit do tří podskupin[3]: 1. Plná virtualizace, kdy dochází k téměř dokonalé simulaci skutečného hardwaru. To umoţňuje aplikacím, které závisí na operačním systému VM, aby běţely bez nutnosti jakýchkoliv úprav. 2. Částečná virtualizace, kde je simulována pouze část cílového prostředí. Zde musí být některé aplikace upraveny, aby na takovém VM mohly fungovat. 3. Paravirtualizace, kde není hardware simulován vůbec, nicméně aplikace jsou spouštěny ve vlastních, izolovaných oblastech, jako by běţely na odděleném systému. Tyto programy však vyţadují zvláštní úpravy, aby na takovém prostředí mohly být spuštěny. Nejznámějšími komerčními softwarovými implementacemi paravirtualizace jsou modifikovaná jádra systému Linux od XenSource a GNU/Linux distribucí. Plná virtualizace je v dnešní době podporována samotným hardwarem. Základem je především speciálně navrţený procesor (CPU) a další komponenty, které pomáhají zvýšit výkon VM běţících na hostitelském počítači. Do běţně dostupných procesorů se tato technologie implementuje od roku 2006 a dnešní moderní VM platformy ji ke svému běhu přímo vyţadují (VMware pro x64 platformy, Microsoft Hyper-V, Linux KVM, a další)[4]. Tato podpora spočívá ve správě přístupů do ochranných sekcí procesoru, nazývaných „ring“. Tyto kruhy jsou definovány čtyři – ring 0, ring 1, ring 2, ring 3. Ring 0 je nejvyšší privilegovaná oblast, která má přímý přístup na hardware, jakým je CPU, paměť, atd. Oproti 1
Hostitel a host jsou v odborných kruzích nepřekládané termíny a pouţívají se tedy jejich anglické výrazy. Důvodem jsou moţné zmatky v označení, neboť: hostitel – host (ang.), host – guest (ang.). Povšimněte si, ţe anglický výraz pro hostitele je shodný s českým výrazem pro hosta. V textu tedy budu nadále pouţívat i běţně pouţívané anglické výrazy, případně opis výrazů českých, abych zmatečnému významu předešel.
7
tomu ring 3 je určen pro přístup aplikacím a nemá přímý přístup k hardwaru (spyware běţící jako aplikace nemůţe například zapnout webovou kameru, aniţ by o tom byl uţivatel informován). Důvodem je ochrana celého systému. Pokud by došlo k chybě v ringu 0, dojde k pádu celého systému. Pokud dojde k chybě v ringu 2, dojde k chybě pouze v ringu 3 a ringu 2 samotném, zbytek systému je ochráněn[5]. Dále se budu podrobněji věnovat jednotlivým platformám, které plnou virtualizaci nabízejí. Odborně se nazývají „Virtual machine monitor“ a značí zkratkou VMM (obecně jsou spíš známé jako hypervisor). Těchto platforem existuje celá řada, a protoţe není primárním cílem této práce podrobně popsat všechny dostupné produkty na trhu, budu se věnovat pouze těm nejrozšířenějším.
8
1.1 VirtualBox Oracle VM VirtualBox je x86 virtualizační software původně vytvořený společností Innotek GmbH, která byla následně v únoru 2008 koupena společností Sun Microsystems. Od ledna 2010 je dále vyvíjen pod značkou Oracle Corporation jako součást rodiny virtualizačních produktů. Za zmínku zde také stojí, ţe původní developer Innotek spolupracoval na vývoji OS/2 a Linux podpoře pro produkty společnosti Connectix a také jejich OS/2 portací. Produkty společnosti Connectix posléze převzala společnost Microsoft, podrobněji zmíněné v odstavci 1.3.1. Konkrétně Innotek vyvíjel přídavné kódy do produktů Virtual PC a Virtual Server, které velmi výrazně zvyšovaly spolupráci mezi hostujícím a hostovaným (host a guest) OS. VirtualBox se instaluje na host OS a v rámci něj pak umoţňuje instalaci dalšího, hostovaného operačního systému (guest). Jako host OS lze pouţít systémy Linux, Mac OS X, Windows XP, Windows Vista, Windows 7, Solaris a OpenSolaris. Existuje i portace na FreeBSD, avšak pouze ve verzi OSE (Open Source Edition). Hostované OS (guest) lze instalovat Windows, Linux, BSD, OS/2, Solaris a další (od verze 3.2.0 umoţňuje i omezenou virtualizaci Mac OS X na hardwarovém základu počítačů Apple). Původně byl software plně licencovaný a tedy placený, kromě verze zdarma pro osobní a vývojové pouţití. V lednu roku 2007 byla vydána verze VirtualBox Open Source Edition (OSE) pod licencí GPLv2 (pro komerční pouţití to znamená jistá omezení – podporu pro USB 2.0 zařízení, RDP a PXE boot pro síťové karty Intel – tyto součásti jsou vydávány zvlášť jako rozšiřující modul, avšak jiţ pouze pro osobní a vývojové pouţití). Jako většina virtualizačních softwarů, i VirtualBox umoţňuje hardware virtualizaci, která vyţaduje speciální procesor, i softwarovou emulaci (paravirtualizaci), která můţe být pouţita i v případě, kdy fyzický počítač poţadovaný procesor neobsahuje. Všechny x64 hostované OS (guest) a OS/2 však vyţadují hardwarovou virtualizaci.[10] VirtualBox je určen především pro virtualizaci desktopů, tedy počítačů koncových uţivatelů, podobně jako VirtualPC. Jeho moţnosti jsou, na rozdíl od jednoduchého VirtualPC, velmi široké. S funkcemi jako je „teleportation“, obdoba funkce „live migration“, podporovanou 2D a 3D akcelerací, HD audiem, RDP s video akcelerací, podporou pro více monitorovou plochu a dalšími, se jedná o velmi výjimečný software pro virtualizaci klientských počítačů. Mezi širokou veřejností je VirtualBox právem velice oblíben a to především pro svoji univerzálnost
9
a podporu širokého spektra hostovaných operačních systémů. Tomu odpovídá i výsledek průzkumu serverů LinuxJournal.com a LifeHacker.com z roku 2010, kde byl VirtualBox nejpopulárnějším virtualizačním softwarem s více neţ 50% hlasujících internetových uţivatelů. Následující graf ukazuje oblíbenost virtualizační platformy u široké veřejnosti, tedy koncových uţivatelů, nikoliv zástupců podnikových řešení. Proto se ve výsledcích zobrazují pouze produkty právě pro koncové uţivatele (druhým v pořadí je systém od VMware, konkrétně produkty VMware Workstation, případně či odlehčený VMware Player).[23]
Obrázek 1 - Výsledek ankety o nejoblíbenější VM. Zdroj: [23]
Společnost Oracle samozřejmě nabízí plné spektrum virtualizačních nástrojů a tak nemůţe chybět ani nástroj pro virtualizace serverové infrastruktury. Ten je v tomto případě postaven na základech Xen serveru, kterému je věnována samostatná kapitola 1.2 a proto bych zde jen uvedl tabulku hostovaných operačních systému v kombinaci s typem moţné virtualizace.
10
Guest Operating System
Hardware Hardware Paravirtualized Paravirtualized Virtualized 32- Virtualized 6432-bit 64-bit bit bit
SUPPORTED GUEST OPERATING SYSTEMS ON 64-BIT CPUs Oracle Linux 6.x Oracle Linux 5.x Oracle Linux 4.x Red Hat Enterprise Linux 5.x Red Hat Enterprise Linux 4.x Red Hat Enterprise Linux 3.x Microsoft Windows 2000 Microsoft Windows 2003 Microsoft Windows XP Pro Microsoft Windows Vista Microsoft Windows 7 Microsoft Windows 2008 SP1 Microsoft Windows 2008 R2 Oracle Solaris 11 Express* Oracle Solaris 10* SUPPORTED GUEST OPERATING SYSTEMS ON 32-BIT CPUs Oracle Linux 6.x Oracle Linux 5.x Oracle Linux 4.x Red Hat Enterprise Linux 5.x Red Hat Enterprise Linux 4.x Red Hat Enterprise Linux 3.x Microsoft Windows 2000 Microsoft Windows 2003 Microsoft Windows XP Pro Microsoft Windows Vista Microsoft Windows 7 Microsoft Windows 2008 SP1 Oracle Solaris 11 Express* Oracle Solaris 10*
Tabulka 1 – možnosti Oracle VM. Zdroj: [15]
11
1.2 Citrix Xen server Xen byl zaloţen jako výzkumný projekt na Cambridgeské Univerzitě, který vedl docent Ian Pratt, zakladatel společnosti XenSource, Inc. Tato společnost nyní podporuje vývoj OpenSource projektu a také prodává Enterprise verzi softwaru. První verze Xen byla veřejně vydána v roce 2003. Společnost XenSource, Inc. v říjnu roku 2007 koupila firma Citrix a následně upravila názvy všech produktů Xen tak, aby nesly její značku. Struktura systému Xen má jako nejniţší vrstvu s největšími oprávněními Xen Hypervisor (VMM). Nad ní je pak jeden nebo více hostovaných operačních systémů (guest OS), kterým VMM plánovaně přiděluje výpočetní výkon fyzického procesoru hostitelského počítače. První hostovaný OS bootuje automaticky při bootování VMM po spuštění počítače a v terminologii Xen je nazýván doménou 0 (dom0). Automaticky jsou mu přidělena zvláštní správcovská oprávnění a má přímý přístup k veškerému fyzickému hardwaru. Systémový administrátor se můţe do nulté domény (dom0) připojit za účelem správy všech dalších OS, jenţ jsou v terminologii Xen nazývány domény U (domU). Jako dom0 mohou být pouţity upravené systémy Linux, NetBSD a Solaris. Několik upravených systémů na bázi systému Unix můţe být pouţito na určitém hardwaru jako domU. Neupravené verze systému Microsoft Windows a dalších patentově chráněných systémů mohou také běţet jako domU. Procesor fyzického počítače však musí podporovat x86 virtualizaci (Intel VT-x nebo AMD-V). Xen Server na většině procesorů pracuje na principu Paravirtualizace, kdy můţe dosáhnout vysokého výkonu i na architektuře x86, která je známa nespolupracováním s tradičními virtualizačními technikami. Výhodou Xen serveru je také podpora funkce “Live migration”, která administrátorům umoţňuje přesouvat virtuální stroje mezi jednotlivými fyzickými počítači (hosty) v síti LAN bez ztráty jejich dostupnosti. Během této procedury se opakovaně kopíruje paměť virtuálního stroje do cílového umístění a to bez přerušení běhu původního. Závěrečná synchronizace vyţaduje zhruba 60-300ms, neţ se virtuální stroj spustí na cílovém hostiteli, coţ navozuje iluzi plynulého přestěhování. Obdobná technologie umoţňuje uspat běţící virtuální stroj na pevný disk a opět ho spustit kdykoliv později ve stavu, v kterém byl při uspání (jako kdyţ na přehrávači filmů nebo hudby stisknete pause).
12
V nově vydané verzi Xen serveru 3.2, vydané 18. ledna 2008, byla představena velmi významná funkce PCI passthrough. Pro budoucí vyuţití to mělo zásadní vliv, neboť hostované operační systémy mohly adresovat i PCI karty, coţ umoţnilo širší pouţití virtualizace a to především pro moţnost vyuţívání specializovaného PCI hardwaru jako jsou např. speciální faxové karty, střiţny videa, karty pro monitorovací zařízení atp.[6] Velmi důleţitým faktem je, ţe společnost Citrix nechala základní verzi tohoto produktu pod licencí GPL (GNU General Public License), coţ znamená, ţe produkt je volně k dispozici zdarma. Pro korporátní sféru a tedy nasazení ve velkých společnostech je však Open Source řešení jádra virtualizační platformy spíše slabinou celého řešení. Zmiňuje to i studie společnosti Gartner z června roku 2012, která je blíţe popsána v závěrečném porovnání hypervizorů na straně 29. Z internetových stránek společnosti Citrix můţeme celkem snadno vyčíst i podporované hostované operační systémy pro aktuální verzi Xen server 6.1. Vzhledem k jejich mnoţství pouţiji přímou citaci produktových stránek s vlastním překladem textů, viz Tabulka 2. Podporované hostované operační systémy systémem Citrix Xen Microsoft Windows 32-bit
Linux 64-bit
32-bit
64-bit
Windows Server 2008
Windows Server 2008
Red Hat Enterprise Linux
Red Hat Enterprise Linux
Windows Server 2003
Windows Server 2003
CentOS
CentOS
Windows SBS 2003, R2
Windows 7
Oracle Enterprise Linux
Oracle Enterprise Linux
Windows 2000
Novell SUSE Ent. Linux
Novell SUSE Ent. Linux
Windows 7, Vista, XP
Debian Lenny, Squeeze
Debian Squeeze
Ubuntu Lucid Lynx
Ubuntu Lucid Lynx
Experimentální hostované operační systémy systémem Citrix Xen UNIX 32-bit
Linux 64-bit
Solaris 10 Update 9
Solaris 10 Update 9
32-bit
64-bit
CentOS 6.0
CentOS 6.0
Ubuntu Lucis Lynx 10.10
Ubuntu Lucis Lynx 10.10
Ubuntu Lucid Lynx
Ubuntu Lucid Lynx
Tabulka 2 – podporované hostované operační systémy Xen serveru. Zdroj: [16]
13
XenServer Features by Edition
Advanced (1000$)
Enterprise (2500$)
Platinum (5000$)
64-bit Xen Hypervisor Active Directory Integration VM Conversion Utilities Live Migration with XenMotion® Multi-Server Management with XenCenter Management Integration with Systems Center VMM Automated VM protection and recovery Live migration with Storage XenMotion® Distributed Virtual Switching Dynamic Memory Control High Availability Performance Reporting and Alerting Mixed Resource Pools with CPU Masking Dynamic Workload Balancing and Power Management GPU Pass-Through for Desktop Graphics Processing IntelliCache™ for XenDesktop Storage Optimization Live memory Snapshot and Revert Provisioning Services for Virtual Servers Role-based Administration and Audit Trail StorageLink™ Advanced Storage Management Monitoring Pack for Systems Center Ops Manager Web Management Console with Delegated Admin Provisioning Services for Physical Servers Site Recovery
Tabulka 3 zobrazuje přehled funkcí, které jsou obsazeny v jednotlivých edicích Xen serveru (v závorkách jsou platné ke dni 25. 6. 2013, obsahují roční subscription a počítají se v reţimu per server, tedy za kaţdý server).
14
XenServer Features by Edition
Advanced (1000$)
Enterprise (2500$)
64-bit Xen Hypervisor Active Directory Integration VM Conversion Utilities Live Migration with XenMotion® Multi-Server Management with XenCenter Management Integration with Systems Center VMM Automated VM protection and recovery Live migration with Storage XenMotion® Distributed Virtual Switching Dynamic Memory Control High Availability Performance Reporting and Alerting Mixed Resource Pools with CPU Masking Dynamic Workload Balancing and Power Management GPU Pass-Through for Desktop Graphics Processing IntelliCache™ for XenDesktop Storage Optimization Live memory Snapshot and Revert Provisioning Services for Virtual Servers Role-based Administration and Audit Trail StorageLink™ Advanced Storage Management Monitoring Pack for Systems Center Ops Manager Web Management Console with Delegated Admin Provisioning Services for Physical Servers Site Recovery
Tabulka 3 – srovnání možností edic Xen serveru. Zdroj: [16]
15
Platinum (5000$)
1.3 Virtualizace Microsoft 1.3.1 Virtual PC Společnost Microsoft vstoupila do oblasti virtualizace v únoru roku 2003 zakoupením společnosti Connectix, která v červnu roku 1996 vydala produkt Virtual PC, původně vyvíjený pro platformu Macintosh. Microsoft k tomuto kroku přistoupil poté, kdy začal být zřetelný jasný zájem o virtualizaci ze strany podnikové klientely, která si začala uvědomovat její důleţitost. První verzí Virtual PC určenou pro systémy na platformách Windows byla verze 4.0, vydaná v červnu 2001. Connectix prodával verze Virtual PC v balíku s různými hostovanými operačními systémy, zahrnující Windows, OS/2 a Red Hat Linux. V červenci roku 2006 vydala společnost Microsoft verzi Virtual PC 2004 SP1, která byla pro platformu Windows zdarma, nicméně verze pro MacOS jiţ byla placená. Srovnatelná verze pro MacOS, verze 7, byla poslední verzí Virtual PC pro tuto platformu. Zlomovým bodem bylo vydání verze Virtual PC 2007 (19. února 2007). Tato verze jiţ byla pouze pro platformy Windows, nicméně přinesla zásadní změnu. Tou byla podpora hardwarové virtualizace.[7] Z pohledu společnosti Microsoft se v tomto případě jedná o jednoduchý produkt pro koncové uţivatele, kteří ho vyuţijí především jako moţnost pouţívat starší software na novějších verzích Windows, které jiţ v zásadě nepodporují běh šestnáctibitových aplikací. Windows Virtual PC je s novými OS (edice Professional, Enterprise a Ultimate) dodáván zdarma spolu s licencí Windows XP Professional, jakoţto hostovaného OS (guest). Funkce je označována jako Windows XP Mode. Virtual PC samotné je však k dispozici ke staţení zdarma, bez omezení edice Windows.
1.3.2 Virtual Server Microsoft Virtual Server je virtualizační řešení, které umoţňuje vytvoření virtuálních strojů na OS Windows XP, Windows Vista a Windows Server 2003. Původně byl vyvinut společností Connectix, stejně jako výše zmíněný produkt Virtual PC. Ve skutečnosti také Virtual Server vychází právě z produktu Virtual PC, který je určen pro virtualizaci desktopů, tedy klientských OS. Jedná se o sofistikovanější produkt neţ Virtual PC a virtuální stroje jsou zde vytvářeny a spravovány skrze webové rozhraní běţící na serveru IIS (webový server společnosti
16
Microsoft, jenţ je dodáván s jejími operačními systémy) nebo přes klientský Windows aplikační nástroj VMRCplux. Umoţňuje tedy centrální a vzdálenou správu, coţ samo o sobě napovídá, ţe produkt je určen spíše pro podnikové nasazení a pro běh mnoha virtuálních strojů souběţně. Vzhledem ke skutečnosti, ţe základem tohoto produktu je výše zmíněný Virtual PC, obsahuje i všechny jeho vlastnosti. Navíc podporuje i víceprocesorové prostředí s funkcí SMP (Symmetric MultiProcessing), která na hostujících OS s více procesory nebo vícejádrovými procesory značně optimalizuje běh a zálohu hostovaných strojů (guestů) v reálném čase přes Volume Shadow Copy zapisovač (pouze hostitelích Windows Server 2003 a Windows Server 2008). Podpora operačních systému Linux, jakoţto hostovaných OS (guest) je samozřejmostí.[8] Virtual Server byl později zcela nahrazen novým produktem Hyper-V.
1.3.3 Hyper-V Produkt Microsoft Hyper-V byl vyvíjen pod kódovým označením Viridian a obecně je znám jako Windows Server Virtualization. Je zaloţen na bázi hypervizoru a je určen pro systémy x86 a x64. Beta verze Hyper-V byla vydána s určitými edicemi Windows Server 2008 a ostrá verze pak přišla automaticky přes Windows Update 26. Června 2008. Hyper-V byl posléze vydán i jako samostatný produkt zdarma. Aktuální produkční verze je Hyper-V v3, která byla vydána v rámci produktové řady Microsoft Windows 2012. Hyper-V existuje ve dvou variantách a to jako samostatný produkt zvaný Microsoft Hyper-V Server 2008 a dále jako instalovatelná role v serverech Windows Server 2008, 2008 R2 a v aktuální edici rodiny Windows Server 2012. Samostatná verze Hyper-V, jak jiţ bylo zmíněno, je k dispozici zcela zdarma a byla vydána 1. Října 2008. Jedná se vlastně o instalaci jádra systému Windows Server 2008 s plnou funkcionalitou Hyper-V, avšak bez moţnosti instalovat ostatní role a s omezenými sluţbami Windows serveru. Tato edice také neobsahuje grafické uţivatelské rozhraní (GUI) a veškeré operace se provádí příkazy v prostředí Power Shell (jedná se o vylepšený systém příkazové řádky v systémech Windows, umoţňující především psaní a spouštění skriptů, atd.). Vzhledem ke skutečnosti, ţe veškeré operace jsou prováděny z příkazové řádky, jsou k dispozici ke staţení mnohé hotové skripty, usnadňující správu systému. Správa a konfigurace hosta i guesta je pak moţné provádět i přes rozšířené MMC (Microsoft
17
Management Console) nainstalované na systémy Windows 7 nebo Windows 2008 Server. Tato moţnost jiţ nabízí grafické prostředí pro správu a monitorování Hyper-V Serveru ovládané myší, nicméně je vhodné spíše pro jednodušší operace a udrţování plně nakonfigurovaného prostředí, provedeného dříve přes Power Shell konzoli. Zde bych rád podotkl, ţe díky architektuře samostatného Hypervizoru, tedy celého jádra Windows Server, je Hyper-V ze své konkurence (XEN a ESXi) největší, co se obsazeného místa na disku a obsazené paměti týče. Architektura systému je zaloţena na vzájemně oddělených částech, zvaných „partition“. Přímo nad hardwarem počítače operuje hypervizor (Hyper-V), nad kterým musí být alespoň jedna zdrojová část (parent partition) s běţícím podporovaným operačním systém Windows Server (2008, 2008 R2 nebo 2012). Virtualizační vrstva běţí ve zdrojové části a má přímý přístup k hardwarovým zařízením. Zdrojová část pak vytváří podřízené části (child partition), které hostují operační systémy virtuálních strojů. Virtualizované části nemají přístup k samotnému fyzickému procesoru, ani nemohou pracovat se skutečnými přerušeními. Podřízené části nemají ani přímý přístup k hardwarovým zdrojům. Místo toho jsou pomocí zdrojové vrstvy vytvořeny jejich virtuální obrazy, virtuální zařízení. Jakýkoliv poţadavek na virtuální zařízení je přesměrován skrz rozhraní VMBus na zařízení ve zdrojové části, která jej dále zpracuje. VMBus je logický kanál, který umoţňuje komunikaci mezi jednotlivými částmi systému. Stejně tak odezva fyzického zařízení je skrze VMBus přesměrována zpět na virtuální zařízení. Pokud je zařízením ve zdrojové části jiné virtuální zařízením, poţadavek je přesměrováván dál a dál, dokud nedosáhne tu zdrojovou část, která umoţní přímý přístup na fyzické zařízení. Zdrojové části dále obsahují Virtualization Service Provider (VSP), sluţbu, která se připojuje k VMBusu a ovládá poţadavky na zařízení z podřízených částí. Podřízené části obsahují sluţbu Virtualization Service Client (VSC), která přesměrovává poţadavky do VSP v základních částech skrz VMBus. Celý tento proces je pro hostovaný OS transparentní. Schéma architektury znázorňuje Obrázek 2.2 Virtuální zařízení také mohou vyuţít výhod funkce Windows Server Virtualizace zvané Enlightened I/O. Tato funkce umoţňuje speciálním vysokoúrovňovým komunikačním protokolům, jakými je třeba SCSI, komunikovat přímo s VMBusem, čímţ obchází vrstvu emulace zařízení. Tím je komunikace mnohem efektivnější a virtualizované systémy mohou 2
Na obrázku stojí mimo jiné za povšimnutí, ţe Microsoft v této architektuře vyuţívá pouze dvou ochranných pásem procesoru (ring 0 a ring 3). Důvodem je základ v operačním systému Windows, který tímto omezeným způsobem pracuje napříč všemi edicemi. Není však mým záměrem označit toto chování za špatné nebo dokonce chybné – uvádím pouze jako zajímavost.
18
běţet mnohem rychleji, neţ kdyby vyuţívaly emulovaný hardware. Hostované systémy (guest) musí ovšem tuto funkci podporovat. Funkce můţe pracovat s procesy ukládání dat, síťové komunikace, grafickými podsystémy a další.
Obrázek 2 – Architektura Hyper-V. Zdroj: [9]
Hyper-V ve Windows Serveru 2008 nepodporuje funkci „live migration“, jejíţ funkce jiţ byla popsána v kapitole 1.2. Místo toho Hyper-V na edicích Server 2008 Enterprise a Datacenter podporuje funkci „quick migration“, kde je při přesunu virtuální stroj na jednom hostiteli uspán a na druhém poté spuštěn. Operace odstaví virtuální stroj z provozu na dobu potřebnou k přesunu celé uloţené aktivní paměti z jednoho hostitele na druhý. I přes to, ţe se jedná o časy v řádu několika sekund, můţe to znamenat v určitých případech značné nepříjemnosti. S vydáním Windows Serveru 2008 R2 je jiţ v rámci Hyper-V funkce „live migration“ podporována při pouţití sdílených disků Windows Clusteru (CSV – Cluster Shared Volumes). Na principu funkce „live migration“ je také realizováno vyvaţování zátěţe hostujících serverů tak, ţe se jednotlivé virtuální stroje přesouvají z jednoho člena clusteru (nodu) na druhý,
19
pokud je jeden enormně vytíţen na úkor druhého. Tato funkce je nazývána „Automatic workload balancing“, neboli automatické vyvaţování pracovní zátěţe.[9] Mezi podporované hostované operační systémy na hypervizoru Hyper-V v3, tedy v aktuální verze, najdeme výhradně produkty z dílny Microsoft. Jedná se konkrétně o Windows Server 2003, 2008, 2008 R2, 2012, Windows Home Server 2011, Windows Small Business Server 2011, Windows XP, Vista, 7 a 8. Všechny systémy ve variantách 32 i 64 bitové architektury, pokud je k dispozici (Windows Server 2008 R2, 2012, Home Server 2011 a SBS 2011 jsou výhradně 64bitové). Po stíţnostech z řad uţivatelů přidal Microsoft i podporu pro Linuxové platformy Red Hat 6, SUSE 11 a CentOS 6, opět pro obě varianty architektury. Tato podpora je však podporou ve smyslu moţné instalace těchto operačních systémů na hypervizor Hyper-V. Například správa paměti nebo zálohování s Linux platformou vůbec nepočítají a takových oblastí je mnoho. [22] Podporu Linuxových platforem je proto třeba brát s rezervou, neboť, dle mého názoru, v reálném nasazení zatím neobstojí.
20
1.4 Virtualizace VMware Společnost VMware, Inc. byla zaloţena v roce 1998 a sídlí v Palo Alto, v Kalifornii v USA (Silicon Valley). Jejím většinovým spoluvlastníkem je společnost EMC Corporation.[11] Jejími produkty jsou software pro virtualizaci desktopů (VMware Workstation, Fusion a Player) a pro virtualizaci serverů (VMware ESX a ESXi). Zatímco první skupina běţí jako software na hostitelském OS Microsoft Windows, Linux nebo Max OS X, druhou skupinou tvoří vestavěné hypervizory běţící přímo na hardwaru serveru a nevyţadují pod sebou ţádný další OS. VMware software poskytuje kompletní virtualizaci hardwaru pro hostovaný operační systém. Virtualizuje se hardware pro grafický adaptér, síťový adaptér a adaptéry pevných disků (řadiče). Hostující systém poskytuje průchod pro ovladače USB portů, sériových a paralelních zařízení. Díky tomu se virtuální stroje VMware staly vysoce přenositelné mezi různými počítači, protoţe pro hostující OS se kaţdý host tváří téměř identicky. V praxi to znamená, ţe systémový administrátor můţe pozastavit běţící virtuální stroj na jednom počítači, přesunout nebo zkopírovat jej na jiný a obnovit jeho běh přesně tam, kde byl na původním stroji pozastaven. Na podnikových serverech obdobnou funkci nazýváme vMotion. Ta opět umoţňuje přesunutí běţícího virtuálního stroje z jednoho serveru na druhý v rámci jednoho úloţiště. Zde však přesuny probíhají pro všechny uţivatele daných virtuálních strojů prakticky bez povšimnutí (princip této funkce popíšeme dále, nicméně při spuštěném průběţném pingu na přesouvaný stroj je vidět přerušení provozu a to viditelně time outem jednoho z pingů, coţ některé aplikace nemusí snést bez problémů).
1.4.1 VMware Workstation VMware Workstation je software pro vytváření a spouštění virtuálních strojů na x86 a x64 počítačích. Umoţňuje uţivatelům spouštět jeden nebo více virtuálních strojů současně, přičemţ kaţdý z těchto systémů můţe být libovolným z podporované škály (Windows, Linux, BSD a další).[12] Podporuje přemostění existujících síťových adaptérů, CD-ROM zařízení, pevných disků a USB zařízení a také má moţnost simulovat některý hardware. Například umí připojit ISO soubor jako fyzickou CD-ROM a soubory .vmdk jako pevný disk a můţe nakonfigurovat síťový adaptér jako NAT (Network Address Translation – síťový překlad adres) z hostujícího počítače (host) namísto jejího přemostění, coţ by vyţadovalo vlastní IP adresu pro kaţdý z hostujících strojů (guest).
21
Další důleţitou funkcí je vytváření mnohonásobných bodů obnovení (snapshot), coţ umoţňuje vytvoření jakéhosi stromu uloţených stavů, kde se v kaţdém okamţiku můţete přesunout na libovolný z nich. Například je tak moţné vytvořit si z jednoho virtuálního stroje celou řadu testovacích strojů různých konfigurací a dle potřeby se mezi nimi přesouvat. Výhodou je především to, ţe všechny snapshoty na stejné úrovni stromu mají jeden základ a ukládá se tedy vţdy pouze datový rozdíl. Výsledná velikost takového stromu je mnohokrát menší, neţ kdyby kaţdý bod byl samostatným strojem. I při jejich vytváření je práce obdobným způsobem velmi usnadňována. Tato funkce je jednoduše neocenitelným pomocníkem především pro testery a vývojáře. Vyuţití je však obecné a velmi široké.
Obrázek 3 – VMware Workstation - správce snapshotů. Zdroj: [12]
22
VMware Workstation obsahuje i moţnost ovládat několik virtuálních strojů jako skupinu, jenţ pak administrátor můţe najednou vypnout, zapnout, uspat a obnovit jako jeden objekt, coţ můţe být velmi uţitečné při testování klient-server prostředí. Na internetu je také k dispozici mnoho hotových virtuálních strojů ke staţení zdarma a to především pro testovací účely. Usnadňuje tak práci lidem, kteří o daný software mají zájem a navíc, můţe obsahovat určité hotové konfigurace, které mohou být uţivatelům velmi nápomocné. Přes všechny vlastnosti asi není překvapující, ţe software VMware Workstation je placený produkt. Jeho odlehčená varianta, která je k dispozici zdarma se nazývá VMware Player. Do verze 3.0 však neumoţňoval vytváření virtuálních strojů a aktuální verze nadále neumoţňuje například vytváření vícenásobných bodů obnovení.
1.4.2 VMware ESX/ESXi Server VMware ESXi server je v současné době jediný produkt určený pro podnikovou sféru, který je společností VMware vyvíjen. Přináší výrazně vyšší výkonnost neţ jeho předchůdce ESX server nebo dříve volně dostupný VMware Server a to především díky niţší reţii. Jak jiţ bylo zmíněno, jedná se o samostatný produkt, který ke svému běhu nepotřebuje hostující OS a zavádí se přímo na hardware fyzického počítače. Nejprve se nastartuje jádro systému Linux, které nahraje do paměti různé specializované virtualizační komponenty, včetně VMkernel. Následně se tento zprvu nabootovaný Linux stane prvním virtuálním strojem a dále je nazýván servisní konzolí. Při normálním běhu je tedy VMkernel spuštěn přímo na fyzickém počítači a servisní konzole na bázi Linuxu běţí jako první virtuální stroj. VMkernel sám má tři rozhraní do okolního světa - hardware, hostované systémy (guests) a servisní konzoli. V nadpisu podkapitoly je zmíněno označení ESX a ESXi. Jedná se o akronym pro Elastic Sky X, avšak aţ na velmi vzácné výjimky se tento název v oficiálních materiálech VMware neobjevuje. Verze ESXi pak vznikla vydáním nové, technologicky odlišné, verze hypervizoru, který byl plně integrován a nepotřeboval ţádný hostující OS.[13] Rozdíl mezi verzemi ESX a ESXi je tedy poměrně zásadní co se architektury týče a i přes to, ţe se v případě ESXi jedná o následníka ESX, poměrně dlouho koexistovali a byly souběţně vyvíjeny. Oba tyto produkty jsou úzce vázány na správcovské prostředí vCenter, podle kterého jsou také verzovány. ESX jako první produkt rodiny vznikl v první produkční verzi s typickým označením 1.0. Od verze 3.0 pak přibyl v portfoliu produkt ESXi, který je
23
aktuálně jediným pokračovatelem a to ve verzi 5.1. Projekt ESX byl ukončen verzí 4.1 z 13. července 2010, která však dostala poslední update ještě 30. srpna 2012 a VMware tedy ani na 2 roky starou verzi nezapomíná. Původně vznikla ESXi varianta jako odlehčený hypervizor, zabírající jen 32GB místa na lokálním disku, která měla být spravovaná vzdáleně přes síť skrze VMware Infrastrukture Client Interface. To umoţnilo vyuţití více zdrojů na provozované VM. Myšlenka to byla natolik dobrá, ţe od verze 5 jiţ jiná moţnost ani není nabízena. Správa ESXi je prováděna vzdáleně, tedy z libovolného počítače v síti s nainstalovanou aplikací VMware vSphere Client, nově pak i přes webové rozhraní, které má časem, dle informací VMware po vydání verze 5.1, plně nahradit tlustého klienta. Rozdíly v architektuře mezi ESX a ESXi bych zde také rád krátce přiblíţil, neboť ukazují jistý trend leadera virtualizací, který budou ostatní výrobci, dle mého názoru, muset nějakým způsobem následovat, pokud chtějí v konkurenčním boji obstát (konkurence vyuţívá architekturu podobnou ESX). Graficky tento rozdíl znázorňují Obrázek 4 a Obrázek 5.
vSphere ESX (~2GB diskového prostoru)
vSphere ESXi (~150MB diskového prostoru)
VMware a agenti třetích stran běţí v COS (Console operating system – operační systém běţící na Hostu určený pro správu hypervizoru) Většina funkcí pro správu poskytovaných agenty běţí také v COS
VMware agenti běţí přímo na VMkernelu
Uţivatelé se musí přihlásit do COS, aby mohli spouštět příkazy pro konfiguraci a diagnostiku
VMware komponenty a komponenty třetích stran se aktualizují nezávisle
Autorizovaní agenti třetích stran běţí také přímo na VMkernelu a poskytují monitoring hardwaru a také ovladače hardwaru (přímá podpora specifických zařízení).
Tabulka 4 – Porovnání hlavních rozdílů architektur ESX a ESXi. Zdroj: vlastní
24
Obrázek 4 – Architektura ESX. Zdroj: [17]
Obrázek 5 – Architektura ESXi. Zdroj: [17]
Z tohoto jednoduchého porovnání je na první pohled zřejmé, ţe nároky na prostředky lokálního serveru jsou v případě ESXi nesrovnatelně niţší a efektivita celého virtuálního prostředí je tak daleko vyšší. To je pro uţivatele primární faktor, neboť vyšší potřeba zdrojů generuje další náklady. Nesmím zapomenout i na lepší moţnosti při správě a monitoringu, kdy je zajištěn přímý přístup k jádru ESXi serveru. Virtuální HOST servery jsou spojovány
25
do celých clusterů či farem a v takovém nasazení je zbytečné, aby kaţdý jednotlivý HOST server měl vlastní administrační konzoli, tedy celý robustní operační systém. Podstata myšlenky virtualizace je maximální vyuţití fyzických prostředků serveru na generování uţitné hodnoty a tedy minimalizaci všech procesů, které vlastní uţitnou hodnotu negenerují. Pro lepší představu, jak mohou být tyto úspory v případě ESXi serveru přínosné, bych rád uvedl konkrétní hodnotu zabrané operační paměti po čisté instalaci ESXi verze 5.1. Jedná se o pouhých 9 MB!3 Pro správu paměti pouţívá VMware hypervizor také několik velmi zajímavých funkcí. Jejich popis bude sledově odpovídat jejich postupné aplikaci. Základní funkcí, která je aplikována vţdy je Transparent Page Sharing (TPS), kterou znázorňuje Obrázek 6. Tato technologie zvyšuje densitu fyzických serverů, tedy jejich moţné obsazení virtuálními stroji, aţ o 20 % oproti konkurenčním hypervizorům. TPS dokáţe identifikovat stejné bloky v paměti a ty sloučit tak, ţe se v paměti drţí pouze jednou. Všechny operační systémy, které dané bloky paměti potřebují, si však myslí, ţe je jim tato paměť dedikována.
Obrázek 6 – Transparent Page Sharing. Zdroj: [22]
Druhým nástrojem pro efektivnější distribuci paměti je Memory Balooning. Tato technika spočívá ve vypůjčování jiţ přiřazené operační paměti virtuálním strojům tomu stroji, který ji zrovna potřebuje. Konkrétně to funguje tak, ţe pomocí nástroje VMware Tools poţádá virtuální stroj, kterému paměť schází, hypervizor o zapůjčení další paměti. Ten pak poptá ostatní virtuální stroje, zda nemají nějakou volnou, sobě naalokovanou paměť. Pokud ano, VMware Tools na těchto strojích spustí proces, který virtuálně spotřebuje takovou velikost 3
Čistá instalace ESXi 5.1 bez zavedených ovladačů hardwaru a spuštěných virtuálních strojů, testováno v laboratoři při školení VMware vSpehere: Install, Configure, Manage ve společnosti Arrow, 5.10.2012.
26
paměti, kterou je daný stroj schopen nabídnout a hypervizor pak tuto paměť uvolní virtuálnímu stroji, který poţadavek podal. Ve chvíli, kdy jiţ dodatečnou paměť nepotřebuje nebo ji její původní drţitel potřebuje, je zpětným procesem navrácena. Tato technologie velmi pomáhá, zvlášť pokud jsou je virtuálním strojům paměť přímo rezervována. Většina operačních systému a řada aplikací (velice pověstné je tím například MS SQL) si alokuje více paměti, neţ ve skutečnosti potřebuje a proto tento nástroj pomáhá k jejímu efektivnějšímu vyuţití napříč virtuálními stroji. Pokud nestačí nárokům na paměť virtuálních strojů ţádný z předchozích nástrojů, nastupuje třetí nástroj a tím je komprese paměti. Obsah paměťových bloků je v paměti jednoduše zkomprimován. Komprese paměti však jiţ má vliv na výkon celého systému, a pokud se ve výkonnostních grafech začne tento parametr objevovat, je to pro správce systému signál k tomu, aby situaci začal nějakým způsobem řešit. Ve chvíli, kdy jiţ ani komprese paměti nestačí, nastupuje poslední technologie, obecně známá z operačních systémů. Nazývá se swapováním paměti a ve své podstatě se jedná o odkládání méně potřebných, respektive méně ţádaných částí paměti, na pevné disky souborového systému. Vezmeme-li v úvahu, ţe dnešní paměťové moduly mají prostupnost od 8 do 12 GB/s a nejrychlejší současné SSD pevné disky mají rychlost od 0,5 do 1 GB/s, je jiţ na první pohled patrné, jak velký vliv na výkonost celého host serveru bude nástup této technologie mít4. Swapování paměti je nástroj pro udrţení přetíţeného host serveru v provozu a tedy jako nouzová moţnost. Rozhodně není určena k běţnému uţívání a počítat s ní při návrhu serverové kapacity bych označil přinejmenším za hazard. VMware ESXi můţe být integrováno do jiţ zmíněného systému VMware vCenter, který nabízí zvláštní sluţby pro vylepšenou dostupnost a správu virtuálních serverů. Nabízí tak sluţby jako je: VMotion – přesun běţícího virtuálního stroje z jednoho ESXi hostitele na druhý (obdoba „live migration“). Storage VMotion – moţnost přesunout běţící virtuální stroj z jednoho úloţiště na druhé.
4
Rychlost běţných pevných disků a levnějších NAS serverů je kolem 0.1 GB/s, běţné SSD pevné disky dosahují 0,5 GB/s, SSD paměťové karty aţ 1 GB/s. Rychlost nejvýkonnějších Fibre Channel diskových polí je 8 Gb/s, coţ je zhruba na hranici 1 GB/s (B – byte = 8x b – bit).
27
DRS (Dynamic Resource Scheduler) – automatické vyvaţování zátěţe v rámci ESXi clusteru za pouţití funkce VMotion a nově i Storage VMotion (od verze 5.1). HA (High Availability) – v případě, ţe dojde k selhání hardwaru v rámci ESXi clusteru, virtuální stroje se automaticky restartují na jiném nodu tohoto clusteru. FT (Failure tolerance) – vylepšená funkce HA, která v případě selhání hardwaru v rámci ESXi clusteru, přesune virtuální stroje na jiný node a to bez sebemenšího výpadku. Samotný server ESXi je ke staţení i uţívání zcela zdarma, stejně tak, jak je tomu i u konkurence. Licence za vCenter edice, které nabízejí všechny výše zmíněné pokročilé funkce, jsou však poměrně drahé. Zájemci o provozování virtualizačního prostředí od VMware si pak musí dobře promyslet, zda a kterou edici do své společnosti pořídí a zda poměrně vysoké pořizovací náklady přinesou i odpovídající protihodnotu do zamýšleného konkrétního nasazení. Nabízené edice jsou v současné době tři, základní Standard, střední Enterprise a nejvyšší Enterprise Plus. Všechny výše zmíněné sluţby, které jsou následně podrobně představeny v další části dokumentu, jsou dostupné jiţ v základní edici Standard. Jedinou výjimku tvoři funkce DRS, která je k dispozici aţ od verze Enterprise. Ceny produktů se určuji vţdy za kaţdý pouţitý fyzický procesor a na celkovou cenu má vliv mnoho dalších faktorů. Pro lepší představu však alespoň uvedu, ţe základní cena edice Standard je 1565 € za kaţdý pouţitý procesor, edice Enterprise 3265 € za kaţdý pouţitý procesor a u edice Enterprise Plus je to 3815 € za kaţdý pouţitý procesor.[17] Ze všech virtualizačních platforem má VMware ESXi server i nejširší základu podporovaných hostovaných operačních systémů. Celkově jich je v aktuální verzi ESXi 5.1 celých 96 5. Z důvodu rozsahu a zaměření mé práce zde nebudu zařazovat seznam všech podporovaných operačních systémů tak, jako u ostatních platforem, ale v pouţitých zdrojích přímo odkazuji na oficiální materiál VMware HOS Compatibility Guide[18]. Za zmínku však jistě stojí jedinečná podpora MS-DOS 6.22, Solarix, či MacOS X.
5
Toto číslo vychází z předpokladu počítání rozdílných architektur téhoţ operačního systému jako samostatných poloţek. Pro porovnání u Hyper-V je to 20 a u XenServeru při stejném výpočtu 30.
28
1.5 Shrnutí virtualizačních technologií Pro následující část práce týkající se vysoké dostupnosti serverové infrastruktury, připadají do úvahy pouze tří produkty, které hrají významnou roli i v reálném nasazení v produkčním prostředí většiny firem a podniků na celém světě. Jsou jimi Microsoft Hyper-V server, Citrix XEN server a VMware ESXi server. Společnost Microsoft se na svých firemních internetových stránkách odkazuje na studii věhlasné společnosti Gartner, vyhodnocující virtualizační platformy v polovině roku 2012. S ohledem na relevantnost zdroje a faktu, ţe tento odkaz je mezi hlavními marketingovými odkazy produktových stránek o virtualizaci i v současné době, tedy v polovině roku 2013, dovolím si pokládat jejich hodnocení za stále aktuální. Analytici společnosti Gartner (Thomas J. Bittman, George J. Weiss, Mark A. Margevicius, Philip Dawson) ve studii popisují velmi podrobně stav na poli virtualizace z různých pohledů a pozice jednotlivých účastníků spolu s jejich silnými stránkami a hrozbami. Shrnuto je pak vše graficky v Magickém kvadrantu, kde jsou v sekci lídrů pouze 3 výše zmínění zástupci, z nichţ je s velkým odstupem vedoucí VMware, následovaný Microsoft Hyper-V a jen velmi těsně se do jejich společnosti zařazeným XEN serverem 6 .[21] Vojtěch Morávek ze společnosti VMware se ve svém Webtechu „Porovnání hypervizorů očima VMware“ zaměřuje na porovnání konkrétních funkcí převáţně u VMware a Hyper-V. Podíváme-li se do historie virtualizace, koncept jaký známe dnes, oznámila společnost VMware v roce 2001. V roce 2008 ohlásila pouţití a vyuţití cloudů. V té samé době, vyšlo první Microsoft Hyper-V. Dlouhé roky náskoku ve vývoji byly opravdu znát, neboť jakékoliv porovnání těchto dvou, v té době jediných platforem pouţitelných pro virtualizaci serverové infrastruktury, bylo absolutně jednostranné, samozřejmě ve prospěch VMware. Na jaře roku 2012 Microsoft oznámil vydání Windows Serveru 2012 a spolu s ním i Hyper-V verze 3. Tato verze jiţ můţe být skutečně produktem hodným srovnání s VMware, kde, alespoň v oblasti škálovatelnosti a limitů pro virtuální stroje, Microsoft na vývoji velmi zapracoval. Stále však zůstal u stejné technologie a velmi tak zaostává v densitě a výkonnosti, jak je popsáno výše v samostatném oddílu o Hyper-V. Tato technologie však má ještě jednu, a v případě Microsoft produktů velmi výraznou, slabinu. Je jím vlastní operační systém, v kterém hypervizor běţí, tedy Windows Server. Na platformu Windows je totiţ vydáváno velmi často velmi mnoho updatů a značná část z nich vyţaduje po své aplikaci restart celého serveru. 6
Materiál společnosti Gartner je licenčně chráněn proti distribuci bez souhlasu společnosti a nemohu tedy přímo citovat ani pouţít grafické zobrazení Magického kvadrantu. Odkaz na studii je však součástí pouţitých zdrojů a rozhodně doporučuji do ní nahlédnout.
29
Tabulka 5, převzatá z výše zmíněného Webtechu, názorně dokazuje, jak neefektivní toto spojení v tomto ohledu je. Microsoft vydává své patche pravidelně kaţdé první úterý v měsíci. V období od července roku 2011 do června 2012 bylo kaţdý měsíc vydáno na platformu Windows Server obsahující pouze roli Hyper-V 7 několik důleţitých či kritických patchů a po jejich aplikaci byl vţdy vyţadován restart serveru. Důleţitý je zde však fakt, ţe ţádný z těchto patchů se netýkal vlastní virtualizační platformy a z druhého pohledu i fakt, ţe samotný operační systém je z hlediska bezpečnosti tím nejslabším místem, který je nutné neustále opravovat a hlídat. Pro úplnost dodám, ţe Tabulka 5 prezentuje hodnoty pro edici Windows Server 2008 R2. V září roku 2012 byla vydána nová verze Windows Server 2012, nicméně ze své zkušenosti nepředpokládám zásadní změnu v aplikaci distribuovaných patchů a nutnosti post-instalačního restartu serveru prakticky pokaţdé.[22]
Důleţité a kritické patche pro jádro OS* Počet updatů týkajících se virtualizace Vyţadován restart?
7/11
8/11
9/11
10/11
11/11
12/11
1/12
2/12
3/12
4/12
5/12
6/12
2
5
2
3
2
4
1
4
3
2
4
3
0
0
0
0
0
0
0
0
0
0
0
0
A
A
A
A
A
A
A
A
A
A
A
A
* všechny instalace Hyper-V tyto patche vyţadovaly Tabulka 5 – Microsoft patch Tuesdays - vliv patchů OS na virtualizaci. Zdroj: [22]
Bavíme-li se o vysoké dostupnosti a o tom, co pro zákazníka znamená, restart serveru a tím způsobená nedostupnost aplikací, respektive sluţeb na něm běţících je tou nejneţádanější operací. V případě Microsoft Windows je to otázka měsíční pravidelnosti a vezmeme-li v úvahu, ţe na jednom host serveru běţí v průměru 45 virtuálních serverů8, které jsou tímto restartem přímo ovlivněny, není to pro server management lehký úkol. ESXi server lze nazvat tenkým hypervizorem, který kompletně abstrahuje hardwarovou platformu a poskytuje logické zdroje virtuálním serverům. Takto postavenou technologii má aktuálně pouze hypervizor od VMware, jak jsem jiţ podrobněji popsal v sekci týkající se právě ESXi serveru. Oproti tomu ostatní výrobci mají své hypervizory postaveny jako doplňky k operačním systémům (Windows nebo Linux platformy) a jsou na něm více, či méně závislé. Takto fungují jak Hyper-V (Windows Server), tak XEN server (Linux). Pokud celý ESXi server je vyvíjen pouze za jediným účelem a tím je virtualizace, operační systémy 7
8
Patche jsou vydávány pro všechny edice Windows Serveru, nicméně tabulka ukazuje pouze ty, které byly nutné pro čistou instalaci Windows Serveru s rolí Hyper-V a tedy netýkající se jiných rolí, které operační systém můţe obsahovat. Celkově jich bylo tedy více, neţ je v tabulce znázorněno. Zdrojem informace je VMware Webtech „porovnání ESXi vs Hyper-V“, kde Vojtěch Morávek (Systems Engineer VMware) sděluje, ţe VMware česká republika eviduje u největších instalací v ČR mezi 40 a 50 virtuálními servery na jednom host serveru.[22]
30
pod hypervizory dalších výrobců jsou vyvíjeny se zcela odlišným cílem. Musejí být univerzální a musejí být schopny provozovat i vše ostatní, co se od samotného operačního systému očekává. Virtualizační část od toho celku nelze oddělit a celkově to tedy má negativní dopad na výkonnost a škálovatelnost. V tuto chvíli lze namítnout, ţe například Hyper-V existuje ve verzi Core, která by měla být čistě jen virtualizační platformou. Marketingově je to jistě pravda, technologicky však ne zcela. Hyper-V Core zabírá po instalaci pouhých 5 GB diskového prostoru oproti vice neţ 8 GB plného Windows Serveru 2012, nicméně například Citrix XEN server potřebuje něco přes 1 GB a jak jiţ bylo také zmíněno, ESXi serveru stačí pouhých 144 MB. Jiţ z těchto čísel je patrné, ţe v případě Hyper-V Core se nejedná o čistě virtualizační prostředí. Tato edice je vlastně jádro operačního systému Windows Server s přidanou rolí Hyper-V, avšak bez grafického uţivatelského rozhraní a moţností přidávat další role a funkce jako u běţných edic Windows Server. V tomto ohledu jde VMware technologicky hodně dopředu a s odstupem času, od vydání první verze ESXi, lze říci, ţe správným směrem.[22] Společnost Wikibon prováděla v srpnu 2012 průzkum zaměřený na produkty VMware, kde oslovila 158 respondentů z řad společností, které provozují virtualizační prostředí a kaţdá z nich produkty společnosti VMware provozovala. Jakoţto vedoucího na poli virtualizace to nebylo velkým překvapením. Zajímavý byl podíl ostatních virtualizačních platforem, jakoţto dalších provozovaných systémů těchto společností. Celých 43 % respondentů provozovalo pouze produkty VMware, dalších 35 % firem provozovalo kromě VMware i jeden z dalších hypervizorů. Tabulka 6 ukazuje celkový poměr vyuţívaných hypervizorů. Průzkum se nedotazoval na důvody nasazení dalších hypervizorů v organizaci a tak nelze zcela jasně určit váhu podílu dalších hypervizorů na trhu.[20] Pouţití Hypervizorů u respondentů VMware
68
43%
VMware + 1 další
56
35%
VMware + 2 další
26
16%
VMware + 3 další
6
4%
VMware + 4 další
2
1%
VMware + 5 další
0
0%
158
100%
Celkem
Tabulka 6 – Poměr nasazených hypervizorů dle průzkumu Wikibon 2012. Zdroj: [20]
31
Ve vlastní praxi jsem se setkal s nasazením hypervizorů od různých výrobců v rámci jedné organizace, přičemţ mnohdy se jedná o testování alternativních prostředí pro případnou migraci na levnější řešení vyhovující po technické stránce firemním nárokům, jindy o dvě produkční řešení, kde druhé, tedy to, které sekunduje VMware produktu, je vyuţíváno pro provoz méně důleţitých systémů, neboť je provozováno v reţimu „zdarma“, tedy bez placené podpory, licencí nebo subscription. Velice zajímavý je Obrázek 7, který ukazuje podíl druhotných instalací hypervizorů u dotazovaných firem. O malý kousek je mezi dalšími ve vedení Hyper-V před XEN serverem od Citrixu. Oba tyto produkty jsou v základních verzích zdarma, jak jsem zmínil v odstavcích věnujících se jim konkrétně a z pohledu jejich provozovatele tedy nic nebrání tomu, aby testovali jejich nabízené moţnosti například na jiţ zmíněných méně důleţitých systémech nebo výhradne ve zkušebním reţimu. I kdyţ se HyperV i XEN server prezentují jako produkty zdarma, jejich nasazení v produkčním prostředí s sebou nese vţdy provozní náklady, a to buď v podobě placené podpory nebo dalších produktů, které je nutné pro takové prostředí dokoupit (v případě Microsoft produktů to mohou být plná verze MS SQL, System Center 2012, atd.).
Obrázek 7 – Podíl ostatních hypervizorů provozovaných vedle VMware. Zdroj: [20]
Z předcházejících odstavců lze celkem jednoznačně vyvodit závěr, ţe nejoblíbenější a také světově nejrozšířenější je virtualizace postavená na VMware ESXi serverech, vCenter managementu a mnoha dalších rozšíření, které se souhrnně nazývají VMware vSphere.
32
V oblasti virtualizace je společnost VMware také předním inovátorem a spolu s omezeným rozsahem této práce to jsou důvody, proč následující řádky práce budou věnovány právě a jen produktům od společnosti VMware. Celkový přehled moţností, které poskytuje virtualizace v serverové infrastruktuře, bude tak obsaţen zcela, přičemţ některé z následujících technik a funkcí je pak v nějaké obdobě moţno velmi snadno přenést i na prostředí ostatních zmíněných výrobců (časem, jak vývoj konkurenčních produktů bude postupovat, bude jich jistě většina).
33
2. Vysoká dostupnost serverové infrastruktury Pojem vysoké dostupnosti je dnes velmi rozšířen a z pohledu zákazníků, jimiţ jsou v tomto smyslu konzumenti sluţeb poskytovaných IT infrastrukturou, hojně vyţadován. Pojem „zákazník“ budu nadále pouţívat ve výše zmíněném smyslu, neboť i v rámci jedné organizace by mělo IT oddělení poskytovat sluţby ostatním oddělením tak, jako by byly jejich skutečnými zákazníky na reálném trhu. IT oddělení jsou ve většině organizací pouhými interními servisními jednotkami, poskytující prostředky a podporu pro běh důleţitých aplikací, které ostatní oddělení firmy, tvořící jádro obchodní činnosti, nutně potřebují. IT oddělení je pak přímo závislé na úspěchu těchto oddělení, protoţe právě jejich úspěch tvoří jediný zdroj jeho financování. Trendem dnešní doby je pak oddělovat IT oddělení do samostatných obchodních jednotek, které poskytují IT prostředí a podporu pro celou mateřskou organizaci a ta jim za dodané sluţby reálně platí. Tyto samostatné IT jednotky pak mají dále moţnost poskytovat svoje know-how a své zdroje i ostatním firmám, které o její sluţby budou mít zájem a tak efektivně vyuţít všech svých zdrojů k maximalizaci svého zisku. V tomto pohledu je pak jiţ pojem „zákazník“ jasně definovaný. Pokud si představíme obchodní organizaci, která má několik poboček po celé Evropě a je ţivotně závislá na svém informačním systému, bude po IT oddělení takové organizace poţadována 100 % dostupnost takového systému a 100 % bezpečnost jeho dat. IT svět však pojem 100 % dostupnost nezná, respektive není schopen takovou dostupnost sluţby reálně nabídnout. V oboru informačních technologií se dostupnost měří na počet devítek, které jsou na stupnici od jedné do sedmi. Nejniţší dostupnost, definovaná na jednu devítku, znamená 90-98 % celkové roční dostupnosti daného systému. Smluvně, případně interním nařízením, se definuje jedno konkrétní číslo na daný systém.9 Konkrétně to v provozu znamená například maximálně 7.3 dne výpadku, tedy nedostupnosti systému, v průběhu jednoho roku v případě 98% poţadované dostupnosti. Nejvyšší míra garantované dostupnosti se pak definuje jako dostupnost na sedm devítek, coţ znamená 99.99999 % a v praxi to pak toleruje výpadek sluţby na 3.15 vteřiny za období jednoho roku.[14] Tabulka 7 zobrazuje běţně definované úrovně dostupnosti spolu s tolerovanými časy moţných nedostupností. Je nutné si uvědomit, ţe daná nedostupnost nezohledňuje vlastní příčinu nedostupnosti a tak například havárie 9
Dokumenty zahrnující kromě definované doby dostupnosti, definovaných časů reakcí na hlášený incident, definovaných časů vyřešení incidentů, definice závaţnosti incidentů a mnoha dalších termínů, se souhrnně nazývají SLA (Service Level Agreement) a jsou definovány mezinárodním „best practice“ rámcem ITIL.
34
systému ubírá čas stejně, jako jeho nutná údrţba. Prokázané překročení tolerovaného času nedostupnosti systému má v rámci podepsané SLA za následek velmi tvrdé finanční postihy pro poskytovatele sluţby. To má několik racionálních důvodů. Jedním z nich je vysoká důleţitost odebíraných sluţeb, kde čím vyšší je jejich důleţitost, tím vyšší je jejich poţadovaná dostupnost. Druhým důvodem je pak velmi vysoká cena za poskytování takto vysoce garantované sluţby. Spolu s prvním důvodem do hry vstupuje i moţnost ušlého zisku, který se sice těţko prokazuje, nicméně i tento fakt je dobrým argumentem pro stanovení co nejvyšších smluvních pokut. Dostupnost % 90 % ("jedna devítka")
Doba výpadku za jeden rok
Doba výpadku za jeden měsíc
Doba výpadku za jeden týden
36.5 dnů
72 hodin
16.8 hodin
95 %
18.25 dnů
36 hodin
8.4 hodin
97 %
10.96 dnů
21.6 hodin
5.04 hodin
98 %
7.30 dnů
14.4 hodin
3.36 hodiny
99 % ("dvě devítky")
3.65 dny
7.20 hodin
1.68 hodiny
99.5 %
1.83 dne
3.60 hodiny
50.4 minut
99.8 %
17.52 hodin
86.23 minut
20.16 minut
8.76 hodin
43.8 minut
10.1 minut
99.95 %
4.38 hodiny
21.56 minut
5.04 minut
99.99 % ("čtyři devítky")
52.56 minut
4.32 minuty
1.01 minuty
99.999 % ("pět devítek")
5.26 minut
25.9 vteřin
6.05 vteřin
99.9999 % ("šest devítek")
31.5 vteřin
2.59 vteřiny
0.605 vteřiny
3.15 vteřiny
0.259 vteřiny
0.0605 vteřiny
99.9 % ("tři devítky")
99.99999 % ("sedm devítek")
Tabulka 7 – Procentuální definice dostupnosti SLA. Zdroj: [14]
V praxi není mnoho poskytovatelů sluţeb, kteří jsou schopni nabídnout a garantovat dostupnost výš neţ na pět devítek a ta se tak stala vrcholem běţné nabídky. V odstavci, který shrnuje virtualizační platformy, jsem zmiňoval nutnost restartovaní serveru po aplikaci bezpečnostních záplat. V kontextu s hodnotami, které ukazuje Tabulka 7 je pak tato potřeba vnímána zcela odlišně, protoţe doba, kterou je server mimo provoz při svém restartu, můţe dosahovat i desítek minut (příklad z mé praxe: pro velmi běţně uţívaný Microsoft Exchange server je čas výpadku při jeho restartu mezi delší jak 10 minut, velké databáze nebo informační systémy pak mohou startovat i v řádech této doby). Pokud by se jednalo o restarty
35
pravidelné, například kaţdý měsíc, dosaţení garance dostupnosti na pět devítek by pro samostatný systém byla prakticky nemoţná. Tyto důleţité systémy se tedy provozují v různých typech redundantních provozů. To znamená, ţe jednu sluţbu poskytuje několik komponent (serverů, switchů, diskových polí, atp.) a výpadek nebo vypnutí jedné z nich pak pro zbytek fungujících znamená jen o něco více práce se zpracováním odbavovaných poţadavků. Všechny důleţité komponenty tedy musí být v takto zabezpečené infrastruktuře minimálně dvakrát a cena takového řešení je vůči jejich efektivnímu vyuţívání při běţném provozu neúměrně vysoká. Na manaţerech obchodní společností uvaţované na začátku tohoto odstavce je pak odpovědnost rozhodnout, jak vysokou dostupnost své aplikace opravdu potřebují v poměru k nákladům, které je taková dostupnost bude stát. Příchod virtualizace přinesl v tomto ohledu nové, do té doby nepředstavitelné moţnosti. V následujících částech detailně popíši ty funkce, které přímo umoţňují nebo pomáhají k zajištění vysoké dostupnosti poskytované sluţby a zajišťují maximální efektivitu při vyuţívání nákladné infrastruktury. Jak jiţ bylo zmíněno v předchozím shrnutí, budu se věnovat výhradně technologiím společnosti VMware, konkrétně technologii vMotion, Storage vMotion, High Availability, Fault Tolerance, DRS (Distribute Resource Scheduler). Ještě před popisem jednotlivých funkcí je třeba zmínit se o architektuře VMware řešení. Jádrem celého systému je vCenter Server, coţ je aplikace, která zajišťuje veškeré řízení celého prostředí. Instaluje se buď jako virtuální stroj v rámci serverů, které spravuje nebo na samostatný server mimo ESXi servery. S její pomocí se samostatné ESXi servery skládají do klastrů. Mezi jednotlivými ESXi servery a vCenter Serverem probíhá komunikace zcela odděleným kanálem, po takzvané Management network síti. Po této síti také probíhají veškeré dále popsané operace a její dimenzování a zajištění proto není dobré podcenit. Následující kapitoly se opírají převáţně o mé vlastní zkušenosti s produkty, znalostmi získanými na školeních VMware a podloţeny školícími studijními materiály VMware [1].
2.1 vMotion Hned na úvod bych chtěl poznamenat. Ţe funkce vMotion nezajištuje vysokou dostupnost v pravém smyslu slova. Jak jsem jiţ ale v předchozím textu zmínil, vysokou dostupností zde budeme chápat jako zajištění co nejvyšší míry dostupnosti poskytovaných sluţeb. K tomuto účelu je pak funkce vMotion velice přínosným pomocníkem.
36
Jejím hlavním účelem je přenesení běţícího virtuálního stroje z jednoho fyzického hosta na jiného a to bez narušení jeho běhu. Důvod, proč jsem zařadil tuto funkci mezi funkce zajišťující vysokou dostupnost serverové infrastruktury je nasnadě. Představme si situaci, kdy jeden z fyzických hostů virtuálního clusteru začne vykazovat například chybu jednoho paměťového modulu. I přes to, ţe moderní servery mají mnoho komponent v reţimu hot-plug, tedy vyměnitelné za provozu, základní komponenty serveru za provozu měnit nelze a je proto nutné pro takový úkon server vypnout. Důvodů pro vypnutí nebo i pouhý restart fyzického serveru je v běţném provozu celá řada. Pomocí funkce vMotion můţe správce systému za běhu přesunout všechny hostované virtuální stroje na ostatní nody VM clusteru, aniţ by si uţivatelé něčeho všimli. Neţ si představíme princip fungování této technologie, bude dobré zmínit její omezení a předpoklady: 1. Sdílené úloţiště pro soubory virtuálních strojů (úloţiště VMFS10 nebo NFS) – zdrojový i cílový host musí mít přístup do jednoho sdíleného úloţiště, které obsahuje soubory virtuálního stroje, jejţ chceme migrovat. 2. Alespoň 1 Gigabit síťová karta – aţ pro 4 souběţné vMotion migrace, 10 Gbps síť pro aţ 8 souběţných vMotion migrací. 3. Přístup do stejné fyzické sítě. 4. Připojené periferie – virtuální stroj nesmí mít připojeny ţádné lokální periferie, jakými jsou CD-ROM, mechanika Floppy, případně virtuální periferie s připojeným obrazem z lokálního disku. Po migraci by nebylo moţné tyto periferie z pochopitelných důvodů zachovat. 5. Virtuální stroj nesmí mít nakonfigurovánu afinitu procesoru11 6. Kompatibilní procesor – procesory na zdrojovém a cílovém hostu musí být od stejného výrobce a ze stejné rodiny, musí podporovat stejnou sadu instrukcí (některé mohou být schovány pomocí funkce Enhanced vMotion Compatibility nebo
10
11
VMFS je zkratka VMware File Systém a tímto souborovým systémem se formátují logické disky pro pouţití na ESXi serveru. Oproti tomu NFS, jakoţto sdílený síťový disk má jiţ souborový systém vlastní a ESXi server ho pouze přebírá. VMFS je při pouţití s ESXi servery díky své optimalizace mnohem výkonnější – například zamyká soubory jen na úrovni bloků a tak je mnohem volnější a výkonnější při vícenásobném přístupu. Funkce CPU affinity znamená omezení virtuálního stroje na vyuţívání pouze jednoho konkrétního procesoru z host serveru (zdroje jsou jinak rozdělovány dle dostupnosti bez ohledu na číslo procesoru nebo jádro). Konfiguruje se například z licenčních důvodů pro software licencovaný na počet procesorů - Oracle
37
kompatibilním maskováním); rychlost procesoru, velikost cache paměti, počet jader nebo podpora funkce hyper threadingu zde však nehraje roli.12 Existuje ještě několik dalších omezení, jsou však natolik detailní a specifická, ţe jsou za hranicí rozsahu této práce. Jejich detailní popis je moţné dohledat v dokumentaci funkce vMotion. A jak tedy taková migrace při splnění výše vyjmenovaných podmínek vlastně funguje? Před vlastním zahájením migrace vMotion je zkontrolováno, zda všechny nutné podmínky pro provedení migrace jsou splněny a pokud tomu tak není, je správci zobrazen jejich detailní soupis. V praxi se většinou můţe v takovém případě jednat například o opomenutý připojený CD-ROM, coţ se rychle napraví jeho odpojením a můţe se pokračovat. Vlastní proces migrace začíná kopírováním obsahu paměti virtuálního stroje ze zdrojového serveru do paměti serveru cílového. Pracovní paměť virtuálního stroje se mezitím neustále mění a tyto změny jsou zaznamenávány v takzvané bitové mapě paměti. Bitová mapa neobsahuje obsah adres paměti, ale pouze seznam adres, které se od počátku migrace změnily. Ve chvíli, kdy je celá paměť virtuálního stroje přenesena ze zdrojového serveru na cílový, je tento uveden do klidu. To znamená, ţe je stále v paměti, ale neobsluhuje nadále poţadavky klientů. V tuto chvíli je přenesena bitová mapa paměti na cílový server a zároveň se i označí jako vlastník přeneseného virtuálního stroje. Okamţitě poté, co je virtuální stroj na zdrojovém serveru uveden do klidu, začíná se inicializovat a běţet na stroji cílovém. Cílový server ještě pomocí protokolu RARP (Reverse Address Resolution Protocol) vyšle poţadavek do síťového switche, aby přeregistroval MAC adresu virtuálního stroje na síťový port, do kterého je připojen. Paměť zdrojového serveru obsazená virtuálním strojem je současně s tím uvolněna. Klientské poţadavky v tuto chvíli jiţ odbavuje virtuální stroj běţící na cílovém serveru.[2] Pokud jsem v úvodu této kapitoly zmínil, ţe přenesení virtuálního stroje probíhá bez narušení jeho běhu a popisu vlastní funkce pak píši o uvedení virtuálního stroje do klidu tak, ţe nezpracovává poţadavky klientů, musím tento zjevný rozpor vysvětlit. Při testování v laboratoři jsem s funkcí vMotion dělal pokusy a při spuštěném příkazu ping (s parametrem –t, aby probíhal kontinuálně) na virtuální stroj z jiného počítače, se mi vţdy podařilo přenést virtuální stroj s výpadkem jednoho packetu. Drtivá většina aplikací 12
Protoţe vlastnosti procesoru, jako jsou instrukční sady, se načítají ovladači při spuštění virtuálního stroje, není moţné přesunout tento stroj na host server, který obsahuje procesor bez podpory některé z načtených instrukčních sad. Studená migrace, tedy migrace při vypnutém virtuálním stroji, mezi servery s nekompatibilními procesory však na VMware problém není.
38
klient-server snese výpadek 2-3 takových packetů, neţ informují o problémech s konektivitou. Uţivatel sluţby tak opravdu nic nepozná a migrace se tak ve skutečnosti jeví jako bezvýpadková.
2.2 Storage vMotion Podobně jako funkce vMotion, slouţí funkce Storage vMotion k přenesení virtuálního stroje za jeho běhu z jednoho místa na druhé. Na rozdíl od vMotion, kde se mění místo, kde virtuální stroj běţí, u Storage vMotion se mění úloţiště, které drţí soubory tohoto virtuálního stroje. Na první pohled by se mohlo zdát, ţe tato funkce není příliš přínosná, avšak pokud to přiblíţíme k přenosu systémových souborů libovolného běţícího operačního systému, zdání je tu tam. Pokud bych měl nastínit případ uţití modelovým případem, zkusme si představit například potřeby údrţby nebo výměny diskového pole, které obsahuje soubory mnoha produkčních virtuálních serverů. Pokud bychom museli všechny virtuální stroje vypínat, přenést jejich data a znovu je spouštět z jiného umístění, nejen ţe by to trvalo velmi dlouhou dobu, ale také by to znamenalo jejich vyřazení z provozu na dobu probíhající migrace. Důvodů pro uvolnění datového úloţiště lze v praxi najít celou řadu a i přes to, ţe stejně jako funkce vMotion, nezajišťuje funkce Storage vMotion přímo vysokou dostupnost serverů, velmi pomáhá k zajištění vysoké dostupnosti poskytovaných sluţeb. Oproti funkci vMotion nemá Storage vMotion ţádná technická omezení ani nutné předpoklady a lze tedy pouţít napříč všemi podporovanými datovými úloţišti (tedy jak pro NFS, tak VMFS úloţiště na Fibre Channel, iSCSI nebo lokálních SCSI discích). Jediné omezení, které by stálo za zmínku, je nemoţnost přesunutí snapshotů, tedy bodů obnovení, při pouţití funkce Storage vMotion na serverech ESX(i) ve verzi 4. Zmiňuji to z toho důvodu, ţe i přes to, ţe poslední verze 4.1 byla vydána před třemi lety, je stále mnoho firem, které dosud na aktuální verzi 5.1 nepřešly. Je samozřejmé brát na zřetel fakt, ţe Storage vMotion by jako kaţdý další zásah do produkčního prostředí neměl být spouštěn bezhlavě a bez konzultace se správci daného serveru. Stejně tak je vhodné provádět tuto migraci mimo časy špiček vytíţení daných serverů. Toto jsou však pouhá doporučení plynoucí ze zkušeností a zdravého rozumu. Vlastní proces migrace dat probíhá pouze jedním během a to tak, ţe se zkopíruje veškerý obsah ze zdroje blok po bloku na cílové úloţiště. Pokud se během kopírování změní uloţené bloky zdroje v místě, které jiţ bylo zkopírováno, jsou tyto změny synchronizovány s cílovým úloţištěm pomocí mirror driveru a není proto nutné se ke změněným místům znovu vracet.
39
Toto pochopitelně zajišťuje prakticky nejkratší moţnou dobu provedení této migrace. Zmíněný mirror driver je vlastně funkce zrcadlení I/O diskových operací, které se souběţně zapisují jak na zdrojový, tak na cílový disk. Díky němu trvá migrace mnohem kratší dobu, je spotřebováno mnohem méně I/O operací a umoţňuje také migraci na cílové úloţiště, které je pomalé a při rekurzivním kopírování by nestíhalo prováděné změny zapisovat (migrace by nikdy neskončila). Po úspěšné synchronizaci dat začne pracovat virtuální stroj s daty na novém úloţišti a data na starém jsou odstraněna. Ve verzi ESXi 5 byla přidáno API rozhraní pro přímou komunikaci s diskovými poli a tato funkce je označována jako VMware API for Array Integration (VAAI). VAAI je jinak známá také jako hardwarová akcelerace diskového pole. Diskové pole tuto funkci samozřejmě musí podporovat, pokud ji chcete pouţít. Operace kopírování tak můţe probíhat dvěma způsoby. Klasicky jsou data přesouvána pomocí funkce jádra hypervizoru, tedy přes datovou komunikaci mezi ESXi serverem a diskovým polem a zatěţuje tak I/O operacemi jak server, tak datové linky. S pouţitím funkce VAAI je poli předána informace, která data se mají přesunout a kam. Zbytek je jiţ čistě v reţii diskového pole. Obrázek 8 znázorňuje celý proces Storage vMotion migrace, včetně alternativního pouţití VAAI funkce.
40
Obrázek 8 – Schéma funkce Storage vMotion. Zdroj: [1]
2.3 High Availability (HA) Jak jiţ z názvu vyplývá, jedná se jiţ o skutečnou funkci zajišťující vysokou dostupnost serverové infrastruktury i proti neplánovaným výpadkům. Pokud chceme provozovat servery zajištěné vysokou dostupností, musí tomu odpovídat i navrţená infrastruktura. Z hardwarového pohledu potřebujeme alespoň 2 fyzické servery, které by ideálně měly být výkonově i parametrově odpovídající, aby nedošlo k v případě výpadku výkonnějšího z nich k enormnímu přetíţení slabšího a tím způsobenému omezení nebo dokonce úplnému přerušení i zbývajících sluţeb, které slabší server do té doby provozoval. Pokud jsem upozorňoval na nutnost kompatibility procesorů u funkce vMotion, u HA toto není vyţadováno. Virtuální stroje v případě výpadku startují na svých nových hostech od nuly a ovladač procesoru se při bootování můţe přizpůsobit. Dále potřebujeme sdílené úloţiště, které bude obsahovat soubory virtuálních strojů a bude dostupné ze všech serverů VMclusteru. Krom velmi drahých diskových polí provozovaných
41
na Fibre Channelu nebo iSCSI lze pouţít i mnohem levnější, zato znatelně pomalejší NFS úloţiště (například NAS) nebo dokonce lokální disky zvaţovaných fyzických serverů pomocí funkce vSphere Storage Appliance (VSA). Ta v případě klastru sloţeného ze dvou serverů rozdělí lokální disky obou serverů tak, ţe z jedné části vytvoří disky pro lokální ESXi server a na druhé části udrţuje repliku lokálního disku druhého ESXi serveru. Z toho však vyplývá niţší kapacita diskového prostoru a výrazná duplikace dat (na kaţdém ze serverů by měly být disky v nějaké formě RAID pole, vzhledem k výkonu je doporučeno RAID 0+1, a data jsou v tomto případě drţena 4x). Máme-li servery a datové úloţiště, potřebujeme zajistit komunikaci serverů s okolním světem a mezi sebou samými a vCenter Serverem, který celý HA řídí. Komunikace mezi fyzickými servery a vCenter serverem probíhá, po oddělené síti Management network. Je doporučeno, aby fyzické servery obsahovali alespoň dva fyzické síťové porty, kdy jeden je pouţit pro běţnou síťovou komunikaci a druhý pro Management network. Oba síťové kanály jsou pak připojeny do fyzického switche, případně switchů. Tímto bychom měli postavené a připravené prostředí nutné pro zajištění funkce HA, tedy vysoké dostupnosti virtuálních serverů. Pokud se však zamyslíme nad takto popsanou architekturou, je takto postavené řešení funkční pouze za předpokladu, ţe všechny ostatní komponenty krom vlastních fyzických serverů budou vţdy plně funkční. Pokud by došlo k výpadku síťového přepínače (switche) nebo například Fibre Channel switche, došlo by k fyzickému přerušení síťového kabelu (například neopatrnou uklízečkou) anebo mnoho a mnoho dalších moţných scénářů, stane se celé řešení pro zajištění vysoké dostupnosti zbytečným a neúměrně drahým. Ve správně navrhovaných architekturách je proto vţdy myšleno na takzvaný Single Point of Failure (SPOF), tedy jediné místo chyby. Pokud tedy například celý náš zamýšlený klastr byl síťově propojen do jednoho jediného síťového přepínače, byl by tento switch při svém selhání SPOF a způsobil by nefunkčnost celého systému. Obrázek 9 zobrazuje právě takové zapojení. Jedná se o klastr sloţený ze tří fyzických ESXi serverů. Všechny servery mají pouze jeden síťový komunikační port a stejně tak jsou propojeny pouze jednou cestou ke třem LUNům13 jednoho, případně několika diskových polí. Pokud by došlo k poruše na některé z komunikačních větví, způsobilo by to značné omezení nebo dokonce výpadek celého řešení.
13
LUN je běţně uţívaná zkratka (Logical Unit Number), která je identifikátorem kaţdé logické diskové jednotky v rámci diskového pole.
42
Obrázek 9 – Scénář neredundantního zapojení VM klastru. Zdroj: [1]
Správné a dostatečně robustní zapojení by tedy vypadalo tak, ţe všechny komunikační cesty by byly zdvojeny. Pro síťovou komunikaci by kaţdý ze serverů měl vyhrazeny alespoň dva síťové porty, kaţdý z nich by pak byl zapojen do jiného síťového přepínače. Stejně tak i Management network by bylo lepší mít oddělen na vlastních portech a samozřejmě také redundantní zapojení do dvou různých switchů. Obdobně by pak mělo vypadat zapojení směrem k diskovým úloţištím. V případě NFS úloţišť by dostačovala komunikace po výše zmíněných síťových portech (pokud by nám stačila jejich přenosová kapacita), avšak na straně vlastního diskového pole NAS musí být opět propojeno přes dva síťové porty do dvou různých switchů. V případě Fibre Channel by pak kaţdý z fyzických ESXi serverů měl mít dvě komunikační HBA14 karty zapojené kříţem do dvou různých Fibre Channel switchů. Obdobně i pro iSCSI. Názorně takové zapojení ukazuje Obrázek 10. Znázorněny jsou dva fyzické servery, kaţdý z nich obsahuje dva síťové porty a dvě HBA komunikační karty pro Fibre Channel. Ty jsou kříţem zapojeny do síťových přepínačů. Z těch je dále zapojení realizováno opět kříţem do síťových routerů, respektive vlastních diskových polí. Takové zapojení je odolné vůči selhání některé z komponent a je tedy vhodné pro provozování HA řešení.
14
HBA (Host Bus Adapter) karta je komunikační zařízení určené pro komunikaci serveru se síťovým diskovým polem – SAN (Storage Area Network).
43
Obrázek 10 – Příklad redundantního zapojení serverů (zdroj: vlastní)
V tuto chvíli máme i hardwarové zapojení dostatečně robustní a můţeme se tedy pustit do spuštění funkce HA na VMware. V administraci vCentra zapneme funkci HA na vytvořeném klastru. V tu chvíli se na všech členech klastru spustí sluţba Fault Domain Manager (FDM), která zajišťuje komunikaci mezi členy klastru a celá funkce HA je pomocí ní řízena. Vlastní řízení zajišťuje jeden ze členů klastru, který je zvolen jako Master. Tato volba probíhá okamţitě po spuštění FDM a má dva kroků rozhodování. První je počet datových úloţišť, ke kterým se člen klastru dokáţe připojit. Ten, který jich má k dispozici nejvíce je zvolen Masterem. Pokud má stejný nejvyšší počet dostupných úloţišť více neţ jeden ze členů klastru, volba probíhá druhým krokem, který přidělí roli Mastera členovi s nejniţším Managed Object ID (MOID), coţ je identifikátor přidělovaný serverem vCenter. Tato volba je vyvolána během zhruba 15 vteřin po třech moţných událostech: 1. Zapnutí funkce vSphere HA. 2. Úřadující Master selţe, je přepnut do údrţbového reţimu, je přepnut do reţimu standby anebo pokud je funkce HA překonfigurována. 3. Pokud podřízení členové klastru (Slave) nemohou s Masterem komunikovat, například kvůli poruše na síti.
44
Master server poskytuje rozhraní pro vCenter server, kterým je zjišťován stav celého klastru a dostupné virtuální stroje. Kaţdý z podřízených serverů se hlásí Master serveru pomocí takzvaných heartbeatů. To jsou signály, na základě kterých Master server pozná, ţe Slave je v pořádku a funkční. Tyto heartbeaty jsou primárně posílány přes Management network, pokud však dojde k poruše této sítě, supluje se komunikace přes běţnou síťovou vrstvu (přes výchozí bránu) a pokud ani ta není k dispozici, posílají se heartbeaty přes datové úloţiště. Celý systém této komunikace nemá doposud ve světě serverové virtualizace obdoby. V celém systému HA můţe dojít ke čtyřem scénářům selhání a k nim odpovídajícím následným reakcím: selhání Slave serveru, selhání Master serveru, izolace hosta, selhání síťové komunikace (Management network), o síťové rozdělení, o síťová izolace. Průběh prvního scénáře, tedy selhání Slave serveru probíhá následovně. V případě náhlého výpadku jednoho z podřízených serverů, je tento označen Master serverem jako „agent nedostupný“. Master server se poté snaţí zjistit, zda došlo k výpadku síťové komunikace, pádu HA agenta nebo opravdového pádu celého serveru. Pokud se nepodaří zkontaktovat nedostupný server ţádnou variantou záloţní komunikace, je server označen jako porouchaný a všechny virtuální stroje, které na něm doposud běţely, jsou spuštěny na ostatních členech klastru. Pokud dojde k selhání Master serveru, ať jiţ neplánovaným výpadkem nebo třeba plánovaným přepnutím do reţimu údrţby, podřízené servery detekují, ţe Master server jiţ nevysílá heartbeaty. V takovém případě se provede nová volba Master serveru a to za stejných pravidel, jak jiţ bylo popsáno výše. Následně pak nový Master server provádí kroky prvního scénáře. Jak z předešlých dvou popsaných scénářů vyplývá, nezáleţí na tom, kolik nodů klastru vypadne, ba dokonce ani na tom, jestli vypadnutým nodem je sám Master server. V případě serverového clusteru společnosti Microsoft, který je vyuţíván i pro Hyper-V, je situace trochu sloţitější. Pokud bychom vzali modelovou situaci klastru o pěti členech, z kterých by v jeden
45
okamţik tři servery zhavarovali (například jsou umístěny v jednom racku, kterému selţe napájení), budou na platformě VMware přesunuty běţící virtuální stroje na zbývající dva členy klastru a funkce bude zajištěna. V případě Hyper-V a jeho klastru na bázi Quorum modelu by v takovém případě celý systém selhal. Zbývající servery by jiţ nedokázali zjistit, který z nich má prioritu a HA přestává fungovat. V případě Microsoft clusteru je tedy potřeba zvaţovat i tuto situaci a přizpůsobit tak například i umístění serverů v rámci datového centra, aby pravděpodobnost výpadku více neţ jednoho ze členů klastru byla minimální. Třetím scénářem, tedy izolací hosta, rozumíme situaci, kdy dojde k selhání komunikace mezi serverem a zbytkem klastru (bez ohledu na to, zda se jedná o Master nebo Slave server) stejně jako v prvních dvou scénářích, avšak Master serveru, případně nově zvolenému Master serveru, se podaří komunikovat se selhaným serverem pomocí heartbeatů posílaných přes diskové úloţiště. Server, u kterého došlo k selhání, musí dále splnit dvě podmínky. Není schopen přijímat signály skrze Management network a současně není schopen provést příkaz ping na adresu výchozí brány. V takovém případě je tento server označen jako Izolovaný a podle konfigurace pro případ izolace hosta jsou virtuální stroje na tomto serveru buď ponechány v běţícím stavu, natvrdo vypnuty nebo vypnuty korektně skrze příkaz poslaný do jejich operačních systémů. Tato konfigurace se nastavuje pro celý klastr, ale je moţné nastavit zvlášť i na jednotlivých virtuálních strojích, kde je navíc moţnost pro převzetí globální nastavení klastru. Pokud je vybrána jedna z moţností vypnutí, jsou virtuální stroje nastartovány na ostatních členech klastru (při okamţitém vypnutí je přesun rychlý, vypnutí přes operační systém pak sice trvá déle, nicméně některé aplikace okamţité vypnutí nemusí dobře snést – typicky databáze). Pokud dojde někde na síti Management network k takové závadě, ţe skupina serverů jednoho je komunikačně rozdělena do samostatných ostrovů (například vadný router), jedná se o scénář síťového rozdělení. V takovém případě se ve skupině, která obsahuje původní Master server nic nezmění, v kaţdé další izolované skupině je dle dříve popsaných pravidel zvolen vlastní Master server. Po obnovení síťové komunikace mezi oddělenými ostrovy opět převezme jeden z Master serverů roli od všech ostatních a zůstává nadále jediným. Klastr se vrací do normální činnosti. Tento scénář je moţný pouze v případě, ţe komunikace samostatných ostrovů s vCenter serverem a s okolním světem probíhá normálně. V opačném jsou host servery ve skupině odříznutých serverů prohlášeny za selhané podle prvních dvou scénářů.
46
Kromě sledování vlastních fyzických členů klastru je moţné sledovat i jednotlivé virtuální stroje. Sluţba VM Monitoring sleduje odezvy aplikace VMware Tools, která musí být nainstalována na operačním systému virtuálního stroje a pokud heartbeat signál nepřijde do nastavené doby nebo operační systém nevysílá ţádné I/O operace po dobu alespoň 2 minut (výchozí hodnota), je operační systém virtuálního stroje povaţován za selhaný a následně restartován k obnovení sluţby. Při obnovování provozu lze také na virtuálních strojích nastavit prioritu startování a upřednostnit tak obnovu velmi důleţitých systému před těmi méně důleţitými. Nastavení se provádí na úrovni jednotlivých virtuálních strojů ve čtyřech úrovních priority – vypnuto, vysoká, střední, nízká. Pokud dojde k výpadku většího mnoţství hostů, zbývající funkční servery mohou mít problém se zvládnutím velkého mnoţství nově přiřazených virtuálních strojů a samozřejmě to můţe ovlivnit dostupnost a kvalitu sluţeb doposud na těchto serverech běţících. Pro tento případ je v rámci nastavení funkce HA připravena ochrana celého klastru proti přetíţení. Tu lze nakonfigurovat třemi způsoby. Buď na maximální povolený počet selhaných hostů, ze kterých budou virtuální stroje rozděleny a spuštěny napříč HA klastrem nebo se definuje maximální procentuální část rezervovaných zdrojů (zvlášť pro CPU a RAM) kaţdého člena klastru pro spuštění přepadlých virtuálních strojů ze selhaných serverů anebo se specifikují pouze konkrétní host servery, na které se v případě selhání některého, případně některých členů klastru převedou virtuální stroje. V posledním případě však nelze určit rezervaci zdrojů a můţe tak k jejich přetíţení dojít. Zvolení správného chování je v tomto případě závislé na struktuře celého klastru, pouţitých serverech a systémech, které jsou zde provozovány. Funkce HA je tedy velmi důleţitým pomocníkem v zajištění vysoké dostupnosti serverové infrastruktury a dovolím si ji označit za její základní stavební kámen. V případě jakéhokoliv selhání je automaticky zajištěno obnovení sluţeb poskytovaných nefunkčními členy klastru, případně nefunkčním virtuálním strojem. V kaţdém případě však znamená výpadek na HA určité omezení provozu, protoţe virtuální stroje jsou nově startovány na nových hostech, výpadek sluţeb pak odpovídá zhruba době startu jednotlivých operačních systémů.
47
2.4 Fault Tolerance (FT) Funkce vysoké dostupnosti v pravém slova smyslu. Tak by se dala jednoduše definovat tato unikátní funkce společnosti VMware. Kombinuje v sobě spolehlivost předchozí funkce HA a naprosto bezvýpadkový provoz. Při pouţití této funkce je vytvořena kopie chráněného virtuálního stroje (jeho paměti) na některém z dalších host serverů a pomocí technologie vLockstep je po celou dobu běhu synchronizována. Ve skutečnosti tedy běţí souběţně dvě kopie stejného virtuálního stroje, mají však jednu IP adresu a jednu MAC adresu a jsou spravovány pouze pomocí primární kopie. Pokud jedna z běţících kopií selţe, je okamţitě vytvořena kopie nová na dalším volném členu klastru. Pokud je selhaným strojem primární kopie, sekundární stroj převezme okamţitě jeho úlohu a je vytvořen nový sekundární stroj. Pokud je selhaným serverem sekundární kopie, je pouze vytvořena nová sekundární kopie na novém serveru, provoz však dále běţí na primární kopii. Protoţe je paměť obou kopií neustále precizně synchronizována, je přepnutí z jedné kopie na druhou okamţité, veškeré informace jsou zachovány a běţící aplikace normálně pokračují ve své činnosti. Kdyţ jsem se s touto technologií poprvé setkal, bylo to pro mě něco neuvěřitelného. Pokud jsem u pouţití technologie vMotion popisoval výpadek jednoho packetu funkce ping za uţivatelem nepozorovatelný, při testování funkce Fault Tolerance jsem při tomtéţ sledování systému a jeho náhlém vypnutí opakovaně nepozoroval výpadek jediného ping packetu. Zní to i přes zjevně vysoké nároky na utilizaci host serverů skoro neuvěřitelně. Bohuţel tato funkce má i svá ale. Těmi jsou její limity, které zatím brání jejímu většímu rozšíření v produkčních prostředích. Ty nejdůleţitější systémy, poskytující uţivatelům tolik ceněné sluţby, aby stálo za to je tímto způsobem chránit, jsou většinou i velmi náročné na výkon. Kvůli patentu drţenému společností Microsoft je funkce FT omezena na pouhé jedno CPU v jednom virtuálním stroji. Podle informací přímo od společnosti VMware, která byla sdělena účastníkům školení VMware vSphere: Install, Configure, Manage ve společnosti Arrow, pracuje společnost VMware spolu se společností Intel na novém typu procesoru, který patentové omezení odstraní. V budoucnu tedy nebudou virtuální stroje pod ochranou funkce FT omezeny na jednovláknové zpracování výpočetních úkonů a dovolí to tak této technologii plného rozmachu. Zajištění vysoké dostupnosti na více neţ pět devítek tak bude o mnoho snazší a výrazně levnější neţ doposud.
48
Pro úplnost zmíním ještě několik dalších omezení, které však jiţ nejsou tolik limitující. Na virtuálních strojích pod ochranou FT nelze pouţívat body obnovení (Snapshoty). Na jednom fyzickém hostu mohou být provozovány maximálně čtyři FT virtuální stroje. Toto omezení není striktní, nicméně provozování FT enormně zatěţuje síťovou komunikaci a disky, proto je toto číslo jako doporučené. Skutečný počet provozovaných FT virtuálních strojů na jednom fyzickém hostu je závislý na jejich velikosti a zatíţení host serveru i samotných virtuálních strojů.
2.5 Distributed Resource Scheduler (DRS) Poslední funkcí, kterou bych chtěl v souvislosti s vysokou dostupností serverové infrastruktury představit, je funkce DRS. Stejně jako u prvních dvou představených se ani zde nejedná o funkci přímo zajišťující vysokou dostupnost serverů, ale přesto, dle mého názoru, zde zaujímá místo právem. Primárně se jedná o funkci vytvořenou za účelem lepší škálovatelnosti a utilizace fyzických host serverů. V následujících řádcích se pokusím svůj názor obhájit. Funkce DRS lze rozdělit do třech oblastí. První z nich zajišťuje prvotní umístění virtuálních strojů v klastru. Pokud správce spustí nějaký nový virtuální stroj, funkce DRS dle stavu vytíţení jednotlivých členů klastru zjistí nejvhodnější umístění a tam buď stroj přímo spustí, nebo dá správci k tomu doporučení. Druhou, a řekněme zřejmě primární funkcí, je load balancing, tedy vyvaţování zátěţe. DRS neustále monitoruje přidělování a vyuţití zdrojů (CPU a RAM) na všech hostech v klastru. Naměřené hodnoty pak porovnává s ideálním vyuţitím zdrojů. Na základě výsledků buď přímo provádí migraci virtuálních strojů anebo vydává doporučení pro správce systému. Třetí funkcí je pak Power management (DPM). Pokud je funkce DPM zapnutá, DRS porovnává spotřebovanou kapacitu celého klastru a jednotlivých host serverů s výkonovými poţadavky virtuálních strojů, včetně poţadavků z nedávné historie. Pokud je poskytována přebytečná kapacita, jsou virtuální stroje přestěhovány tak, aby vyuţili efektivně kapacitu fyzických serverů, a zcela uvolněné servery jsou převedeny do stavu standby (nebo je vydáno pro tyto úkony doporučení). Pokud je naopak zdrojů nedostatek, jsou volné vypnuté servery zapnuty a virtuální stroje z přetíţených serverů jsou na ně přestěhovány.
49
Všechny přesuny virtuálních strojů, které funkce DRS provádí, jsou realizovány pomocí jiţ zmíněné funkce vMotion. Pro její běh tedy platí stejná omezení a předpoklady, jako pro vMotion. Obdobou funkce DRS pro host servery je funkce Storage DRS pro datová úloţiště. Pro tuto funkci musí být zapnuta funkce Storage I/O Control pro všechna datová úloţiště dostupná DRS klastru. Pomocí této funkce jsou pak monitorovány I/O operace napříč datovými úloţišti a v případě jejich přetíţení je vyrovnání zátěţe provedeno migrací některých virtuálních strojů pomocí funkce Storage vMotion. Funkce DRS je úţasným doplňkem pro funkce HA a FT a VMware doporučuje pouţívat je společně. DRS pro funkci HA zajišťuje rovnoměrné rozdělení virtuálních strojů při přesunu ze selhaných hostů na zbývající členy klastru a zamezuje tak přetíţení jednotlivých hostů. Stejně tak při obnovení provozu vadného host serveru rozdělí virtuální stroje ideálně napříč celým klastrem (funkce HA sama o sobě virtuální stroje na své původní host servery nevrací a je tedy nutný ruční zásah správce systému). Pro funkci FT pak doporučuje umístění kopií virtuálního stroje na ideální host servery. Na DRS lze nastavit tři úrovně automatizace. Ruční, částečně automatizované a plně automatizované. Při ručním nastavení vydává funkce DRS pouze doporučení. Při spuštění virtuálního stroje nebo ve chvíli, kdy se vytíţení klastru stane nevyváţené, zobrazí se v konzoli vCenter serveru seznam doporučení pro konkrétní přemístění určitých virtuálních serverů. Správce systému buď doporučení potvrdí a to se následně provede nebo nepovolí. Při částečně automatizovaném provozu se nově spuštěné virtuální servery automaticky umístí na nejvhodnější host klastru, avšak v případě nevyváţenosti vytíţení klastru se postupuju stejně jako v případě ručního nastavení. Plně automatizovaný provoz pak provádí veškeré operace bez zásahu správce systému. V rozhodování o umístění virtuálních strojů jsou brány v potaz konfigurovatelná omezení, která se nazývají Affinity a Anti-affinity. Těmi lze omezit vzájemné umístění jednotlivých virtuálních strojů tak, aby musely být vţdy spolu na jednom host serveru nebo naopak, ţe se nikdy na jednom host serveru nesmí sejít. Důvodem sdruţování můţe být například poţadavek na výkonnost vzájemné komunikace15, důvodem pro oddělení pak poţadavek na dostupnost.
15
Při pouţití virtuálního síťového adaptéru VMXNET 3 můţe být rychlost komunikace mezi virtuálními stroji v rámci jednoho fyzického host serveru aţ 10 Gb/s. V praxi se nám podařilo naměřit hodnoty pohybující se od 3 do 8 Gb/s.
50
V úvodu části věnované DRS jsem vznesl polemiku nad tím, zda je moţné tuto funkci pokládat za funkci zajišťující vysokou dostupnost. Z předchozího popisu je jiţ zřejmé, ţe zajištění vysoké dostupnosti přímo velmi dobře podporuje. Pokud se v myšlenkách vrátím na úplný začátek této kapitoly, kde jsem serverovou infrastrukturu a zajištění její vysoké dostupnosti přenesl na zajištění vysoké dostupnosti dodávaných sluţeb, pak i samotná moţnost vyvaţování zátěţe můţe být pokládána za část zajišťující takové prostředí. Ve chvíli, kdy dojde k přetíţení některého serveru a ten tak nezvládá vyřizovat poţadavky virtuálních serverů a potaţmo pak aplikací, které na nich běţí, stanou se tyto aplikace nepouţitelné a tedy není reálně zajištěna jejich dostupnost, i přes to, ţe servery, na kterých aplikace běţí a celá okolní infrastruktura je v plně funkčním stavu.
51
3. Ekonomické vyhodnocení Přesto, ţe cílem této práce není rozbor virtuálních technologií z pohledu ekonomického, jsou přínosy virtuálizace z pohledu omezování nákladů na provoz značné. V kapitole 1.5 jsem zmiňoval, ţe se průměrná densita virtuálních serverů provozovaných v České Republice na platformě VMware pohybuje mezi 40 a 50 virtuálními stroji. Díky lepší správě paměti je tato densita zhruba o 20% vyšší neţ u konkurence a jako univerzální průměr tak zvolím 40 virtuálních strojů provozovaných na jednom hostu, bez ohledu na pouţitý hypervizor. Běţně pouţívané low-end rackové servery se pohybují v cenách od 100 tisíc korun. Jen v ceně samotných serverů tak jeden virtuální host pojme hodnotu přesahující 4 miliony korun. Server samotný, dimenzovaný na zvládnutí takové zátěţe jistě cenou vejde do 1 milionu korun. Dále budeme počítat, ţe 40 takových serverů bude mít za běhu špičkový příkon 40 kW (předpokládám 2 zdroje o příkonu 500 W na kaţdý server). Reálnému provozu pak bude odpovídat zhruba 60% této hodnoty a tedy 24 kW. Jeden virtuální server nahrazující těchto 40 fyzických, bude mít špičkový příkon řekněme pětinásobný, tedy dva zdroje o příkonu 2,5 kW, celkem 5 kW (počítáno pro značně naddimenzovaný plně osazený Blade server s 16 jednotkami). Jeden standardně pouţívaný 19” rack pojme v průměru 10 serverů. Na 40 fyzických serverů by tedy bylo potřeba zaplnit 4 racky. Virtuální servery bychom do takového racku umístili přinejmenším dva (v případě zmíněného Blade serveru), coţ znamená, ţe jeden rack by takto byl schopen pojmout 80 serverů. Obsazený prostor, stejně jako spotřeba energie se pak samozřejmě rovná obrovským nákladům na budování a údrţbu datového centra, především pak na provoz chlazení vnitřního prostoru. I přes čistě teoretické výpočty je na první pohled je zřejmé, ţe přímá finanční úspora je velmi výrazná. Abych závěry svých teoretických kalkulací mohl opřít o nějaký podloţený příklad z praxe, pouţiji odpověď Karla Pecla, ředitele ICT Division společnosti Datart, který byl hostem Ing. Lubomíra Jankových, CSc. na přednášce z předmětu Správa a řízení IS ze dne 4. 4. 2012. V prostoru pro dotazy jsem poloţil otázku, jak se změnila IT struktura ve společnosti Datart po migraci na virtuální prostředí VMware a jaká byla finanční úspora v po prvním roce provozu, byla-li vůbec nějaká s ohledem na náklady spojenými s vlastní migrací. Jeho odpověď pro mě samotného byla překvapující, neboť v rámci projektu bylo zmigrováno 250 fyzických serverů obsluhující pobočky firmy po celé Evropě na servery virtuální, které běţí
52
na pouhých 7 host serverech. Za první rok provozu pak zaznamenali úsporu 3,5 milionu korun. Vlastní migrace fyzických serverů do virtuálního prostředí samozřejmě také stojí značné mnoţství finančních prostředků, ať jiţ za nákup nových serverů, licencí za virtuální prostředí nebo stovky hodin práce odborných konzultantů, ale jak je z příkladu společnosti Datart zřejmé, i po započtení těchto pořizovacích nákladů byla v porovnání se zaběhnutým provozem jiţ v prvním roce generována značná úspora. Produkty společnosti VMware jsou aktuálně nejdraţší moţností na trhu, sic se velmi snaţí různými kalkulacemi srovnávat s konkurenčními produkty. Ceně však odpovídá i kvalita jimi nabízených produktů, potaţmo funkce, kterým ostatní výrobci zatím dokáţí jen velmi těţko konkurovat. U menších společností, vlastnících malé technologické zázemí, je na počátku rozhodnutí o spuštění tak významného projektu potřeba zamyslet se nad tím, zda opravu pro své prostředí potřebuji tak rozsáhlé řešení a nezvolí-li raději levnější produkt konkurence, který bude jejich nárokům plně vyhovovat i s přihlédnutím na budoucí rozvoj.
53
Závěr Ačkoliv je virtualizace poměrně nová technologie a skutečně reálné podnikové nasazení probíhá jen posledních několik málo let, i za tak krátkou chvíli přesvědčivě dokázala svůj význam a obrovský potenciál. Virtualizační technologie dále poskytují neskutečně silnou základnu všem cloudovým řešením a to především díky technologiím poskytujícím vysokou dostupnost a široké migrační moţnosti bez nutnosti vypínat běţící sluţby. Nezávislost virtuálních strojů na pouţitém fyzickém hardwaru pak moţnosti vyuţití dále rozšiřuje. Při selhání fyzického serveru nebo jeho výměně za výkonnější není třeba znovu instalovat operační systémy virtuálních serverů a znovu sloţitě implementovat běţící aplikace. Nejsilnější firmou na poli virtualizace je jednoznačně společnost VMware, která celou éru virtuálního věku odstartovala a její prvenství je tak pochopitelné. Své produkty prezentuje pod společným označením vSphere, coţ má na první pohled ukázat jejich úzkou vzájemnou provázanost a konzistentnost celého řešení. Na druhém místě je pak společnost Microsoft s produktem Hyper-V, který dodává zdarma buď jako samostatný produkt nebo se zakoupenými licencemi produktů rodiny Windows Server. Od prvního představení v roce 2008 udělal Microsoft na vývoji Hyper-V mnoho práce. Poslední verzí, vydanou na podzim roku 2012 spolu s novou verzí Windows Server 2012, upevnila a potvrdila své druhé místo na trhu. Třetím v pořadí je pak společnost Citrix se svým Xen serverem. I tento produkt je nabízen zdarma a to pod licencí GPL. Jeho většímu rozšíření v korporátní sféře je tento fakt spíše překáţkou, coţ potvrzují i analytici společnosti Gartner[21]. Svým podílem na trhu a kladným hodnocením z řad odborníků dokazuje, ţe je kvalitním produktem a měl by být zařazen do rozhodování o tom, jaký produkt pro virtualizaci nasadit. Virtualizační technologie se v dnešní době jiţ stávají běţným standardem a rozšiřují se od virtualizace serverů, po virtualizace celých sítí aţ po virtualizaci celých datových center. Směrem ke koncovým uţivatelům se pak virtualizují pracovní stanice nebo dokonce samotné aplikace. Moţnosti virtualizačních technologií neustále rostou vysokým tempem, stejně jako jejich přínos uţivatelům. Z pohledu efektivity vyuţívaní zdrojů, vlivu na ţivotní prostředí a značnou ekonomickou výhodnost nelze jejich pouţití jinak neţ doporučit. To je i v souladu s cílem této práce.
54
Seznam použité literatury Bibliografie [1] VMware® Education Services. VMware vSphere: Install, Configure, Manage (Student Manual, ESXi 5.0 and vCenter Server 5.0). Revize A, 2011. Part Number EDU-ENGICM5-LEC1-STU a EDU-ENG-ICM5-LEC2-STU [2] Scott Lowe. Mistrovství ve VMware vSphere 4, kompletní průvodce profesionální virtualizací. 1. Vyd. 2010. ISBN 978-80-251-2915-9
Elektronické dokumenty [3] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 25. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/Virtualization#cite_note-PH-19-0 [4] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 20. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/Hardware-assisted_virtualization [5] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 28. 5. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/Ring_(computer_security) [6] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 26. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/Xen [7] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 16. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/Microsoft_Virtual_PC [8] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 22. 5. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/Microsoft_Virtual_Server [9] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 1. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/Microsoft_Hyper-V [10] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 7. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/VirtualBox [11] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 21. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/Vmware
55
[12] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 25. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/VMware_Workstation [13] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 26. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/VMware_ESX [14] Citace. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 11. 12. 2006, last modified on 25. 6. 2013 [cit. 2013-06-26]. Dostupné z: http://en.wikipedia.org/wiki/High_availability [15] Oracle VM, Oracle Virtualization [online] Oracle® [cit. 2013-06-26]. Dostupné z: http://www.oracle.com/us/technologies/virtualization/oraclevm/index.html [16] Citrix Xen Server – Efficient Server Virtualization Software [online] Citrix Systems, Inc. [cit. 2013-06-26]. Dostupný z: http://www.citrix.cz/products/xenserver/ [17] VMware Virtualization for Desktop & Server, Public & Private Clouds [online] VMware®, ©2013 [cit. 2013-06-26]. Dostupné z: http://www.vmware.com/ [18] VMware. Host OS Compatibily Guide [online] VMware®, ©2010 [cit. 2013-06-26]. Dostupné z: http://www.vmware.com/resources/compatibility/pdf/VMware_HOS_Compatibility_Gui de.pdf [19] Microsoft Hyper-V Server 2012 [online] Microsoft, ©2013 [cit. 2013-06-26]. Dostupné z: http://www.microsoft.com/hyper-v-server/en/us/default.aspx [20] Scott Lowe. VMware's hypervisor hold may be waning. In: Wikibon [online] Wikibon, ©2008-2013 [cit. 2013-06-26]. Dostupné z: http://wikibon.org/wiki/v/VMware's_hypervisor_hold_may_be_waning [21] Thomas J. Bittman, George J. Weiss, Mark A. Margevicius, Philip Dawson. Magic Quadrant for x86 Server Virtualization Infrastructure. In: Gartner [online] Gartner ®, ©2012 [cit. 2013-06-26]. Dostupné z: http://www.gartner.com/technology/reprints.do?id=1-1AWDKK7&ct=120613&st=sb [22] Vojtěch Morávek. Porovnání hypervizorů očima VMware. In: VMware Webinar [online] VMware®, ©2012, vysíláno 6. 12. 2012 [cit. 2012-12-06]. Dostupné z: https://plus.google.com/117303080147384663900/posts (příspěvek z 29. 11. 2012) [23] Jason Fitzpatrick. Best Virtual Machine Application: VirtualBox. In: Lifehacker.com [online] © Gawker Media 2013 [cit. 2013-06-26]. Dostupné z: http://wikibon.org/wiki/v/VMware's_hypervisor_hold_may_be_waning
56
Seznam obrázků Obrázek 1 - Výsledek ankety o nejoblíbenější VM. Zdroj: [23] .............................................. 10 Obrázek 2 – Architektura Hyper-V. Zdroj: [9] ........................................................................ 19 Obrázek 3 – VMware Workstation - správce snapshotů. Zdroj: [12] ...................................... 22 Obrázek 4 – Architektura ESX. Zdroj: [17] ............................................................................. 25 Obrázek 5 – Architektura ESXi. Zdroj: [17] ............................................................................ 25 Obrázek 6 – Transparent Page Sharing. Zdroj: [22] ................................................................ 26 Obrázek 7 – Podíl ostatních hypervizorů provozovaných vedle VMware. Zdroj: [20] ........... 32 Obrázek 8 – Schéma funkce Storage vMotion. Zdroj: [1] ....................................................... 41 Obrázek 9 – Scénář neredundantního zapojení VM klastru. Zdroj: [1] ................................... 43 Obrázek 10 – Příklad redundantního zapojení serverů (zdroj: vlastní) .................................... 44
Seznam tabulek Tabulka 1 – moţnosti Oracle VM. Zdroj: [15] ........................................................................ 11 Tabulka 2 – podporované hostované operační systémy Xen serveru. Zdroj: [16] ................... 13 Tabulka 3 – srovnání moţností edic Xen serveru. Zdroj: [16]................................................. 15 Tabulka 5 – Porovnání hlavních rozdílů architektur ESX a ESXi. Zdroj: vlastní ................... 24 Tabulka 6 – Microsoft patch Tuesdays - vliv patchů OS na virtualizaci. Zdroj: [22].............. 30 Tabulka 7 – Poměr nasazených hypervizorů dle průzkumu Wikibon 2012. Zdroj: [20] ......... 31 Tabulka 8 – Procentuální definice dostupnosti SLA. Zdroj: [14] ............................................ 35
57
