Szinte hetente egyszer belefutok egy olyan kérdésbe, hogy ez vagy az az alkalmazás támogatott-e ilyen vagy olyan hypervisoron. Általában persze el lehet mondani, hogy az SVVP program erre jó választ ad. Néha azonban az ügyfelek hivatalos választ várnak. Márpedig ilyet készíteni – tekintettel a rengeteg hypvisor, az azon futó még több operációs rendszer verzió, és a még annál is több alkalmazás változat miatt – ugyancsak bajos.

Ezen a helyzeten próbál változtatni az SVVP oldalon található Support Policy Wizard. A varázsló segítségével három lépésből hivatalos választ lehet generálni a minket érdekelő alkalmazásról.

1. Adjuk meg az alkalmazásunk nevét és javítócsomag számát. (Pl.. Exchange 2003 SP2)
2. Második lépesben adjuk meg a hypervisor típusát,  vendég operációs rendszer verzióját és architektúráját.
3. Megkapjuk a hivatalos támogatási álláspontot (Supportability statement)

A fenti példában egy Exchange 2003 SP2-vel “játszottam”. A végső álláspont az, hogy az Exchange 2003 csak Virtual Server 2005 R2 alatt támogatott.

A listában szereplő hypervisorok a cikk írásnak pillanatában: Hyper-V (nincs különbség a 2008-as és a 2008 R2-es változat között), Citrix XenServer 5, 5.5; VMware vSherep 4; ESX 3.5 update 2,3,4; Esxi 3.5 update 3,4; SUSE Enterprise 10 SP2; Cisco WAAS Virtual Blades 4.1.

A Microsoft erőssége, hogy plaformot készít. A Hyper-V sem más, mint egy olyan alap, amelyet a partnerek tetszés szerint egészíthetnek ki, és készíthetik el a maguk megoldását.

Pár héttel ezelőtt a VMWorld-ön jelentette be a piacvezető, hogy adatközpontok közötti gépmozgatást fog támogatni működés közben. Szép! A katasztrófatűrés nem egy szoftver, vagy egy dobozos termék. Egy komplett megoldás, amelyet a virtualizáció segíthet, gyorsíthat és egyszerűbbé tehet. A bejelentés konkrétan a VMware, az EMC és a Cisco együttműködéséről (is) szólt.

A Microsoft rendszeres lesajnálást kap, hogy rendre lemarad a technológiai trendekről. Különösen így tartják ezt a virtualizáció területén. Pedig ez a lemaradás sokkal kisebb, mint azt sokan gondolják. Erre egy szép példa a SteelEye megoldásával kombinált Hyper-V fürt, amely adatközpontok között képes virtuális gépeket mozgatni. A SteelEye biztosítja a tároló rendszerek közötti replikációt és a fürtintegrációt, a Hyper-V pedig a gépek működés közbeni mozgatását.

Még egyszer: ez nem egy konkrét megoldás. Csupán egy komponens, amely fontos részét képezheti egy katasztrófa-tűrő rendszer kialakításának. Szükség van itt még a hálózat beállítására, a sávszélesség belövésére, a változás-kezelés helyes lekövetésére és még folytathatnánk.

A demonstráció viszont arra jó, hogy bemutassa: pusztán a hypervisor már nem akadálya a megoldás kialakításának.

Az Hyper-V Server 2008 R2-ről szóló előző cikket elküldtem egy szakmabéli, virtualizációval foglalkozó kollégámnak, mert kíváncsi voltam a véleményére. Elolvasta, megköszönte, majd mosolyogva annyit mondott, hogy “elértétek az ESXi szintjét”. Bevallom, meglepett a válasz. A cikk végső soron arról szólt, hogy a Hyper-V Server 2008 R2 elődjével szemben mindazt a tudást hozza, amit a Hyper-V platform nyújtani tud.

A történet azonban meg is fordítható: vajon milyen képességekkel rendelkezik az ingyenes(*) Hyper-V R2, amely csak lincenc díj ellenében kapható például a VMware-nél? Nem feltétlenül olyan funkciók ezek, amelyeket csak kis- vagy közepes szervezetek igényelnek. Ellenkezőleg: néha nagyon is nagyvállalati követelményekről van szó. Lássuk:

1. Tartománytagság. – A világ legelterjedtebb hálózati operációs rendszer címtára az Active Directory. A tartománytagság előnyeit nem kell ecsetelnem: jobb biztonsági modell, jobb felügyelhetőség, házirendek, távfelügyelet stb. A Hyper-V Server 2008 R2 magától értetődően képes a tartomány-tagságra, sőt, fürtalkotáshoz ez elengedhetetlen a számára. A VMware infrastruktúrában, ha van vCenter, a ESX/ESXi gépeknek nem kell tartománytagoknak lenniük ahhoz, hogy az AD integráció megvalósuljon. A vCenter elvégzi mindazt, ami az integrációhoz szükséges – elsősorban a felhasználói fiókokhoz rendelt szerepek definiálására és ellenőrzésére (authorization) kell gondolni. Ha azonban nincs vCenter, akkor nincs ez a fontos integrációs pont sem.

2. Lemezegység hozzáadása működő virtuális géphez  - A funkció mindkét platformon elérhető, de a Microsoft megoldásában ez a képesség a Hyper-V Server 2008 R2-ben is benne van, nem csak a Windows kiszolgálókban. A VMware futó géphez hardvert csak az Advaced vagy afeletti csomagok esetén enged hozzáadni.

3. Esemény-vezérelt feladat-ütemezés – A VMware Felhasználók Magyarországi Egyesületének ülésén láttam egy olyan képességet, hogy a vSphere rendszer a vCenter segítségével képes arra, hogy bizonyos események bekövetkezésekor adott válaszreakciót – pl. egy script futtatását vagy e-mail elküldését hajtson végre. Az előadó ecsetelte, hogy sokat bővült az események köre, példaként pedig azt hozta fel, hogy a rendszer SMS-t küld neki, ha a kollégái létrehoznak egy új virtuális gépet. A kérdésemre, vajon ez a funkció melyik alrendszer része, azt a választ kaptam, hogy a vCenter-é. Nos, ez a képesség a Hyper-V Server 2008 R2-ben is megvan, azzal a különbséggel, hogy BÁRMILYEN eseményre lehet egyszerű vagy összetett feladatot megfogalmazni, ütemeztetni és végrehajtatni. Ne legyen senkinek kétsége: nem ez a módszer a világ legjobb menedzsmentje. De ha nincs összetett eseménygyűjtő, kezelő rendszerünk, akkor nagyon is jól jön. A Microsoft ezért a képességért nem kér pénzt.

4. 6 magosnál több processzorok támogatása – Olyan nincs is! Valóban, a nyolcmagos CPU-kra 2010 elejéig várni kell, s akkor is csak drágán juthatunk hozzájuk. Eltart még egy darabig, amíg általánosan elterjedtek lesznek. Az első példányokat valószínűleg nagyvállalatok vásárolják majd, nekik meg lesz pénzük. Tényleg? Meglehet. De az is lehet, hogy nem jön jól, ha néhány tucat új processzorhoz egyben új licenceket is vásárolniuk kell.

5. Több mint 256 GB memória támogatása – Ilyen sincs, igaz? A munkám során eddig a legtöbb memória, amit egy gépben láttam, az 128 GB volt, a 256 GB egészen biztosan nagyon ritka. Ma még. Egy bizonyos: valamennyi cég akkor szokott támogatni valamit, ha azt le is tesztelte. Márpedig mind a Microsoft, mind a VMware 1 TB-nyi memóriával ellátott gépek támogatását vállalja. Akkor ez a technológia létezik is. A különbség annyi, hogy ezen dimenzió mentén (vagyis a memória nagysága miatt) a Microsoft nem számol fel licenc költséget, legalábbis a virtualizációs szerepkör esetén nem.

6. Energia-takarékos processzor használat – OK. Ez már nem a szférák világa. (Freudi elszólás :-)). A virtualizáció egyik alapvető hajtóereje, hogy a fizikai kiszolgálók egyenként kihasználatlanok, miközben – feleslegesen – energiát emésztenek fel. A virtualizáció önmagában hatalmas energiamegtakarítást jelent – platformtól függetlenül. A tudomány állása szerint viszont ennél is többet lehet tenni: a virtualizációs gazdagépek fogyasztását is érdemes csökkenteni. A VMware rendelkezik egy remek megoldással, úgy hívják Distributed Power Management. Ennek segítségével valóban szépen meg lehet takarítani további áram-számlát, csupán egy gond van vele: azok az ügyfelek profitálhatnak belőle, akik Enterprise vagy Enterprise plus csomagot birtokolnak. (Arról nem is beszélve, hogy az Enterprise csomag megszűnik.) Ezzel szemben a 2008 R2-es szerver generáció valamennyi tagja, így a Hyper-V Server 2008 R2 is használhatja a beépített “Core parking” funkciót, és mindazokat az egyéb fejlesztéseket, amelyek energiamegtakarítást eredményezhetnek. (Egy szép dolgozat összefoglalja, mi mindent tud ezen a téren a 208 R2-es széria). A core parking segítségével például az operációs rendszer mikro, mili, néha egész másodpercre képes kikapcsolni a processzor egy-egy magját, ha arra éppen nincs szükség. Az saját méréseink szerint egy Windows Server 2008 R2 terheléstől függően 5-20%-kal fogyaszt kevesebbet, mint egy Windows Server 2003 R2. Ha elképzelünk egy Windows Server 2003 R2-t pl. VMware Serverrel, vagy Virtual Server 2005-tel, akkor azokhoz képest 20%-ot lehet nyerni az áramon. No, ezt a 20%-ot a Hyper-V Server 2008-cal ingyen be lehet gyűjteni. (Szándékosan nem az ESXi-t említettem itt, hiszen a mérések Windows Server 2003-as szerverekre vonatkoztak.)

7. Magas rendelkezésre állás virtuális gépek számára – Az IT szakemberek megegyeznek abban, hogy a virtualizáció és a magas rendelkezésre állás kéz a kézben járó megoldások. Hypervisor ide, “bare metal” oda, a hardveren mégiscsak egy operációs rendszer fut (Igen, az ESX és az ESXi is egy operációs rendszer.), Márpedig ezek karbantartása és/vagy váratlan meghibásodása a teljes virtuális gépparkunk leállásával jár, hacsak nem implementálunk valamilyen HA megoldást. A Hyper-V server első verziója nem tartalmazott HA képességeket, sőt, fel sem okosíthattuk erre. A 2008 R2 viszont egy nagyon jól skálázható (a manapság a VMware által divatba hozott kifejezésekkel: “érett” és “nagyvállalati környezetben bizonyított”) komponenst tartalmaz. Mi több, a tárolóalrendszer támogatása esetén földrajzilag elosztott  fürtöket hozhatunk létre – feltéve, ha ezt a tárolóalrendszer gyártója támogatja. Csak megjegyzem, hogy ezzel a Hyper-V Server 2008 R2 már nem csak a vSphere rendszerbe “harap bele”, hanem a VMware Site Recovery Manager megoldásába is. (A VMware HA már a vSphere Standard csomagnak is része, de az ingyenes ESXi önmagában nem képes rá.)

8. Működés közbeni virtuális gépmozgatás – A működés közbeni gépmozgatás a VMware kereskedelmi gépezetének köszönhetően ma a virtualizáció alapköve (pedig nem kellene annak lennie.). Hát jó! Ha alapkő, akkor legyen a platform része. A Hyper-V Server 2008 R2 képes működés közben, leállás nélkül virtuális gépeket egyik kiszolgálóról a másikra mozgatni. Nálunk Live Migration a képesség neve. Sőt! A tétet emelendő, egy blogbejegyzéshez írt megjegyzésében egyik fejlesztőnk azt is elárulta, hogy mivel a R2-es generáció támogatja a CSV-t és a többtelephelyes fürtözést, a live migration működik telephelyek között is – a tároló-alrendszer szállító támogatása esetén. Vagyis: a Microsoft nem kér pénzt azért, hogy telephelyek között mozgasson valaki virtuális gépeket – “Long distance VMotion”. (Azért nem eszik olyan forrón a kását. Ehhez azért rendesen meg kell konfigurálni a hálózatot is. Ettől a tény még tény. Mindehhez a hypervisorért nem kell fizetni.)

9. Multipath I/O harmadik gyártó eszközkezelőivel – Még a Windows Server 2008 debütált egy újraírt MPIO (Multipath IO) alrendszerrel. Ez tulajdonképpen egy keretrendszer hatféle terhelés-elosztási algoritmussal. Használata azonban egyáltalán nem kötelező. Semmi akadálya annak, hogy bármely tároló-gyártó, vagy HBA adapter-gyártó saját MPIO módszert használjon. Eszközkezelőt, amióta világ a világ, szabad volt írni a Windowsra, és az eszközkezelők használatáért a Microsoft sohasem kért pénzt. A vSphere esetén a harmadik gyártó MPIO megoldása csak az Enterprise Plus licenc megvásárlásával érhető el. (Ugyanakkor fontos elmondani, hogy beépített MPIO minden ESX/ESXi verzióban van.)

10. Csoportházirend – Amikor a vSphere “Host Profiles” funkciójáról először olvastam, rögtön rávágtam, hogy “DCM” (Ez a System Center Configuration Manager 2007 egyik új funkciója. Új a 2007-ben, vagyis jelenleg már két és fél éves.) Nem talált. A Host Profiles módszertana is, és hatása is más. Úgy működik, hogy veszünk egy referencia gépet, “lefényképezzük” a konfigurációját, majd az így elkészült sablont ráhúzzuk a többi gépre. Eredmény: teljesen egyforma beállítások. Van aki csak ügyes képességnek gondolja, pedig egy roppant fontos komponens. Nem lehet eléggé hangsúlyozni a fontosságát. A standard  konfiguráció automatizmus általi biztosítása elképesztő mennyiségű munkamegtakarítást jelent, potenciális hibákat zár ki, és bizonyosan megfelel azoknak az ellenőrző szerveknek, amelyek kívülről birizgálnak egy IT csapatot “megfelelés” ürügyén. A Host profiles nyolc alprofilból áll (memory reservation, Storage, Networking, Date & Time, Firewall, Security, Service, Advanced), találtam egy weboldalt, ahol képeket is láthatunk róluk.

Nem kérdés, hogy a Host Profiles értékes dolog, de van egy kis gond vele. A Hyper-V világában nem a DCM a megfelelőja, hanem a csoportházirend. (Még akkor is, ha más módszer alapján működik). A nyolcból minimum öt alprofil-t a házirendek kapásból tudnak. Sejtésem szerint a memory reservation és a Storage alprofil hozta képességek is benne vannak a GPO-ban, de ezt nem merem biztosan mondani, ki kellene próbálni. Szabványos konfigurációt szeretnénk egy Windows rendszeren?Használjunk csoportházirendet. Ingyenesen.

A lista biztos nem teljes lehet folytatni, de azt hiszem talán ennyi is elég, hogy megmutathassam: a Hyper-V Server 2008 R2 sokkal (sokkal-sokkal) több. mint egy ingyenes ESXi.

  ----------------

(*) – Ebben a cikkben tisztáztuk, hogy mit jelent az, hogy ingyenes a Hyper-V Server 2008 R2.

Azt hiszem, hogy kevés olyan terméke van a Microsoftnak, amelyet ennyire nem értenek a piacon, mint az épp most megjelent Hyper-V Server 2008 R2-t. Többnyire legendák terjednek róla, minthogy “kis és középvállalatoknak szánt”, meg a “Windows szerverbe integrált Hyper-V kistestvére”, meg “belépő szintű rendszer” stb. stb. Ezeket tessék gyorsan elfelejteni, a Hyper-V Server valami egészen más dolog…

Eredete és képességei
A Hyper-V Server technológiai értelemben egy olyan Windows Server Enterprise Editon, amely

• Csupán egyetlen szerepkört (Role) tartalmaz – ez a Hyper-V.
• Tartalmaz minden olyan “Feature”-t, vagyis tulajdonságot, amely a Hyper-V-vel kapcsolatba hozható (Fail-over cluster, WoW64, MultipathIO, .Net Framework)
• Kizárólag “Server core” módon telepíthető.
• Nem tartalmaz Windows Server licencet – ezért nem szerepel a nevében a “Windows” szó.

Mivel az Enterprise Edition lényegében csak licencelés szempontjából tér el a Datacenter verziótól, ezért nyugodtan mondhatjuk, hogy egy teljes értékű hypervisorral van dolgunk.  A “kistestvér”, meg “belépő szintű” jelzők elfelejtendők. Elég csak ránézni a Hyper-V Server skálázhatóságára:

• 64 processzormag támogatás, hyperthreading esetén akár 128 végrehajtási szál. Akár 8 magos processzorok is támogatottak.
• 1 TB fizikai memóra támogatás
• Maximálisan 384 futtatható virtuális gép
• Maximálisan 512 virtuális processzor.
• 256 TB lemezterület LUN-onként (!)
• 16 node-os fürt, maximum 1024 virtuális géppel
• Földrajzilag eloszott fürtrendszer támogatása, többfajta fürt-modell
• Clustered Share Volume
• Multipath IO támogatás
• VMQ, Jumbo Frames, TCP Offload, 10 GBitE támogatás
• Pass-through lemez támogatás 256 TB LUN-ig.

A helyi GUI-t leszámítva minden képességében megfelel a Windows szerverbe 2008 R2-be beépített Hyper-V-vel. Ezek közül van néhány meglehetősen érdekes:

• RD-Virtualization szolgáltatás – Ez a szolgáltatás kapcsolatot tart a 2008 R2 szerverben debütáló connection brokerrel és annak kérésére bekapcsolja/felébreszti az igényelt desktop operációs rendszereket. Vagyis a Hyper-V Server a Microsoft VDI megoldások építőköve is lehet, nem kell hozzá a Windows Datacenter változatát használni.
• VHD hozzáadás virtuális géphez működés közben. Egy futó virtuális géphez bármikor hozzáadhatunk még egy vagy több virtuális lemezt.
• Magas rendelkezésre állás (High availability) – a fürtszolgáltatásból ered.
• Quick / Live Migration – szintén a fürtszolgáltatásból ered
• VHD Boot – Érdekes felállás, hogy maga a fizika rendszer is egy VHD-ben található. 2008 R2 képesség.
• Boot from SAN – Már régóta meglévő Windows szerver képesség.
• Bitlocker – akár TPM modullal is támogatott, teljeskörű merevlemez titkosítás .
• Remote Desktop kapcsolat – akárcsak a Windows szervereknél, a Hyper-V-nél is létre lehet hozni két, felügyeleti célokat szolgáló RDP kapcsolatot. Ebből adódóan egy Remote Desktop Gateway-t elé pakolva a világ bármely pontjából 443-as porton kereszül grafikus konzolon át elérhető a rendszer.

Ezen kívül van egy olyan tulajdonsága is, amellyel az “eredeti” hyper-v nem rendelkezik: USB-ről is indítható, vagyis az OEM szerver gyártók merevlemez (pontosabban: system diskhez tartozó merevlemez) nélküli rendszereket is építhetnek a segítségével. Elegendő érvet soroltam fel, hogy a “belépő szintű” jelzőt töröljük? ;-)

Beépített felügyeleti eszközök
Mivel a Hyper-V Server 2008 R2 technikai értelemben egy Windows Server Enterprise “Server Core” telepítéssel, ezért mindazon eszközök használható a menedzselésére, amely a teljes verziónál rendelkezésre áll. Vagyis:

• Server Manager – WinRM segítségével rá lehet kapcsolódni a távoli Hyper-V kiszolgálóra és hajrá. A Server Manager egy kivételével valamennyi, a Hyper-V-hez szükséges MMC beépülő modult képes magába foglalni. Ezek: Hyper-V Management, WSUS, Fail-over cluster management, Group Policy Management, eseménykezelés, Teljesítmény-monitorozás, Eszközkezelés, Lemezkezelés stb. stb.
• Authorization Manager MMC konzol – Ha szerepköröket szeretnénk definiálni a Hyper-V kiszolgálóhoz, korlátozottabb jogokkal, akkor az ebben a modulban végezhető el.
• SCONFIG – A Hyper-V konzolon automatikusan elinduló, karakteres konfigurációs ablak.

Mivel jópár olvasó lehet, aki talán még 2008-as kezelőfelületet sem látott, ezért készítettem egy képsorozatot a Hyper-V kezeléséről. Néhány megjegyzés a képek kapcsán:

1-7 kép: A Hyper-V server 2008 R2 felülete a konzolból.
6-7 kép: az iSCSI és a Multipath IO konfigurálására is van parancssori eszköz, de akinek az bonyolult, annak ott van ez a két panel.
8-16 kép: A Server Manager. Egyetlen ablakban tartalmaz (szinte) mindent, amely a felügyelethez szükséges. Mindezt összecsukható, kinyitható áttekintő panelekkel.
17-19 kép: A Server Managerbe begyógyul a Hyper-V konzol. Ha kell, akár futás közben is felvehetünk újabb VHD-t.
20-22 kép: A Server Manager-ből működik a fail-over cluster modul is. A Hyper-V Server clusteremnek csak az egyik kiszolgálója futott, ezért a jobb oldalon a “Live Migration” menü most épp szürke. Mellesleg a jobb oldalon a menü folyamatosan változik a környezettől függően.
23-25 kép: Az eseménykezelés többszintű. Tetszőleges szűrő készíthető, de van beépített a szerepkörökre vonatkozóan (itt, ugye, csak egy szerepkör van, a hyper-v), és van administrativ események szürő, ami meg megmutatja, milyen hibák vannak ténylegesen a rendszerben. Akinek nagyon részletes napló kell, az igény szerint leáshat.
26-29 kép: A Windows szervereknél megszokott teljesítmény-monitorozás és adatgyűjtés (nálam az RC bugos, a gyűjtéssel kapcsolatos varázslót nem tudtam lefuttatni.)
30-36. kép: Időzített és ütemezett feladatokat lehet végrehajtatni a Hyper-V-vel. A képeken például készítettem egy e-mail riasztást.
37-40. kép: Tűzfalkezelés, több profillal, kimenő/bemenő szabályokkal, előre felvett protokollokkal stb.
41-42. kép: Szolgáltatások távoli kezelése; A Hyper-V kiszolgáló felhasználóinak és felhasználói csoportjainak kezelése.
43-44. kép: Teljeskörű távoli lemezkezelés. Jól látható, hogy a boot disk egy VHD. :-)
45-48. kép: Még néhány áttekintő ábra a Hyper-V MMC modul képességeiről.
49. kép: Server Manager szerrepkör áttekintő tábla. Egy képen a legfrissebb események, a futó szolgáltatások, támogatás, dokumentáció stb.
50. kép: Csoportházirend alkalmazása. Ezzel egészen összetett elvárt konfigurációt lehet létrehozni és kikényszeríteni.
51. kép: Authorization Manager – szerepkörök létrehozása a hyper-v rendszer felügyeletének delegálására.

Egy jó kliens
A képek mellett érdemes megjegyezni, hogy egy Hyper-V Server 2008 R2 mindazon felügyeleti képességek alanya lehet, amelyet egy Active Directory tartomány nyújthat, vagy alanya lehet minden olyan menedzsment eszköznek (Microsoft vagy nem Microsoft), amely Windows szervereket felügyel. Megint néhány példa:

• Ha van egy Windows rendszerek lemezképeit elkészítő és disztributáló eszközünk, akkor azok használhatók a Hyper-V szerverhez, nincs szükség másikra. A Microsoft egyébként rendelkezik ilyennekkel. A lemezképeket készítő eszköz a Microsoft Deployment Toolkit 2010 (ingyenesen letölthető, használható). A disztribúciós eszköz a Windows Deployment Service, minden Windows szerver verzió része.
• Ha van egy Windows rendszerek frissítését elvégző eszköz, akkor az használható a Hyper-V szerverhez, nincs szükség másikra. A Microsoft egyébként rendelkezik ilyennel, Windows Software Update Service a neve, és minden Windows szervernek része. (Mellesleg Magyarország legnépszerűbb szoftverfrissítő eszköze.)
• Ha van egy hardver/szoftver leltárt készítő eszközünk, amely a Windows kiszolgálókat és/vagy desktopokat felméri, akkor az jó lesz a Hyper-V szerverhez is, nincs szükség másikra. A Microsoftnak többféle szoftvere is van erre a feladatra. Ezek közül a Microsoft Assesment and Planning (MAP) 4.0 ingyenes, az MDOP részeként elérhető Asset Inventory Service (AIS) előfizetés jellegű, de nem igényel helyi infrastruktúrát, míg a System Center Configuration Manager (SCCM) teljes értékű nagyvállalati megoldás.
• Ha van egy rendszerüzemeltetést segítő szoftverünk, amellyel Windows szerverek felügyelhetők, akkor az használható a Hyper-V szerverhez, nincs szükség másikra. A Microsoftnak van ilyen, úgy hívják System Center Operations Manager és külön megvásárolható.
• Ha van egy mentő rendszerünk, amely kompatibilis a Windows Server 2008 R2 Hyper-V változatával, az működni fog a Hyper-V Server 2008 R2-vel is. A Microsoftnál készül a DPM v3, amely ezt a képességet tartalmazza majd.
• Ha van Active Directory, akkor használhatók a csoportházirendek. Így egyetlen helyen beállítható elég sok minden. Például:
  • Tűzfalszabályok, akár többféle profillal. Naplózási beállítások.; Helyi felhasználói csoportok tagjai; IPSec házirendek (Domain izoláció); Szolgáltatások automatikus indítása/tiltása.; Eseménynaplók konfigurációja.; Auditálási szabályok.; Fájlok, mappák, registry értékek. Ugyanezek hozzáférési szabályai
  • GPO-val tanusítványok oszthatók
  • GPO-val különböző menedzsment ügynökök telepíthetők (MSI csomagból).

A csoportházirendek jelentőségét nem lehet eléggé hangsúlyozni. Nemcsak beállításról, de kikényszerítésről is szó van. Ehhez hasonló képesség a a VMware-nél a “Host Configuration Controls” vagy Host Profiles az ESX 4 Enterprise Plus – tehát a legdrágább -  csomagban érhető el, és a nyolc sub-profile-ból (memory reservation, Storage, Networking, Date & Time, Firewall, Security, Service, Advanced) a Date & Time, Firewall, Security, Service, Advanced részeket a GPO lefedi, nem beszélve néhány egyéb képességről, mint a szoftver telepítés.

Ára
A Microsoft Hyper-V Server 2008 R2 a Microsoft Download oldaláról ingyenesen letölthető és használható. Pont. Ezzel együtt a fenti funkciók teljeskörű kiaknázásához mégiscsak feltételez két dolgot a gyártó:

1. Van legalább egy  Windows 7 a közelben, amelyre telepíthetjük a Remote Server Administration Tool (RSAT) nevű eszközt. (Ez tartalmazza a Server Manger-t, a Fail-over cluster manager-t, a Hyper-V MMC konzolt, a Group Policy Management Console-t és minden más, szerver felügyeleti MMC modult.) Az RSAT ingyenes, de a Windows 7 nem.

2. Active Directory tartományban dolgozunk. A Hyper-V Server 2008 R2-nek természetesen NEM követelménye az AD, elvan anélkül is. De a fail-over clusterhez (High availability, Quick / Live Migration) szükség van AD-re, vagyis szükség van legalább egy Windows szerverre is. A ma kapható legolcsóbb Windows szerver változat a “Windows Server 2008 R2 Foundation Edition”. Ez már tartalmazza a WDS, a WSUS, a GPO-t, sőt az RSAT is használható rajta.

Azt gondolom, hogy ma vállalatok túlnyomó többsége a fenti kitételeket könnyedén megugorja. Számukra a Hyper-V server nem okoz többlet beszerzési költséget. Akik minden fent funkciót ki szeretnék próbálni, de nincs AD-jük vagy legalább egy Windows 7-esük, akkor nekik a Hyper-V server telepítése előtt ezeket az előfeltételeket be kell szerezni.

Figyelem! Mint minden más informatikai terméknek, a Hyper-V Server 2008 R2-nek is van üzemeltetési, birtoklási költsége: TCO-ja. Egy szoftvert fenntartani pénzbe kerül.

Jelentősége
A virtualizációs piacon ténylegesen két szereplő van, aki súlyánál, méreténél, piaci potenciáljánál fogva jelentős: a Microsoft és a VMware. A Microsoft most egy olyan hypervisort dobott a piacra, amely nemcsak hogy ingyenes, de a konkurrencia termékének számos olyan tulajdonságát is tartalmazza, amely vágyott, de éppen ezért eddig drága volt.

A Hyper-V Server 2008 R2 kétszeresen is naggyá tett szoftver. Egyrészt naggyá tette a Microsoft azzal, hogy az Enterprise változatból hozta létre, így minden, az Enterprise verzióra jellemző tulajdonsággal bír. Másrészt naggyá tette a VMware kereskedelmi gépezete: éveken keresztül a VMotion volt az a szent tehén, amely nélkül “virtualizáció elképzelhetetlen” (Naná! Olyan csak nekik volt.) Ez nem volt igaz, de az ügyfelek elhitték, a szoftver adoptációját pedig felgyorsította. Most mindenki működés közbeni migrációt szeretne. A Microsoft pedig azt ingyen adja. Hiába mondja mostantól a VMware partneri kör, hogy “a live migration már nem minden” – ezt elhitetni már sokkal nehezebb.

Az gondolom, hogy a legkevesebb, amikor azt mondjuk: a Hyper-V Server 2008 R2 figyelemre méltó.

Az első budapesti virtualizációs nap legvégén, a kerekasztal beszélgetés kezdetén, azt a kérdést kaptam nyitásképpen, milyen Linux verziók támogatottak Hyper-V alatt (vagyis: felett). Ezzel rögtön bele is futottunk a LINUX-támogatottság-IC problémakörbe. Nagyjából vázoltam a jelenlegi (akkori) helyzetet, és hamar kibukott, hogy a most (akkor) elérhető IC csak a 2.6.19-es kernel verzióig képes működni, annál újabbak esetén el sem indul. Rögtön jött a kérdés, hogy vajon a Microsoft miért nem GPL alatt fejleszti az integált komponenseket a Linuxhoz. Erre azt válaszoltam, hogy “Nem tudom, pedig logikus lenne.” majd mindjárt hoztam egy példát, nevezetesen a System Center Operations Manager 2007 R2 Cross Platform Extension fejlesztését, ahol a Microsoft aktívan beszállt az OpenPegazus projektbe.

Úgy látszik, nem csak én gondoltam, hogy van értelme egy ilyen lépésnek. A minap a Microsoft bejelentette, hogy kb. 20 000 sornyi forráskódot, a Hyper-V Linux Integrált komponensét (rövidítve: IC),  a GPLv2 licence alá helyezi, az IC eszközmeghajtók pedig a Linux kernel eszközmeghajtó ágában fognak megjelenni. Juhéjj!! A világ persze a szenzációt keresi, és az, hogy “Microsoft és GPLv2”, így együtt, szenzációsnak tűnik. Meg az is, hogy “a Microsoft részt vesz a Linux kernel írásában”, ami meg, ugye, nem egészen pontos fogalmazás.

Azt gondoltam, hogy a magam tudásával összeütök egy kis “Gyakori kérdések" listát, hátha sikerül néhány fehér foltot eltüntetni a témába.

K: Milyen szoftvert tett nyílt forráskódúvá a Microsoft?
V: A Hyper-V-n futó Linuxos virtuális gépekhez tartozó integrált komponensek forrása lett nyílt.

K: Mi az, hogy Hyper-V?
V: A Hyper-V a Microsoft nyers vason futó (angolul. bare metal, vagy type I.) hypervisora. Olyasmi, mint a Xen, vagy a KVM.

K: A teljes Hyper-V nyílt lett?
V: Nem. Távolról szemlélve a Hyper-V három részből áll: Maga a hypervisor, a szülő partíció (mint a Xen-ben a Dom0) komponensei és a gyermek partíciókba (virtuális gépekbe) telepítendő, operációs rendszer függő, integrált komponensek. E három közül az utolsó, abból is a Linuxhoz tartozó lett nyílt.

K: Pontosan mit jelent, hogy integrált komponens, és mit csinál?
V: Leegyszerűsítve olyasmi, mint a Xen-es paravirtualizált driverek.

K: Ok. És nem leegyszerűsítve?
V: Az Integált komponensek is három részre oszthatók:

1. Paravirtualizált driverek, jelenleg:
   - Hálózati csatoló
   - IDE csatoló
   - SCSI csatoló
   - Videó kontroller
   - Egér vezérlő
2. Integrációs szolgáltatások, jelenleg:
   - Hyper-V Heartbeat Service
   - Hyper-V Guest Shutdown Service
   - Hyper-V Data Exchange Service
   - Hyper-V Volume Shadow Copy Requestor
   - Hyper-V Time Synchronization Service
3. VMBus (Virtual Machine Bus)

Ha az IC-t telepítette a rendszergazda, akkor a szülőpartíció és a gyermek-partíciók (virtuális gépek) között egy pont-pont adatkapcsolat jön létre, ez a VMBus. A paravirtualizált driverek ismerik a VMBus-t és ezen keresztül, a Hypervisort tehermentesítve küldenek illetve fogadnak nagy mennyiségű adatot. A vituális gép I/O (és minden egyéb) teljesítménye ugrásszerűen javul, a virtualizációs többletteher pedig jelentősen csökken.

K: A most nyílttá tett Linux IC minden komponenst tartalmaz?
V: Nem. Tartalmazza az VMBus-t és a paravirtualizált drivereket a videó kontroller kivételével.

K. Tehát nincs például a virtuális gép és a gazdagép között időszinkronizáció?
V: Linux IC esetén, a virtuális gép futása során nincs, csak a VM bootolásakor.

K. És nincs Guest Shutdown Service sem?
V: Linux IC esetén nincs. A VM-ben futó operációs rendszerből kell kiadni a leállítási parancsot, a Hyper-V MMC konzoljából vagy SCVMM-ből ez nem működik.

K: A zárt forráskódban ez még megvolt?
V: Nem, ott sem volt. A most nyílttá tett kód volt régen a zárt kód.

K: Mi az, hogy “Hyper-V Volume Shadow Copy Requestor”?
V: Az egy olyan képesség, amelynek a segítségével nyitott állományokat is le lehet menteni. A Hyper-V esetén ez azt jelenti, hogy a virtuális gépek futás közben konzisztens állapotban menthetők. A Linux IC-ben ez a képesség még nincs meg.

K: És a hiányzó részekkel mi lesz? Ezek nem is kerülnek bele a nyílt kódba?
V: A Microsoft elkötelezte magát, hogy továbbfejleszti a kódot és minden, a Windowsos IC-ben megtalálható funkció elérhető lesz a Linux IC-ben is. Épp azért történt a nyílt forráskódúvá tétel, hogy ez a folyamat felgyorsuljon.

K. Tehát az IC-től jobban fog futni majd egy Linuxos gép Hyper-V felett. Van a most megjelent IC-ben vSMP támogatás?
V: Nem, a mostaniban nincs, és az RTM-ben sem lesz. De később belekerül a kódba.

K. Ha egy disztribúcióban benne lesz a Hyper-V IC, akkor azt a disztribúciót támogatja majd a Microsoft?
V: Nem. A “támogatás” kifejezést a Microsoft széles értelmezi, ezért óvatosan bánik vele. A most megjelent Linux IC-vel a következő disztribúciók támogatottak:

· Red Hat Enterprise Linux 5.2 (x86/x64)
· Red Hat Enterprise Linux 5.3 (x86/x64)
· SUSE Linux Enterprise Server 10 SP2 (x86/x64)
· SUSE Linux Enterprise Server 11 (x86/x64): (hamarosan)

Ezen disztribúciók esetén a Microsoft ügyfelek a Linuxos kérdéseiket is továbbíthatják a Microsofthoz, amelyeket az MS gyártói keresztszerződések segítségével megválaszol/megold. A többi disztribúció esetén az lesz a helyzet, hogy a Microsoft a nyílt forráskódú IC-t támogatja majd, a disztribúciókkal kapcsolatos problémákkal viszont a disztribúció gyártójához kell fordulni.

K: Ez a verzió egy végleges változat?
V: Nem, hivatalosan “Release Candidate 2” a megjelölése. A RTM kód szeptember végéig várható.

K: Kér pénzt azért a Microsoft, hogy egy virtuális Linuxos gépet Hyper-V felett futtatok?
V: Nem, nem kér. A Hyper-V ingyenes abban az értelemben, hogy letölthető és használható. Természetesen birtoklási költsége mindennek, így a Hyper-V-nek is van.

K: Én úgy tudtam, hogy a Hyper-V a Windows része, az meg pénzbe kerül.
V: Igen, a Hyper-V a Windows operációs rendszer része. A Microsoft azonban kiadott egy Hyper-V Server változatot is, az viszont nem kerül pénzbe. Ez a változat a virtualizációs képességeket tekintve teljes értékű a Windows Serverbe beépítettel összevetve.

K: Miért éri meg a Microsoftnak nyílt forráskódúvá tenni a Hyper-V IC-t? Megtérnek?
V: A Linux IC fejlesztése lassan halad és a megfelelő eredmény (értsd: sebesség, válaszidő, késleltetés stb) elérése érdekében szorosabb együttműködésre van szükség a a Linux kernel fejlesztőivel. Ebben az esetben a nyílt forráskód és a GPLv2 a megfelelő megoldás. Az várható, hogy hamarabb jelenik a Linux IC, gazdagabb funcionalitással és folyamatosan követni fogja a Linux kernel változásait.

K: Várható, hogy a Microsoft megnyitja a teljes Hyper-V forráskódot?
V: Nem, erről nincs szó.

K: A Microsoft a Linuxszal való erőlteljes verseny miatt kényszerült kinyitni a kódot?
V: Nem. A heterogén környezet támogatása elengedhetetlen követelmény egy platformként működő hypervisor esetén. A Hyper-V jól teljesít a Windows virtualizációja során, de elmarad a többi platform befogadásában, ideértve nem csak a Linux disztribúciókat, de a Unixokat is. A Lemaradás különösen a VMware-rel szemben jelentős. A nyílt forráskód nem csak a Linux adaptációt segíti, de a többi platform felé is segítség lehet. Vagyis a Microsoft ebben az esetben nem a Linuxszal vetélkedik, hanem inkább a VMware-rel.

K: Elképzelhető, hogy a Microsoft egyszer majd visszavonja a kódot?
V: Nem. Szándék sincs rá, és ezt a GPLv2 is kizárja.

K: Ez az első eset, hogy a Microsoft nyílt forráskódot fejleszt?
V: Nem. A Microsoft korábban részt vett több, nyílt forráskódú projektben, így a PHP és a Firefox Windows-on való optimalizálásában, vagy az OpenPegasus programban. Viszont most fordul elő először, hogy a Microft által írt kód a Linux kernel módú komponensei közé kerül.

K: Mi lesz a többi platformmal? Én a FreeBSD-t favorizálom.
V: Egyelőre a Linux disztribúciók integrált komponensekkel való ellátása a cél. A nyílt forráskód és a GPLv2 viszont előre vetítheti, hogy a jövőben más platformokba is bekerüljenek a Hyper-V VM oldali komponensei. Erre vonatkozóan egyelőre nem jelentett be semmit a Microsoft.

K: Tervez-e újabb nyílt forráskódú projektet a Microsoft?
V: Bizonyára, bár erről semmilyen hivatalos információ nincs. Fantáziálni azonban lehet. Ha például valódi VSS támogatást szeretnénk adni a Linuxos virtuális gépekben, akkor szükség van Linux oldalon egy VSS szolgáltatásra is. Ha esetleg ennek megalkotásában (vagy egy már elkezdődött projektben) részt vesz a Microsoft, akkor megnyílik az út például a System Center Data Protection Manager számára, hogy nem csak Windows-okat mentsen. Még egyszer: mindez csak találgatás.

K: Érdekel, hogy mit csinál a Microsoft a nyílt forráskódú világban. Van erről egy tájékoztató oldal?
V: Igen, több is:

• Open Source at Microsoft
• Port 25: The Open Source Community at Microsoft
• Interop Vendor Alliance

Ez egy régi történet, még 2008 februárjában vetette fel Mike DiPetrillo. Az utóbbi napokban Bognár Attila megjegyzéseiben újra előbukkant a téma, és vele egyetértésben úgy gondoltam, megér egy bejegyzést.

A probléma
Az bizonyára tudjátok, hogy a modern virtualizációs megoldások nem emulálják a processzorokat, hanem csak virtualizálják. Ez azt jelenti, hogy a virtuális gépek bár virtuális CPU-t látnak, annak funkcionalitása lényegében mindenkor megegyezik a fizikai processzor funkcionalitásával. No, mármost a processzorgyártók a közöttük folyó verseny miatt újabb és újabb utasításkészlettel vértezték fel a termékeiket, amelyeket viszont nem engedtek megjelenni a konkurenciánál. Így azután egy Intel és egy AMD utasítás-készlete, regisztereinek száma és funkciója ma jelentősen eltér egymástól. Ha egy virtuális gépet átmozgatunk egyik fizikai kiszolgálóról a másikra, a mozgatásnak van egy olyan fázisa, amikor a forrás-gépen megállítjuk a virtuális processzort, az éppen futó utasításokat és regiszter-értékeket pedig a cél-gépre másoljuk, egy új virtuális processzorba. Ha azonban az új gépen nincsenek meg a forrás-gép regiszterei és utasításai, akkor a másolás nem történik meg, a gép futása pedig kárt szenvedhet. Hasonló a helyzet akkor is, azonos gyártótól származik a forrás- és a célprocesszor is, de a forrás-CPU olyan utasítás-készlettel rendelkezik, amely nem található meg a cél-CPU-n.

Megoldás a VMware-től
Hogy az esetleges virtuálisgép-összeomlásokat megakadályozza, a VMware ESX a VMotion művelet elvégzése előtt ellenőrzi a forrás- és a célprocesszort. Ha azt látja, hogy az utasítás-készletek eltérnek egymástól, akkor megakadályozza a művelet végrehajtását. Az ESX 3.5 U2 még ennél is tovább megy és bevezeti az “Enhanced VMotion Compatibility” funkciót. Ennek lényege, hogy egy fürtön belül minden processzorra maszk húzható, vagyis a virtuális gépek elől elrejthetők az új utasítás-készletek. A fürt szinten egységes utasítás-készlet lehetővé teszi, hogy a VMotion műveleteket sikeresen végre lehessen hajtani. Miután a fürt minden tagja j processzort kapott, a maszkot le lehet venni és az utasítás-készlet használatba vehető.

A Hyper-V működése
Mike DiPetrillo rosszul tudta: mind a Virtual Serverben, mind pedig a Hyper-V-ben VAN processzor kompatibilitás ellenőrzés. A mozgatás során először lementjük a virtuális gép állapotát, majd a célgépen, a mentett állapot betöltése előtt, ellenőrizzük, hogy betölthetők-e a lementett virtuális processzor utasításai. Ha nem, akkor nem történik meg az adott gépen a visszaállítás, az erőforrás csoportnak keresnie kell egy kompatibilis processzorral rendelkező node-ot. Ha nincs ilyen, akkor a mozgatás meghiúsul – de a virtuális gép stabilitása nem kerül veszélybe. Mellesleg van mód arra, hogy inkompatibilis processzorok között mozgatni lehessen gépeket. Nem kell nagy csodára gondolni: pusztán arról van szó, hogy a Quick Migration során be lehet állítani, mi legyen az erőforrás kikapcsolt állapotba tételekor a teendő a virtuális géppel (Offline action). Ha az állapotmentés (save state) helyett azt mondjuk, legyen lekapcsolás (Shut down), máris nincs állapot, amit át kellene vinni, tehát a virtuális gép átköltözhet egyik fizikai kiszolgálóról a másikra – egy újraindítással megfűszerezve.

A történet itt véget is érhetne, a a vmware-es kollégák nem nyugodtak és összehoztak egy videót arról, mennyire “nem működik” a processzor kompatibilitás ellenőrzés a Hyper-v esetén. Intel-AMD demót nem lehet bemutatni a fentiek miatt, maradt hát az azonos gyártó de eltérő utasítás-készlet szituáció. Ha valaki megnézi a videót, első az elszörnyülködés. Te jó ég! Hogy még ezt sem tudja! Hogy lehet egy ilyen termékben megbízni! Mielőtt azonban mindenki teljes letargiába esik, érdemes néhány dolgot “észrevenni”:

1. A videón egy desktop alkalmazás az állatorvosi ló. Nem egy levelező kiszolgáló, nem egy adatbázis-kezelő, nem egy ERP rendszer, nem egy fájl- és nyomtatókiszolgáló, nem egy webszerver stb. stb. Miért? Nem lenne hatásosabb, és főleg, életszagúbb, ha ismert szerver-alkalmazást mutattak volna be? Nem lehetséges, hogy azért ezt az alkalmazást használták a videó készítői, mert nem ismernek olyan szerver szoftvert, amely a fenti utasítás-készlet különbség hatására összeomlik?
2. OK, rendben. Lehet, hogy nincs ilyen szerver alkalmazás. Akkor miért nem olyan utasítás-készletet mutatnak, amely releváns? Nem lehet, hogy azért, mert az SSE 4.1-es utasításkészletet az egyetlen, amin be lehet mutatni ezt a hibát?
3. Az SSE 4.1-et tipikusan multi-média alkalmazások használják. Gyakori használata ez a szerver-virtualizáció termékeknek? Aligha.

Persze adódik a kérdés: ez esetben tulajdonképpen lényegtelen az utasítás-készlet ellenőrzés? Nem, nem az. Látni kell, hogy a VMware ESX lassan nyolc éves termék. Ez idő alatt rengeteg processzor került ki a piacra és bizonyára sokkal könnyebb lenne demózni egy 2002-2003 táján kiadott proci és egy mai közötti inkompatibilitást. A VMware-nek, már csak a termék története miatt is, létre kellett hoznia ezt a funkciót.

A Hyper-V, az ESX-hez képest, az újabb processzorokon fut (megköveteli a hardveres virtualizáció támogatást). Bár a processzorok erőteljesen fejlődnek, a fejlődés jelenleg a magokra, és olyan képességekre koncentrál, amelyet a virtualizációs gazdagépek tudnak kiaknázni, az utasítás-készlet bővülés ritkább (de amint láttuk nem szűnt meg teljesen). Ahogy haladunk előre az időben, úgy válik egyre valószínűbbé, hogy újabb utasítás-készletek lesznek elérhetők. Ha ezeket a szerver alkalmazások is kihasználják, akkor majd a Hyper-V is szembesül azokkal a problémákkal, amelyekkel az ESX már korábban találkozott. Ma még ez nincs így.

Vagyis, összefoglalva: a vmware-es kollégák által készített demó egy ténylegesen meglévő, de jelenleg még marginális probléma felnagyítása. A célja pedig, hogy a bizonytalan ügyfeleket elriassza a hyper-v-től. Úgy szokás ezt nevezni, hogy FUD.

Az úgy volt, hogy a munkám során egyre többször kellett az ügyfelek számára, munkatársak számára stb. összehasonlítgatni az ESX VMotion és a Microsoft Quick Migration funkcióit. A dolog egyre sűrűbben előfordult, rengeteg ködös gondolattal találkoztam szóban és írásban, ezért elkerülhetetlenné vált egy cikk megírása. El is kezdtem, de aztán rájöttem, hogy alapok nélkül nincs értelme, így született meg a majd fél éven át írt összehasonlító cikksorozat, melynek megírása során én magam is sokat tanultam. Végül a konkrét Quick Migration – VMotion elemzés a 10. cikkben íródott meg – s milyen furcsa  - ez a cikk egyetlen megjegyzést sem kapott. (Igaz, a HUP-on megtárgyaltuk a téma egy részét). Az érvelést senki nem cáfolta, még csak nem is kritizálta. Ez egyrészt jó, másrészt azt sejtem, hogy a Excel táblába valójában senki nem kukkantott bele.

Én viszont az egyik ügyfélnél a napokban eljátszottam vele, és úgy gondoltam, néhány képet érdemes megosztani ezen a helyen is. Az eredeti tábla adataival egy “Lehetőségelemzést (What..If Analysis)” végeztem. Ilyenkor meg lehet adni, hogy melyek legyenek a változó adatok, illetve melyek legyenek a megjelenítendő eredmény-cellák. Változónak a negyedik sor három oszlop adtam meg (A gépek száma, amelyen az elosztott alkalmazás fut C4:E4), eredmény-cellák pedig a 22. sorban a rendelkezésre állás értékei (C22:E22) Az eredeti cikkben is említettem ezt a módszert, de nem készítettem róla ábrákat. A vizsgálat, ugye, arra vonatkozik, miként csökken a rendelkezésre állás, ha egyre több – nem redundáns – kiszolgáló alkotja. Az ábrán jó látható, hogy a fizikai kiszolgálók esetén jobban csökken, a QM és a VMotion esetén kevésbé, ez utóbbi kettő szinte fedik egymást. Az ábra léptékéből kevésbé látszik, de el kell mondani, hogy a QM és a VMotion vonala nem párhuzamos, a Quick migration esetén a csökkenés nagyobb, a különbség viszont elenyésző. Mit mond az ábra:

1. VMotion és a Quick Migration technológiák hasznosak, mert növelik a szolgáltatások rendelkezésre állását.
2. A három szituáció közül a legjobban a VMotion teljesít.
3. A Quck Migration karakterisztikája nem a fizikai eszközökéhez, hanem a VMotion-höz hasonlatos .
4. Amekkora a különbség a QM és a VMotion vonal között, annyi rendelkezésre állást lehet “nyerni” a technológiai váltással. (Vagyis elenyészőt.)
5. A kiszolgálók számára növekedésével a rendelkezésre állás erősen csökken, ez a QM/VMotion csak lassítja/csökkenti, de nem szünteti meg.

A következő esetet úgy készítettem, hogy a fizikai és a VMotion adatokat változatlanul hagytam, a Quick Migration-nél viszont 2 VM-es környezettől kezdődően egy tartalék VM-et iktattam a rendszerbe, vagyis az egyik rész-szolgáltatást redundássá tettem (pl. egy webszervernek van egy párja és NLB-ben működnek együtt.) Az összehasonlítás persze “igazságtalan”, de a célom az volt, hogy megvizsgálja, hogyan hat a rendszerre, ha a hypervisor szintű fürtözést legalább egy vendég-gép magas rendelkezésre állásával ötvözöm.

Jól látható, hogy, a Quick Migration-ös eset “jól reagál” a plusz VM-re, a szolgáltatás rendelkezésre állása javul, méghozzá sokkal jobban, mintha QM helyett Live Migration-t kezdenénk használni. Tegyük rögtön hozzá, hogy abban az esetben, ha a VMotion-ös rendszernél alkalmaztuk volna ugyanezt, a vonal éppúgy megugrott volna. Az ábrából az alábbi következetés vonható le:

1. A vendég rendszerekben megvalósított magas rendelkezére állás biztosítása hatékonyabb (jobban tartja vízszintesen a vonalat, illetve magasabban fut a vonal), mint akár a Quick Migration, akár a VMotion alkalmazása.
2. Lehet a Quick Migration-ös rendszerekkel magasabb rendelkezésre állást biztosítani, mint a VMotion-ösökkel, ha az utóbbinál a tervezés során elhanyagolják a vendég VM-ekben implementálható magas rendelkezésre állási technológiákat.
3. A Quick Migration és a VMotion nem váltja ki az alkalmazás szinten biztosított magas rendelkezésre állási technológiákat.

A harmadik ábra az előző kiteljesítése. Itt úgy módosítottam az adatokat, hogy a Quick Migration esetében minden VM teljes, alkalmazás szintű rendundanciát élvez. (Ez megint “igazságtalan”, de a vizsgálatnak megint csak “hatás” vizsgálata a célja.)

Az ábrából levonható következtetések:

1. Az alkalmazás szinten megvalósított magas rendelkezésre állásnak nincs párja. (Legalábbis itt nincs :-)). Sokkal jobban tűri a rendszer összetettebbé válását, mint bármely más módszer.
2. Virtualizált környezetben sem szűnik meg az alkalmazás szintű technológiák haszna, sőt, akinek igazán számít a HA, az ezt a módszert alkalmazza.

Összességében elmondható, hogy:

1. Akinek számít a magas rendelkezésre állás, az nem mond le az alkalmazás szintű (VM szintű) eszközök használatáról. Ebben az esetben mindegy, hogy VMotion vagy Quick Migration segíti.
2. Akinek nem számít a magas rendelkezésre állás, annak lényegtelen, hogy a Quick Migration kapcsolat-kiesést okoz.

Miért fontos ezen gimnasztikázni? Azért, mert a VMotion-t ma kötelező elemnek érzik az ügyfelek(*), míg a Quick Migration-t alkalmatlannak tartják arra, amire a Microsoft javasolja. Az is igaz, hogy csupa olyan ügyfél gondolja ezt, aki maga még nem használta. Ahol implementálták, elégedettek vele.

Idáig az eredeti cikk kiegészítése. Ugyanakkor már a HUP-on is leírtam, ezért itt is elmondom, hogy az érvelés ugyan helyes, de van olyan szituáció, amikor nem állja meg a helyét. Idézek magamtól:

“A fenti okfejtésből egy dolog maradt ki: mi van akkor, ha maga a virtuális gép léte és működése a szolgáltatás? Akkor fordul elő ez a helyzet, ha a “vas” szolgáltatója és a tényleges, VM-ek hordozta szolgáltatás gazdája egymástól független, vagy azért mert eleve valamilyen hostolás/Outsource stb. helyzetről van szó, vagy pedig azért, mert olyan irdatlan nagy az IT. Nos ekkor a QM könnyűnek találtatik, nem elégséges.” (2008. dec. 6. - HUP)

Nos, pontosan ezt történt a Microsoft esetében is. A Microsoft IT rendszere az egyik legnagyobb elosztott vállalati IT a világon. Számos szempontból különleges, egyedi. Többek között abban például, hogy a saját vállalati szoftvereinket rendre béta3 körüli állapotukban bevezetjük, majd a bevezetés tapasztalatai alapján szükség szerint módosítunk a szoftveren. “Edd meg, amit főztél!”, angolul dogfooding. Így történt ez a Hyper-V-vel is. A Quick Migration gyenge pontja, ahogy azt decemberben leírtam, rendesen meg is jelent.

A cikk címébe is beleírtam, hogy a témát utoljára feszegetem. A Windows Server 2008 R2 megjelenésével a VMotion megszűnik “megkülönböztető képesség” lenni, megfutjuk a kötelező kört. Lesz persze a vSphere-ben “teljes hibatűrés” – de az más lapra tartozik.

Már “csak” azt kell a fejekben tisztában tenni, hogy mikor használjuk a hypervisor szintű és mikor vendég-OS szintű HA technológiát. Függetlenül a hypervisor gyártójától.

--------------------------------

(*)  A virtualization.info-tól idézve (kiemelés tőlem): “Microsoft will join the party in early 2010, when it will finally have that live migration (available for free as well) that customers perceive as a mandatory feature of every hypervisor.”

Elindult a VDI mizéria Magyarországon, és szokás szerint most sincs egyetlen használható magyar nyelvű összefoglaló sem a működéséről sem a használhatóságáról. No, most majd lesz. A következőkben bemutatom, mi az a VDI, milyen alapötletből származik, mit szeretne megoldani és milyen komponensekből épül fel. Aztán egy másik cikkben meg az elemezzük, milyen tévhitek terjednek a VDI kapcsán, mire jó és mire nem, valamint, hogyan lehet jól és rosszul VDI projektet lebonyolítani.

Mi az, hogy VDI?
A kilencvenes évek közepén az eloszott számítógépes architektúrák kiszorították a nagygépes környezeteket és kezdetét vette a PC-k garázdálkodása a vállalati IT világában. A folyamat megállíthatatlan volt, de az informatikusok részéről kevés ováció fogadta. Az elitista, nagygépes szemlélet mindig is lenézően kezelte a tömeggyártásból kikerülő, “egyszerű architektúrájú”, kevésbé megbízható és kiforratlan, de főleg kontrollálatlan PC-t. A felhasználók azonban kikövetelték maguknak ezeket a gépeket, mert jól, önállóan és hatékonyan tudtak dolgozni. A PC-k a fogyasztói piacról származtak, akik kitalálták, álmukban sem gondolták, hogy egyszer minden irodai asztalon lesz egy személyi számítógép – így a menedzselhetőség a sokadik szempont volt a tervezéskor. A PC-k legfőbb operációs rendszer szállítója, a Microsoft sem tudta igazán pontosan, miben is más egy vállalati számítógép egy otthonitól. Akárhogy is, egyszer csak azt vette észre mindenki, hogy nem csak kikövetelték maguknak a felhasználók a gépeket, de azok üzemszerű működését is elvárták. Hiba esetén javítani vagy cserélni kelletta desktopokat, hardver- és szoftver leltározási feladatok keletkeztek, szoftvertelepítés, frissítés, vírusírtás, felhasználói adatok mentése és helyreállítása – megannyi új, addig alig ismert feladattal szembesült az informatika. Aztán mindez tudományos és/vagy üzleti köntöst is öltött: elkészültek az első TCO számítások. Aha! A gépeknek nem csak beszerzési, hanem életciklus költsége is van.

Ahol felüti a fejét a költség, ott előbb utóbb lesz költségcsökkentés is. Az IT pedig “tudta” hogyan kell költséget csökkenteni: központosítással. A ribillió felszámolásával. Ah, a régi terminálok, ha visszajöhetnétek! Visszajöttek. Persze már nem zölden, kurzorvillogva – arra ki kíváncsi – hanem grafikusan, színesen és szagosan. Egy Citrix nevű cég készített egy kiegészítést a Microsoft új alapokra épült operációs rendszeréhez, az NT-hez, és úgy nevezte: Citrix WinFrame. Ez egy távolról elérhető, grafikus terminál volt. “Terminál” – zene füleinknek. Egy gépet többen használhatnak, az eloszott telepítési és karbantartási feladatoknak vége – az inga újra a centralizált környezet felé lendült. Aztán valahogy mégis megállt ez a lendülés: 1999-ben 0,6% volt a vékony kliensek aránya, 2007-ben pedig alig 1,1%. 8 év alatt 5 tizedszázalék növekedés. Vajon miért?

A terminál szerver jó dolog, csak nem “annyira” jó. Vannak alkalmazások, amelyek remekül futnak rajta – mások viszont nem. Jó dolog, hogy a felhasználókat korlátozhatják a rendszergazdák, csak éppen ez nem mindig célszerű. Kis sávszélesség mellett is működik a rendszer, csak nem minden alkalmazás esetén. Lássuk be, a terminál szerver nagyszerű, amikor üzletileg és technológiai szempontból használható, viszont nagyon sok esetben nem felel meg a követelményeknek. Hmm. Egy ábránddal kevesebb.

Aztán pár éve megmozdult valami. A VMware 2006 áprilisában elindított egy kezdeményezést, a VDI szövetséget (Virtual Desktop Infrastructure Alliance). Ott volt, aki élt és mozgott: Altiris, Appstream, Ardence, Check Point Software Technologies, Citrix, ClearCube Technology, Devon IT, Dunes Technologies, Fujitsu, Fujitsu-Siemens, Hitachi, HP, IBM, Leostream, NComputing, NEC, Platform Computing, Propero, Provision Networks, Route1, Softricity, Sun, Wyse Technology, Zeus Technology. Hardver gyártók, virtualizációs szoftvercégek, vékonykliens specialisták. Ez valami más, mint a Terminál szerver. A VMware nem Citrix, a virtualizáció pedig – mint mindig – most is alapvetően újat ígért.

A VDI nem más, mint szerver kiszolgálókon, hypervisorok segítségével futtatott desktop operációs rendszerek biztosítása a felhasználók számára. Persze csak akkor, ha egyetlen mondatban kell technológiai szempontból korrekt állítást megfogalmazni. Mert a VDI ennél sokkal több. Egy remény, hogy erőfeszítés nélküli lehet desktop üzemeltetést végezni. Egy álom a szabványosságról, egyszerűségről, rugalmasságról. Egy ígéret, hogy a PC korszak véget ér és valami más jön helyette.

VDI alapok
Azt nem tudom, hogy ezek az álmok és remények valóra válnak-e, viszont be tudom mutatni, hogy néz ki – vagy nézhet ki – egy VDI rendszer ma. Nézzük az alapokat. (A megnevezéseket önkényesen magyarra fordítottam, ahol jónak láttam).

Egy VDI infrastruktúra alfája és omegája az a szerverfarm, amely a virtuális gépeket futtatja. Type1-es hypervisor természetesen, a fürthöz megfelelően méretezett közös tároló alrendszer, mindehhez pedig a gazda- és virtuális gépek felügyeletét elvégző menedzsment infrastruktúra. (A VMware esetén például a Virtual Center egyaránt végez változás- és konfiguráció kezelést, valamint monitorozást. A Microsoftnál az előbbire az SCVMM és az SCCM, az utóbbira pedig a SCOM való) Fontos, hogy a fürt egyaránt biztosít magas rendelkezésre állást és dinamikus erőforrás allokálást (DRS), a virtuális gépek pedig gond nélkül költöznek át egyik kiszolgálóról a másikra (VMotion). A nagy gépsűrűség elérése érdekében működik a memória –túlfoglalás. A vékonykliensek valamilyen távoli asztali protokollal érik el a virtuális gépeket (RDP, ICA, ALP stb.) A rendszer máris hordoz előnyöket az PC-kkel szemben:

• A gépek létrehozása sablonból történik, gyors és szabványos.
• A virtuális gépek nem érzékelik a hardver meghibásodását (vagy alig). Magas(abb) rendelkezésre állású desktopokról beszélünk.
• Az asztali protokoll szabályozásával ellenőrizhetjük milyen adatok kerülhetnek ki az adatközpontból.
• A mentési rendszernek csak az adatközpontra kell koncentrálnia, a vékonykliensek állapot nélküliek.
• A szerverek erőforrásai összeadódnak, hatékonyabban használjuk őket, mint a PC-k esetén, ezért a teljes rendszer áramfelvétele kisebb, mint a PC-s rendszeré.

Mindez azonban még messze van az optimálistól. Ha eddig volt 1000 PC-nk, most pedig lesz 1000 virtuális gépünk, akkor a helyzet alig változott. Ráadásul a felhasználóknak “tudniuk kell” hova csatlakoznak, ami nem transzparens és nem is hatékony. Így aztán a rendszert egy kicsit finomítjuk:

A távoli asztali kapcsolatokat egy kapcsolat szétosztó (Connection broker) kezeli, amely sok-sok hasznos képességgel egészíti ki a VDI rendszerünket:

• A beérkező kapcsolatokat megvizsgálja és a felhasználót a saját gépéhez irányítja (már ha van ilyen).
• Az újra felépülő kapcsolatoknál visszairányít a korábbi virtuális géphez.
• A virtuális desktopok lekapcsolhatók vagy mentett állapotba tehetők bizonyos inaktivitás után, mert a kapcsolat kezelő bekapcsoltatja illetve visszatöltetheti ezeket a desktopokat. Ez jelentős memória-megtakarítást eredményezhet, ami viszont kisebb hypervisor farmok létrehozását teszi lehetővé.
• Kétféle desktop kiajánlási sémára nyílik lehetőség. A korábbi dedikált gépek mellett desktop-kötegekkel (desktop pool) is dolgozhatunk. Ilyenkor a felhasználónak nincs dedikált virtuális gépe, hanem a bejelentkezéskor kap egyet a sok közül. A rendszer gondoskodik róla, hogy mindig legyen két-három működő, de üres és kiosztható virtuális gép. Aztán amikor a gépből kilép a felhasználó, az meg is szüntethető.

Ez már így egész szép, de messze nincs vége. A vékonykliensek és a virtuális gépek köztt a kapcsolat valamilyen távoli asztali protokoll (RDP, ICA, ALP stb.) és ha most VDI-ban gondolkodunk, egészen biztosan, de legalábbis nagy valószínűséggel, van már terminál szerver farmunk is. Vajon a kapcsolat szétosztónak csak a virtuális gépekkel kellene törődnie?

Nem, nem így gondolják a VDI szállítók sem, a mai kapcsolat szétosztók egyaránt elirányítanak virtuális desktopokhoz és terminál kiszolgálókhoz is.

Alakul a VDI rendszerünk, de azért itt-ott még “torkavéres”! A kapcsolat szétosztó által lehetővé tett kétféle desktop kiadási modell meg a terminál szerverek képbe kerülése, ha minden így maradna, csak galibát okoz. Ha bármelyik felhasználó bármelyik virtuális gépre bejelentkezhet, hogyan biztosítsuk, hogy minden alkalmazását elérhesse azon a virtuális gépen. Telepítsük fel? Nem biztos, hogy minden alkalmazás feltelepíthető egymás mellé, néha ütik egymást. Legyen több virtuális gépe? Honnan tudja, hogy mikor hova jelentkezzen be? És hova kerüljenek a felhasználó alkalmazásokhoz kötődő beállításai? És a dokumentumai?

Meg kell oldani a virtuális gépek “állapot nélküli”-vé tételét. Az szoftverterítéshez a desktopok állapotát nem megváltoztató alkalmazás-virtualizáció használható. Ezen rendszerek segítségével az egyes alkalmazásokat gombócba csomagolhatjuk (technikai szempontból a gombóc egy fájl), majd igény esetén, amikor a felhasználó elindítja, a gépre sugározzuk (streaming) és elindítjuk. Ez egy fantasztikus megoldás, mert nagyon lecsökkenti a VDI gépek lemez méretét, ráadásul lehetővé teszi, hogy csak egyetlen VM template-et (image) kelljen kialakítani.

Van azonban tovább is: a gépekről le lehet pusztítani a felhasználói beállításokat és a  saját állományokat. Az ábrán ezt a “Felhasználói profilok” kiszolgálóval jeleztem. Van gyártó, ahol a beállítások és adatok együtt kezelendők, van ahol külön, a mi szempontunkból ezt most mindegy. Ha mindezt megtettük, akkor a további képességekkel bővül a VDI megoldásunk:

• A VDI desktopok állapot nélkülivé válnak, menedzselésük drasztikusan egyszerűsödik, tényleg megvalósítható a desktop-kötegek használata.
• A VDI gépek nagyon kevés – akárcsak egyetlen – VM sablonból készülhetnek. Ez a gépek megalkotásának költségét csökkenti drasztikusan.
• Az állapot nélküli gépeknél ún. “vékony létrehozást” (thin provisioning) technológiát vethetünk be. Ennek lényege, hogy a a futó virtulis gépek egy mester- vagy arany- merevlemezből készülnek,  differenciális (más gyártónál linked clone) lemezekkel kiegészítve. Egy példán keresztül ezt könnyebb megérteni. Tegyük fel, hogy virtuális 100 desktop gépet kell üzemben tartanunk. Minden gép kap 20 GB méretű virtuális lemezt. Ha egyszerre mindegyik gép üzemel, akkor a teljes diszk-kapacitás igény kb. 2 TB lesz. Nézzük ezt thin provisioning esetén. Tegyük fel, hogy egyetlen VM sablonból készíthetjük el a virtuális gépeinket. Ez esetben elég egy mester- vagy arany virtuális lemez, a desktopok egyediségét pedig különbség lemezekkel (Differential disk; linked clone) biztosítjuk. Mivel a különbség lemezek mérete sokkal kisebb ( mondjuk 5-6 GB az eredeti 20-hoz képest) ezért a teljes lemezigény is drasztikusan kevesebb lesz, a mi példánkban 20 GB + 100x 6 GB = 620 GB. Az eredeti állapothoz, tehát a 2 TB-hoz képest ez kb. 70%-kal kevesebb kapacitás-igény. Bámulatos.

Ez az utóbbi képesség egyáltalán nem triviális, a VMware View például csak 2008 decembere óta tartalmazza.

A hátradőlőket figyelmeztetnem kell, hogy még mindig nem kész a megoldásunk. Hogyan érjük el mindezt az adatközponton kívül?

Ahhoz, hogy a leendő végfelhasználók külső hálózatból, Internetről, otthonról elérhessék a desktopjaikat, egy átjárót kell a számukra biztosítani. Miért nem elég egy egyszerű tűzfal publikálás? Azért nem, mert nem egy szervert, hanem 1000 szerverecskét kell kiajánlanunk. Ha nincs átjáró, akkor vagy mindegyiket külön IP-címen, vagy egy címen, ámde külön portokon ajánljuk i. Az átájró biztosítja az 1 IP-cím 1-port megoldást, és még olyan feladatokat is el tud látni, mint a vékonykliensek és/vagy a felhasználók azonosítása, a protokoll folyamatos figyelése stb.

No, most már kész? Nem, még mindig nem, mert a belső vékonykliensek még a LAN-on lógnak. Toljuk ki őket távoli telephelyekre. Lógjanak egy kis sávszélességű, és/vagy nagy késleltetésű WAN vonal végén. Így is meglesz a szükséges (de legalábbis: a minimális) felhasználói élmény?

Egyáltalán nem biztos. Akár az RDP, akár az ICA protokoll hamar bajba kerülhet, ha a rendelkezésre álló sávszélesség kevés, vagy hirtelen nagy lesz a volna késleltetése. Ezeket a hatásokat szűrik és tompítják a WAN vonalakat optimalizáló eszközök, nem is beszélve a sávszélesség szabályozásról és az adott kapacitás biztosításáról (QoS). Említsük meg, hogy bizonyos vékonykliensekben van (vagy hamarosan belekerül) olyan chip vagy a firmware-en futó szoftver, amely a távoli asztali protokollt optimalizálja. A VMware a Teradici-vel állt össze a PC-over-Etherner protokollért, a Microsoft a  Callista nevű céget vásárolta fel, a Citrix pedig a Desktop receiver-rel szórja tele a vékonykliens gyártókat.

Most kész? Hát, az attól függ. A fenti architektúra még nem redundáns, márpedig amikor a felhasználónak más eszköze sincs, mint egy vékony vonal, amin bejelentkezhet, akkor a redundáns hálózati útvonal, a több kiszolgálóból álló kapcsolat szétosztó vagy VDI átjáró alapfeltétel. Nem jeleztem, de a WAN optimalizálók egyaránt megtalálhatók a távoli telephelyeken és a központban. Sokan elfelejtik, hogy a vékonyklienseknek szüksége van valamilyen felügyeletre – időnként firmware-t kell frissíteni, protokollt javítani, leltározni stb. stb.

ÉS még valami. Ha minden desktopunkat behoztuk a központba virtuális gépként, akkor igen csak elgondolkodtató, hogy vajon katasztrófa esetén mit csinálunk. Vagyis rendes helyen a fentek x2.

No, ilyen ma egy VDI architektúra. És mit nyerünk vele? Soroltam már jópár hasznos VDI tulajdonságot a képek között, de azért maradt még néhány:

• Minden adat az adatközpontba került. Teljeskörű adatbiztonság megteremtésére nyilik lehetőség (Feltételezzük, hogy a notebook-ok, ha maradtak is, nem tárolnak adatot. Csak arra valók, hogy elérhessék a távoli desktopokat)
• Minden szoftvert kontrollálunk, már ha a felhasználóknak nincsenek rendszergazdai jogaik.
• Csökkentettük az áramszámlánkat, legalábbis a Windows XP desktopokhoz képest. Ha Vista notebookokat használunk, azok megverik a VDI architektúrát a fogyasztás terén.
• Egyszerű kihúz-bedog tevékenységgé redukáltuk a desktop felügyeletet a távoli irodákban. Nem szükség annyi rendszergazdára a végeken. Egy részük viszont karriert csinálhat a központban.

Hogy megéri-e? Arról majd egy másik bejegyzében elmélkedem. Akár meg is érheti.

Végezetül álljon itt egy kis táblázat, hogy a három jelentős VDI szállító hogy áll jelenleg az egyes komponensek tekintetében. Teljes megoldása senkinek sincs. A VMware-nek hiányzik a terminál szerver és jelenleg nincs saját protokollja meg WAN optimalizáló rendszere. A Microsoft a kapcsolat szétosztóját a Windows Server 2008 R2-ben jelenteti meg, és szintén nincs saját WAN optimalizálója. A Citrix jól áll az optimalizálás területén, nála viszont az operáció menedzsment a gyenge terület. Ez a kis táblázat nem akar összehasonlítás lenni, hanem inkább csak eligazítás, hogy hol keressünk egy-egy funkciót egyik vagy másik gyártónál.

Indulhatnak a demókörnyezetek! Kellemes VDI-ozást!

Pár napja olvastam a virtualization.info-n, hogy a VMware a végén még  “infrastructure management company” lesz. Az az igazság, hogy mi, a Microsoftnál, azóta látjuk így, amióta a elindítottuk a magunk DSI stratégiáját, az pedig nem most történt. 2006-ban érkeztem a céghez, és azóta mondjuk, hogy a virtualizáció végső soron rendszerfelügyelet, és hogy nem a hypervisor a legfontosabb – bár persze azért el nem hanyagolható.

Nem véletlen, hogy a Microsoft nem kezdett bele valami teljesen újba (na jó, régebben azért nem volt Virtual Machine Manager), hanem a meglévő System Center termékeit okosította fel. Csak néhány példa:

• A fizikai és virtuális gépek monitorozását az Operations Manager végzi, nem pedig az új SCVMM.
• A virtuális alkalmazások terítését rá lehet bízni az Configuration Manager-re.
• Az Offline patching feladatokat az a komponens végzi, amely az “online” frissítéseket: az SCCM.
• A PRO tippeket – a teljesítmény-paraméterek figyelésével – a Operations Manager adja, viszont az SCVMM hajtja végre.

