Tények és tévhitek az alkalmazás-virtualizációról

A minap levelet váltottam egy ügyfelünkkel, ahol Windows 7 bevezetést terveznek. Megkérdeztem tőlük, hogy számolnak-e alkalmazás-virtualizációs megoldással. Egy elhaló “nem” volt a válasz, meg az, hogy  “tulajdonképpen nem sokat tudnak róla”.

Egy-két hónapja egy induló VDI kezdeményezésnél, amikor az alkalmazás-virtualizációt szóba hoztam, az üzemeltetési vezető azonnal leállított: “nem akarom túlbonyolítani a projektet.”

A héten megbeszélést tartottunk. Egy ügyfelünknek mutatjuk be a Windows 7 újdonságait, új lemezképet (image) terveznek, meg persze teljes átállást. Amikor a saját kollégáim előtt az alkalmazás-virtualizációt megemlítettem, rendre utasítottak, miszerint “ezek a fiúk most Windows 7 image-et terveznek, nem pedig alkalmazás-virtualizációt”.

Se szeri, se száma az ilyen és ehhez hasonló reakcióknak. Pedig három éve, amióta a Microsoftnál dolgozom, ha az operációs rendszer átállás szóba került (és tessék elhinni, ez még a Vista idején is gyakori volt) mindig volt rá érkezésem, hogy az alkalmazás-virtualizáció fontosságát hangsúlyozzam. De nem csak erre volt: Budai Petivel nap mint nap találkozva volt alkalmunk a témát alaposan tárgyalni, ezért aztán a Technet minden fórumán (újság, amíg volt, blog, weblap, előadás, screencast) felhoztuk a App-V témát. Akinek vállalati környezetben csak egy kicsit is megfordult a fejében, hogy Windows 7-et használ, az találkozhatott az “igehirdetésünkkel”. Úgy tűnik, még nincs áttörés. Vajon miért nincs?

Biztos, hogy az alkalmazás-virtualizáció körül rengeteg a tévhit. Most helyben cáfolok néhányat:

  • Az alkalmazás-virtualizáció olyan, mint a szerver virtualizáció. Mivel nekünk szerver virtualizációnk már van, alkalmazás-virtualizációra igazából nincs szükségünk. – TÉVEDÉS. A szerver virtualizációnak és az alkalmazás-virtualizációnak csupán annyi közük van egymáshoz, hogy mindkettőnél érvényesül az izoláció elve, vagyis az, hogy valamit elválasztunk valami mástól. Ezen túl azonban semmi sem közös bennük. Pár példa:
    • A szerver virtualizációval operációs rendszereket választunk el a hardvertől. Az alkalmazás-virtualizációnál alkalmazásokat választunk el egymástól.
    • A szerver virtualizáció bináris traszlációra, ring-compression-re vagy hardveres virtualizáció támogatásra épül. Az alkalmazás virtualizációnál egyik funkciót sem használjuk, operációs rendszer hívásokat irányítunk át.
    • A szerver virtualizációnál operációs rendszereket virtualizálunk. Az alkalmazás virtualizációnál (jelenleg) desktop alkalmazásokat.
  • A szerver virtualizáció és az alkalmazás virtualizáció egymást kizáró lehetőség. TÉVEDÉS. Ahogy láttuk korábban, egy közös elvtől eltekintve semmi közük egymáshoz. Lehet-e autóm, ha van hűtőm? A kérdésnek sincs értelme.
  • Az alkalmazás virtualizációval szükségtelenül elbonyolítjuk a megoldásainkat. TÉVEDÉS. Az alkalmazás-virtualizációval egyszerűsíthetjük a ma még bonyolult környezetünket.
  • Az alkalmazás-virtualizációval feleslegesen duplikáljuk a szoftver-terítési módszereinket. TÉVEDÉS. Az alkalmazás-virtualizációval egyszerűsíthető a szoftver-disztribúció. Az alkalmazás-virtualizáció – legalábbi a Micorosoft esetében – teljes mértékben integrált a Microsoft általános szoftverterítő megoldásával a System Center Configuration Manager 2007 R2-vel.
  • Az alkalmazás-virtualizáció alkalmazás-streaminget jelent. (Nekünk olyan nem kell). TÉVEDÉS. Az alkalmazás-virtualizáció nem kell, hogy együtt járjon a streaminggel. Alkalmazás virtualizációs kliens működhet önmagában, szerver nélkül, workgroup környezetben is. A streaming egy hozzáadott képesség, de semmiképp sem kötelező.
  • Az alkalmazás-virtualizációval majd akkor kell foglalkoznom, amikor az alkalmazások terítését akarom racionalizálni. TÉVEDÉS. Az alkalmazások felhasználóhoz juttatásának sok módja és sok akadálya van. A desktop alkalmazások életciklusa nem csak a telepítésből, terítésből, de a tesztelésből, frissítésből, eltávolításból is áll. Az alkalmazás-virtualizáció minden munkafázis során nagy hatást képes gyakorolni és sok felesleges fejfájástól képes megszabadítani egy IT csapatot.

Ezt az utolsó tévedést külön kiemeltem, mert ezt tartom a legveszélyesebbnek. Az alkalmazás-virtualizációt a neve ejti rabul. Az “alkalmazás” azt sugallja, hogy csak az alkalmazásokat érinti, a virtualizáció pedig a szerver virtualizációval való összevetésre sarkall. Nem, nem és nem.

Az alkalmazás virtualizáció egy olyan technológiai megoldás, amely az desktop alkalmazások teljes életciklusára, végeredményben pedig a digitális munkakörnyezetek egészére kihat, az ezzel kapcsolatos munkákat, tevékenységeket drasztikusan megváltoztatja, egyszerűsíti. Nem hiszed? Most figyelj:

Előkészítés, telepítés

  • Mivel az alkalmazás-virtualizációval előkészített szoftverek nem igényelnek telepítést, elegendő csupán kiajánlani őket. Ha az ikonjaikra kattintunk, automatikusan letöltődnek és elindulnak. Ez drasztikusan leegyszerűsíti a lemezképek készítését, mivel minden alkalmazás kihagyható belőlük. Majdnem elegendő egy alap operációs rendszer.
  • Ha VDI megoldással kacérkodunk, kritikus lehet a lemezkép méret minimalizálása. Az App-V ebben nagyszerű segítség lehet.
  • Ha mégis szeretnénk az alkalmazásainkat az image-ben tudni, akkor az SFT fájlokat elhelyezhetjük a App-V kliens cache-ben. A nyereség egyértelmű: nem kell azzal foglalkoznunk, hogy az egyik alkalmazásunk belehelyezése miatt esetleg nem fog működni egy másik alkalmazásunk. A jobb helyeken elmaradhat a regressziós tesztelés. Ahol ez eleve nem is volt, ott meg a véletlenül előforduló hibák száma csökken.

Aki  Windows 7 lemezkép készítésbe vágja a fejszéjét, ajánlom neki az ismerkedést az App-V-vel.

Kiajánlás, Terítés

  • Virtuális alkalmazásoknál csak a sequencing során, vagyis az előkészítéskor beszélhetünk telepítésről. A terítés nem más, mint az SFT állományok cache-be másolása és elindítása. Hacsak nincs elég hely a gépen, a terítés sikeres lesz, de legalábbis sokkal kevesebb lesz a sikertelen terítési kísérlet.
  • A kiajánlás AD tagságra épül és 30 percenként frissíthető. Vagyis, ha a felhasználó nem csinál semmit, 30 percen belül megkapja az új alkalmazását, vagy 30 percen belül elvehetjük tőle az addig nála lévőt.
  • A szoftver terítésére bármi alkalmas lehet: elindíthatjuk egy megosztott meghajtóról, USB kulcsról, a terítést integrálhatjuk SCCM-mel, sőt, mivel az App-V csomagok MSI-be ágyazhatók, mindenki használhatja nyugodtan a már megszokott disztribúciós mechanizmusát is (Tivoli, Altiris, LanDesk Zenworks stb.)
  • Az alkalmazások kiajánlása működhet akár Interneten keresztül is. Nem kell bejönnie a felhasználónak, sem VPN-nel csatlakoznia, de még Direct Access-szel sem kell rendelkezie ahhoz, hogy kapjon egy új virtuális alkalmazást, vagy annak egy frissítését. Elég egyetlen protokoll (https, 443) kipublikálása. Vajon mit ér ez a képesség egy ügynökhálózattal rendelkező cégnek?

Aki szoftver disztribúcióvaL foglalkozik, annak ajánlom az ismerkedést az App-V-vel.

Futtatás

  • Az alkalmazás virtualizáció izolálja egymástól az alkalmazásokat. Vagyis, olyan alkalmazásokat is futtathatunk egymás mellett, amelyek amúgy ütnék a másikat. Például:
    • Két Java motor. Az egyikkel egy banki szoftvert, a másikkal meg az ABEV-et.
    • ERP rendszer eltérő GUI verziói. Kockázat nélkül frissíthetünk LOB alkalmazásokat, tehetjük a különböző javítócsomagú verziókat egymás mellé.

Ismerek nem egy olyan magyar informatikai szervezetet, amelyek úgy oldották meg az inkompatibilis alkalmazások problémáját, hogy kettő PC-t adtak a felhasználónak. Vajon mennyit fizetne ez a cég azért, hogy a gépek felétől (de mondjuk legalább a 20%-ától) megszabaduljon?

  • Megtehetjük, hogy egy nagyobb szoftver rendszernél (Office, SAP stb.), amelyek lecserélése nehezebb, vagy előre nem látható kockázattal jár, az új verziót virtuális alkalmazásként terítjük. Így már kipróbálható az új, míg gond esetén elérhető továbbra is a régi.
  • Ugyanez a eset, csak fordítva: mindenhol bevezetjük az új szoftvert, de néhány problémás helyen virtuális alkalmazásként otthagyjuk a régit. Még az sem probléma, hogy nyilvántartsuk, mely felhasználóknak adtunk haladékot: csupán a megfelelő AD csoporttagságot kell ellenőriznünk.
  • Több olyan szoftver is lehet, amely igényel valamilyen alap-szoftvert. Ilyenek például az Excelekbe beépülő BI megoldások. Ilyenkor sem probléma az alapszoftver frissítése. Egyszerűen a BI megoldást egybe-sequenceljük a meglévő Excellel, majd kiadunk egy új Office-t, meg a régi BI megoldásunkat.  BI a régi Excel-t látja, minden más pedig az újat.
  • Mellékhatás ugyan, viszont gyakorlati tapasztalat, hogy a XP-n sequencelt alkalmazás nem dob fel UAC ablakokat. A Windows 7-tel ez a probléma ugyan csökkent, de nem tünt el. Érdemes kipróbálni. (Pl.: ABEV futtatása virtuális alkalmazásként)
  • A RDS (leánykori nevén Terminál) szerverek esetén különösen hasznos az inkompatibilis alkalmazások egymás melletti futtatása. Nagyobb implementációk esetén az inkompatibilis alkalmazások futtatását úgy oldják meg, hogy RDS (TS) silókat hoznak létre. Egy-egy silóban a felhasználók számától függően “N” db RDS szerver fut, és olyan alkalmazásokat telepítenek a kiszolgálókra, amelyek nem ütik egymást. Egy másik silóban meg másik alkalmazás-csokor található. App-V esetén ezek a silók (feltéve, hogy az alkalmazások virtualizálhatók) teljesen felszámolhatók.

Aki szoftvereket biztosít a felhasználók számára, annak ajánlom az ismerkedést az App-V-vel.

Frissítés, karbantartás

  • Szemben a hagyományos alkalmazásokkal, a virtuális szoftvereket a sequencerrel lehet frissíteni. Miután az új csomag elkészült, a felhasználók a következő indításkor már az új verziót kapják. Garantáltan sikeres frissítés, azonnal. Nem kell nézegetni a WSUS riportokat, hogy vajon az ilyen-olyan hotfix felment-e már a gépen y%-ára. A gépek nem igényelnek újraindítást.
  • RDS-nél a helyzet hasonló, csak éppen az eredmény még látványosabb. A kiszolgálót nem kell karbantartási üzemmódba rakni, a felhasználóknak nem kell sem kijelentkezni, sem a munkát felfüggeszteni. Aki még a régi példányt indította el, az még azt futtatja, az újonnan indított alkalmazások viszont már a javított verziót tartalmazzák. És persze nem volt szerver-újraindítás sem. Ezt csinálja meg valaki hagyományos alkalmazással!

Aki szoftver karbantartásal, foglalkozik, annak ajánlom az ismerkedést az App-V-vel

Támogatás

  • Mivel az alkalmazások elszigeteltek egyrészt egymástól, másrészt az operációs rendszertől, sokkal kisebb a valószínűsége, hogy összeütközések adódnak. Ezzel csökken a konfigurációs hibák száma.
  • A gyors alkalmazás-csere egységesebb alkalmazás portfólióhoz vezet. Ez megint csak a támogatási feladatok csökkenését jelenti.
  • Ha egy alkalmazás meghibásodik (pl.: tönkremegy az SFT fájl), elég csak törölni és újra behívni a cache-be. A művelet pár másodpercet vesz igénybe. Ezt kell összevetni egy újratelepítéssel.

Akinek felhasználói támogatás a feladata, annak ajánlom az App-V-t.

Eltávolítás, megszüntetés, kivonás

  • Akár csak a frissítés, az alkalmazások telepítése és cseréje is sokkal gyorsabb. Vajon hány olyan szervezet van, ahol a tehetetlenség miatt még mindig múlt évezredből, vagy a 2000-es évek elejéről való desktop alkalmazásokkal dolgoznak?
  • A felhasználók csak azokat az alkalmazásokat látják, amelyeket kiajánlottunk nekik. Abban a pillanatban, hogy megszűnt az AD tagságuk (OK, ahogy fentebb írtam, 30 percen belül), megszűnt az alkalmazáshoz való hozzáférésük is. Így aztán nincsenek hátramaradó alkalmazások.

Tudjuk, hogy “Párizs megér egy misét”. Szerintem az alkalmazás-virtualizáció is. És akkor még nem is túloztam.

One Response to Tények és tévhitek az alkalmazás-virtualizációról

  1. András says:

    Nagyon köszi a gondos és hasznos írást!Ugyan már többször hallottam Tőled a témáról és hozzá is tanultam, vagyis nem ismeretlen az alkalmazás virtualizáció, nekem nagyon hasznos a fenti gyűjtemény.Ismerős az érzés, amire következtetek az írásodból :) Nekem most a szívemhez legközelebb álló téma az "Optimális munkakörnyezet". Megelőzte a "szerelmet" és a "virtualizációt" :) Egy olyan forradalmi változást hozni képes, az üzemeltetést, de az egész IT infrát radikálisan egyszerűbbé és rendezettebbé hozni képes csokor, amit rettentően fontos lenne, hogy minden érintett értsen, megismerjen, felismerjen és használjon. Az elemei egyenként is megállják a helyüket, de így együtt jóval több, mint a részek összessége. Nem is bírom megállni, hogy ne hozzam fel minden kicsit is lehetőséget adó tárgyalás alkalmával. Általában türelmesen végig hallgatnak, néha látom a szemekben azt, amit már a te alkalmazás terítéses demód után is mindig látni, hogy "uh, de frappáns! basszus, ez ilyen egyszerű és gyors!?" de utána semmi. Nincs még áttörés. Nem túl jó ez az érzés, hogy van egy atom jó technológia, amiről látod, hogy sokaknak hasznos lehet, de ők meg nem látják és nem is tudod őket meggyőzni. Én eddig azt hittem, hogy egyedül az a gát, hogy az ismeretlentől tart a legtöbb ember. Csak szorgalmasan terjeszteni kell az igét, ha megérdemli a megoldás, el fogja érni a kritikus tömeget. A fent felsorolt tévhitekkel én kevésbé találkoztam, de ezután direkt rá fogok kérdezni néhányra. Kíváncsi vagyok.Kár, hogy itt sem és a technet-en sem divat hozzászólni azok részéről is, akiknek íródnak a cikkek :( Én baromi hálás lennék a véleményükért. Bár a techneten most nekem sem sikerült elküldenem a hozzászólásomat.köszi(ja, és még a "kiemelt tanácsadói program"-ban résztvevőknek, nem kis munkával létrehozott levlistáján sem divat visszajelezni, még akkor sem, ha konkrét kérdést teszel fel :( nem irigyellek és nem is értem.)

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: