Mellékleteink: HUP | Gamekapocs
Keres

Alkalmazás- virtualizáció

TechNet, 2008. december 15. 09:48
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

A virtualizációs megoldások általában -- az alkalmazásvirtualizáció pedig konkrétan ebben az írásban azt ígéri, hogy a tűzoltás mellett már másra is jut idő, mégpedig azért, mert a javasolt technológia az elvégzendő tevékenységek számát csökkenti és emellett még az előforduló hibák valószínűsége is kisebb lesz.

A rendszerüzemeltető informatikusok többsége minden szándék ellenére az állandó "tűzoltással" foglalkozik: folyamatosan esnek be hozzájuk az újabb és újabb panaszok, hibajegyek, miközben erejüket megfeszítve, és gyakran automatizmus nélkül igyekeznek teljesíteni az olyan legitim kéréseket, mint a szoftver-telepítés, gépcsere, szoftver-frissítés és még sorolhatnánk. A virtualizációs megoldások általában – az alkalmazás virtualizáció pedig konkrétan ebben az írásban azt ígéri, hogy a tűzoltás mellett már másra is jut idő, mégpedig azért, mert a javasolt technológia az elvégzendő tevékenységek számát csökkenti és emellett még az előforduló hibák valószínűsége is kisebb lesz.

Alapozás

Az alkalmazásvirtualizáció egy olyan technológia, amely elválasztja egymástól az operációs rendszert és a rá telepített szoftvert. Ahogy a szerver/hardver virtualizáció esetén az teljes operációs rendszerből, pontosabban azok virtuális lemezeiből egyetlen állomány keletkezik, úgy az alkalmazásvirtualizáció is egyetlen állományba zsúfolja a virtualizált szoftvert. Ezt a trükköt persze az alkalmazás "nem veszi észre", előttünk viszont, ahogy azt majd látni fogjuk, futurisztikus lehetőségek nyílnak meg.

A Microsoft és az alkalmazásvirtualizáció

A virtualizáció elvét a telepítendő szoftverekre alkalmazni viszonylag új keletű megoldás. 1999 júniusában négy IT-szakember, Harry Ruda, David Greschler, Stuart Schaefer és Owen Mysliwy megalapította a Softricity nevű céget, s azt tűzték ki célul, hogy a szoftvert úgy lehessen elérni, mint ahogy ma az elektromosságot. (Software + Electricity = Softricity) A Softricity első terméke volt a SoftGrid, az első alkalmazásvirtualizációs megoldás. A dotcom lufi kipukkadását a cég túlélte, az ígéretes termék szépen fejlődött, a vállalat nevét felkapták.

A Microsoft, amely 2003-ban felvásárolta a Connectix-et (a Virtual PC és a Virtual Server szoftverek gyártóját), egy komplex, az adatközpontban folyó tevékenységek mindegyikére kiterjedő megújítási stratégiát dolgozott ki Dynamic System Initiative (DSI) néven. A kezdeményezésben kiemelkedő szerepet szánt a virtualizációnak, annak szinte minden változatának. Így került a képbe a Softricity. 2006 júniusában létrejött az egyezség a két cég vezetői között, és a Microsoft felvásárolta a Softricity-t. A SoftGrid zászlóshajó terméke lett a később kialakított, előfizetéses jelleggel igénybe vehető Microsoft Desktop Optimization Pack (MDOP) szoftvercsomagnak. A fejlesztés természetesen nem állt le, és 2008. nyár közepére várható a legfrissebb, 4.5-ös verzió, immár a SoftGrid név nélkül. Az új termék neve Microsoft Application Virtualization 4.5 (MAV 4.5).

A MAV működési elve és komponensei

A MAV működése négy fő részre osztható. Az első fázis a virtuális alkalmazás elkészítése. Ezt a folyamatot "sequencing"-nek hívják, jellegét tekintve egyfajta csomagolás, intelligens "pillanatfelvétel" készítés. Azért intelligens, mert a sequencer -- tehát a műveletet végző segédprogram -- a kezdeti és végállapoton túl rögzíti, hogy a virtualizálandó szoftver betöltésekor mely állományokra milyen sorrendben van szükség (innen a sequencing, "sorrendberakás" kifejezés). Ráadásul még olyan műveletek is elvégezhetők, mint a Microsoft Update-ről való alkalmazás-frissítés, vagy akár a beaktiválás. Látható, mindez sokkal több, mint egy egyszerű különbségképzés. A végeredmény egy SFT kiterjesztésű állomány, amely az alkalmazás összes komponensét tartalmazza, továbbá még néhány, a csomag közzétételéhez szükséges konfigurációs fájl.

A második fázis a publikáció és a szoftver eljuttatása a megfelelő eszközre. A MAV a regisztrált csomagokhoz adott Active Directory csoportoknak ad hozzáférést. Aki egy ilyen csoport tagja, az elérheti az alkalmazást, mások nem. A publikáció az Application Virtualization Management Serveren végezhető el a MAV MMC konzol segítségével. Sok más mellett itt állíthatók (opcionálisan) a csomagokra vonatkozó licencelési szabályok. E funkció segítségével lejárati időt adhatunk egy csomagnak, meghatározhatjuk az összes lemásolt SFT-fájl számát vagy éppen az egyidejűleg használt szoftverpéldányok mennyiségét. Ha a csomagot regisztráltuk és a megfelelő AD csoportnak kiajánlottuk, a célba juttatásról az Application Virtualization Streaming Server gondoskodik. Ez a harmadik fázis.