Nem csak mi gondoljuk, hogy a rendszerfelügyelet a lényeg. Ezt gondolja a VMware is. Olyannyira, hogy az ő termékük – egyelőre – meg sem kerülhető. Azt tudtam, hogy az SCVMM felügyelheti az ESX kiszolgálókat, és azt is tudtam, hogy ehhez VMware Virtual Centerre is szükség van. Most viszont már azt is tudom, hogy miért.

A Microsoft viszont a hypervisor körül másképp alakította ki az API felületet. Bárki készíthet a System Center termékeknél jobb megoldásokat úgy, hogy a System Center családot teljesen elhagyja.  Íme két kis videó, amit a Citrix mérnökei készítettek. A Citrix Essentials (a lényeg, ugye :-)) egy készülő rendszerfelügyeleti megoldás, amely egyaránt képes lesz Hyper-V, XenServer és ESX felügyeletére. Az egyik fantasztikus szolgáltatásuk a StorageLink lesz, érdemes megnézni mit fog tudni, ha elkészül.

Csak néhány finomság: sokszor emlegetett hátránya a hyper-v-nek, hogy mivel nem tartalmaz fürtözött fájlrendszert, ezért minden VM-nek külön LUN-t kell biztosítani, ami meg elviselhetetlen terheket ró a storage-ot felügyelőkre. Itt meg az történt, hogy a StorageLink elkészítette a LUN-okat, ráadásul úgy, hogy a tényleges tevékenységet maga a storage végezte. Hmm. Derék. Aztán, hogy hasítson mint a villám, pass-through lemezként adta oda virtuális gépeknek. És a felület? Tisztára SCVMM érzés.

Van itt egy másik kis videó is, ez is Citrix, a készülő “Dynamic Provisioning Services"-ről. Szervertelepítésindításhasználatbavételegyegérhúzással? Na, itt lehet megnézni:

A mögötte lévő technológia is megér egy misét. A Citrix az Ardence felvásárlásával jutott ehhez az érdekes funkcióhoz. Ahogy a videón is elhangzik, a HP kiszolgáló nem egy helyi lemezről indul, hanem a hálózatról. Az Ardence kifejlesztett egy, az iSCSI-nél hatékonyabb protokoll-t, amely segítségével a hálózaton át felcsatol egy mappát és onnan indul a gép. A történetben az az izgalmas, hogy ezt mind fizikai, mid virtuális gép esetén meg lehet tenni – sőt ez a technológia az alapja a Citrix alkalmazás-streamingnek is.

Szép kis verseny lesz itt jópár éven keresztül, de már nem a hypervisor a lényeg.

Bevallom nem szeretem a blogot hivatkozásjegyzékként használni, de most találtam két olyan fontos anyagot, amelyeket érdemes ajánlani bárkinek, aki desktop virtualizációval foglalkozik.

Brian Madden nevével még akkor ismerkedtem meg, amikor a MAL-ban rátaláltam a flexprofile nevű kis eszközre. Brian eredetileg Citrix és terminal szerver szakértő, és persze ahogy változik a technológia újabb és újabb területekre fokuszál és osztja meg az igencsak megszívlelendő gondolatait.

A múlt héten még a VMware VMWorld Europe 2009 konferenciáján jár, onnan készítette a Brian Madden TV aktuális adását. Azt hiszem, hogy aki rövid áttekintést szeretne arról, hol áll ma a VDI technológia, az nem fog unatkozni, ha megnézi ezt a 25 percet. Ha pedig valaki szeretné megnézni azt, hogy milyen előadást tartott Brian a konferencián, annak javaslom ezt az oldalt. Igaz, hogy a felvétel hét youtube részletből áll, amatőr kamerával készült és sokszor remeg, mégis megéri a 70-75 percet végigülni, mert végre valaki a VDI feltalálójának rendezvényén elmondta mit is ér jelenleg ez a technológia.

Néhány apró megjegyzést leszámítva teljes egészében egyetértek Briannel – és ezt később majd részletesen is kifejtem ez a kis fórumon. Addig jó tévézést. :-)

Lehet, hogy még egy hónap múlva sem írtam volna meg ezt a cikket, ha nincs az ESXi-ről egy hosszú-hosszú fórumszál a hup.hu-n, és nem látok benne annyi félreértést és félremagyarázást. Itt az ideje, hogy a régi ígéretemet beváltsam és összehasonlítsam ezt a két “ingyenes” hypervisort.

VMware ESXi
A VMware ESXi 2007. decemberében jelent meg és kezdetben nem volt ingyenes, 459$ volt a listaára. 2008. júliusában azonban a gyártó úgy döntött, nem kér már pénzt a termékért. Ezt megelőzően megjelent egy spekuláció a virtualization.info-n arról, hogy az ESXi ingyenessége a VMware belépését jelenti a kis- és középvállalati piacra. Ezt nagyjából az egész iparág így könyvelte el, és lényegében ezt ismételtem én is az egyik összehasonlító cikkben, amire persze többen is felkapták a fejüket és javítottak. Ma már világosabb, hogy bár lehet szerepe az ESXi-nek az SMB szegmensben, sokkal inkább az ESX, egy architektúrális változásról beszélhetünk. Nézzük meg, miben különbözik a két szoftver.

           A VMware ESX kiszolgáló architektúrája                                         A VMware ESXi architektúrája

A bal oldali ábrán egy hagyományos ESX-et láthatunk, míg jobb oldalon egy ESXi mutatkozik be. Első ránézésre nem sok különbség látszik, “csupán” annyi, hogy a Service Console eltűnt, és helyett egy “User World” nevű komponens jelent meg. Ebből a szemszögből a változás minimális, mi itt a nagy felhajtás? Nos, a fenti ábrák csalnak, ugyanis nem jelezik, hogy mekkora szoftver-kód van egy-egy kocka mögött. Ezért aztán egy internetről beszerzett, eredeti VMware-es ábrát is mutatok a változás érzékeltetéséhez.

Hoppá! Az Service Console valójában a szállított kód 92%-a! Ráadásul egy Red Hat Enterprise Linux alapú rendszer. Tudjuk, hogy az ESX egy monolitikus hypervisor – vagyis szinte egy teljes operációs rendszer fut hypervisorként – ezért már korábban is megvolt az elvi lehetőség, hogy Console operációs rendszer nélküli változat készüljön(*). Persze az “elvi” lehetőség azért erőd fejlesztést igényelt, ami végül is sikerült – sok, sok előnyt hordozva mind a VMware, mind pedig a felhasználók számára. Ezek többek között:

• A kevesebb kód kevesebb hibát feltételez – ahogy az ábrán is láthatjuk a javítások számának drasztikus csökkenésére lehet számítani.
• A 32 MB-os kód terjesztése/indítása SD kártyáról, USB kulcsról és egyéb, nem merevlemez médiáról is megoldható. A hypervisor “firmware” jelleget ölt.
• Ha nincs harmadik gyártótól származó Service Console, akkor esetleg fizetni sem kell annak a gyártónak.  - Itt a egyik titka, miért lehet ingyenes az ESXi?

Fontos tudni, hogy funkcionális értelemben az ESXi és az ESX lényegében azonos: azonos teljesítmény, skálázhatóság, menedzselhetőség. Az olyan funkciók, képességek, mint a VMware Virtual Machine File System, Virtual SMP, VirtualCenter, VMotion, VMware Distributed Resource Scheduler, VMware High Availability, VMware Update Manager és VMware Consolidated Backup – mind-mind előcsalogathatók az ESxi-ből.

Eddig minden szép és jó. Csakhogy nem véletlen használtam az “előcsalogatható” kifejezést az előbb. Nézzük meg még egyszer, hogyan lehet a VI Enterprise különböző verzióihoz hozzájutni.

Látható, hogy minden változat alapja lehet ESXi, még a teljes értékű csomagnak is. Ingyenesen azonban csak a bal szélső csomag érhető el. A probléma az, hogy a különböző VMware-es ismertetőkben a VMotion, a VMware Distributed Resource Scheduler, a VMware High Availability, a VMware Update Manager és VMware Consolidated Backup mind-mind ESXi képességként van feltüntetve, de az már csak “kisbetűs” rész, hogy a menedzsment funkciókért továbbra is fizetni kell.

Sőt! Sokaknak furcsa lehet, de az ESXi-nek továbbra is van fizetős változata. Ami még ennél is furcsább, a fizetős és ingyenes ESXi között van némi technológiai különbség is – a fizetős javára.

• Az ingyenes ESXi Remote Command Line Interface (RCLI) –e csak olvasható, míg a fizetősé írható/olvasható
• Az ingyenes ESXi SNMP támogatása letiltott, a fizetősé nem.
• Az ingyenes verzió nem AD integrált, mivel az integráció a Virtual Center (vCenter Server)-en keresztül történik, azért pedig már fizetni kell.

Mindezt azért jó látni, mert egy összehasonlítás előtt  mindig tisztázni kell, hogy most a valóban ingyenes ESXi-ről beszélünk, vagy a VI infrastruktúráról – amelynek alapja lehet az ESXi is.

A Microsoft Hyper-V Server
2007. novemberében a barcelonai TechEd konferencián jelentette be a Microsoft a Hyper-V nevet, a termék különböző verzióit, illetve azt, hogy megjelenik egy önálló “Microsoft Hyper-V Server” nevű termék is. Az eredeti tervek szerint – ne feledjük, ekkor még nincs a piacon az ESXi sem – a termék 28$ lett volna. 11 hónappal később, a tényleges megjelenéskor viszont már egészen más volt a piaci helyzet, az ingyenes ESXi után kijöhetett pereskedés nélkül egy ingyenes Hyper-V szerver is. Akárcsak az ESXi-nél, itt is akadt némi félreértés a termék körül. Mivel a Microsoft folyamatosan egy “vékony” hypervisorról beszélt, mindenki egy olyan terméket várt, amelynek mérete az ESXi-vel összemérhető. Ez azonban – a mikrokernel architektúra miatt és a tudomány jelen állása szerint – nem megvalósítható, ezért a piaci csalódás általános volt. Növelték mindezt a Hyper-V – sokak számára érthetetlen - hardver-korlátai, mint például a 32 GB maximális memóra, vagy a fürtbe köthetőség hiánya. No, járjunk utána, mi is valójában a “Microsoft Hyper-V Server”!

Archittektúrális értelemben a Hyper-V Server nem más, mint egy “Windows Server 2008 Standard Edition with Hyper-V” derivátum. A derivátum itt egyszerre jelent öröklést és származást. A Hyper-V server nagyjából az alábbi “műveletekkel” jött létre:

• Végy egy Windows Server 2008 Standard with Hyper-V (x64) szerver kiadást
• Vedd ennek a Server Core telepítését
• Vedd el ebből az összes szerepkört a Hyper-V-t leszámítva
• A telepítéskor tedd fel a Hyper-V-t automatikusan
• Tégy hozzá egy karakteres konfiguráló programot
• Vedd el az összes licence jogot virtuális Windows példány futtatására
• Add ingyen, tedd letölthetővé.

A fenti “műveletek” minden lépése fontos, innen származnak ugyanis a képességek, a korlátok, az ár, sőt még a név is. Lássuk sorban:

Név: A Microsoft Hyper-V Server nem tartalmazza “Windows” nevet, amivel a gyártó azt jelzi, ezzel a termékkel nem jár teljes értékű Windows operációs rendszer futtatási joga. Technológiai értelemben persze a Hyper-V – ahogy azt pár sorral feljebb írtam – egy Windows-származék, de licencelési értelemben nem. (Sokan úgy humorizáltak, hogy nem Windowsless, hanem Windows liceceless)

Ár: Mivel jogi értelemben nem Windows-ról van szó, ezért az árat is másképp határozza meg a gyártó. Ez konkrétan azt jelenti, hogy a termék ingyenes.

Képességek és korlátok: A Microsoft Hyper-V Server – jelen kiadásában – technológiai értelemben mindazt tudja, amit egy Windows Server 2008 Standard with Hyper-V rendszer tud, és éppen ugyanazokkal a korlátokkal rendelkezik. Konkrétan: éppúgy lehet tartománytag, ugyanazok a integrált komponensek használhatók, ugyanúgy működik a Windows Update, telepíthetők rá management agent-et, felügyelhető SCVMM-mel stb. stb. Ugyanakkor nem lehet fürttag – hiszen ahhoz Enterprise Edition-ből kellene származnia, nem kezel 32 GB RAM-nál többet, nem kezel négy processzornál többet stb. stb.

Szemben az ESXi-vel, a Microsoft nem feltétlenül “első lépésnek” tekinti a Hyper-V szervert, hanem meghatározott célterületeken látja hasznosnak. Ezek:

• Teszt és fejlesztés – Világos, nem kerül pénzbe, nem kritikus, hadd menjen!
• Alapszintű szerver konszolidáció – két-három régi gépet, különösebb magas rendelkezésre állási követelmény nélkül is rátehetünk egyetlen hypervisorra.
• Távoli telephelyek (branch office) – ott, ahol soha nem is lesz két szervernél több, milyen jó, ha van egy hypervisor, amellyel pl. a beszerzett vasak számát le lehet felezni.
• Alapszintű VDI – Ez is lehetséges. Képzeljünk el egy hat-nyolcfős irodát, amely a második munkaállomást VM formájában biztosítja a munkatársainak. Jó erre egy Hyper-V Server? Miért ne lenne?

A “továbblépés” nem teljesen triviális, de szintén megoldható. A Hyper-V szerver nem változtatható át Windows szerverré, de a System Center Virtual Machine Manager-nek lehet ügyfele, így aztán a gépeket, igény esetén, át lehet migrálni a nagyobb testvérekre.

Hasonlítgassunk
Az Interneten található összehasonlítások legnagyobb problémája, hogy nem definiálja pontosan, mit mivel hasonlít össze, illetve össze nem hasonlítható dolgok kerülnek egymás mellé. Véleményem szerint kétféle korrekt összevetés tehető: egy, amelyben kizárólag a két ingyenes megoldást tesszük egymás mellé, illetve egy másik, amikor teljes díszbe öltöztetjük őket és a menedzsment környezetet is számításba vesszük. Az első esetben azt nézzük, mit kapunk tényleg ingyen, a másik esetben pedig azt, hogy mit hozhatunk ki – akár pénzt sem sajnálva – a termékekből.

Szemtől szemben, pucéran
Az Interneten kering néhány összehasonlítás, amitől a hajam égnek áll, ezért egy-két megjegyzést fűzök ezekhez is. Az első  méretbeli különbségek emlegetése: 32 MB vs 2,2 GB, következtetés: az ESXi kisebb támadási felülettel rendelkezik és kevesebbet kell patchelni. Nos, először is fenti két szám csak a igényelt lemezterületet fedi, a szükséges memória tekintetében már más a helyzet:, az ESXi 700 MB-ot is elvisz alapjáraton, a Hyper-V üresen kb. 400 MB-nál áll meg. Ha a támadási felületet a memóriában is számításba vesszük, akkor a kép egy kicsit másképp fest(ene).  Másrészt szeretném felhívni a figyelmet egy érdekes adatra az egyik ábrán, néhány bekezdéssel feljebb. Láthattuk, hogy a az ESXi az ESX-hez képest 92%-kal kevesebb kódot tartalmaz. Szép. Az ábrán az is látszik, hogy ez a 92% kód a hibák és sérülékenységek valamivel több, mint 50%-áért felel. Vagyis fordítva: az ESXi-ben maradó kódkészletben – statisztikailag – a hibák és sérülékenyégek valamivel kevesebb, mint 50% ott maradt. Micsoda?? A kód 8%-a felelős a patchek majdnem 50%-áért? Ennyivel rosszabb kódot írna a VMware, mint tette azt a RedHat?

Egyáltalán nem erről van szó, de ahhoz, hogy korrekt válaszokat adjunk, el kell szakadnunk a FUD-ok világától. Az igényelt lemezméret csupán egy a sok paraméter közül, amely meghatározza, hogy egy szoftver biztonságos-e vagy sem. Számít például az architektúra, a kódolás folyamata, és az abba épített biztonsági ellenőrzési ciklusok (a Microsoftnál ez az SDL, a VMware-nél nincs ilyen, vagy nem publikálják), de nem mellékes például egy támadási felület dokumentáció, vagy éppenséggel egy Security Guide. És még egy fontos, dologról megfeledkezik mindenki: bármelyik terméknél, ha betartják azt a szabályt, hogy a management hálózatot (Hyper-V esetén a szülő partíció dedikált hálózati kártyáját) elválasztják a többi hálózattól, akkor kizárólag a vendég gépeken keresztül lehet végrehajtani támadásokat – ezt az utat pedig mindkét szoftver nagyon védi. (Az ábrán egy kompromittált virtuális gépből indítható támadási útvonalak láthatók.)

Summa summarum, a hypervisor méretét, OS függőséget emlegetni  a fenti tényezők elhagyása mellett – meglátásom szerint – puszta félelemkeltés, vagyis FUD. A témába vágóan egyetlen fontos kritikát viszont meg kell fogalmazni a Hyper-V-vel szemben, ez pedig a rendszerindítás helye. Az ESXi-vel ellentétben ugyanis a Hyper-V nem kapható SD kártyán vagy hasonló gyors és kényelmes médián. Úgy gondolom, hogy a firmware jelleg, legalábbis a merevlemeztől való elszakadás, elvárható lenne.

Sokszor írtam már a VMware azon állításáról is, miszerint – szemben a Hyper-V-vel - “megerősített” eszközkezelők dolgoznak az ESXi-ben. Hát nem! Az igazság az, hogy “hypervisorba fordított” eszközkezelők futnak az ESXi-ben. Ez azonban nem jelent nagyobb biztonságot, sőt, összetettebb és heterogén forrású hypervisort jelent (lásd a fenti gondolatmenetet a patchek számáról) – ez a szememben inkább probléma. Ami a Hyper-V-t illet, a Windows Server katalógusban megtalálható eszközökkel kompatibilis, a felhasználható eszközkezelők pedig azonosak a Windows szervereknél megszokottakkal.

Izgalmas dolog a VMFS kérdése. Az ingyenes ESXi nem képes semmiféle fürtben részt venni, így aztán a fürtözött fájlrendszernek sem tudja hasznát venni. A szokásos összehasonlításoknál persze a VMFS-t előnyként említik, pedig inkább hátrány: az NTFS sokkal több operációs rendszerből olvasható és önmagában jobban kezelhető, mint a VMFS.

Általában kihagyják az értékelésből a távoli menedzsment kérdéskörét. És nem csoda: az ESXi ingyenes változatánál ez nem fényes történet. Adott ugye a konzol az alapadatok beállításához, ez rendben is van. Távolról GUI felület az ESXi számára a Virtual Infrastructure Client, rövidítve a VI client. Ez is rendben. De az már nincs rendjén, hogy a VI Client nem képes több ESXi menedzselésére – csak akkor ha veszünk egy Virtual Centert. Upsz! Vagyis ha van 4 telephelyünk, és mindegyiken 1-1 ESXi hypervisor, akkor azt ingyenesen csak 4 VI kliens lesz képes távolról birizgálni, nem pedig egy közös, nyoma sincs az MMC egyszerűségének. (Egy többtucat helyszínből álló branch office virtualizációba már bele sem gondolok.) Hasonlóan hiányozhat a többszörös konfiguráció elkerülése – a Hyper-V viszont lazán magára veszi a csoportházirendeket. És a Hyper-V servernél megoldott az automatikus, sőt a központilag vezérelt hotfix frissítés is, az ESXi a témában megint csak sántikál. (Jegyezzük meg, hogy a frissítések telepítése után az ESXi MINDEN ESETBEN újraindítást igényel, a Hyper-V-nél ez nem így van.) A menedzsment körben a végső döfés az Active Directory integráció: az ESXi-nél ez sem megy, míg a Hyper-V server természetesen aktív tagja lehet egy tartománynak – élvezve annak minden előnyét.

És akkor a táblázat. Elvileg a korábban összegyűjtött mind a 160 paramétert ide lehetne citálni, de ezt nem teszem, viszont felhívom a figyelmet, hogy a teljes összehasonlítás esetén az alábbi táblázat csak kiegészítője és pontosítója az eredeti nagynak. Kiemelem azt, ahol a Hyper-V Server kevesebbet tud, mint a nagyobb testvérei, illetve, ahol az ESXi korlátokba ütközik a menedzsment hiánya miatt. nagyjából láthatóak lesznek a különbségek. Ahol külön nem jelzem, ott a funkcionalitás (pl. SMP támogatás, Guest OS támogatás, belső architektúra, hardware támogatás stb.) megegyezik a teljes képességű verzióval. Még egyszer: most a pucér szoftvereket vetjük össze.

Szemtől szemben teljes harci díszben:
Ahogy korábban írtam, az összehasonlításnak kétféle korrekt módszertana lehet, az első a valóban ingyenes képességek összevetése, a másik pedig a termékek vizsgálata teljes környezetben. Most nézzük a fenti táblázatot, hogyan festi át a VI infrastruktúra. A korábbi sántikáló ESXi szárnyakat kapott és számos képessége kibontakozott (AD integráció, patch management), sőt az oly annyira sztárolt  VMotion, Storage VMotion, DRS is elérhető. Nincs is olyan tulajdonság, amelyben a Hyper-V Server – legalábbis így madártávlatból – felülmúlhatná a nehézsúlyú VI Enterprise-t. Talán csak néhány érdekes sort említek – ahol nem veszít, vagy nem annyira.

Itt van mindjárt a DRS / PRO kérdésköre. Világos, hogy teljes funkcionalitáshoz az kellene, hogy a Hyper-V Server is fürtbe köthető legyen – de az nem lehetséges. Viszont ettől még a PRO működhet. Tegyük fel, hogy van három Hyper-V Serverünk, amelyeken van 2-2-2 virtuális gép, webszerverek, NLB-be kötve. Ha megnő a fürt terhelése és egy újabb virtuális gépet kell üzembe állítani, akkor ezt az SCVMM egy Hyper-V Serveren is végre tudja hajtani, tehát a PRO képességek azon része, amely nem gépmozgatással jár, működhetnek. (Mellesleg ilyen parancsot a DRS nem is tud adni). A 7. sorban ezért írtam a “korlátozott” értéket.

Az sem teljesen igaz, hogy a Hyper-V-ről nem lehet elmozgatni virtuális gépeket. Az SCVMM ismeri a NPIV szabványt, és ha a tároló alrendszer is támogatja, meg a SAN switchek, akkor a LUN-ok áthelyezésével egyik hypervisorról a másikra “tehető át” egy virtuális gép. Végül – és ez  nagyon fontos – a Hyper-V Server is lehet mind SCOM, mind pedig SCVMM ügyfél, vagyis éppúgy menedzselhető, mint a teljes értékű változatok.

Összegzés
Amikor elkezdtem a cikket, fogalmam sem volt, hogy mire fogok kilyukadni, mostanra azonban néhány dolog világosan körvonalazódott a számomra.

• Az ESXi egy architektúrális változás a VMware zászlóshajójánál, ingyenessége másodlagos jelentőségű.
• Az ingyenes ESXi egyáltalán nem jelenti, hogy a kisvállalatok körében valóban jó megoldással rendelkezik a VMware. Számomra úgy tűnik, hogy az ingyenes VMware-es megoldásra az SMB szegmensben továbbra is a VMware Server – csakhogy az meg nem type1-es hypervisor.
• Az ESXi elsősorban továbbra is a  nagyvállalatokat célozza, és a kezdeti ismerkedés után a menedzsment termékek megvásárlására ösztönzi a felhasználókat.
• A Hyper-V képességei lefedik a kis- és középvállalatok igényeinek egy részét, de még itt is hiányozhat a magas rendelkezésre állást biztosító technológia.
• A Hyper-V server nem tud mindent, viszont amit tud, azt jó minőségben – a Windows korábbi fejlesztéseire alapozva tudja.
• A weben található összehasonlítások azért sántítanak, mert nem vizsgálják előzetesen, mi a termék célcsoportja és felhasználási területe.

…a parkőr meg mindenkit haza zavart
  Pár hete már jeleztem, hogy a Hyper-V Server 2008 R2 nem egy Windows Standard derivátum lesz, hanem egy Enterprise Edition, ezért minden, ma még felróható fogyatékossága (fürtözött fájlrendszer, cluster, live migration stb.) egycsapásra megszűnik. Ez a fenti csetepatét kispajtások számháborújává fokozza le: számos, ma még a legdrágábbnak számító képesség (pl. VMotion) ingyenesen lesz elérhető.

A kórházi kirándulásom közben újabb bejelentés érkezett, miszerint a Citrix XenServer – az, amivel az Amazon felépítette a maga cloud-computing szolgáltatását – teljesen ingyen letölthetővé vált. Ami fizetős (Citrix Essentials), az a rendszerfelügyelet.

Mindez lépésre kell, hogy késztesse, sőt üzleti modelljének átalakítására kell, hogy sarkallja a VMware-t. A vSphere legfontosabb újítása az ártáblázata lesz. Meglátjuk.

-------------------------

* – Kevesen tudják, de még az ESXi-nek is van egy konzol-szerű komponense, ezt Tech Support Mode-nak hívják. Alapértelmezetten kikapcsolt, kizárólag hibakereséskor használható.

Pár napja megjelent a VMM 2008-hoz tartozó Management Pack frissített változata amely két nagyon fontos újdonságot tartalmaz. Az első a virtualizációs jelentések, amelyek a RTM verzióból – hogy is fogalmazzak finoman – kimaradtak.

A másik fontos újdonság a PRO tippek bővülése. A PRO a Performance and Resource Optimization rövidítése és ebben a cikkben már írtam róla egy keveset, kifejtve, hogy a nagy potenciál mellett jelenleg még kevés PRO tipp létezik, és néhány ezek közül eléggé hiányzik.

Nos, most megjelent egy olyan PRO tip amely mindenkinek fontos – és amely nem mellesleg megmutatja a PRO erejét is.  Már a korábbi management pack is tartalmazott tippet arra a helyzetre, amikor a fizikai vason elfogyna a processzor-kapacitás vagy éppenséggel a fizikai memória. Ez idáig DRS. Most viszont a PRO-val belenézhetünk a virtuális gépbe (vagyis, pontosabban: a SCOM a virtuális gépet CPU és memória teljesítményparamétereit is figyeli) és ha úgy látja, hogy a virtuális gép rosszul méretezett, akkor javaslatot tesz arra, hogy adjunk több memóriát a VM-nek, netán még egy processzort.

Minek is örülök? Gondoljunk arra, hogy egy virtuális gép kifogy a számára kiosztott memóriából. Mi történik ilyenkor? Elkezdi használni a lapozófájlját – amivel viszont a teljes rendszer válaszidejét rontja le. Vajon milyen könnyű megkeresni, hogy a 15 futó virtuális gépből vajon melyik és milyen módon terheli az IO rendszert azért, mert valójában kevés a memóriája? Nehéz feladat, pedig bármikor előfordulhat. Most már könnyebb lesza PRO tippel.

Igaz, a rendszer nem hárítja el a hibát automatikusan. (Nekünk kell leállítanunk a virtuális gépet, majd bővíteni és újra bekapcsolni), mégis, a legnehezebb pillanatokban adhat egy jó tippet, mitől is nem olyan a rendszerünk válaszideje, mint amilyennek mi szeretnénk tudni.

Azt hiszem, most egy kicsi, de nagyon hasznos dolog született.

Tudom, hogy mindenki Windows 7 lázban ég, ha pedig nem, akkor a Windows Server 2008 R2 bétára veti figyelő szemét. Így aztán a “nagy zsivajban” nehezebb felfedezni, hogy a Hyper-V Servernek, tehát a hyper-v szabadon letölthető és használható verziójának is megjelent az új próbaverziója, ráadásul egy olyan változással, amely hosszú távon gyökeres átalakulást indíthat a virtualizációs piacon.

A Windows Server 2008 R2 legfontosabbnak ítélt újdonsága a virtualizáció területén a “Live migration”, és persze az ehhez tartozó fürtözött fájlrendszer. Kifejtettem már a véleményemet erről, de hát ha egyszer ezt várja a nagyérdemű, akkor ezt várja. A szükséges képességhez Fail-over cluster funkcióra van szükség, és ez, ugye, minimum Enterprise Edition-t vagy Datacenter Edition-t igényel. Ebben nincs változás.

Az is köztudott, hogy a “Microsoft Hyper-V Server” nem tartalmazza a Windows nevet és nem véletlenül: nem jár vele egyetlen operációs rendszer futtatási joga sem. Cserébe ingyenes. Ez ugyanakkor nem jelenti azt, hogy nem lenne közös a kódja a Windows Server 2008-cal. Ellenkezőleg: A Hyper-V server gyakorlatilag egy Server Core változat, amelyből minden más szerepkör hiányzik és csak virtualizációs kiszolgálóként használható.

A Hyper-V Server jelenleg letölthető változata technológiai értelemben a Window Server 2008 Standard derivátuma, és éppen ezért ugyanolyan technikai limitációkkal is rendelkezik, nevezetesen: nem fürtözhet, maximum négy processzort tartalmazhat, legfeljebb 32 GB memóriát kezel stb. stb.

Ezzel szemben a Microsoft Hyper-V Server 2008 R2 Beta 1 már az Enterprise Edition változatból származik, és képességei is azzal egyeznek meg, tehát:

• Maximum 8 processzor (max. 32 core és max. 256 virtuális processzor)
• Maximum 1 TB memóra
• Quick migration támogatás
• Live Migration támogatás (!)
• Fürtözött fájlrendszer
• Stb. stb.

Idézzük fel egy pillanatra a VMware VI licenc struktúráját (árba jobb oldalon). Elemeztük már, hogy a VMotion elérése a VI-ban vagy az Enterprise verzió megvásárlásával lehetséges, vagy a la Carte módon a Foundation csomaghoz vehető meg. (A Standard esetén nem éri meg a VMotion külön megvásárlása, az ESXi pedig VC Agent hiányában nem képes VMotion-re). Egyszerűen fogalmazva a licenc konstrukcióból az olvasható ki, hogy a VMotion egy értékes dolog, amiért sok pénzt lehet elkérni. El is kérik, meg is fizetik.

No, ezt fogja a Microsoft ingyen ajánlani. A pirosan bekeretezett képességekből a Hyper-V server lefedi a “High availability” a “Live VM Migration” és a “Power Management” funkciókat.

Négy megjegyzésem van még:

1. Azt hiszem, a VMware át fogja alakítani a VI licencelését. Megérzés ;-)
2. Tavaly decemberben azt írtam a HUP-on, 2011-ben remélem azt írhatom a Live Migration-ről, hogy bárki tényleg ingyen hozzájuthat. Még két hónap sem kellett, hogy állíthassam: ez belátható időn belül így lesz.
3. Ha valaki azt szeretné írni, hogy még mindig nem biztos a funkció megjelenése, azt szeretném megelőzni: a “Live Migration” Prio 0, vagyis enélkül nincs termék.
4. Mindazt, amit eddig a Quick Migration vs VMotion témában leírtam, továbbra teljes egészében tartom.

Jó próbálgatást.

Boldog új évet mindenkinek!

Ezt a cikket még valamikor az év végén kezdtem el írni, de sokkal tovább tartott, mint arra számítottam. Úgy gondoltam, hogy mivel az alapplatform összehasonlítása befejeződött, mielőtt a menedzsment képességek összehasonlításába fognék, készítek egy részösszefoglalót, de úgy, hogy a táblázat már a jelenlegi állapotokat tükrözze. A cikksorozat indításakor a Hyper-V RTM státuszban, a VMware ESX 3.5 pedig az Update2-vel rendelkezett. Időközben mindkét termék új frissítéseket kapott, ezért a táblázatokat nem egyszerűen összevontam, hanem aktualizáltam is.

Eredetileg 163 szempontot tartalmazott a cikksorozat, de volt néhány, amely ismétlődött, ezeket eltávolítottam. Ugyanakkor volt néhány olyan képesség, amelyet korábban táblázatban nem tüntettem fel. Egy esetben azért, mert a Microsoft Hyper-V server megjelent, de az előzetes várakozásokkal ellentétben beágyazott formában nem kapható és ezt jelezni szerettem volna. Egy másik esetben pedig az történt, hogy az eredeti cikkben elfelejtettem feltüntetni a Storage Vmotion képességeiből fakadó fukciókat, ez viszont igazságtalan lenne a VMware-rel szemben, úgyhogy ebben az összefoglalóban ezt pótoltam. A változásokat (X)-el jelöltem, a táblázat után pedig azt is leírtam, pontosan mi változott az eredeti összehasonlítás óta. Nem mondom, a weben kicsit nehézkes olvasni, de kinyomtatva talán már követhető. A fő táblázat mellett frissítettem a támogatott kliens operációs rendszerek listáját is, a változásokat hasonló módon feltüntetve.

Azt gondolom, hogy egy viszonylag jól használható – habár csak a funkciókra koncentráló – táblázat keletkezett. Négy fontos dologra viszont szeretném felhívni a figyelmet:

1. A táblázat a legnagyobb jóindulat mellett sem teljes. Habár mindent elkövettem, hogy átfogó összehasonlítást tegyek, ez nem jelenti azt, hogy ez minden lehetséges módon meg is történt. Az alapplatformban is lehet olyan képesség akár egyik, akár másik oldalon, amely a bevezetést befolyásolhatja, persze remélem, hogy nem sok ilyen maradt.
2. A funkciók nem súlyozottak, vagyis nem akarom – hisz nem is tudom – eldönteni, vajon egy-egy képesség mennyire fontos. Ezt mindenkinek magának kell megtenni.
3. A táblázat lényegében csak az alapplatform összehasonlítását tartalmazza. Beleharaptunk persze a végén a VMotion-nel meg a DRS-sel és a PRO-val egy kicsit a menedzsmentbe is, de ez mégsem jellemző. Ebben az évben remélem lesz majd alkalmam folytani a cikkeket (esetleg más címmel) és a menedzsment képességeket jobban górcső alá tudjuk venni.
4. Végül – és egyáltalán nem utolsó sorban fontos elmondani, hogy egy kiválasztás során ez a teljes táblázat is csak egy szempont (a műszaki funkcionalitás) a teljes kiválasztási folyamatban. Emellett sok minden más szempont is létezik – ezek egy részét a mérnökök szeretik, másokat nem. A lehető legrövidebb időn belül erre még egy bejegyzésben visszatérek.

Végezetül az eredeti cikkek első sorát szépen lassan frissítem majd, és erre a cikkre fogok hivatkozni. De ez nem megy majd azonnal. Jó olvasgatást.

A változások összefoglalása:

8. – Új sor. Az eredeti cikk megjelenésekor még nem készült el a Microsoft Hyper-V Server és azt sem lehetett tudni, hogy milyen módon lesz elérhető. A kezdeti hírek arról szóltak, hogy 28 dollár lesz az ára. Azóta a termék elkészült, ingyenesen letölthető, de szemben a korábbi várakozásokkal, nem kapható beágyazott formában. A táblázatban tehát feltüntettem, hogy létezik ingyenes alternatíva minkét gyártónál, ugyanakkor megtartottam a beágyazott verzióra vonatkozó 7. sort, mivel az ESXi esetén ilyen formában is elérhető a szoftver.

9. sor. A Microsoft a 956710-es tudásbázis cikkében leírtak szerint kibocsátott egy frissítést, amellyel 16-ról 24 processzormagra növekedett a gazdagépek által támogatott maximális logikai processzorok száma. A sor ennek megfelelően változott, tovűbbá hatása továbbgyűrűzik a 10. és 12. sorra is.

10. sor. Mivel a Hyper-V általá támogatott logikai processzorok száma 24-re emelkedett, az egy processzorra jutó maximális virtuális processzor szám viszont nem változott, továbbra is 8, ezért a maximális virtuális processzorszám egy rendszeren belül 24x8-ra, vagyis 192-re növekedett. Ezzel a korábbi VMware előny elolvadt, a színeket tehát eltüntettem.

11. sor. A VMware ESX 3.5 Update 3 –ban megnövelték az egy processzormagra jutó virtuális proceeszorok számát 8 (VDI esetén 11)-ről  20-ra. A megfelelő Release Note ugyanakkor jelzi, hogy ez csak a támogatás mértékének növekedése, és nem járt a termék további optimalizálásával. Ezt mindenki értékelje úgy, ahogy akarja, én mindenesetre becsületesen bezöldítettem a VMware oldalt és bepirosítottam a Hyper-V-t. Mejegyzem a maximális gazdagép processzormag szám nem változott, tehát ez inkább a 4-8 magos gépek estén használható képesség.

12. sor. Ahogy azt jeleztem, a 956710-es frissítés azt is eredményezte, hogy a gazdagépenként futtatható virtuális gépek száma 192-re nőtt a Hyper-V esetén. Ezzel viszont ebben a sorban fordult a kocka, mivel a VMware továbbra is csak maximálisan 170 virtuális gépet támogat egy kiszolgálón.

22. sor. Az eredeti cikkben van egy táblázat, amely ezt a sort fejtette ki részletesen. A táblázatot nem hoztam át. Egyéb változás nincs.

30.-31. sor. Az eredeti táblázatban a Hyper-V oldalon az szerepelt, hogy egy SCSI kontrollerre 256 SCSI lemezt lehet csatolni. A pontos érték azonban csak 64. Ebből adódóan a következő sorban is negyedelődött a Hyper-V oldalán a korábbi 1024-es szám. A jelenlegi paraméter 256. A színeken nem változtattam, mivel a módosított értékek mellett is a Hyper-V “vezet”.

75. és 77. sor. A hálózati részben bőségesen taglaltam, hogy az iSCSI esetén milyen fontos a Segmentation offloading és a Jumbo Frame-ek támogatása, és hogy bár a kliens oldalon a Hyper-V ezt nem támogatja, a host oldalon igen, és ez igen dícséretes. Aztán amikor a Windows Server 2008 R2-ről megjöttek az első hírek, csodálkozva láttam, hogy ezek a funkciók csak ott működnek majd. Utána jártam a belső fórumokon és a következő eredményre jutottam: a szülő-partíció valóban támogatja, már most, ezeket a funkciókat. Csakhogy a Szülő partíció is virtualizált, és csak virtuális switcheken keresztül éri el a külvilágot. Ezek a switchek ugyanakkor nem támogatják a fenti funkciókat – ergó az egész mégsem működik. Ez nagy égés, és a cikksorozat legnagyobb hibája. A jó szándék mellett is előfordul. Mivel az eredeti cikkeket teljesen át kellene írni, inkább úgyí döntöttem, hogy egy megjegyzést helyezek el bennük, amelyek erre a táblázatra mutatnak.

86. sor. A cikk megírása óta már tudom, hogy a VMware világban a képesség neve “Linked clone”. A ESX VI önmagában nem támogatja a funkciót (az ESX4 már valószínű igen), egyelőre csak a VMware Lab Manager megvásárlásával csalható elő a képesség. Mindezek miatt az érték mardt, ahogy volt, de ezzel a mostani magyarázattal kiegészítve.

94. sor – Az eredeti megjegyzés eltávolítva

104. sor – Az eredeti megjegyzés eltávolítva

135-137. sorok. Beszúrtam három új sort is, mivel az eredeti cikkben elfelejtettem a Storage VMotion-ből fakadó képességeket “táblázatosítani”.

139, 144, 146 – Az eredeti megjegyzések eltávolítva.

A változások összefoglalása:

6. sor – Külön táblázat helyett szürke színnel jelöltem a gyártók által már nem támogatott operációs rendszert.

7. sor – A Microsoft még mindig nem támogatja az RHEL 5 rendszert. Levettem a “hamarosan” jelzőt.

11. sor – Új bejegyzés, a Az ESX 3.5 U3 támogatja a CentOS Linux disztribúciót. A támogatás időintervallumáról nem sikerült információt szereznem.

12. sor – Új bejegyzés, a VMware ESX 3.5 Update3 támogatja a SUSE Linux Enterprise Desktop 10 rendszert is.

15., 18., 20., 21. sor - Külön táblázat helyett szürke színnel jelöltem a gyártók által már nem támogatott operációs rendszert.

22. sor – A Microsoft még mindig nem támogatja az Solaris 10 x86 rendszert. Levettem a “hamarosan” jelzőt.

(Eredetileg a 9-10-11. kör egy cikknek készült. Végül olyan terjedelmes lett, hogy három cikkre bontottam, viszont a kereszthivatkozásokat nem gyomláltam ki belőlük. Érdemes egyszerre elolvasni őket.)

Erőforrás-használat kiegyenlítése
Kevesen tudják, de erőforrás-használat kiegyenlítésre mindkét gyártónak van megoldása. A VMware-nek, ahogy azt a HA-nál már említettük a DRS végzi ezt, a Microsoftnál pedig a felsorolható funkciók egy részét a System Center Virtual Machine Manager (SCVMM)önmagában tartalmazza, más részüket a System Center Operations Manager-rel együtt valósítja meg. A téma persze itt is a kereteket feszegeti, úgyhogy teljes elemzésre nem tudunk sort keríteni. Egyetlen szemszögből nézzük most a témát: virtuális gépek mozgatása.

A VMware Distributed Resource Schedulere igazából két feladatot végez: a megfelelő helyre rakja ki a virtuális gépet amikor az megszületik (Initial placement), majd annak működése során, ha szükségesnek látja, folyamatosan rakosgatja egyik kiszolgálóról a másikra – természetesen a szolgáltatás megszakadása nélkül, VMotion-nel integrálva. Mikor láthatja szükségesnek a DRS a gép mozgatását? Íme a lista:

• CPU túlterhelődés egy adott kiszolgálón. Ha a processzorokból kifogy a szufla, egy virtuális gép áthelyezése egy másik kiszolgálóra kielégítheti a megnövekedett számítási igényt.
• Memória túlfoglalás egy adott kiszolgálón. Ha túl sok gép túl sok memóriát igényel, akkor átkerülhet egy másik node-ra, ahol van elég.
• Együttmozgás. Ha az egyik gép átmozog, mozogjon vele egy (vagy több) másik is.
• Géptaszítás. Ha egy gép egy kiszolgálóra kerül, akkor egy másik vándoroljon el onnan. Van például két webkiszolgálónk NLB-fürtben. Célszerű a két gépet külön állomásokon tartani, hogy összeomlás esetén ne álljon le a szolgáltatás.
• Karbantartás. A szervert le kell üríteni, hogy karbantarthassuk.
• Kiszolgáló kiürítés lekapcsoláshoz. Ha DRS úgy látja, hogy kevesebb kiszolgálóra is össze lehetne sűríteni a virtuális gépeinket, akkor erre javaslatot tesz. Ha megfogadjuk a tanácsát, akkor a felesleges kiszolgálókat ki is kapcsolja. Majd igény szerint bekapcsolja őket Wake-On-Lan-nal.

Nagyon impozáns képességek ezek. Ha azt vesszük, hogy mindez integrált a VMotion-nel, a virtuális gépeknek garantált kapacitásokkal, az erőforrás pool-okkal – no, hát ez ma a virtualizáció csúcsa. Lehet ezt felülmúlni?

Performance and Resource Optimization
Igen, lehet, sőt, bizonyos vonatkozásban már most felülmúlták. A Microsoft is készített egy, a fentihez hasonló rendszert, ami néhány megvalósított képességeiben most is, potenciáljában pedig messze a DRS előtt jár. Miről is van szó?

A DRS egyfajta monitorozó feladatot végez. Látja a kiszolgálók CPU foglaltságát, memória-foglaltságát, továbbá látja a virtuális gépek néhány alapadatát, de a virtuális gépeket úgy kezeli, mintha kis gombócok lennének – nem lát beléjük, nem látja az alkalmazásokat, és a figyelt paraméterek száma nagyon korlátozott.

A System Center Operations Manager (SCOM) ezzel szemben egy teljes felügyeleti rendszer. Nem csak belelát a gépekbe, hanem felismeri és menedzseli az alkalmazásokat, de ami még ennél is fontosabb: látja az összefüggéseket. Nem csak azt képes megállapítani, hogy magas egy gép CPU használata, de azt is tudja, miért. Nagyon használja a fizikai lemezeket egy virtuális gép? Vajon rosszul konfigurált a antivírus szoftver, SQL index-építés folyik, vagy elfogyott a gépnek allokált memória és a lapozófájlt használja? Vajon azzal, hogy átköltöztetjük a gépet egyik kiszolgálóról a másikra, megoldottuk a problémát?

A SCOM a tudását ún. Management Pack-ek formájában tárolja. Belső Microsoft szabvány, hogy minden vállalati termékhez management pack-et is kell készíteni, ami tartalmazza azt, hogy mit kell figyelni az adott terméken, a hibák esetén hogyan kell a problémát elhárítani stb. stb. Az hibák kiküszöbölése új értelmet nyert a virtualizáció megjelenésével. A legújabb Management Pack-ek elláthatók “Performance and Resource Optimization” (PRO) képességgel. A PRO képesség az egyik “ragasztó” a SCOM és a SCVMM között. Tegyük fel, hogy magas egy Hyper-V kiszolgáló CPU terheltsége, és a SCOM úgy látja, egy virtuális gép elköltöztetése megoldaná a problémát. Megoldás? A SCOM ügynök riasztása után a SCOM kiszolgáló “javasolja” az SCVMM-nek a virtuális gép átmozgatását, ami azután a rendszerüzemeltető kézi beavatkozásával, vagy automatikusan végrehajtódik. A történet eddig a DRS másolása. Csakhogy Management Pack-et bárki írhat, néhányan már el is kezdték. A Dell például a management pack segítségével figyel a blade kiszolgálók hőmérsékletét, és ha túlmelegedést észlel, akkor “karbantartási módba” kapcsolja a kiszolgálókat, ami azután Quikc Migration-t eredményez. Nem kell részletezni, hogy ez a proaktivitás hozza az igazi rendelkezésre állást. A DRS ilyet nem tud. Az Emulex a saját HBA kártyáit figyeli és szükség esetén szintén gépmozgatást alkalmaz. A sort végtelenül lehet sorolni, hiszen ezer és egy oka lehet a gépek mozgatásának. A PRO keretrendszer jellege, a hardvert, operációs rendszert és az alkalmazásokat is felölelő monitorozási képessége messze a DRS fölé emeli.

De a Microsoft még ennél is “pimaszabb”. Azt mondja, hogy a PRO még a DRS-t is javíthatja. Ha SCVMM-mel felügyelünk egy ESX rendszert, akkor az ESX-ekre is használhatók a PRO javaslatok. Olyannyira, hogy az ESX kiszolgálók – a licenc megléte esetén – a PRO javaslatokat VMotion-nel végzi el!

Amikor a PRO előnyeit ecseteltem, soha nem felejtem el hangsúlyozni, hogy ma még csak részterületeken és potenciáljában múlja felül a DRS-t. Ennek többféle oka van. A Management Pack-ek itt-ott már elkészültek (lásd Dell, Emulex stb.), és a Microsoft is gyártott már ilyet, de a javaslatok száma még messze nem annyit, amennyi lehetne. A hőmérséklet-figyelés, meg a HBA kártya figyelést az ESX-DRS nem tudja, viszont a gép együttállást-különállás dobozból kicsomagolva is megy a VMWare-nek. A DRS-t mindenki a teljesítmény-optimalizálással köti össze, miközben a legszebb és leghasznosabb tulajdonsága a karbantartási üzemmódba helyezett kiszolgáló automatikus leürítése. (50 VM-nél ez nagy előny!) A SCOM-nál (ma még!) ezt magunknak kellene Management Pack-be varrni, amire nincs mindenkinek erőforrása/pénze/tehetsége/ideje.

Van aztán olyan, amit egyáltalán nem tud még a PRO, mert a hypervisorból hiányzik, ez pedig az elosztott energia-gazdálkodás. Láttuk a DRS képes lekapcsolni a kiszolgálókat, hogy áramot takarítson meg. A Microsoft világban majd csak a Windows Server 2008 R2-vel jön el egy hasonló funkcionalitás, amit Core parking-nak hívnak.

Értékelemzés
”Rendes ember” implementálta a DRS-t, ettől lesz dinamikus az IT – tartja mostanság a közvélekedés. Da vajon tényleg? Vegyük mindkét megoldást egy kalap alá, nevezzük magyarul “erőforrás-használat kiegyenlítés”-nek, és nézzük meg, mi az értéke/haszna egy ilyen dolognak.

