Bevezetés a VDI világába

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!

No.	Funkció	Microsoft	Citrix	Vmware
1.	A megoldás neve	Remote Desktop Service	XenDesktop	VMware View
2.	Hypervisor	Hyper-V	XenServer	VMware ESX/ESXi
3.	Konfiguráció menedzsment	System Center Virtual Machine Manager (SCVMM) System Center Configuration Manager (SCCM)	Citrix Essentials for XenServer Citrix Provisioning Server	Virtual Center VMware View Administrator (VMware View Composer)
4.	Operáció menedzsment	System Center Operations Manager (SCOM)	Citrix Essentials for XenServer	Virtual Center (Hypervisor hostokra)
5.	Kapcsolat szétosztó	Nincs (R2: Remote Desktop Connection Broker)	Desktop Delivery Controller	View Manager Connection Server
6.	Terminál szerver	Windows Server Terminal Services (R2: Remote Desktop Server)	XenApp	Nincs
7.	Alkalmazásvirtualizáció	App-V	XenApp for Virtual Desktops	ThinApp
8.	Profile-kezelés	OS funkció; Group Policy	Desktop Delivery Controller	Nincs ilyen (OS képességek vagy partner: RTO Virtual Profiles; AppSense)
9.	Felhasználói adatok kezelése	OS funkció; Group Policy	Desktop Delivery Controller	Nincs ilyen (OS képességek, vagy partnerek: RTO Virtual Profiles; AppSense)
10,	Távelérés biztosítása	Terminal Server Gateway (R2: Remote Desktop Gateway)	Citrix Access Gateway	Vmware View Manager Security Server
11.	Távoli asztali protokoll	RDP 6.1 (R2: RDP 7)	ICA	Nincs ilyen (RDP 6.1, ALP; vNext: PCoE)
12.	WAN optimalizálás	Nincs (partner: Riverbed)	WANScaler	Nincs ilyen (partner: Riverbed)
13.	Hardveres kliens remoting	Nincs (terv: callista)	Nincs	Teradici OEM
14.	Szoftveres  kliens remoting	Nincs (R2: Win7)	Citrix Desktop Receiver	Nincs (terv: PCoE)