VDI – projekt kockázatok

Miután megismerkedtünk a VDI rendszerek felépítésével és azokkal az előnyökkel, amelyet egy VDI rendszer hordozhat magában, most nézzük meg, milyen projekt kockázatokkal kell számolnunk a bevezetés során. Elöljáróban jelzem, hogy bár a cikk negatív kicsengésűnek tűnhet, ez a kockázat-feltárás jellegéből adódik. Az Interneten sok eufórikus cikk és bejegyzés olvasható a VDI-ról, s miközben világos, hogy a megoldásnak van helye a nap alatt, érdemes szembenézni a korlátaival és a megvalósítási lehetőségével, mert csak így lehet sikeres VDI projektet véghezvinni.

A kockázat mértéke több tényezőtől is függhet, én ezek közül négyet elemzek:

  • Az informatikai szervezett érettségi szintje
  • A tervezés
  • A technológa
  • A megváltozó folyamatok

Infrastruktúra érettség
Az Infrastruktúra optimalizációról már volt szó korábban is a webnaplóban, de nem árt az ismétlés. Eredetileg egy 2004-es Gartner kutatási dokumentációban született meg az infrastruktúra érettségi modell fogalma (Később az anyagot 2007-ben frissítették). Ezek szerint egy informatikai szervezet az alkalmazott technológia, a bevezetett folyamatok és a szervezeti tagok képzettsége szerint hat érettségi szintbe sorolható. A Microsoft átvette a Gartner eredményeit, és – egy egyszerűsített formában – alkalmazni kezdte. Az átmenet a két módszertan között jól következő az alábbi ábrán:

image

Az eredeti hat szintből négy lett, a lényeg azonban változatlan maradt. A Microsoft fogalmak mellett maradva egy IT szervezet lehet:

  • Alapszinten – amikor a folyamatai koordinálatlanok, a tevékenységek túlnyomó része pedig kézzel végzett.
  • Standardizált – alapszintű folyamatokkal és belső szabványokkal, de korlátozott automatizációval.
  • Racionalizált – erősen szabályozott folyamatokkal, kiterjedt automatizációval, iteratívan rögzített üzemeltetői tudással.
  • Dinamikus – Teljes automatizmussal, dinamikus erőforrás-használattal, az üzleti igények diktálta szolgáltatási szintekkel és automatikusan rögzített üzemeltetői tudással.

Három infrastruktúra optimalizációs modell létezik: a CoreIO (alap infrastruktúra), a BPIO (Üzleti produktivitás) és a APO (Alkalmazásfejlesztés). Számunkra a CoreIO a lényeges. Az alapinfrastruktúra modell több. ún. képességre (capability) és alképességre (sub capability) oszlik. A képességek az alábbi ábrán láthatók:

image

A képességek közül egy, a “Desktop, Device és Server Management”, további négy alképességre bontható:

  • Desktop Management
  • Virtualizáció
  • Server Management
  • Mobile, Device Management

Egy VDI bevezetés, ha nem is egyforma mértékben, de minden CoreIO képességet érint. A felhasználók azonosításuk alapján kapnak virtuális gépet; a desktopok felügyelete teljesen átalakul, a vékonykliensek megjelenésével “Device Management” feladatok jelennek meg; a WAN optimalizációval a hálózat-felügyeleti feladatok változnak, a centralizált, szerver alapú virtuális gépek, valamint a központosított felhasználói adatok pedig a mentési és helyreállítási folyamatokat érinti alapvetően. Egy sikeres VDI implementáció az adott IT szervezetet racionalizált vagy dinamikus szintre emeli. Ugyanakkor látni kell, hogy az érettségi modell azt is kimondja: nem lehet bizonyos érettségi fázist elérni egy képességben anélkül, hogy előbb ne szereznénk érettséget (értsd: tapasztalatot, tudást) más képességekben. Egy konkrét példával: hiába implementáltunk jól egy VDI projektet egy profi desktopos és virtualizációs csapattal, ha a hálózatfelügyelet nincs megfelelő szinten, akkor a szükséges WAN optimalizáció nem fog kielégítő szolgáltatási színvonalat nyújtani – tehát a távoli felhasználóink elégedetlenek lesznek a projekt végeredményével.

Mindebből már körvonalazható az érettségi szint kockázatra gyakorolt hatása: minél éretlenebb egy szervezet, annál valószínűbb, hogy nem rendelkezik kellő üzemeltetési tapasztalattal, megfelelően lefektetett folyamatokkal és képzett emberekkel, amelyek a VDI implementálásához és üzemeltetéséhez szükséges. És fordítva: minél érettebb egy IT szervezet, annál nagyobb a valószínűsége, hogy ilyen összetett informatikai fejlesztést is sikeresen végrehajtson.