Az első érv a funkció mellett, hogy “ha erőforrás szűke” lép fel, akkor azonnal lehet rá reagálni. Igaz. De mikor lép fel erőforrás szűke? Ha rendesen konfiguráljuk a fürtünket, és előre is gondolkodunk kicsit, akkor igen ritkán. Miért is? Képzeljük el, hogy ha tele van egy kiszolgálónk, akkor – mivel a fürt tagjai nagyjából egyenletesen terheltek – azt kell gondolnunk, hogy a fürt többi tagján sincs igazán sok erőforrás. Meg aztán, láthattuk a magas rendelkezésre állás elemzésénél, be kellett állítanunk, hány fürttag kiesését kell elviselnie a teljes rendszernek. Ha számolunk egy nyolctagú fürttel, ami azért nem kicsi magyarországi viszonylatban, akkor az erőforrások legalább 1/8-a szabad kell, hogy legyen (CPU, memória) minden gépen ahhoz, hogy a fürt magas rendelkezésre állású maradhasson. A gyakorlatban ugyanakkor még több a szabad erőforrások aránya, hiszen egy jó rendszerüzemeltető számít arra, hogy újabb és újabb igények sorakoznak majd, ezért beszerzéskor “tartalékokkal” vásárolja a hardvert – okosan és helyesen. Csakhogy ez tovább csökkenti annak valószínűségét, hogy performancia probléma miatt kell vándorolnia a gépeknek.

(Az már egy másik kérdés, hogy mivel a VMware VI Enterprise egy nem olcsó mulatság, a rendszerüzemeltetők néha rászorulnak a “minél kevesebb host” stratégiára. Akár azon az áron is, hogy megszegik a HA előírásokat és sárga vagy piros – tehát a magas rendelkezésre állást nem minden tekintetben teljesítő -  fürtöket üzemeltetnek. Ilyenkor felpörögnek a DRS javaslatok, és valóban hatékonyabb lesz az erőforrások elosztása – csakhogy itt a probléma megoldása mellett magát a problémát is a gyártó generálta.)

Van azután az energia-gazdálkodás, takarékoskodás. Ez nagyon jó funkció, de szerintem csak tényleg nagy (értsd: nagyon nagy!) cégek tudják hasznosítani. Van pl. egy akció a webáruházban, ehhez szükség van egy csomó webszerverre. Az akció elmúltával a virtuális gépek kikapcsolhatók, a fürt pedig összehúzhatja magát. (Nota bene: a PRO lehetővé teszi, hogy a webszerverek terhelésének függvényében újabb és újabb gépeket tudjunk automatikusan csatasorba állítani, értsd provizionálni. Ez is unikum). De komolyan: van 100 szervered 10 hoston. Estére összehúzod magad 7-re? Reggel újra bekapcsoltatod a hármat? Kételkedem. Ami tényleg jó, az az affinitás, anti-affinitás. Ha mozgatok egy gépet, mozogjon egy másik is. És persze a karbantartás-leürítés. Csakhogy ez meg majdnem egészében a tervszerű karbantartáshoz visz vissza minket. Azt meg jól tudjuk kezelni a Quick Migration-nel is.

Összegezve úgy látom, hogy a VMware DRS – önmagában – kevesebb haszonnal bír, mint amekkora a híre.  Egy klasszikus “fájdalompontra adott gyors megoldás”, erejét pedig főleg nagyobb rendszereknél fejti ki. Ettől függetlenül vannak elvitathatatlan előnyei:

• Integráció. A DRS integrált a HA-val, a VMotionnel, a erőforrás-poolokkal – mindennel, ami az ESX világban létezik.
• Egyszerű. A PRO képességei beláthatatlanul tágak. Van, akit ez megnyugtat, és van, akit megijeszt.
• Egyetlen komponens. A PRO a  “Hyper-V- Fail-Over Cluster – SCOM – Management Pack – SCVMM” komponensek együtteséből adódik ki. “Mindent tud” – de méretes is.
• Gyors megoldás. – A “karbantartáskor leürítem a szervert” egy roppant egyszerű dolog. Egy PRO szintű rendszernek meg sem szabadna kottyannia. Mégis, az MS fejlesztői elfelejtenek apró sikereket elérni. Reméljük azért hamarosan ez is eszükbe jut. (Már továbbítottam az ötletet ;-))

Van még érdekes vonatkozása a DRS-nek, illetve a virtuális gépek mozgatásának, és ezt Magyarországon még soha senki nem feszegette. (VMotion-re és Quick Migration-re egyaránt érvényes!) Vajon a változás-kezelés témakörébe tartozik-e a gépek mozgatása? Erre a VMCommunity egy tagja is kíváncsi volt. 2006-os beszélgetés, de azért érdemes elolvasni. Van, aki annak tartja, van, aki nem. Van, aki a DRS által kezdeményezett mozgást nem tartja annak, és van, aki igen. Nem triviális, viszont fontos a VMotion-Quick Migration vitában. Ott, ahol konzervatívabbak és a változás-kezelés hatálya alá utalják ezt a műveletet, szükségszerűen kell valamiféle engedélyezési kört futni. Csak úgy VMotion? Felejtsd el! Elég tervezett karbantartáskor. Innentől tudjuk… Másrészt, legalább egy alapos végiggondolást igényel kockázat oldalról is. Vajon minek kisebb a a kockázata? Maradjon egy gép, vagy menjen? Erre tényleg egyedileg lehet választ adni. Hiszem, hogy a mozgatás kockázata kicsi, de hogy pontosan mekkora, azt azért nem árt tudni.

Hát így áll – szerintem – a világ a virtuális gépek mozgatása terén. Biztos van olyan helyzet, amikor a VMotion fontos, de hogy a mostani virtualizációs telepítések kevesebb, mint 5%-ánál, az biztos, és NEM a méret, hanem az egyedi igény a meghatározó. Mindenhol máshol “nem rossz, ha van”. Akkor a Microsoft minek fejleszt ilyen funkciót a Windows Server 2008 R2-be? Tudatosan kerültem, hogy akár csak egyszer is leírjam “a Microsoftnak is lesz Live Migration” képessége, pedig lesz. Ha valaki ezután fogna egy szövegszerkesztőt, és minden VMotion szót kicserél “Microsoft Live Migration”-re, majd megkérdezné, fenntartom-e, amit leírtam eddig, akkor azt mondanám neki, hogy fenntartom. Látható az előző cikkbeli táblázatból, hogy van helye a Quikc Migration-nek a nap alatt. Akkor miért gondolja az MS másképp?

Ha valaki engem kérdez, miért szükséges a Live Migration a Windows Server 2008 R2-be, akkor két okot tudok felsorolni: egyrészt tényleg lehet olyan helyzet, amikor Live Migration nélkül romlik a szolgáltatás minősége. Tessék csak a Windows Azurra, vagy Live Mesh-re gondolni (meg arra, hogy ezek mekkora méretűek). De technológiai szükség mellett van egy nagyobb: a megoldással kapcsolatos percepció.

“Tévedések vígjátéka”
A Vmotion alkalmas arra, hogy félreértsék. Az értékesítésben résztvevő kereskedők (és nem a mérnökök!) a VMotion kapcsán a “magas rendelkezésre állás” hívószót alkalmazzák szinte mindig. A partner napon bőven volt alkalmam hallgatni VMware mérnökök ezzel kapcsolatos elégedetlenségét, hiszen az ügyfélben keltett túlzott várakozásokat nekik kell aztán hűteni. Minderre még a VMware marketingje is rákontráz: a clustert, a DRS-t és a VMotion-t együtt úgy pozicionálják, hogy “olyan ez, mintha egy nagy szervered lenne, egyben látod a rendelkezésre álló processzor, memória stb. erőforrásokat, és tetszés szerint allokálhatsz belőle.” Ez a mondat nem teljesen hamis, de megint csak túlzott várakozásokat hoz létre. Nekem személyesen is több ügyfélnél kellett tisztáznom azt, hogy a VMware nem képes több fizikai kiszolgálót egyetlen virtuális hosttá tenni. Személy szerint egyébként még a túlzott várakozások közé sorolom azt is, hogy az ügyfelek elkezdik nem használni a belső guest-clustering megoldásokat, mondván, van VMotion és HA. Látható a táblázatból, hogy ez rövidlátó stratégia, technológiai vakság.

“Álmodozások kora”
Van azután egy érzelmi hatás, ami a működő gépek mozgatásával kapcsolatos. Nem véletlenül hoztam a cikk elején, mennyire nagy hatást gyakorolt rám is a VMotion demó. Elhivatott szakmabéli vagyok (még így éjjel fél egykor is :-)) és van egy álmom, hogy az IT jobbá tehető. A VMotion ennek az álomnak a megvalósulását ígéri. Olyan egyszerű és olyan átlátható. A Microsoft megoldása – amely “csak” 99%-ban hozza azt, amit lehetne egyébként, “eladhatatlan”. Az IT szakember arról fantáziál, hogy lehet jobb IT-t csinálni. És VMotion-t vesz, mert ragaszkodik az álmaihoz. Az ár/érték arány számításhoz ugyanis fel kell ébredni, ki kell ábrándulni. És ki szeret kiábrándulni? A Quick Migration nem teljesíti az álmokat és a felsővezetésnek is “eladhatatlan”.

“A hiúság vására”
És végül, de nem utolsó sorban, említsük meg, bizony a hiúság is szerepet játszik VMotion sikerében. “Na ne hogy már mi ne legyünk dinamikusak!” “Na nehogy éppen nekünk ne kelljen ez a fantasztikus dolog! Hiszen mi akkora nagyvállalat vagyunk mint ide Kuskunlacháza!”
Évek óta nem találkoztam olyan informatikussal, aki ne kisírt szemmel panaszkodott volna, mennyire nincs pénz az IT fejlesztésekre. Tudni kell, hogy van Magyarországon, nem egy és nem kettő olyan cég, ahol irdatlan mennyiségű pénzt tapsol el az IT minden évben. Ezen cégek közül nem kevés azt a stratégiát vallja, hogy “minden termékből a legkiválóbbat”, vagyis többnyire a legdrágábbat. Se stratégia, se standardizáció, se platform-építés. Lokális maximum. Helyi kis szemétdombok. A virtualizáció ráadásul – még a borsos VI árak mellett is – extrém hamar megtérülő, kristálytisztán kimutatható költségcsökkenést hozó technológia. Hol van itt akadály? Sehol.

A fenti három attitűd mind-mind alátámasztja, hogy hiába volt technológiailag helyes elhalasztani a Live Migration funkciót a Hyper-V-ből a megjelenés tartása érdekében, marketing szempontból ez katasztrófális következményekkel járt, amit – ismerjük el – ügyesen és szorgalmasan ki is használt a versenytárs (lásd korábbi összehasonlító demó). A helyzet jövőre lezáródni látszik, hacsak a Continuous Replication nem okoz némi turbulenciát… de erről majd máskor.

Táblázat

Előzmények

A VmWare ESX 3.5 és a Microsoft Hyper-V összehasonlítása – bevezetés
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 1. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 2. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 3. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 4. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 5. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 6. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 7. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 8. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 9. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 10. kör

(Eredetileg a 9-10-11. kör egy cikknek készült. Végül olyan terjedelmes lett, hogy három cikkre bontottam, viszont a kereszthivatkozásokat nem gyomláltam ki belőlük. Érdemes egyszerre elolvasni őket.)

Tervezett leállás
Amikor tervezett leállásról beszélünk, akkor valami előre eltervezett tevékenységre gondolunk. Mi most megengedőbbek vagyunk. Minden olyan szituációt, amikor nem lép fel hiba, és a virtuális gépek szabályos módon át akarnak/tudnak költözni egyik kiszolgálóról a másikra, tervezett leállásnak tekintünk. A tervezett leállás célja, hogy kiürítsünk egy szervert, és annak hypervisorát vagy hardverét karbantartsuk. A VMware a fenti célra a VMotion-t, a Microsoft jelenleg a Quick Migration-t használja.

Sokan kétlik, hogy a két megoldás egyáltalán összevethető. Gondolom mindenki láttam már a VMware mérnökök által készített rövid demókat, amely bemutatták a két megoldás közötti különbséget, és demonstrálta, mennyire “alkalmatlan” a Quick Migration vállalati környezetben. Van még ember, aki veszi a bátorságot az összehasonlításra? No, én veszem a bátorságot.

Készítettem egy kis excel táblát, amelyben azt lehet vizsgálni, hogy egy szolgáltatás rendelkezésre állására hogyan hat a virtualizáció. Elgondoltam, hogy a mai vállalati szolgáltatások elosztottan, több számítógép együttműködésével valósulnak meg. Három fő szituációt hasonlítottam össze:

1. Minden gép fizikai kiszolgálón fut .
2. Minden gép virtuális gépben fut Hyper-V környezetben, és működik a Quick Migration.
3. Minden gép virtuális környezetben fut VMware ESX környezetben, a gépek mozgatását pedig a Vmotion szolgáltatás végzi.

A modell átláthatósága érdekében néhány egyszerűsítéshez folyamodtam, ezek a következők:

• Mindegyik szituáció homogén, tehát ugyanolyanok a gépek, csak egyfajta technológiát használunk (vagy csak fizikai, vagy csak Hyper-v, vagy csak ESX)
• Egy gép egyetlen feladatot lát el, amely a teljes szolgáltatásnak egy része. Egygépes környezetben a részfeladat egyenlő a teljessel.
• A gépek méretét átlagosra vettem az itt látható táblázatból. 2 GB RAM-mal rendelkeznek és 2 Gb-es Fibre Channel kapcsolattal. A Quick Migration áttérési időt a táblázatból vettem, és 16 másodperccel számoltam minden alkalommal.
• Nincs nem tervezett leállás.
• A tervezett leállások az alábbi okokból következhetnek be (nem mindegyik létezik minden szituációban, módosítható értékek):
  • Vendég gép alkalmazásának karbantartása (egységesen 20 perc/hónap)
  • Vendéggép operációs rendszerének karbantartása (egységesen 20 perc/hónap)
  • Gazdagép karbantartása (OS és hardver együtt, újraindulással, egységesen 20 perc/hónap)
  • Quick Migration átállási idő (egységesen 16 másodperc)
  • Quick Migration visszaállási idő (egységesen 16 másodperc)
• Ha egy gép bármely okból leáll, akkor a teljes szolgáltatás leáll. Minden gép szükséges a teljes szolgáltatás működéséhez.

Ez utóbbi feltételezés nagyvállalati környezetben nem állja meg a helyét, ezért a gépek száma alatti sorban feltüntettem azon gépek számát, amely redundanciát biztosítanak egy-egy rész szolgáltatásnak. Ez további állásidőket hozott be a modellbe:

• A redundáns rész-szolgáltatás átállási ideje a tartalék kiszolgálóra. Egységesen 16 másodpercben számoltam, ami erős átlag. Vannak olyan szolgáltatások, amelyeknek nincs szükséges átállási időre (pl.: AD, DNS, NLB), másoknak viszont akár több is lehet, mint 16 másodperc (pl: Exchange adatbázis, SQL adatbázis stb.)
• A redundáns rész-szolgáltatás visszaállási ideje a tartalék kiszolgálóra.

Ezek az új állásidő-típusok ugyanakkor megtakarításokat is jelentenek. A redundáns rész-szolgáltatások esetében nem kell számolni a Quick Migration időkkel, sem a vendég operációs rendszerek és szolgáltatások karbantartási idejével. Amikor tehát megadunk egy redundanciát biztosító kiszolgálót, a modell levonja az így elért megtakarításokat.

Négy kiesési idővel számoltam, természetesen ezek sem jelentkeznek mindig minden alkalommal. A négyféle kiesés:

1. A nem redundáns rész-szolgáltatások kiesési ideje. Havonta meg kell frissíteni az alkalmazást és az operációs rendszert.
2. A redundáns rész-szolgáltatások kiesési ideje. Az át- és visszaállási idők.
3. A virtuális gépek mozgatásából fakadó kiesési idők. Ez értelem szerűen csak a Quick Migration esetén jelentkezik.
4. A hardver karbantartásból fakadó kiesési idők. (Beleértve a hypervisor karbantartását is.) Ez meg, természeténél fogva, csak a fizikai környezetben jelenik meg, hiszen mind a hyper-v mid pedig az ESX kiüríti a gazdagépet, tehát annak karbantartása nem jelent szolgáltatás kiesési időt.

A négy kiesési időt összegeztem és megszoroztam 12-vel, hogy az éves kiesést láthassuk. Végül éves rendelkezére állást számoltam, meg azt, hogy a kiesési időt hány százalékkal képes csökkenteni a Quick Migration illetve a Vmotion. Akkor most játsszunk a számokkal.

Az első körben egy olyan szolgáltatásra végeztem számítást, amely egyetlen kiszolgálón fut. Az eredmény az ezen a képen látható. A modell szépen kihozta, hogy a virtualizációval jelentősen csökkenthető az állásidő, mert a hardver karbantartása többé nem befolyásolja a szolgáltatás működését. Az is látható, hogy a legjobban a VMotion teljesített. A Quick Migration elmaradása ugyanakkor minimális, a rendelkezésre állást tekintve ezredszázalékban mérhető, de az állásidő csökkentésének mértékében is 1%-on belül marad.

Egy gép nem gép. Nézzük a következő ábrát, itt 50 kiszolgáló alkot egyetlen nagy szolgáltatást. A fizikai szerverekből álló rendszer rendelkezésre állása 93% könyékére sűllyedt. Érthető: ha nincs magas rendelkezésre állás, akkor a karbantartás mind jobban zavarja a szolgáltatást. A virtualizációs megoldások jobban teljesítettek 95%-ra “érkeztek”, kidomborodik a hypervisorok alkotta fürtök előnye. Ugyanakkor még egy ilyen nagy rendszernél is tized százalékon belüli a Quick Migration hátránya a VMotion-höz képest. Elgondolkodtató, ugye? És az is elgondolkodtató, hogy a virtualizáció sem képes megoldani a szolgáltatás rendelkezésre állásának erodálódását.

És akkor végül a harmadik ábra. Öt kiszolgáló alkotta szolgáltatás. A Quick Migration-nel rendelkező felhasználók előtt két hiptetikus út áll: átnyergelnek VMotion-re, vagy elkezdenek foglalkozni a szolgáltatások magas rendelkezésre állásának biztosításával a virtuális gépeken belül. Ezt mutatja a két kis nyil. A VMotionnal, láttuk, tizedszázalékot lehet nyerni. De akár csak egyetlen rész-szolgáltatás magas rendelkezésre állásúvá konvertálása 13%-kal több állásidő csökkentést tesz lehetővé. Ha viszont nő azoknak a gépeknek a száma, amelyek a virtuális világon belül redundánsak, akkor tovább eliminálódik a Quick-Migration-ből fakadó leállás (A D16-os érték 2 perc nyolc másodperc. Ha nem lenne a plusz egy redundancia, akkor 2:40 lenne)

Levonható következtetések:

1. A virtualizáció azonnali rendelkezésre állás növekedést eredményez, mert megszűnik a hardver karbantartás. A VMotion és Quick Migration itt és csak itt fejti ki jótékony hatását.
2. Bármilyen nagy és összetett alkalmazásról beszélünk, a Quick Migration hátránya a Vmotion-höz képest elenyésző.
3. Ha nem gondoskodunk a virtuális gépeken belüli alkalmazások redundanciájáról, akkor nem tudjuk megakadályozni a teljes szolgáltatásunk rendelkezésre állásának erodálódását. Ennek az ok az, hogy a vendég rendszereket továbbra is karban kell tartani. Amíg a HA-nál még megengedők lehettünk, itt már nem. Súlyos baklövés kihagyni a vendéggépek fürtözését vagy egyéb módon való többszörözését. Ha valakinek a rendelkezésre állás fontos, akkor a VMotion/Quick Migration önmagában nem elég.
4. Ha a VM-eken belül is alkalmazunk valamilyen redundanciát, akkor ugrásszerűen javul a rendelkezésre állás – és még inkább marginalizálódik a VMotion és a Quick Migration közötti különbség!

Van még jó hírem. A modellben “kialakított” szolgáltatások mind azt feltételezik, hogy a kliensek a túloldalon azonnal leszakadnak és a szolgáltatás megszűnik, éppen úgy, ahogy a VMware-es videóból is látszik. A valóság azonban teljesen más. Mi történik, ha egy Exchange kiszolgáló eltűnik egy pillanatra a hálózatról, a szolgáltatás túloldalán pedig Outlook 2003/2007 szoftverek futnak? Mindenki tudja a választ: ha működik a “cache mode exchange” üzemmód, akkor semmi. Az Outlook kliensek tűrik a szakadást, majd alkalmas időben újraépítik a kommunikációs csatornát. És mit történik egy Terminál szolgáltatás esetén? Semmi. Pontosabban az RDP kliens 20 alkalommal megpróbál újracsatlakozni, és amint sikerül, ott lehet folytatni a munkát, ahol abbahagytuk. (Jól látható a videóból, hogy a Hyper-v esetén nem egy valódi Remote Desktop, hanem a Hyper-V Manager VMConnect szolgáltatása szakad meg.) Fájlmásolás? Nézzünk nagyvállalati fájlszolgáltatást! Mi történik, ha egy SCCM disztribúciós pont replikál egy másik disztribúciós pontra és megszakad közöttüka kapcsolat? Semmi. Amikor helyreáll, ott folytatják, ahol abbahagyták. Mi történik ha egy felhasználó a hálózati meghajtóra átirányított, majd kapcsolat néküli üzemmódra felkészített “My Documents” mappájában megnyit egy állományt a szerveren? Vista esetén semmi. A rendszer tűri a kapcsolat nélküli üzemmódot, még az éppen nyíitott állományok esetén is. (Auto-Offline üzemmód.)

Vagy nézzük (a modell által érintett) redundáns szolgáltatásokat! Mi történik, amikor egy tartományvezérlő fél-percre, egy percre kiesik a hálózatból? Semmi, a tartalék DC dolgozik helyette. Mi történik a DNS szolgáltatással? Semmi, a másik DNS működik. Mi történik, ha egy DHCP szerver nincs rajta a hálózaton egy percig. Semmi, a kliensek újrapróbálkoznak egy kicsit később. Mi történik, ha egy NLB-fürtbe tett webszerver egyik állomása épp nincs rajta a hálózaton. Semmi,a többiek végzik a munkájukat. Láthattuk a modellből, hogy a szolgáltatások redundanciája nem oldható meg kizárólag HA-val, VMotion-nel, Quick Migration-nel. Ha viszont szükség van a Guest clustering bármilyen formájára, értelmét veszti a Quick Migration használhatatlanságáról beszélni.

És még néhány apróság:

• a VMotion (és a majdan megjelenő Microsoft-féle Live Migration) használatakor NEM GARANTÁLT az átállás egyik kiszolgálóról a másikra. Ha túl gyorsan változnak a memória-lapok, és nincs elég sávszélesség az átmásolás befejezésére, a VMotion folyamat egy idő után leáll. A sokat szidott Quick Migration viszont végbemegy.
• A VMotion nem működik a Raw Device Mapping “Physical Compatibility” módjával, sem az SCSI2-es (értsd: Windows Server 2003, vagy korábbi) Microsoft Guest clusternél. A Quick Migration számára a Pass-through disk nem akadály (SCSI2-es Guest cluster viszont Hyper-V alatt nincs, ahogy azt már korábban írtam.)

A témát egy nem jelentéktelen ténnyel szeretném zárni. Vajon mennyire fontos a virtuális gépek mozgatása? Mindkét gyártó azt állítja, hogy nagyon fontos. Ehhez képest egyik sem teszi lehetővé, hogy bármely megoldásában a gépmozgatás megjelenjen. A VMware egyenesen csak a legdrágább csomagjának megvásárlóiról gondolja úgy, hogy fontos nekik a tervezett leállás. A Microsoft ehhez képest megengedőbb: nem kell menedzsment szoftver venni a funkcióhoz (néhány képesség feláldozása az ár), és nem kell a legdrágább operációs rendszert megvenni. Ez az ügyfél szempontjából jobb. A tökéletes persze az lenne, ha mindenki, minden verzióban ingyen hozzáférne ezekhez a funkcióhoz. Mert tényleg fontos!

Végső következtetésem, hogy – az általános vélekedés ellenére – a VMotion nem szükséges a tervezett karbantartáshoz. Jó, ha van, jó, ha az ember megengedheti magának, technológiai értelemben jobb, mint a Quick Migration. A Quick Migration viszont, a jelenlegi licencelési konstrukciókat nézve – ár/teljesítményben elpáholja a VMotion-t.

Akkor hol fontos a működő gép kiesés néküli mozgatása egyik kiszolgálóról a másikra? Az dinamikus erőforrás-használat kiegyenlítésnél. Vagyis… majd a következő cikkben meglátjuk.

Megjegyzések

* – A cikkben felsorolt kivételektől eltekintve
** – Ilyen képesség a Hyper-V-ben nincs

Utóirat:
A VMotion-Quick Migration összevetésének van még egy dimenziója, de ezt majd csak a 11. rész végén tárom fel.

Előzmények:
A VmWare ESX 3.5 és a Microsoft Hyper-V összehasonlítása – bevezetés
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 1. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 2. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 3. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 4. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 5. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 6. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 7. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 8. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 9. kör

(Eredetileg a 9-10-11. kör egy cikknek készült. Végül olyan terjedelmes lett, hogy három cikkre bontottam, viszont a kereszthivatkozásokat nem gyomláltam ki belőlük. Érdemes egyszerre elolvasni őket.)

Az előző körben begyűjtöttük, hogy a két gyártó milyen megoldásokat dolgozott ki a virtuális gépek mozgatására a különböző szituációkban. Most összehasonlítjuk ezeket a megoldásokat – mindegyik persze a maga párjával, azonos helyzetben. Mielőtt azonban ezt elkezdenénk, egy fontos figyelmeztetést előre  kell bocsátanom.

A két gyártó teljesen más filózófia mentén csomagolja a termékeit, más kerül pénzbe az egyiknél illetve a másiknál. A korábbi cikkek során csak olyan képességeket hasonlítottunk össze, amely a Windows Server 2008 Hyper-V szerepkör és/vagy az ESX alaprendszer hordozott magában. Ezúttal azonban a górcső alá vett szoftver-komponensek részben vagy egészben nem az alap-platform részei.

A VMware-nél , ha a standard csomagokat tekintjük, a HA képesség a VI Standard, a Vmotion és a ráépülő egyéb megoldások pedig a VI Enterprise részei. Kapható ugyan minden komponens külön is, “a la cart” jelleggel, a weblapon talált árazást figyelembe véve azonban vagy le kell mondanunk a Vmotion-ről, vagy a HA-ról, vagy ha mind a kettőt szeretnénk, de nem szeretnénk Enterprise-t, akkor az drágább, mint az Enterprise licence, az ilyen választásnak meg sok értelme nincs. (Erről még később értekezünk.)

Nem is rágódnék ezen annyit, ha nem helyezné a funkciók többségét egészen máshová a Microsoft. De ezt teszi, és ez megnehezíti az alma-alma jellegű összehasonlítást. A Microsoft is négyféle megoldást kínál, de ezek mind az operációs rendszerre vonatkoznak, nem pedig a menedzsmentre. Az MS táblázatból hiányzik a teljes System Center termékcsalád, miközben a HA és a Quick Migration az operációs rendszer része (Enterprise és Datacenter esetén), nem pedig a menedzsmenté. Mindez azért fontos, mert mind a Quick Migration, mind pedig a magas rendelkezére állás területén a System Center szoftverek kiegészítik az operációs rendszer alapképességeit.

A fentiek figyelembe vételével tehát a következő munkamódszert alkalmaztam:

Vettem az ESX VI Standard illetve Enterprise készletét és azt hasonlítottam össze a Microsoft alap operációs rendszerével. Amikor azonban olyan funkciók is felszínre kerültek, amelyek a Microsoftnál megvannak, de nem az alaptermékben, hanem a System Centerben, akkor azt külön jeleztem. No, akkor most indulhat az értékelés.

Az előző cikkben felsorolt képességeket három szituációban lehet használni.

1. Nem tervezett leállás
2. Tervezett leállás/karbantartás
3. Erőforrás-használat kiegyenlítése

Nem tervezett leállás 
Nem tervezett leállás (pl. váratlan hardver meghibásodás) ellen a VMware platform a HA clustert, a Microsoft pedig a Fail-over clustert vonultatja fel. A VMware világban egy clusternek két funkciója lehet: DRS (Distributed Resource Scheduler) és HA (High Availability). Most csak a HA-t taglaljuk, a DRS-re később térünk ki. Ez azért nem triviális, mert a HA sok tekintetben sziámi a DRS-sel, a dokumentáció is együtt foglalkozik velük. Ugyanakkor a szinergiák ellenére különöböző licencekről, és persze eltérő funkcionaliásról van szó, ami megerősíti a külön tárgyalás lehetőségét.

A legfontosabb tudnivaló, hogy hiba, kiesés, kiszolgáló meghibásodás esetén mindkét termék újraindítja a virtuális gépeket egy másik, virtuális gépeket futtató kiszolgálón, esetünkben fürttagon. Azért fontos ezt hangsúlyozni, mert a HA és a Vmotion képességet sokszor, helytelenül, összemossák, és azt hiszik, a HA is úgy működik, mint a VMotion. Nem! Egészen másképp működik.

Ezen túlmenően a fürtöknek előéletükből eredően vannak előnyeik, illetve hátrányaik, nem könnyű eldönteni, hogy egy megvalósított képesség egyiknél job, vagy a másiknál. Itt van például a virtuális gépek indítási sorrendje. A VMware HA-ban prioritást (Disabled, Low, Medium, High) lehet a VM-ekhez rendelni, értelem szerűen előbb a magas prioritású gépek indulnak, majd a közepesek, végül a maradék. Azért célszerű ez a funkció, mert fürt-túlallokálás esetén biztosítható, hogy a magas prioritásúak mindenképp fussanak. Konkrét – gépről gépre történő beállítás ugyanakkor nincs. A Hyper-V a gépek indítási sorrendjét úgy határozza meg, hogy minden géphez késleltetést rendelhetünk (másodpecben). Ha konzekvensen alkalmazunk értékeket (pl.: 5, 10, 15 másodperces késleltetést használunk csak), akkor hasonló hatást érhetünk el, mintha prioritást használnánk, kényszer azonban nincs, ráadásul a másodpercek súlyként való alkalmazása nem mindig elfogadható. Viszont néha épp ez a megfelelő beállítási rend. Elemzés kérdése, hogy melyik megoldás jobb. Gépről gépre történő beállítás a Microsoft világban sem ismert.

A VMware HA beállítható úgy, hogy akkor is elindítson gépeket, ha a rendelkezésre állási elvárásokat a fürt megszegi. Hogyan lehetséges ez? Úgy, hogy a gépek ugyan elindulnak, de a számukra előzetesen lefoglalt garantált erőforrások nem teljesen érhetők el. Ez adott esetben drasztikus teljesítmény-csökkenést jelenthet – cserébe a szolgáltatások a virtuális gépekben mégis futhatnak. A Microsoft ezt a funkciót az SCVMM-be implementálta, de mivel nincs memória-túlfoglalás, a gépek vagy elindulnak, vagy, ha nem áll rendelkezésre elegendő erőforrás, akkor nem tudnak elindulni. Itt is kérdés, hogy melyik megoldás a jobb. Talán azzal, hogy az ESX konfigurálható “SCVMM-esre”, fordítva viszont nem, egy hajszállal az ESX tűnik jobbnak. Ha SLA előírás létezik teljesítményre is, akkor a két megoldás egyforma: sem így, sem úgy nem teljesül az SLA. Mindkét megoldás ismeri egyébként a fürt-túlfoglalás fogalmát. Ez azt jelenti, látják, képes-e a fürt adott számú fürttag kiesése esetén a magas rendelkezésre állású virtuális gépeket a maradék fürttagokon futtatni. Ha túlvállalást észlelnek, akkor például nem engedélyezik újabb virtuális gépek létrehozását.

Van aztán olyan terület, ahol a Microsoft fürtje érettebb. Mindenek előtt képes kezelni a földrajzilag elosztott fürt fogalmát. Néhány fürttagot elhelyezhetünk egyik, illetve másik telephelyen, és konfigurálás nélkül “evakuálhatjuk” a futó virtuális gépeket – quick migration-nel - az egyik telephelyről a másikra. Mindez persze nem működhet harmadik gyártó storage replikációs mechanizmusa nélkül. Kicsit ironikus, de az  EMC is támogatja a Windows földrajzilag elosztott fürtjét.  A VMware cluster önmagában nem ismeri a multi-site fogalmat, de storage replikációval és “némi” kézi konfigurálással azért itt is megoldható a katasztrófa telephely kialakítása. Van a VMware-nek még egy Site-Recovery megoldása is, de ez nem része a “Virtual Infrastructure” csomagnak, hanem külön megvásárolható szoftver. Most nem tárgyaljuk.

Fura volt olvasni, de a VMware HA-ban van egy “lyuk”. Normál esetben 15 másodperc szükséges ahhoz, hogy a fürt tagjai észleljék egy node kiesését (Windows esetén ez 5 másodperc, mindkét megoldásnál állítható a paraméter). A VMware “Resource Management Guide” 79-80. oldalán olvasható  “Host Network Isolation” rész taglalja azt, mi történik ebben a 15 másodpercben. A leírás szerint, ha a 12. másodpercben az elszakadt fürt lekapcsolja a gépeket, de a 14. másodpercben visszajön a kapcsolat, akkor a gépek lekapcsolva maradnak és nem indulnak újra. Nem mondom, hogy nagyon gyakori szituáció, de nem szép, az biztos. A Microsoft a “split brain” helyzetet konzekvensen kezeli, a szavazásos módszer korszerűbb, mint a VMware féle primary-secondary node konfiguráció, ráadásul többféle cluster modell is felépíthető. A fürttagok kiesését figyelő heartbeat forgalom időtúllépési értékei éppen azért finomhangolhatók, hogy a fürt alkalmazkodhasson az egyes modellekhez, például a földrajzilag elosztott konfigurációhoz.

A nem tervezett leállást kivédő szoftverek elemzésével kapcsolatban egy fontos dolgot nem árt tudni, bármelyik megoldást is válasszuk. A rendszer felkészíthető arra, hogy a virtuális gépek egy másik gépen elindulhassanak, és ez olyan gondolatokat ébreszthet bennünk, hogy az ilyen megoldások kiválthatják a hagyományos fürtöket és magas rendelkezésre állási technológiákat. A VMware dokumentációk bátorítanak is erre. A magam részéről csak egy kitétellel együtt tudok ezzel a tervezési elvvel egyetérteni. A kitétel pedig az, hogy gondoskodnunk kell a vendéggép mentésből való helyreállíthatóságáról és tudatában kell lennünk annak, a megoldásunk magában hordozza az adatvesztés lehetőségét. Ennek alátámasztására álljon itt néhány mondat az ntfs.com-ról:

“NTFS uses transaction logging and recovery to guarantee that the volume structure is not corrupted. For this reason, all system files remain accessible after a system failure. However, user data can be lost because of a system failure or a bad sector.”

A Hyper-V esetén ez azt jelenti, hogy mind a szülő-partíció, mind pedig a vendég elindítható marad, de a vendég memóriájában található, ki nem írt adatok elvesznek. Nem találtam erre vonatkozó utalást, de feltételezhetem, hogy a VMFS éppúgy képes túlélni az ilyen leállásokat, de a benne futó virtuális gépekre a figyelmeztetés ugyanúgy áll. Nem Windows vendéggépek esetén meg kell nézni, hogy a fájlrendszer képes-e a tranzakció-naplózásra és helyreállásra. A mai rendszerek többsége ezt tudja, de egy ellenőrzés azért nem árt.

Előzmények:
A VmWare ESX 3.5 és a Microsoft Hyper-V összehasonlítása – bevezetés
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 1. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 2. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 3. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 4. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 5. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 6. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 7. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 8. kör

A cikk a 10. körrel folytatódik

Ma a virtuális gépek gazdagépek közötti mozgatásáról lesz szó. A VMware ESX kiszolgálónál a VMotion-t / Storage VMotion-t és a HA-t, a Hyper-V-nél pedig a Quick Migration-t ismertetem nagy vonalakban. Most még csak technológiai alapozást tartunk. Ezzel a cikkel annyi a célom, hogy leírjam, melyik megoldás hogyan működik. Az értékelésüket, hasznosságuk becslését, további felhasználási területüket egy következő alkalommal, a 9. körben fejtem majd ki.

Egy érzelgős történet
2004. őszén egy VMware ESX bemutatón vettem részt, amelyet a BCSS Kft. munkatársai szerveztek nekem és Krisztián kollégámnak. Láttam már korábban is virtualizációt, 1999. óta ismertem a VMware-t, egy-két éve már GSX-et is használtunk, de a srácok valami különlegeset ígértek. Hosszan fejtegették, hogy az ESX, szemben a GSX-szel, már nem igényel operációs rendszert, hanem közvetlenül a vason fut, és olyan nagyvállalati funkciók vannak benne, amely a GSX-ben sohasem lesznek. A felsorolt és demózott példák között volt egy lenyűgöző: elindítottak egy virtuális gépet, elkezdtek rámásolni egy állományt a hálózatról, elkezdték folyamatosan pingelni, majd egy speciális technológiával azt mondták, hogy "move", és a virtuális gép némi szöszmötölés után átugrott egyik kiszolgálóról a másikra úgy, hogy csupán egyetlen ping maradt ki, a fájlmásolás pedig gond nélkül folytatódott. Leesett az állam. Percekig nem tértem magamhoz. Vigyorogtam, mint a tejbetök. Micsoda távlatok! Egy operációs rendszer, amely nincs a vashoz kötve, amely igény szerint vándorol. A hardverhibák tökéletesen kiküszöbölhetőek! EZ KELL NEKEM!

Ekkor vettem meg az ESX-et. Persze a számlát nem akkor és nem én írtam alá, de amikor elmeséltem a főnökömnek, hogy mit láttam - és higgyétek el, eléggé érzékletesen meséltem el - nem volt többé kétség, hogy a virtualizáció felé indul a cég, és az új kiszolgálóinkat már ezzel szereljük fel. Rajtam múlt, én akartam, és tudtam, hogy ez a jövő, és pár év múlva minden a virtualizációról szól majd.

Az élet felgyorsult 2004. vége felé. Újabb és újabb kiszolgálókat kellett volna üzembe helyeznünk, de a iroda födémje ezt már nem bírta. Le kellett költöztetnünk a szerverszobát a földszintre. Olyan érdekesnek láttam az előttem álló feladatokat, hogy elhatároztam, blogot fogok vezetni. 2004. December 20.-án el is kezdtem. A legelső feladat, amelyet magam előtt láttam? VMWare ESX 2.5 szerver éles üzembe állítása. Végül sor került rá, a 2005-ben sokat írtam róla. Sajnos a beruházás elég költséges volt, vasakat is kellett venni, storage-ot, meg minden. Nem jutott már pénz a Virtual Centerre, sőt még a Virtual SMP-re sem. (Akkoriban azért még fizetni kellett.) És igazság szerint a Vmotion-t sem tudtuk megvenni. Bánni bántam, mert nagyon jó lett volna, viszont helyette megcsináltuk talán az ország első éles guest-clusterét RDM-mel. Éles Exchange 2003 clusterrel! Nem annyira látványos, mint a vmotion, de amikor belegondoltam, elégedett lehettem: tulajdonképpen ugyanazt csinálta, mint a vmotion, a szolgáltatást elválasztotta a hardvertől és tetszés szerint mozgatta. Ha kevés a pénz, akkor a kevésből kell kihozni a legtöbbet. Nekünk így sikerült.

-------------------------------------

Ma már tudom, hogy több szempontból is nagyon tipikus volt, ahogy a VMware és a virtualizáció megjelent nálunk. Ezek közül a legfontosabbak:

• Hardver erőforrás beszerzése a kiindulópont.
• Közös, bemutatóval összekötött, profi mérnök vezette munkanap.
• “Nagyvállalati technológiák” előtérbe helyezése – középpontban a magas rendelkezésre állás.
• Homályos fogalmak, úgy mint: “bare metal hypervisor”
• A bemutatón a teljes rendszer együttes bemutatása (Platform + Management)
• A döntő momentum a Vmotion demó.

Bátran állítom, hogy a VMotion megjelenése pillanatától az egyik legfontosabb képesség a VMware számára. Eldönti az üzletet, eladja magát, meg a céget is. Nem véletlen, hogy csak a legdrágább VI változatban lehet hozzájutni.

Majdnem két évig volt páratlan funkció a VMotion. A Microsoft Virtual Server 2005 R2 – 2005. novemberében jelent meg, és először hordozott olyan képességet, amely, összevethető volt vele. Akkoriban ezt úgy hívták, hogy “host clustering”. Egy kis script, amely nem tesz mást, mint átmozgat egy virtuális gépet az egyik fürttagról a másikra. Az idő gyorsan elszállt, ma már Windows Server 2008-as fürtökön Hyper-V ketyeghet, és a beintegrált host clustering technológiát “Quick Migration”-nek nevezik. Ez egyáltalán nem úgy működik, mint a vmotion, ám amikor érték-elemzést végzünk, meglepő eredményre juthatunk. Nézzünk meg, hogyan is műkődik a két megoldás.

Technológiai ismertetők

A VMotion
A Vmotion technológiának van néhány előfeltétele, lássuk ezeket sorban:

1. A megoldás szerverek között működik, tehát szükségünk van legalább két szerverre.
2. Meg kell vásárolnunk a megfelelő licenceket. Látszólag nevetséges ezt felsorolni a feltételek között, de mégis muszáj. A funkcióval kapcsolatos táblázatok néha csalnak. Az ESXi ingyenes, és amikor a funkciót feltüntetik az ESXi képességei között, akkor úgy tűnik, mintha a Vmotion is ingyenes lenne. Nem az, pénzbe kerül.
3. Szükségünk van valamilyen közös adattároló rendszerre, célszerűen SAN-ra.
4. Szükségünk van egy olyan hálózati szegmensre, amelyen a Vmotion az adatokat mozgatja. Sok lesz belőle, ezért célszerű a dedikált szegmens és hálózati adapter.
5. Szükségünk van közel azonos processzor architektúrára a szerverekben. A processzoroknak nem kell teljesen azonosaknak lennie, de azért rendes kis aknamezőt hozott össze az iparág. Szerencsére van kompatibilitási mátrixunk (HP forrás, Dell forrás) és a Vmotion maga is alapos ellenőrzést végez a gépmozgatás előtt. Jelenleg abszolút megkerülhetetlen feltétel az azonos gyártótól származó processzor (Reméljük nem sokáig: épp a minap demonstráltál először, hogy lehetséges live migration intel-amd processzorok között is. Ez ugyan most még nem ESX Vmotion, de idővel az is lesz.)
6. Végezetül szükségünk lesz egy ún. fürtözött fájlrendszerre. Mindjárt azt is leírom, miért, itt most legyen annyi elég, hogy az ESX rendelkezik ilyennel, VMFS-3 a neve.

Ha minden előfeltétel adott, akkor lássuk a mutatványt – nem túlbonyolítva a működés mikéntjét:

1. Kiadjuk az utasítás a gép mozgatására
2. Az ESX elvégzi a megfelelő ellenőrzéseket, hogy a Vmotion művelet elvégezhető-e. (Van-e elegendő szabad memória a másik szerveren, megfelelő-e a processzor architektúra stb. stb.)
3. A két rendszer elkezdi a virtuális gép memória tartalmát egyik szerverről a másikra másolni. Eközben a virtuális gép fut tovább, így a memória térképe is változik.
4. A másolás végeztével egy újabb iterációval a megváltozott memóriablokkok másolása kezdődik, és a folyamat addig tart, amig a két kiszolgálón a mozgatandó gép memória-tartalma közel azonos.
5. Az első kiszolgáló megállítja a virtuális gép futását, átmásolja az utolsó változott memóriablokkokat, végül a VMFS fájrendszerben elengedi a virtuális gép merevlemezeit. A második szerver lefoglalja a VM merevlemezeit reprezentáló fájlokat, elindítja a virtuális gépet, a hálózatra pedig kiküld egy olyan ARP csomagot, amely jelzi a hálózati kapcsolóknak, hogy a virtuális gép MAC címét ezentúl hol keressék. Ez az ötödik pont kevesebb, mint egy másodperc alatt zajlik le.
6. Az első kiszolgáló törli a virtuális gép memória tartalmát. A folyamat kész.

Kritikus az egész tevékenységsor során, hogy a memória-lapok változásával keletkezett adatmennyiség képes legyen átvándorolni a másik kiszolgálóra. Ha bárhol szűk keresztmetszet jelentkezik, az iteráció soha nem ér véget, egy idő után pedig a művelet meghiúsul. A Vmotion tehát nem tudja garantálni az átmozgatás sikerét, sem a folyamat hosszát.
A fürtözött fájlrendszer az ötödik lépésnél nagyon fontos. Az ilyen típusú fájlrendszereknek az a sajátossága, egy egy időben több kiszolgáló is elérheti, írhat rá és olvashat róla, a fájlok zárolását és hozzáférését pedig egy elosztott algoritmussal biztosítják. Vagyis mindkét kiszolgáló “látja” a virtuális merevlemezeket, de egyszerre csak egyikük használja. Az átadás-átvétel ezzel a lehető leggyorsabb. Ugyanakkor látni kell, hogy a virtuális gép egy “egyszerű” vmotion műveletnél nem “mozog” sehová: a virtuális merevlemez változatlanul ott marad az adattárolón, csupán a futtatási feladatokat veszi át egyik szerver a másiktól. Ahhoz, hogy a virtuális gép tényleg vándoroljon, egy másik komponensre van szükség, amit úgy hívnak, hogy Storage Vmotion.

A Storage VMotion
Ha megértettük, hogyan működik a Vmotion, akkor annak analógiájára könnyen érthetővé válik a storage vmotion működési elve. Technológiai részletekbe nem belebújva a lényeg virtuális lemezeket reprezentáló fájlok mozgatása különböző adattárolók között úgy, hogy közben a virtuális gép működik. Ez a képesség újra elindíthatja a fantáziánkat: SAN kiürítés, katasztrófa-telephelyek létrehozása, SAN reorganizáció, I/O terhelés elosztása stb stb.

Külön szépsége a megoldásnak, hogy különböző storage-ok között is működik. Kell hozzá persze a sávszélesség, meg vmotion licensz, csak parancssorból működik és számos korláttal bír, hogy mást ne mondjak, a Vmotion és a Storage Vmotion művelet együtt nem működik jelenleg, NPIV és Storage Vmotion kizárja egymást, snapshot-ot szintén nem használhat a virtuális gép stb. stb., de ettől még ígéretes képességnek tűnik(*). Sőt, ami még fontosabb: akárcsak a Vmotion esetén, további, még szofisztikáltabb megoldásoknak lehet később alapja (pl. Katasztrófa-védelem.)

Egyetlen részletkérdést nem tisztáztunk csupán: mi a helyzet meghibásodáskor? Mi történik, ha egy rendszergazda véletlenül mindkét tápkábelt kihúzza? Mi történik, ha tönkremegy egy kiszolgáló? Hogyan működik ilyen a Vmotion/Storage Vmotion? Nos, sehogy.

VMware High Availability
Meglepő, ugye? Pedig logikus. A Vmotion műveletek időt igényelnek. De a táp kihúzása után már nincs idő. A fizikai kiszolgáló leállt, a virtuális gépek pedig vele együtt a semmibe vesztek – legalábbis ami a memória-állapotukat illeti. A Vmotion/ Storage VMotion-nek esélye sincs működésbe lépni. Ezért van a VMware VI-ban egy haramadik komponens, amit nemes egyszerűséggel “High Availability”-nek, röviden HA-nak hívnak, és az a feladata, amit a Vmotion nem tud elvégezni: elindítani azokat a virtuális gépeket, amelyek a fizikai kiszolgáló hibája, vagy bármi más hiba miatt leálltak. Nincs állapotmentés, nincs működés közbeni átmozgatás és semmi hókuszpók. Egyszerűen csak elindítani azt, ami nem megy, méghozzá ott, ahol lehet.

A Microsoft oldal
Amit a VMware három komponenssel old meg, azt a
Microsoft másféllel próbálja. A Quick migration a Windows Server 2008-ban található Fail-over cluster és a Hyper-V szerepkör házassága. Nézzük az előfeltételeket:

1. Szerverek között mozgatunk majd virtuális gépeket, tehát itt is szükség lesz legalább két kiszolgálóra.
2. Szükségünk lesz a megfelelő kiszolgáló oldali licenszre is. Néha tévesen azt feltételezik, hogy a Hyper-V csak a Windows Server 2008 Enterprise és DataCenter kiadásban található meg. Ez nem így van, a Standard kiszolgáló is futtathat Hyper-V szerepkört. Ugyanakkor érvényes a kiadások közötti “rendes” különbség. Konkrétan a mi esetünkben a Standard kiadás nem tartalmazza a Fail-over cluster-t, így az amúgy létező Hyper-V szerepkörrel sem tud integrálódni. Sok beszédnek sok az alja: a Quick Migration-höz Enterprise vagy Datacenter kiadást kell vásárolni a szerver hardverhez. Vegyük ugyanakkor észre, hogy a Microsoft szerint ez a képesség az  operációs rendszer része és nem igényel külön menedzsment eszközt, pláne nem licencet.
3. Szükségünk lesz SCSI3 Reservation parancsokat értő/ismerő közös tároló rendszerre – célszerűen SAN-ra.
4. A teljes rendszerre vonatkozóan le kell futtatni a fail-over cluster beépített ellenőrző funkcióját (ez telepítéskor mindenképp lezajlik, de később is bármikor elvégezhető.) Ha a validációs eljárásnál a rendszer nem talál kifogásolni valót, akkor a fürt – függetlenül attól, hogy milyen gyártótól származnak a komponensek – támogatott lesz.
5. A Quick Migration éppúgy memória és processzor állapotot mozgat át egyik gépről a másikra, mint a VMotion. És éppen ezért ugyanolyan feltételeket támaszt. Vagyis: a fürttagoknak azonos processzor-architekúrával kell rendelkezniük. A Microsoft nem bocsátott (még) ki kompatibilitási mátrixot, de 99%-os valószínűséggel a HP és Dell források megfelelnek itt is.

Ha minden feltételnek eleget tettünk, akkor következhet az átmozgatás:

1. Kiadjuk a parancsot a virtuális gép mozgatására.
2. A Hyper-V megállítja a VM virtuális processzorát és elkezdi a memória tartalmat a merevlemezre menteni.
3. A kliens alkalmazások – függően attól, miként kezelik a hálózati kimaradást – jelzik, hogy a kiszolgáló nem elérhető. A memória nagyságától és a rendelkezésre álló HBA-k biztosította sávszélességtől függően a Hyper-V lemezre menti a virtuális gép futási állapotát.
4. A virtuális gépet reprezentáló fürt erőforrások egyesével “Offline” állapotba kerülnek. Ultoljára a lemez erőforrás.
5. A utasításnak megfelelően az erőforrás csoportot az cél-kiszolgáló veszi birtokba. Technikai értelemben ez egy SCSI3 lefoglalási paranccsal zajlik. Ez a fázis egy másodperc alatt zajlik le.
6. Az új kiszolgálón elindulnak a fürt erőforrások. Az első ezek közül a lemez-erőforrás, amely a virtuális gép merevlemezeit tartalmazza.
7. A Hyper-V lefoglalja az átkötöző virtuális gép által igényelt memória mennyiségét és megkezdi betölteni azt, felolvasva a másik kiszolgáló által lementett adatokat.
8. Miután a betöltés sikeres volt, a Hyper-V elindítja a virtuális gép processzorát és egy ARP csomaggal jelzi, hol található az új virtuális gép. A folyamat befejeződött.

A mozgatásban nincs iterációs lépés és nem függ a virtuális gép terheltségétől, kizárólag a SAN sávszélességétől. A Quick Migration mindig lezajlik, és a mozgatás ideje jó közelítéssel becsülhető. Ha a célkiszolgáló nem lenne képes fogadni a virtuális gépet, a fail-over cluster automatikusan újabb és újabb kiszolgálót keres mindaddig, amíg a virtuális gépet újra működésbe nem lehet hozni.
Végül látható, hogy nincs fürtözött fájlrendszer, a lemez-erőforrásokat egyszerre csak az egyik fürttag birtokolhatja/olvashatja/írhatja. Akárcsak a VMotion esetén, itt sem mozog a virtuális gép lemeze, csupán annak birtoklása. A tényleges vándorláshoz további eszközökre van szükség.

Földrajzilag elosztott fürt
Nincs szégyenkeznie valója a Windows Server 2008-nak, támogatja a földrajzilag elosztott fürtöket. Igaz, storage replikációs technológiával nem rendelkezik, de ha van ilyen alatta, akkor képes használni. A földrajzilag elosztott fürt persze egy kicsit más, mint a storage vmotion. A kitűzött cél itt a katasztrófa kivédése és a folyamatos üzemmenet. Nincs szó SAN depopulációról, I/O átterhelésről és hasonlókról. Heterogén tároló-rendszer megoldás szinte biztosan nem működik. Viszont a kitűzött célt elég magas szinvonalon elvégzi, többféle modellel – mellesleg nem csak Hyper-V esetén.

Magas rendelkezésre állás
Már csak egy kérdést kell tisztáznunk: mennyire működik a magas rendelkezésre állás? Mi történik egy Hyper-v kiszolgáló elszállásakor?

Nos, a Microsoft megoldása ebben az esetben is a Fail-over cluster. Ha egy kiszolgáló kiesik a fürtből, a többi tag ezt azonnal észreveszi, az erőforrásokat pedig azonnal és automatikusan elindítja a következő preferált vason. Nincs állapot, amelyet vissza lehetne tölteni, a cluster ilyenkor a virtuális gépeket csupán elindítja. Figyelem! A Quick Migration és a HA a Microsoft világában ugyanaz a szoftver végzi.

Az alapokból ennyi elég, az értékelés a következő cikkre vár.

--------------------------------------------------------

(*) – Egy szoftver mindig egy adott szolgáltatás-készlettel rendelkezik: sohasem kész, viszont tulajdonsága, hogy kiadták. A képességeit megvizsgálva el lehet dönteni, hogy kielégíti-e a mi igényeinket, vagy sem. Ha kielégíti, akkor jó, ha nem nem. Értelmetlen ugyanakkor az “1.0” használata lekicsinylő értelemben.

Hosszú ideje nem jelentkeztem már ezzel az összehasonlító cikkel,  de a hol-itt-piros-hol-ott-piros táblázat jól mutatja, hogy a két megoldás sok tekintetben eltér egymástól, ezért nem kevés irodalmazás és konzultáció előzte meg a megírását. Végül minden összeállt, és ez a minden nem is kevés. Igaz, akik várják a bejegyzést, azok ezt nem fogják bánni. A téma felosztható néhány további alfejezetre:

1. A virtuális lemezek típusai és a velük végzett műveletek (undo, snapshot)
2. A támogatott tároló rendszerek típusai és az azokon létrejövő hozzáférés-típusok
3. Redundáns tároló-elérés
4. A közvetlen hozzáférés témaköre.
5. Egyebek (fájlrendszerek, LUN-okkal kapcsolatos tulajdonságok, indítás stb.)

Az egyes témafejezeteket nem jelöltem meg a táblázatban, de egy-egy üres sorral elválasztottam őket a jobb olvashatóság kedvéért. És akkor most a részletek.

A virtuális lemezekkel való zsonglőrködés mindkét rendszernél hasonló. Itt is, ott is vannak dinamikus lemezek, fix lemezek és pillanatfelvételek. Sebesség szempontjából is azonos a két cég javaslata: leggyorsabb mindig a közvetlen hozzáférés, de ezt az üzemmódot inkább csak speciális célokra, mint általános használatra ajánlják. Alig valamivel marad el a fix lemezek sebessége, a legjobb gyakorlat ilyenekkel dolgozni. Ezt követi (sebesség szempontjából) a dinamikusan növekvő lemez, ESX-nél ezt "Thin virtual disk"-nek nevezik. Végül a leglassabb a differenciális lemez, de ahogy elnéztem, ilyen ESX esetén nincs is. (Ha mégis tévedtem, javítsatok ki, és küldjétek el a linket, ahol utána olvashatok a témának.) A differenciális lemezek éles környezetben kevésbé használatosak, inkább teszteknél és bemutatóknál hasznosak: van egy csak olvasható alaplemez, többnyire sysprepelve, amelyre újabb és újabb virtuális gépeket definiálhatunk úgy, hogy mindegyik gép egy különbség lemezre dolgozik.
Itt említsük meg, hogy a virtuális gépekben dolgozó virtuális SCSI adapterek közül csak az ESX-beli képes shared-scsi üzemmódra, vagyis csak ez képes parallel-SCSI fürtök létrehozására. Ez azért fontos, mert így iSCSI target nélkül, pusztán virtuális merevlemezekkel létrehozhatunk Microsoft fürtöket. Igaz, csak két tagból állót és csak Windows Server 2003-ig bezárólag, de akkor is. A Hyper-V integrált komponensben megbúvó SCSI adapter ilyen képességgel nem felvértezett, ezért virtuális gépekből fürtöt (ún. guest clustering) csak iSCSI technológiával lehet létrehozni.

A támogatott interfészek a két rendszernél szintén hasonlóak, de a gyökerekből eredően itt is vannak különbségek.

Az ESX a helyi lemezek közül nem kezeli az IDE/ATA típusúakat. SAS/SATA lemez-tömböket ugyan kezel, de csak akkor, ha azok nincsenek megosztva.  Adatközpontba szánt szoftverről lévén szó ez nem tragédia, de pl. távoli telephelyeknél "olcsósított" hardvernél gondot jelenthet. Sőt, én megosztott SAS tömböket gond nélkül el tudok képzelni még egy bank adatközpontjában is - legfeljebb nem a legfontosabb funkció szalad rajta.

A másik látható történelmi előzmény az NFS. Lévén az ESX-nek Unix/Linux gyökerei vannak, jó barátságban van az ebből a világból származó szabványokkal. Az NFS egy fájl-megosztási technológia, a Windows világ SMB/CIFS techológiájával vethető össze. Szinte várható is, hogy  Hyper-V meg ez utóbbit támogatja, és lám, az alábbi ábra szépen mutatja: lehet fájlmegosztásra VHD-t rakni. Célszerű persze az SMB2 használata - tehát Windows Server 2008 alkalmazása.

Ami számomra meglepő volt a téma kapcsán, hogy a NAS eszközök száma az ESX-nél. Nem tudom, mi az oka annak, hogy egyáltalán van valamilyen korlát a számukra vonatkozóan. Nem mintha a 32 NAS eszköz olyan nagyon komolyan vehető határ, inkább a jelzés, hogy létezik ilyen korlát.

Szintén meglepetéssel tapasztaltam, hogy a redundancia vonatkozásában tároló rendszereknél az ESX történet nem fényes. Van persze többszörös útvonal, és hiba esetén az egyik HBA munkáját gond nélkül átveszi a másik, tehát a kötelező kör, vagyis a hibatűrés letudva. A terhelés-elosztás támogatása viszont gyengére sikeredett. Ezek szerint az ESX 3.5U2 csak "experimental", vagyis próba jelleggel támogatja a "round robin"-t, a legegyszerűbb terhelés-elosztási technológiát.

A Hyper-V a témában csillog: a round robint az útvonalak részhalmazára is támogatja, de tud például  olyat, hogy egy adott IO kérést arra az útra irányítson, amelyben a legkisebb a várakozása sor. Az már csak hab a tortán, hogy az egyes storage IO utakhoz súlyokat rendelhetünk, az adaforgalom pedig ezen súlyozás arányában oszlik el. És mindezt iSCSI-re is. Három 10 Gbit/sec-es iSCSI HBA-val bődületes IO sávszélesség adódik, amit tetszőleges algoritmussal terhelhetünk egyenletesen. Ez a mutatvány nem jöhetett volna létre, ha nincs a Windows Server 2008-nak egy kiegészítő képessége (Feature), a "Multi-path IO".

Hogy a VMware maga is érzi a hiányosságot ezen a téren, azt a legjobban a "ESX Server 3 Configuration Guide" 140-ik oldalán olvasható mondatok támasztják alá: "In addition, with the software‐initiated iSCSI, you can use NIC teaming, so that
multipathing is performed through the networking layer in the VMkernel". És teljesen igazuk van: iSCSI esetén az ESX-be épített NIC teaming nagyon jó szolgálatot tesz, mert a hibatűrés mellett jólfejlett terhelés-eloszlással is rendelkezik. A hátulütő csak annyi, hogy a hardveres iSCSI iniciátorok - tehát a HBA szerepét ellátó kártyák száma kettőnél nem lehet több.

Miután a redundáns hozzáférést jól kiveséztük, a témában egyetlen említésre érdemes szempont maradt, és ez át is vezet minket a közvetlen hozzáférés funkcióhoz. Szemben az előző körrel, itt az ES viszi a prímet. A Hyper-V-ben az MPIO nem működik, ha egy lemezhez közvetlen hozzáférést adunk a virtuális gépek számára. Ez nem szép, mondhatjuk, de én még viszonylag megbocsáthatónak tartom. Az ajánlások szerint a pass-through lemezt csak speciális célokra érdemes használatba venni, például gyorsan "megláttathatunk"' köteteket virtuális gépekkel. Hosszú távon viszont a fix VHD a javasolt. Ha valaki betartja ezt az ajánlást, az MPIO közvetlen lemezeknél nem fog hiányozni neki.

Csakhogy nem ez az egyetlen bibi. A közvetlen hozzáférést használó gépeknél nem lehet pillanatfelvételt sem készíteni hyper-v alatt. Ha tehát valaki abba a kategóriába tartozik, ahol tényleg elengedhetetlen a pass-through lemez, ott további ujjbaharapásokra is számítani kell. Ha nincs pillanatfelvétel, nincs konzisztens online backup lehetőség sem - és ez meg backup szoftvertől független. Lássuk be, az Microsoftnak jó oka van azt ajánlani, hogy a pass-through lemezt csak megfontoltan használjuk. Az ESX ezen a területen jobban áll: kétféle közvetlen hozzáférést támogat: az egyiket "virtual compatibility mode"-nak, a másikat "physical compatibility mode"-nak nevezik. A két üzemmód közül az első lehetővé teszi a pillanatfelvétel használatát, és ha olyan alkalmazást használunk, ahol ez a technológia éles környezetben is támogatott, akkor jól is jöhet. (Az Active Directory és az Exchange éles környezetben való támogatásának egyik feltétele például a pillanatfelvétel funkció használatának elhagyása.)
A közvetlen hozzáférés vitathatatlan bajnokának mégsem nevezném az ESX-et. Egy fontos képességet ugyanis ez a termék is nélkülöz, méghozzá a helyi lemezek közvetlen hozzáférésének biztosítását. Adatközpontban, SAN-os környezetben ilyen igény ritkán jelentkezik, távoli telephelyeknél annál gyakrabban lehetnek olyan kiszolgálók, amelyek DAS-t használnak és kell nekik a pass-through. No, ahhoz jelenleg hyper-v kell.

Maradt még néhány funkció a vegyesfelvágott témakörben. Az NPIV már egy ideje elérhető technológia, még a Virtual Server 2005 is használhatta. A lényege, hogy minden virtuális gép egyedi - virtuális - WWPN-nel rendelkezik, így egy adott LUN-hoz csak egy adott virtuális gép férhet hozzá. A VMFS beköszöntével elérkezett a fürtözött file-rendszerek kora, de azzal, hogy sok virtuális gép lemezét egyetlen LUN-ra raktuk, szépen fel is rúgtuk a SAN felügyelet legjobb gyakorlatát. Az meg különösen csúnya, hogy a direkt hozzáférésű lemezeket a host HBA érheti el - a többi virtuális gép nincs kizárva az zónából. No, ezen segít az NPIV. Nüansznyi dolognak tűnik, de talán a SAN rendszergazdák értékelik, hogy a Hyper-V a Host-nak kiadott LUN-okra is tudja az NPIV-t, miközben az ESX a VMFS-re nem.

Apropó VMFS. Jelentős különbség a két gyártó megoldása között, hogy a virtuális lemezek tárolására szolgáló ESX-féle VMFS fájlrendszer egy "fürtözhető" fáljrendszer. Ez azt jelenti, hogy egyszerre egynél több (maximum 32) kiszolgáló férhet hozzá ugyanahhoz a kötethez, az elosztott fáj-zárolási mechanizmus pedig biztosítja, hogy a kötet integritása és konzisztenciája ne sérüljön. Ez a technológia azért fontos, mert alapja a Vmotion-nek, a DRS-nek, amitől olyan szép az élet a virtualizációs környezetben.
A VMFS-sel szemben ott az NTFS. A jelenlegi verziója nem fürtözött (ezért van olyan tétel a táblázatban, ami Hyper-V esetén nem értelmezhető), ugyanakkor már rég nem küzd olyan 2 TB-os korlátokkal, mint a VMFS amúgy immáron harmadik verziója.
A táblázat végét mazsolázva még egy fontos tulajdonság: mindkét termék képes SAN-ról indulni. Ha valaki ragaszkodna a blade szervereire hypervisort rakni, no neki ez kötelező igénye lesz.

Összegzés:

• A Hyper-V által támogatott storage hardver konfigurációk típus szélesebb, mint az ESX-é.
• Shared SCSI alapú cluster-in-a-box konfigurációt csak ESX-szel lehet további beruházás nélkül megvalósítani
• A Windows Server 2008 MPIO komponense messze lekörözi az ESX HBA terhelés-elosztását
• A Hyper-V-nek van csiszolnivalója a közvetlen hozzáférés témakörén
• A VMFS ugyan fürtözött fájl-rendszer, ennek ellenére még a Windows 2000-beli NTFS méret-maximumait sem éri el

(1) - Thin vmdk
(2) - Nem találtam ilyet
(3) - Forrás: Storage / SAN Compatibility Guide For ESX Server 3.0.x - 2008. november 6.
(4) - Round robin expirimental load balance van.
(5) - Ezt a képességet egyszer már szerepeltettem, itt csupán a téma miatt tettem be újra.

További olvasmányok:
Best Practices Guide on deploying VMware ESX Server 3.5 using Emulex Virtual HBA Technology
Best Practices: SAN Deployment on Microsoft Windows Server 2008 Hyper-V using Emulex Technology
Multipath I/O Overview
Failover Clustering in the Windows Server 2008 Technical Library

Előzmények:

A VmWare ESX 3.5 és a Microsoft Hyper-V összehasonlítása – bevezetés
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 1. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 2. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 3. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 4. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 5. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása - 6. kör

Ezúttal a hálózati képességeket vesszük górcső alá. Ha a alcímet is lehetne adni a bejegyzések címe mellé, akkor azt írnám "Sok hűhó semmiért". A táblázat ugyan szép számmal tartalmaz tulajdonságokat (még ha a TSO és a Jumbo Frames már szerepelt is korábban), valójában azonban kevés releváns és fontos képesség van közöttük. A kötelező köröket természetesen mindenki teljesítette: már nem virtuális hubokról, hanem switchekről beszélünk. Minden gond nélkül tudunk bármelyik termék esetén privát, a hosttal közös, vagy kívülről is elérhető hálózatot definiálni. Végre nem gond a VLAN támogatás a Hyper-V számára sem - ez a VS 2005-höz képest újdonság. A virtualizációs technológia sajátossága a "tetszőleges mennyiségű" virtuális hálózati kártya születése és kimúlása - valahogy tehát kezelni kell a virtuális MAC címeket. Mindkét szoftver képes mind statikus, mind pedig dinamikus címallokációra, de menedzsment szoftver hiányában ez csak korlátozottan valósítható meg, és ebben sincs különbség. A switchek maximális száma és a switch portok száma az ESX-nél korlátozott, de ha a korlátokat összevetjük az egyidejűleg futtatható gépek számával, akkor látható, hogy ez a korlát nem korlát. Az ESX Hyper-V-vel szembeni egyetlen komoly hiányossága az iSCSI támogatásnál mutatkozik. A szülőpartíció képességei révén a Hyper-V vel gyorsabbak lehetnek az iSCSI SAN-ok.

Van aztán egy csomó olyan ESX képesség, amelyre a Hyper-V-ben beépített megoldás nincs. Ezek szinte kivétel nélkül a "port Grouping" funkcióhoz kötődnek (5-11 sor a táblázatban). Amikor először olvastam a VMware dokumentációt a Port Group funkcióról, nem értettem, mire való. Aztán amikor másodszor olvastam, azt gondoltam, ez "király" és "világmegváltó". Ripsz-ropsz WAN hálózatot lehet összeütni virtuális switchekből és lehet tesztelni a tesztelnivalót. No és mi a helyzet az éles környezetben? Mennyi értelme van pl. a virtuális switch autonegotiate képességének? Nem az a lényeg, hogy toljuk át az adatot egyik gépről a másikra, ahogy csak bírjuk? Mi értelme van a Promiscous mód detektálásának és tiltásának, ha mind a virtuális, mind pedig a fizikai világnak mi vagyunk az urai? És minek néhány tucat, extrém esetben százegynéhány gép esetén switch házirendekben gondolkodni. Nem értettem.

Aztán leesett: VM hosting! Ha SLA csoamgokat kell összeállítani, akkor a házirend alapú, technológiai korlátokat szabó megoldások elég dekoratívak. Ha védekezni kell a bérbe vevővel szemben, akkor a promiscous mód figyelése és tiltása hasznos lehet. Ha megadjuk, hogy a bérelt infrastruktúrában mekkora sávszélességgel érhető el az Internet, akkor a házirend megint segíthet. És kik lennének az infrastruktúra megújításában az élenjárók, ha nem a hosting és outsourcing cégek. Lehet, hogy már az ESX 1.0 is használták.

Arra azért senki ne vegyen mérget, hogy ezek után a Hyper-V alkalmatlan lenne a hostingra. A myhosting.com és a Hostbasket is a Hyper-V mellett döntött, pedig ez utóbbi 1200 szervert felügyel, amit mindennek lehet mondani, csak kicsinek nem. Miért is lehetséges ez? Azért, mert a fenti szofisztikált módszerek nélkül is működhet SLA, megoldható a biztonság stb. stb. Maga az ESX is hordoz magában hiányosságokat (pl. port tükrözés), ilyenkor többnyire vagy a fizikai hálózatot kell segítségül hívni, vagy ha az nem oldható meg, akkor LiveCD-s szoftverdisztribúciók úszhatnak be a képbe. Ugyanez igaz a Hyper-V esetén is. Hiányzik a sávszélesség szabályozás? Egy 128 MB-os zeroshell letöltésével - akár VHD nélküli virtuális géppel is kipipálható a feladat.

Van egy olyan képesség, amely nem a Port Grouping témakörébe tartozik és meglehetősen sok figyelmet kapott, hála a VMware kommunikációs csapatának, ez pedig a NIC Teaming. A VMware ESX-nek egy nagyon jó, a GUI-ra integrált, intuitív kezelőfelülete van hálózati kártyák együttes kezelésére, lehetővé téve ezzel a sávszélességek aggregálását és/vagy redundáns konfiguráció kialakítását. Gyakran felhozott érv a Hyper-V-vel szemben, hogy nincs benne NIC Teaming támogatás. Nos, ez így, ebben a formában nem igaz.

Tény: a Windows szerverek egyik változatában sincs NIC Teaming támogatás a Microsoft részéről. Viszont van NIC Teaming támogatás a hardver szállítók oldaláról. Tehát a HP, az IBM, a DELL meg a többiek elkészítették a maguk eszközmeghajtóit és biztosítanak NIC teaminget. A kérdés már csak az, hogy mennyire működnek ezek a meghajtók Hyper-V környezetben, tekintettel arra, hogy a szülőpartíció is virtualizált gép és a hálózati kártyák virtuális switcheket reprezentálnak. Igazság szerint a legutóbbi időkig nem volt túl fényes ez a történet. Augusztustól azonban a HP Network Configuration Utility 9.30.0.0 (Support pack 8.11) már jól működik. Hasonlóan a Broadcom eszközök is a 11.32 verziótól hozzák az elvárt teaming képességet. Mindez nem integrált a Hyper-v kezelőfelületével, de funkcionalitás tekintetében nem marad el az ESX mögött. A táblázatban ezek alapján két sorban tüntettel fel a NIC teaminget, respektálva az ESX integrált GUI fejlesztését.

Végezetül említsük meg, hogy a virtuális hálózat területén jócskán van fejlődnivaló. Senki által sem megoldott jelenleg még az IDS/IPS eszközök futtatása virtuális környezetben, nincs port mirroring, a tűzfalak kezelése homályos és fejlődő terület. A VMware több innovatív fejlesztést is bejelentett, ezek közül kettő különösen fontos. A 4-es verziótól kezdődően lehetőségünk lesz switch gyártók valódi switch operációs rendszereit, mint beépülő modulokat a virtuális környezetbe integrálni. Vagyis a virtuális gépek közé "beépíthetünk" egy virtuális CISCO kapcsolót is - annak minden előnyével együtt. Egyelőre még nem világos, hogy ennek milyen licence-költségei lesznek, de illúzióim nincsenek. A másik jelentős változás a hálózat területén a I/O virtualizáció hardveres támogatása. Itt az Intel fejlesztései lesznek meghatározók, amelyet mind a VMware mind pedig a Hyper-V támogatni fog. Ez azonban már a jövő zenéje.

Összefoglalás: a kötelező köröket mindenki tudja. Hosting környezetben az ES rendelkezik néhány vonzó képességgel. A NIC Teaming - bár mindkét megoldás támogatja, az ESX-nél jobban integrált. Az iSCSI területén a Hyper-V-nél fejlettebb. Néhány képesség mindkét termékből hiányzik - ezeket vagy ingyenes holmikkal lehet orvosolni, vagy várni kell a hypervisor következő változataira.