Bármilyen furcsán hangzik elsőre, a szoftver -- vagyis most már az SFT fájl -- úgy érkezik, mint egy internetes rádióadás-folyam, sőt, még a protokoll sem különbözik (RTSP – Real Time Streaming Protocol TCP 554). Mivel a sequencing fázis során az SFT-fájlban a szoftverindításnak megfelelő módon helyezkednek el az állományok, az adatfolyam célgépre juttatása során mód van csupán az "éppen elégséges" szoftverkód lejuttatására. A gyakorlatban ez azt jelenti, hogy az SFT-nek mindössze 20-30 százaléka kerül a végfelhasználó gépére és máris elindul a szoftver. A koreai súgó meg letöltődik, ha majd szükség van rá.

Eltekintve a furcsának tűnő streaming technológiától, a szoftver lényegében fájlmásolással kerül a desktopokra, ami egyben azt az érdekes helyzetet idézi elő, hogy az alkalmazás "azt hiszi" egyes egyedül "ő" települt és fut az operációs rendszeren (pedig nem), az operációs rendszer ugyanakkor "azt hiszi", hogy érintetlen, és semmilyen szoftver nem került rá (pedig de).

A negyedik fázis főszereplője a munkaállomásokra telepített MAV kliens, melynek háromféle feladat van. A MAV szoftverpublikációkat észleli és az operációs rendszert ennek megfelelő konfigurálja. Ha egy felhasználó jogosult egy adott virtuális alkalmazás futtatására, akkor a MAV kliens gondoskodik az alkalmazást reprezentáló parancsikonok, környezet-érzékeny menük, fájlasszociációk megjelenéséről, mintha az alkalmazás már a gépen lenne. Mikor aztán a felhasználó kettőt kattint az alkalmazás ikonján, a MAV kliens adatfolyamként letölti a streaming szerverről a szükséges mennyiségű kódot a desktopra, pontosabban a MAV cache-be, és a programot elindítja.

Végül a MAV kliens felelős a virtuális környezet biztosításáért. Szemben a hardvervirtualizációval, itt nincs szó emulációról. A MAV kliens figyeli a virtuális alkalmazás rendszerhívásait és meghatározott hívások esetén átirányítja azokat. A virtualizált alkalmazás az operációs rendszer és a sequencing során rögzített rendszerparaméterek egymásra vetített változatát látja anélkül, hogy ezt az "egymásra vetítést" érzékelné.

A fenti módon a következő komponensekre való hivatkozást lehet átirányítani:

  • Fájlok (rendszerfájlok is!)
  • Registry kulcsok és értékek
  • Betű állományok
  • .ini állományok
  • COM/DCOM objektumok
  • Szolgáltatások
  • Névterek
  • Szemaforok, Mutexek

A felsorolt rendszerelemek elérésekor a MAV kliens átirányíthatja a hívásokat az SFT-fájlba. Az átirányítás igény szerinti. Ha például az alkalmazás telepít magával egy betűkészletet, akkor futáskor úgy látja, mintha az adott desktopon a betűkészlet fent lenne. Amikor ténylegesen meghívja valamelyiket, akkor a MAV kliens -- az alkalmazás számára nem észlelhető módon -- átirányítja őt az SFT-fájlba, ahonnan a készlet betöltődik. Hasonlóan működik a többi átirányítás is. A művelet olyan gyors, hogy a futási teljesítményvesztés még az 1 százalékot sem éri el.

Természetesen nem minden műveletet kell átirányítani. Az SFT-fájlban nem található objektumok (rendszerfájlok- és szolgáltatások, COM névterek stb.) rajta vannak a gazdagépen, amit az alkalmazás természetes módon, változtatás nélkül képes elérni. Éppígy működnek a lemezműveletek: a virtualizált WINWORD.EXE a valóságos mappákból valóságos dokumentumokat nyit meg, sőt, a felhasználó beállításait is a valóságos profiljából tölti be. Fontos hangsúlyozni, hogy a virtualizált alkalmazások helyben futnak, éppúgy, mintha telepített alkalmazások lennének. Szépen látszanak például a feladatkezelőben.

Itt jegyezzük meg, hogy bár működhet/elindulhat egy alkalmazás az SFT fájl 20-30 százalékának letöltésekor is, ez nem zárja ki azt, hogy az SFT-t teljes egészében letöltsük, sőt, erre szükség is van kapcsolat nélküli üzemmód esetén. Vagyis, ami nagyon fontos, a MAV képes futtatni a virtuális alkalmazásokat hálózat nélküli állapotban (sőt, még nem 100 százalékos letöltöttség esetén is, de ekkor persze rizikós egy-egy funkció elérése.)

A MAV technológiai korlátai

Nem lenne teljes a kép, ha nem mondanánk el, milyen korlátai vannak a fenti megoldásnak a technológia jelen állása szerint. Nem minden alkalmazás virtualizálható. Ökölszabályként azt érdemes megjegyezni, hogy a kernelmódú komponenst, eszközmeghajtót tartalmazó szoftverek nem csomagolhatók be. Ebbe a kategóriába tartoznak az Antivirus szoftverek vagy CD/DVD-író programok. Ugyancsak nem virtualizálhatók a Com+ komponenseket használó szoftverek, a hardverhez kötődő szoftverek (pl.: a gép MAC-címét ellenőrző megoldások) Teljes bizonyossággal csak az SFT-fájl alapos tesztelése után mondható ki, hogy az alkalmazás virtualizálható. Végül érdemes megemlíteni, hogy a 4.5-ös megoldás még csak 32 bites változatban érhető el, tehát a 64 bites terminál szerverek nem lehetnek MAV-kliensek.

A cikk több oldalból áll:
Facebook
Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.