Mindebből az következik, hogy az éretlen szervezeteknél elbuknak a VDI projektek? Egyáltalán nem, viszont nagyobb a valószínűsége, hogy a projekt nem akkor és nem úgy, sőt lehet, hogy egyáltalán nem térül meg. Egy konkrét példa itt olvasható. Köznyelven: ha valaki sokat markol, keveset fog. Milyen módszerekkel lehet csökkenteni ezt a kockázatot:

  1. Az érettségi szint növelésével. A VDI projekt számos eleme VDI nélkül is releváns. Ilyen például az alkalmazás-virtualizáció vagy a WAN optimalizáció. Egy részelemnek a megvalósítása nagyobb sikerrel kecsegtet, miközben fel is készít egy későbbi VDI projektre.
  2. A projekt céljainak/hatókörének szűkítésével. Szűkíthető a VDI projekt például azzal, hogy csak egy telephelyre, vagy csak bizonyos szervezeti egységre vonatkozóan vezetjük be. Csak bizonyos alkalmazásokat biztosítunk ezzel a technológiával, vagy például katasztrófa esetére hozzuk létre.

Az informatika érettségéből fakadó kockázat hatékonyan csökkenthető, de nem költségmentesen. Az érettségi szint növelése lényegében a VDI projektek elhalasztását jelenti, míg a kitűzött célok szűkítése azt jelentheti, hogy a lecserélni kívánt desktop infrastruktúra részben vagy egészben a helyén marad, továbbá a beruházás méretgazdaságossága megkérdőjeleződhet. (Érdemes-e 100 virtuális gép kedvéért ilyen rendszer felépíteni?)

Tervezés
A VDI projektek kapcsán számos tervezési hiba elkövethető, amelyek azután a projekt sikerét alapvetően befolyásolják. Néhány ezek közül:

  1. VDI Windows XP alapokon. Minden Microsoft szoftvernek meghatározott támogatási életciklusa van. Üzleti szoftvereknél az általános támogatási időszak 5 év, a bővített támogatási időszak további öt év, ezt követően csak önkiszolgáló online támogatás vehető igénybe. A Windows XP ebből a szempontból még kivétel is, hiszen a 2001.-es megjelenést követően nem 2006-ban, hanem jelen évig, pontosabban 2009. április 14.-ig tart az általános támogatási időszak, majd ezután 2014. április 8.-ig a meghosszabbított támogatás. Vagyis a jövő hónaptól nem várható, hogy a Microsoft a terméket bármilyen módón fejlessze (például új távoli asztal protokollal.) Ezen túlmenően az esetleges kompatibilitási problémákra készülő javításokhoz is csak azok férnek hozzá, akik ezért külön karbantartási díjat fizetnek. Tekintettel arra, hogy, a VDI rendszerek erősen fejlődő megoldások, szinte bizonyosan várható, hogy a projekt részeként előálló infrastruktúrát egyszer, vagy akár többször frissítjük, a desktop operációs rendszer esetleges előkerülő hibáit viszont a gyártó már nem – vagy csak pénzért javítja.

 image

A Windows XP operációs rendszer alkalmazása még egy veszélyt rejt magában. A VDI megoldások sokszor építenek a memória túlfoglalásra, vagyis arra, hogy az összes futó virtuális gép memóriaigénye nagyobb, mint a fizikai kiszolgáló tényleges memóriája. Ez – többek között – azért lehetséges, mert a hypervisor figyeli az egyes virtuális gépek memória-lapjait, a közösekből pedig csak egyet tárol. Mivel sok azonos operációs rendszer fut egyszerre, a közös lapok valószínűsége nagyobb, tehát a memória túlfoglalás hatékonyabb, ergo nagyobb virtuálisgép- sűrűséget és kisebb hypervisor farmokat lehet kialakítani. Mindez azonban nem igaz a Windows XP-t követő újabb Windows operációs rendszerekre (Vista, Windows 7), mivel azokban alapértelmezetten működik az “Address Space Layout Randomization” (ASLR) nevű kártékonyí programokkal szembeni védelmi mechanizmus. Az ASLR “mellékhatása” az, hogy gyakorlatilag nincsenek közös memória-lapok, így egy operációs rendszer váltása a farm erőteljes bővítését igényelheti.

  1. VECD licencek. Gyakori hiba hogy a projekt nem veszi figyelembe, miként kell licencelni a virtuális desktopokat. A közkeletű vélekedéssel ellentétben sem az OEM, sem bármely nagyvállalati licenc-szerződés upgrade desktop rendszere nem telepíthető jogszerűen virtuális környezetbe csak akkor, ha a végfelhasználó berendezéshez (a monitorral, egérrel, billentyűzettel stb. ellátott készülékhez, amelyről a végfelhasználó a virtuális gépet elérni) hozzárendeltünk egy “Vista Enterprise Centralized Desktop” licencet. A VECD ára függ attól, hogy a szervezet milyen érvényes Microsoft keretszerződéssel rendelkezik, a teljes költség pedig jelentős tétel lehet a VDI projekt során. A VECD licenc-konstrukcióról ebben a bejegyzésben lehet többet megtudni.
  2. WAN vonalak optimalizálása nélkül. A ma elérhető leghatékonyabb protokollok sem képesek a jelenlegi desktopokat megközelítő felhasználói élményt nyújtani a nagy késleltetésű és viszonylag kis sávszélességű WAN vonalakon, ezért elengedhetetlenek a WAN optimalizálók. Ilyen eszközök használatbe vétele azonban nem kis költség. Egy banki rendszerben akár többszáz kis telephely is előfordulhat, vagyis legalább ennyi (sőt a központi eszközöket beleszámolva még több) WAN optimalizáló készülék üzembe állítása jelentősen növelheti a VDI rendszer kezdeti költségeit. Az optimalizálás elhagyása viszont nagyobb és hektikusabb sávszélesség használatot jelent – gyengébb felhasználói élménnyel párosulva. (Érdemes megjegyezni, hogy a WAN optimalizálók átvezetnek a Brach Office rendszerek kialakításának témaköréhez. Amennyiben nem sikerül a távoli telephelyeken teljes mértékben felszámolni a PC-ket, úgy azok további forgalommal terhelik a vonalakat. A WAN optimalizálók használata lényegében megkerülhetetlen lesz. Ekkor azonban már nem lehet csupán a VDI rendszer szempontjai szerint kiválasztani a megfelelő eszközt, hanem figyelembe kell venni a megmaradó PC infrastruktúra igényeit is.)
  3. WAN vonalhasználat intenzitásának növelése. Kevesen gondolnak bele, hogy a VDI rendszer kiépítése sok tekintetben adatforgalom koncentrációt jelent. A PC-k az egyes perifériákkal saját I/O kapukon, hálózatos szemmel: dedikált csatornán, garantált sávszélességen és kis, de legalábbis pontosan ismert késleltetéssel kommunikálnak. A VDI rendszereknél előkerülő átirányítási  technológiák révén az egyes I/O csatornák (soros port, párhuzamos port, USB kapuk stb.) forgalma egy közös, nem garantált sávszélességű, változó, jellemzően nagyobb késleltetésű vonalra terelődik. Ha teljes desktop kiváltást szeretnénk megvalósítani, akkor olyan adatforgalom megjelenésével is tervezni kell, amelyek korábban akár meg sem jelentek ethernet csatornákon. (Képbeolvasás, biztonsági webkamera stb.)
  4. WAN vonalak alternatív útvonal nélkül. Mivel VDI desktopokhoz csak hálózaton át lehet hozzáférni, kritikus tervezési tényező az alternatív útvonalak tervezése. Sokan azt gondolják, hogy természetes a redundáns WAN vonalak biztosítása. Ez azonban egyáltalán nem biztos. Kiterjedt WAN hálózat esetén ez roppant költséges. Másrészről a sok WAN vonal kellő statisztikai alapot ad annak becslésére, hogy egy adott telephely vagy telephely típus milyen gyakorisággal esik ki, illetve nagyjából meghatározható az is, milyen károkat okoz a kiesés. Ezekből adódik, hogy hol kell és hol nem kell alternatív útvonalakat biztosítani.
  5. A felhasználói adatok centralizációja. A PC-k adatközpontba kerülésével és a felhasználói adatok/beállítások PC-től való elválasztásával jelentős mennyiségű dokumentum és egyéb állomány kerül központi adattárolókra. A tervezés során többnyire egy átlagos kvóta-mérettel szoktak számolni, ám a felhasználók szokásai eltérőek, ezért az általuk tárolt adatok mennyisége erősen szóródhat. Mindenképpen azzal kell számolni, hogy jelentősen nő a tárolt adatok mennyisége. A tervezés során gyakran kihagyják a tárolórendszerek deduplikációs mechanizmusának implementálását, amely pedig mind az adattárolás hatékonyságát, mind pedig egy esetleges storage-replikációt jelentősen gyorsíthat. Erős dilemma elé állítja a tervezőket a felhasználók személyes állományainak tárolása (képes, zenei és videó állományok). Megtartásuk jelentős adattárolási többletet okozhat, használatuk pedig a WAN vonalak sávszélességét pazarolhatja. A tárolás megtagadása viszont a felhasználók “lázadását” eredményezi, amely a projekt sikerét kockáztathatja.
  6. Hálózaton nem tárolható állományok. Különös problémát vet fel – és tipikusan tervezéskor figyelmen kívül hagyott – az olyan állományok tárolása, amelyek hálózaton meghajtón nem helyezhetők el (pl. PST fájlok hálózati meghajtón tárolva nem támogatottak), vagy nem érdemes őket ott tárolni (Access adatbázisok). Ezek az állományok belső indexelő illetve lekérdező mechanizmusokkal rendelkeznek, amelyek lokális PC-re optimalizáltak. A felhasználói adatok operációs rendszertől való elválasztása során megoldást kell keresni az elhelyezésükre vagy felszámolásukra. Többféle megoldással kezelhető a probléma, de mindegyik újabb gondokat vet fel. A VMware View-ban például lehetőségünk van a felhasználók állományait külön virtuális lemezen tárolni, majd azt dinamikusan becsatolni a virtuális desktopba. A megoldás előnye, hogy “helyi” állományokról beszélhetünk, hátránya, hogy a vállalati kereső/indexelő szoftverek elől elrejtjük az információkat. A tényleges megoldás a sziget-adatbázisok felszámolása lenne, ez azonban nem könnyű. A helyzet nehézségét jó érzékelteti, hogy például egy neves autógyár gépein több, mint 100 000 Access adatbázist leltároztak fel, ebből több, mint 10 000-et egy évben belül hoztak létre.
  7. Vékonykliensek felügyelete. Tipikusan “elnézett” tervezési feladat. Ha a meglévő desktopokat valódi vékonykliensekkel váltjuk fel, azok felügyeletéről – leltár, firmware-frissítés stb. – gondoskodnunk kell. Ha tehetjük, akkor a meglévő konfiguráció menedzsment szoftver érdemes felhasználni, de ha erre nincs mód, akkor egy párhuzamos felügyeleti rendszert kell kialakítani. Ez a rendszer ugyan rontja a VDI megoldás ROI-ját, de elengedhetetlen, mivel a desktop operációs rendszerek változásával változhat a távoli asztal protokoll is, amelynek a kliens oldali komponensét a vékonykliensek tartalmazzák.

Technológia
Napjaink egyik legfontosabb VDI kérdése, hogy vajon létezik-e már mindazon feltétel, amely a desktopok teljes kiváltását lehetővé teszi. Kockázat oldalról megfogalmazva: milyen technológiai kockázatokkal kell számolnia annak, aki teljes desktop kiváltást szeretne megvalósítani?
A cikkel kapcsolatos szakirodalom tanulmányozása alapján alapján azt gondolom, hogy egyértelmű a szakmai konszenzus: ma még nem lehet a desktopokat teljes egészében kiváltani. A szakértőknek abban tér el a véleménye, hogy vajon az áttörés közel van-e, vagy távol, vagy esetleg el sem jön, és a VDI egy lesz a szerver alapú közpotosított rendszerek (SBC) közül. A VDI szállítók természetesen lelkesek, de még az ő álláspontjuk között is markáns különbségek figyelhetők meg. A VMware szerint a VDI alapvető és forradalmi változás, a desktop paradigma vége. Mivel azonban a cégnek nincs prezentáció-virtualizációs kiszolgálója, ezért a VMware szerint a VDI-nak kevés köze van a hagyományos terminál szerveres megoldásokhoz. A Citrix ellenben úgy gondolja, hogy a VDI az SBC rendszerek kiegészítője és kiteljesítője – naná, hogy a zászlóshajó XenApp mellett ez nem is lehet másként. Végül a harmadik jelentős piaci szereplő, a Microsoft szerint a VDI ugyanúgy részigényeket kielégítő megoldás marad, mint a terminál kiszolgálók, az elosztott architektúra paradigma pedig még egy darabig marad.
Egy bizonyos, hogy az idei VDI rendszereknél az alábbi technológia korlátok (veszélyek) fennállnak, előfordulhatnak:

  1. Nem minden alkalmazás futtatható SBC környezetben, vagyis terminál szerveren, vagy VDI desktopokon. Jelenleg a grafika-intenzív alkalmazások (autocad, archicad) valamint a multimédia-alkalmazások (média lejátszók) egyáltalán nem, vagy csak speciális körülmények (például LAN kapcsolat megléte) esetén futtathatók bármilyen SBC rendszeren. Tegyük rögtön hozzá ugyanakkor, hogy éppen ez az a terület, amely a közeljövőben alapvetően változni fog: a Wyse TCX, a Treadici vagy a Microsoft Calista fejlesztések megoldják, de legalábbis túlnyomórészt orvosolni fogják a mai technológia korlátokat. Érdemes megnézni, mit tud ma az ICA protokoll, és mit egy RDP, ha a Wyse TCX technológiája segíti.

     

 

      

 
  1. Nem minden alkalmazás virtualizálható. Láthattuk a VDI rendszerben az állapot nélküli desktopok egyik fontos feltétele a rajtuk futó alkalmazások virtualizálása és igény szerinti gyors terítése. Azzal viszont kevés terv számol, hogy jelentős lehet azon alkalmazások száma, amelyet nem lehet virtualizálni. Ezeket vagy eleve a lemezképbe kell építeni, vagy utólag kell telepíteni hagyományos módszerrel. A “hagyományos” két dolgot is jelent: a virtualizált alkalmazások terítésének megteremtése mellett meg kell tartani a fizikai szoftverek telepítési (frissítési, eltávolítási, leltározási stb.) módszereit és rendszereit is – ez rontja a VDI megtérülését. Másrészt számolni kell az alkalmazások inkompatibilitási problémáival, amely végső soron a rendszerlemezképek szaporodását eredményezheti.
  2. Az eszközátirányítás nem mindig valósítható meg. A PC-khez a legkülönbözőbb szabványú I/O kapukon keresztül mindenféle külső eszközt csatlakozathatunk. Amikor a PC helyett távoli asztalon dolgozunk, akkor azt szeretnénk, hogy a helyi eszközhöz csatlakoztatott periféria a távoli asztalon is elérhető legyen. Az eszközátirnyítás viszonylag jól megoldott terület – de a projekt kockázatát épp ez a viszonylagosság okozza. A soros és párhuzamos portok átirányítását minden protokoll tudja – de például a DOT4 portokét – nyomtató/scanner/fax multifunkciós gépek kedvence – nem. Az ICA protokoll átirányít USB eszközöket Windows XP esetén is, ha viszont Microsoft RDP-t használunk, akkor a plug and play eszközátirányításhoz a kliens oldalon Vista Enterprise vagy Ultimate, a VDI oldalon pedig szintén Vista szükségeltetik (lásd korábban a Windows XP-re épülő VDI kockázatait). A teljes desktop kiváltáshoz mindenképp számba kell venni az átirányítandó eszközöket (soros port, párhuzamos port, USB eszközök, nyomtatók, scannerek, faxok, multifunkcionális készülékek, POS terminálok, webkamerák, digitális fényképezőgépek, smartkártya, beléptető rendszerek, adatgyűjtők stb. stb.) és alapos tesztelést kell végezni, miként működik – elfogadható sávszélesség használat mellett – az átirányítás.
  3. Az eszközátirányítás költséges lehet. Még ha sikerül is minden eszköz átirányítását technológiai szempontból megoldani, akkor is adódhatnak “nem technológiai” jellegű problémák. Képzeljünk el egy munkafolyamatot, amelyben egy távoli irodában (WAN vonal, kis sávszélesség)  6-10 oldalas szerződéseket, kérelmeket, dokumentumokat stb. kell bescannelni. Ha nincs is akadálya a képolvasásnak, mindenképp vizsgálatot igényel, milyen sávszélességre van szükség. Ha a beolvasott képek nagy adatmennyiséget jelentenek, akkor vagy lökésszerűen terheljük a hálózatot, vagy sokáig tart a képanyag feljuttatása a VDI gépbe. A “sokáig” mértékét a felhasználónak kell eldönteni. Ergo: a VDI implementálása nem pusztán technológiai mutatvány: az üzleti folyamatokra kiható átalakítás, tehát csak a végfelhasználók intenzív bevonásával lehet megvalósítani.
  4. Eszközátirányítás és vonalszakadás. A PC dedikát I/O csatornáin ritkán tapasztalható “hálózat kiesés”, nem így a VDI környezetben. Fel kell mérni, hogy vannak-e olyan alkalmazások, amelyek folyamatosan használnák a vonalakat (ahogy tették azt az I/O csatornákkal a PC-k esetén), és tesztelni kell, hogyan viselkednek kisebb illetve nagyobb vonalszakadáskor.
  5. Protokoll implementáció. Gyakran előfordul, hogy a vékonykliensekkel való takarékoskodás jegyében olyan változatot sikerül megvenni, amely az RDP protokoll nyilt forráskódú változatát tartalmazza. Ez kétségkívül olcsó megoldás, ám nem veszi figyelembe, hogy az rdesktop jelenleg még csak az RDP 5-ös funkciókészletét tartalmazza,, ezért a 6.0-ás és 6.1-es képességek (és ezek közé tartozik a plug and play eszközök átirányítása) nem működnek.

Változó folyamatok
Végezetül vegyük végig, hogy egy VDI projekt implementációja során milyen informatikai folyamatok változnak meg, és mit jelent ez a változás.

  1. Desktopok telepítése. A folyamat kettéválik, amennyiben gondoskodni kell a felhasználóhoz kerülő végberendezésről, illetve biztosítani kell a megfelelő alkalmazásokkal ellátott virtuális desktopot. Az végfelhasználói berendezések kihelyzése, mozgatása, cseréje a PC-hez képest akkor egyszerűbb, ha a PC nem állapot nélküli, vagyis a felhasználó beállítása és vagy adatai géphez kötöttek. Az előny az állapot nélküliségben rejlik. Ezen felül a vékonykliensek kevesebb mozgó alkatrészt tartalmaznak, ezért – általában – kevesebbet hibásodnak meg. (Viszont az üzemeltetői tapasztalatból állíthatom, hogy éppen úgy meghibásodnak: ethernet kártyák mehetnek tönkre villámláskor, tápegységek pukkannak el, I/O kapuk pöckei törnek le stb. stb. A merevlemez viszont nem száll el – mivel nincs). A vékonykliensek hosszabb élettartama miatt a kihelyezés/mozgatás/csere feladatok csökkennek, és gyakran a végfelhasználóra bízhatók. A VDI oldalon a desktop provizionálás automatizálható – ez a VDI rendszerek legkiforrottabb képessége.
  2. Desktop életciklus. A virtuális gépek életciklusa egészen más, mint a PC-ké. Dinamikusan jönnek létre és – megint csak: ha állapot nélküliek – dinamikusan szűnnek meg. A dinamizmushoz viszont igazítani kell néhány rendszert, például az Active Directory-t, ahol garmadával állhatnak a megszüntetett munkaállomás fiókok, vagy a hardver-szoftver leltárt végző alkalmazások, amelyekkel tudatnunk kell, mely gépek nem léteznek már. (A jobb VDI rendszerek ezt a munkát elvégzik). Ugyancsak felül kell vizsgálni (Vista és Windows 7 klienseknél), miként működik a termékaktiválás. Ha a gépek életciklusa 30 napnál rövidebb, akkor tiltani kell az aktiválást, ha ellenben hosszabb, akkor KMS-t kell üzembe állítani.
  3. Alkalmazások telepítése. Felül kell vizsgálni az alkalmazások telepítési rendszerét. Az összes virtualizálható alkalmazást célszerű virtualizálni, és dinamikusan felhasználóhoz rendelni. A nem virtualizálható szoftvereket viszont vagy lemezképbe kell ágyazni, vagy pedig a hagyományos disztribúciós módszerrel el kell juttatni a virtuális desktopokra. Amit lehet, érdemes terminál környezetben futtatni, mert nagyobb felhasználói sűrűséget érhetünk el – tehát olcsóbb rendszert hozhatunk létre. Mindez precíz szoftverkezelési rendszert, jól működő hardver/szoftver leltárt, helyesen implementált változáskezelést igényel.
  4. A felhasználói adatok tárolása. A korábbi felhasználói szabadságfok valószínűleg csökken. Szabályozni kell – technológiai eszközökkel is! – hova menthetnek adatokat a felhasználók, illetve azok az adatok/állományok milyen típusúak lehetnek. Kvótarendszert kell felállítani, a végfelhasználókat pedig oktatni kell, hogyan gazdálkodhatnak a nekik fenntartott tárterülettel. Az ilyen jellegű incidensek számának növekedésére kell számítani. Kellően nagy szervezet illetve projekt esetén a helpdesk munkatársak száma felülvizsgálandó (Persze célszerű a projekt “eredő” incidens-szám változásával kalkulálni. Itt épp nő az incidensek száma, máshol – a szabályozottságból fakadóan – valószínűleg csökken.)
  5. A felhasználói beállítások tárolása. Szinte bizonyos hogy a legkisebb VDI projekteket leszámítva minden esetben be kell vezetni a felhasználókat követő beállításokat (Romaing profiles). A profilok kezelése történhet az virtuális desktopok operációs rendszereinek beépített képességeivel vagy egy profile menedzsment eszközzel. Az beépített eszközök olcsóbbak, de jónéhány problémát nem oldanak meg (Last write wins; profile növekedés; betöltési idő; virtuális alkalmazások stb. stb.). Emellett minél régebbi operációs rendszerről van szó, annál több korláttal rendelkezik a profile-kezelés (lásd: Windows XP-re épülő VDI). A Profile menedzsment eszköz persze drágább, de néha része egy gyártó VDI megoldásának, lásd Citrix.
  6. Mentési eljárásrend. A PC-kről bekerülő jelentős mennyiségű adat mentését a mentési eljárásrendbe be kell vonni. Ma már rendkívül sok olyan technológi létezik, amelynek segítségével terabájtok mentése is viszonylag gyorsan megoldható szinte folyamatos jelleggel, ezek a megoldások viszont pénzbe kerülnek, és kicsi a valószínűsége, hogy a VDI projekt keretében meg lehetne oldani. Mindenesetre a tárolási és mentési eljárásrendeket a becsült adatnövekedés függvényében felül kell vizsgálni, és gondoskodni kell, hogy a mentési időablak továbbra is elfogadható maradjon.
  7. OS frissítés. A mesterpéldányos virtuális gép használatával lehetővé válik, hogy az egyetlen mesterpéldány frissítésével minden virtuális gépre azonnal frissítés kerüljön – ezt mindenki tudni véli, pedig nem így van. A mesterpéldány mindig csak olvasható, módosításával minden belőle származó virtuális gép megszűnik, vagy, a régi gépek nem látják a frissítést, csak az újak. Jól meg kell tehát tervezni a virtuális gépek életciklusát, hogy adott időn belül minden régi gép eltűnjön és csak újak maradjanak. Azt már alig szokták megemlíteni a gyártók, hogy a frissítések kezelésénél nem a telepítés a legdrágább mozzanat, hanem a frissítések tesztelése. Ebben a tekintetben NEM kapunk segítséget a VDI rendszerektől. 
  8. Alkalmazások frissítése. A virtualizált alkalmazások frissítéséhez más eszközök szükségesek, mint a fizikai alkalmazásoknál megszokottak. A virtuális alkalmazásoknál – jelenleg – manuálisan kell újranyitni, és frissíteni az alkalmazás-csomagot. Implementációtól függ, hogy ezt mely gyártó hogyan támogatja. A frissítések jelenthetik a csomagok teljes újratöltését vagy csupán a különbségek disztribúcióját. A lényeg: a frissítés folyamata és munkaszükséglete változik, nő.
  9. Biztonsági események gyűjtése és egyéb külső elvárásoknak való megfelelés. A jellegüknél fogva dinamikus VDI rendszerek implementációja során számolni kell külső szabályozó szervek egyedi elvárásainak megjelenésével. Tipikus példa lehet erre a biztonsági események gyűjtése, illetve belső támadások, jogszerűtlen adathozzáférések vizsgálatának lehetősége. Amennyiben mondjuk fél évre visszamenően képeseknek kell lennünk meghatározni, hogy ki mikor honnan milyen adathoz fért hozzá, akkor ez nehézségekbe ütközhet egy VDI rendszerben, hacsak nem toljuk ki legalább fél évre a virtuális gépek törlésének határidejét. A probléma viszonylag könnyen orvosolható, de költséges lehet  – tárterületet kell biztosítani.

A folyamatok változásával kapcsolatos projekt veszélyek paradox módon viszonyulnak a projekt megtérüléséhez.: minél kisebb a változó folyamatok száma, annál nagyobb a siker esélye, annál kisebb a kockázat – ám annál kisebb a megtérülés is. Minél teljesebb VDI rendszert építünk, annál gyökeresebb átalakuláson kell átesnie a folyamatainknak is, több kockázattal, de egyben jobb megtérüléssel kecsegtetve.

Nem az IT-n múlik….
A cikk terjedelmes volta ellenére is bizonyára bőven maradtak fel nem tárt kockázatok a VDI projektekkel kapcsolatban. Egy fontos –kultúrális jellegű – veszélyt viszont még nem említettem. A korábbi bejegyzésben röviden összefoglaltam, hogyan került a PC a vállalati informatikai rendszerbe és miként vált elsöprő erővel új paradigmává az elosztott architektúra. A kezdeményezők a felhasználók voltak, az “elszenvedők” pedig az informatikusok. A felhasználók kezelhették a saját adataikat, önállókká válhattak, a korábbiakhoz képest szabad kezet kaptak. Az informatikusok viszont kevésbé voltak képesek felügyelet alatt tartani a rájuk bízott eszközöket, és a új biztonsági, üzemeltetési feladatokkal szembesültek.

image

Az Informatikus-végfelhasználó ellentét – ha más-más igényszint mellett – ma is fennáll. De ma már nem csak önálló munkáról, hanem bárhonnani hozzáférésről, rugalmas konfigurációról, multimédia-támogatásról, összetett kommunikációs eszközök biztosításáról is szó van.

A VDI rendszer többnyire az informatikusok elképzelése arról, hogyan kell munkakörnyezetet biztosítani a végfelhasználóknak. Hogyan kell “rendet tenni a káoszban”, ellenőrizni azt, ami “kicsúszott a kezünkből”. Az informatikusok forradalma. Vagy ellenforradalma? Hagyjuk a politikai címkéket! A VDI projektek óriási hátrányból indulnak, ha nem felhasználók kezdeményezik és nem az ő igényeiket elégíti ki. Az ítéletet végső soron ők mondják ki: elfogadják, ha meggyorsítja a munkát és megkönnyíti a folyamatokat; elutasítják ha akadályokat gördít eléjük és visszalépésnek érzik. Végső soron a felhasználók döntenek – nem előre, hanem utólag. És ha nem kapják meg, amit szeretnének, akkor a VDI ugyanarra a sorsra jut, mint a mainframe-ek. Eltűnik.

A legjobb projekt-kockázat csökkentő módszer: a felhasználók bevonása a projektbe. A lehető legnagyobb mértékben.

8 Responses to VDI – projekt kockázatok

  1. Gábor says:

    Itt azert tobbrol is szo van, mint a Windows XP kioregedeserol. Sajnos a Vista tulsagosan nagy valtozast hozott rengeteg ceges szoftver eleteben, es bizony-bizony, sokszor kell kuzdeni az inkompatibilitassal, illetve – a kisebb ellenallas elve menten – sokszor szukseges az XP alapu desktopok hasznalata. Amig a kulso gyartok mindegyike nem jon ki a sajat, Vista-kompatibilis termekevel – ez pedig meg a jelenhez kepest is tobb ev lehet – addig letezni fognak XP-k, es szukseges lesz ezek tamogatasa valamilyen modon. Mivel itt egy 2000-XP valtashoz kepest sokkal nagyobb valtasrol beszelunk, sokkal tobb alkalmazast is erint ez a dolog, mint amaz erintett. En szemely szerint egy ekkora valtast kulon kezelnek a rendes release ciklusoktol.

  2. Tamas says:

    XP – Vista átállás. Ha mindezt 2006-ban írod, azt mondom OK. 2007-ben, azt mondtam volna, hogy hmm. Ma viszont 2009.-et írunk, két és fél évvel vagyunk a Vista megjelenése után. A Microsoft 2005-ben kezdte el felkészíteni a Windows világot az átállásra. Így számolva már 3 és fél év a felkészülési idő. Láttam már nagyvállalatot, aki nekiugrott egy kompatibilitási tesztnek: 130 alkalmazásból 110-el az égvilágon semmi gond nem volt, 20 esetben meg segített az ACT. És ez egy többezer gépes hálózat volt.Én nem mondom, hogy nincs kompatibilitási probléma, de szerintem – ma már egészen biztos – nagyobb a füstje mint a lángja.

  3. Tamas says:

    "elgondolkodtató, hogy miért legyen valaminek kétszeres memória igénye, ha fele annyiból is meg lehet csinálni. Értsd: ha a kolléga 512GB RAM-on is meg tudja írni a főnöke által írt levelet, akkor minek neki 1GB? Nagyon kiváncsi vagyok, hogy mit hoz a Windows 7, én már nagyon várom." Nos, az operációs rendszer nem csak a felhasználóé. Ne vedd csipkelődésnek: de szöveget szerkeszteni lehet 128 MB RAM-mal, sőt, visszamehetnénk akár 8 MB-ra is, a Win 3.1 azon már jól futott, a Word 6.0-nál pedig "ugyse kell több". Ebbe a kontrasztba állítva már azonnal mondható: aha, csakhogy az a régi operációs rendszer már nem felel meg a kor biztonsági/menedzselhetőségi/funkcionális szempontjainak. (És remélem érzed, hogy csak a kontraszt felállítása miatt írtam mindent, nem pedig bántásból). Ugyanez a helyzet az XP és a Vista esetében. A Vista a 2000-es éve végének igényeire készült: tud ASLR, meg kétirányú tűzfalat, meg több helyi GPO, meg Bitlocker-t, meg Registry virtualizációt, meg Aero-t, meg fel nem sorolom hogy még mi mindent nem, ez viszont "nincs ingyen". Világos, hogy a többletmemória nem a szövegszerkesztéshez kell, hanem sok-sok minden máshoz – amire adott esetben éppúgy szükség lehet. (Az már hab a tortán, hogy ráadásul a Vista gyökeresen másképp kezeli a memóriát, mint az XP, de ezt az ágat most nem fejtem ki.). A Vista fejlesztésénél azonban elkövetett a cég néhány baklövést (írnak erről is a neten, nem ragozom) – én is remélem, hogy a Windows 7-nél már nem ismétlődnek ezek a hibák.Egyébként lehet egy másik gondolatsorral is válaszolni: igen, egy szövegszerkesztéshez nem kell 1 GB memóra. De nem kell 512 MB-sem. 128 MB sem. És a terminál szolgáltatás meg is oldja ezt a problémát. Az SBC nem jelenti kizárólag a VDI-t. Persze, vannak helyzetek, amikor nem jó a TS, de hirtelenjében Te is olyat mondtál, amikor éppen hogy jó. Azt pedig, hogy a TS jobban skálázható, mint a VDI, azt nem csak én mondom, hanem nagyon sokan, ha másra nem Brian Maddenre érdemes hallgatni.Ami Massimo bejegyzését illeti (eléggé hasonló az ízlésünk, én is követem az ő bejegyzéseit) két gondolatom van:1. Megneveznéd a JEOS-t? Az VM Appliance nem tűnik átütő sikernek. 2. OK. Én megnevezem: Windows Server. Most azt hiszed, hogy viccelek, pedig nem. Azt a szót keresd, hogy Oslo."A desktop (de jó lenne erre egy normális magyar kifejezés) célja, hogy a kolléga el tudja végezni a munkáját." – Ahogy a munkahely nem csak arra való, hogy a munkánkat elvégezzük, ugyanez igaz a desktopra is. Amit ide leírtál, az egy őszinte IT hitvallás. Szerintem viszont ez másképp van."Mikor nem volt számítógép, akkor sem mellékeltek a papír/toll együtteshez mindenféle színes regényt és játékokat, hogy azzal is töltse az idejét". Igazad van, ezért a dolgozónak kellett behozni a Playboy naptárat, a gyerek meg a kutya fényképét, szervezni a kalákát a házépítéshez/kiránduláshoz/focizáshoz.A dolgok mindig személyesek. A PC is és minden virtuális munkakörnyezet. Ha bedeszkázzák az eget, akkor az emberek nem érzik jól magukat. És akkor az eszközeiket nem szeretik.Egyszer volt egy riport egy fiatal asztalossal a tévében. A riporter észrevette, hogy szépen kifaragta a gyalut, amivel dolgozott. Kérdezte tőle, hogy ezt ő faragta-e. Igen. Miért faragta ki? – jött az újabb kérdés. – Hát, egész nap ezt nézem. Rondát lássak?"A VDI életképtelenségének mond ellent az is, hogy már jónéhány referencia telepítés van több ezer végponttal, feltételezem, hogy ezen döntések nem ad-hoc történtek" – "…s miközben világos, hogy a megoldásnak van helye a nap alatt…""Kitűnő példa erre a VMotion/Live Migration témakör. Ha annyira nem lenne fontos, szerintem a Microsoft sem fektetne rá akkora hangsúlyt – számos cikkben/írásban már kvázi úgy súlykolják, mintha megjelentek termék/fícsőr lenne az R2" – még egyszer neki fogok futni egy cikknek ezzel kapcsolatban. Nem éppen e bejegyzés miatt, de ez katalizálta."sok esetben átjön egy "savanyú a szőlő" effektus: nekünk nincs ilyen technológiánk, ergó annyira nem fontos és nem is jó " – Nos, a VDI egy összetett technológia, ebből a Microsoftnak tényleg nincs meg minden, de azért ami van, az sem kevés: – vékonykliens OS (WinCE, XP Embedded, WinFLP) – RDP Protokoll – System Managment – Guest OS (XP, Vista) – Hypervisor (Hyper-V) – Alkalmazás virtualizáció (App-v) – Profil virtualizáció (GPO, Offline files, Roaming Profiles) – Termal Server – Terminal Server Gateway, TS WebAccess, RemoteAppÉs igen, a Connection Broker még csak készül. A fontos / nem fontos témát az újabb QM/LM cikkben ki fogom fejteni. A magam részéről az LM demót bemutató cikkben is állítottam, hogy mindazt fenntartom, amit korábban írtam. Egyébként az MS is fenntartja, ha figyelmesen nézed a híreket.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: