Alkalmazás- virtualizáció

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.

[oldal:Felhasználási területek]

A MAV komponensek rövid áttekintése után nézzük meg, hogy ez a viszonylag egyszerű technológia milyen lehetőségeket teremt az üzemeltetők számára. Az itt felsorolt felhasználási területeket ne tekintse az olvasó teljes listának, hiszen csak a fantázia szab határt az alkalmazhatóságnak.

Gyors alkalmazás kiajánlás (provizionálás): A már meglévő csomagok esetén a kiajánlás egy Active Directory csoporttagság beállítására egyszerűsödik. Amint a csoporttagság változását érzékeli a MAV kliens, az alkalmazás ikonja, hivatkozásai, fájl-hozzárendelései megjelennek a felhasználó számára.

Gyors, rugalmas „telepítés”: A virtualizált alkalmazást nem kell telepíteni. Amikor a felhasználó elindítja, magától letöltődik és elindul.

Inkompatibilis alkalmazások párhuzamos futtatása: Az átirányítási technológia lehetővé teszi, hogy minden virtualizált alkalmazás a maga kívánta környezetet lássa, ezáltal párhuzamosan "telepíthetővé" és futtathatóvá válnak egymás létezését kizáró szoftverek is. Két eltérő Java virtuális környezetet igénylő szoftver a maga java futtatójával összecsomagolva párhuzamosan futhat, de ez a helyzet két (sőt akár három vagy négy!) Office verzióval is.

Gyors és biztonságos verzióváltás: A fenti jellemző kihasználásával egy alkalmazás újabbal való lecserélése sokkal gyorsabbá, és ami még ennél is fontosabb, biztonságosabbá válthat. Egy hagyományosan telepített Office 2003 mellé gond nélkül kiajánlhatunk egy virtualizált Office 2007-et. Probléma esetén a gépen maradt korábbi verzió használható, az Office 2007 biztosan nem rontja el az COM/DCOM névtereket. A megfelelő idő elteltével pedig az Office 2003 eltávolítható.

Teljes verzióváltás a maradék szoftverek megtartásával: Az előző példa fordítva is működik. Telepíthetünk hagyományos módszerrel Office 2007-et, és ha például egy részlegen egy régi Access 97-re írt partizán-szoftvert futtatnak, annak virtualizálásával megoldható az új vállalati Office szabvánnyal nem kompatibilis alkalmazások megőrzése is.

Eltérő beállítások alkalmazása: Az Internet Explorer maga nem virtualizálható, de a beállításai igen. Így lehetséges például házirenddel minden ActiveX vezérlőt letiltani, de egy olyan virtuális példányt mégis el lehet indítani, amelybe becsomagoltunk egy, általunk fontosnak ítélt vezérlőt.

Terminál szerver (Citrix) silók megszüntetése: az inkompatibilis alkalmazások komoly méretezési problémát jelentenek a terminál szervereknél. A hagyományos megoldás általában az, hogy két-három ún. silót (szerver-csoportot) hoznak létre: egy-egy silóban csak olyan terminál kiszolgáló található, amely azonos alkalmazásokat futtatnak. Más silókban más, az előző silóval nem kompatibilis alkalmazások futnak. Ez a szerverek számát, ezzel együtt a licence-költségeket jócskán növeli. A MAV lehetővé teszi, hogy a silókat megszüntessük, és csupán egyetlen csoportot hagyjunk meg úgy, hogy az inkompatibilis alkalmazásokat virtualizáljuk.

Többgépes/barangoló felhasználók: Az MAV a felhasználókhoz rendeli a szoftvereket. Mivel az AD csoporttagság minden gépen azonos, ezért MAV kliens esetén az alkalmazások automatikusan követik a felhasználót.

Gépcsere: Ha a személyes beállítások mappaátirányítással központilag letölthetők, a végfelhasználói munkaállomások állapot nélkülivé válnak, vagyis a gépek cseréje, tartalékgépek átmeneti kiadása lényegében nem igényli a rendszergazdák közreműködését, miközben minden felhasználó mindig ugyanolyan környezettel találkozik.

A több desktopos üzemmód megszüntetése: Az inkompatibilis alkalmazások problémájának egyszerű megoldása az adott felhasználóknál a két (három?) PC megjelenése, terminál szerver alkalmazása, VDI megoldás implementálása. Ezek a megoldások teljes mértékben kiküszöbölhetők. Fura, de ebből egyenesen következik, hogy az alkalmazásvirtualizációval akár a felhasználói gépek száma (és azok minden költsége) is csökkenhet.

Kevesebb operációs rendszer lemezkép: A telepített, de egymást kizáró alkalmazások jócskán okoznak többletfeladatot az operációs rendszer lemezképek létrehozásánál és karbantartásánál. Elvileg minden egyes telepített komponenst minden mással le kell tesztelni kompatibilitás szempontjából. Ez a regresszió tesztelés annál hosszabb folyamat, minél több szoftverről van szó, de csak így lehet bizonyosan hibátlan lemezképet előállítani. A MAV lehetővé teszi, hogy ad absurdum egyetlen felhasználói szoftvert se telepítsünk az operációs rendszerre. Akár egy több ezer PC-vel rendelkező szervezet is elboldogulhat egyetlen, jól kialakított lemezképpel. A költséges és hosszadalmas regresszió tesztelés teljes egészében elhagyható.

Active Update technológia: Még nem esett róla szó, de a sequencing támogatja a csomagok frissítését. Egy már elkészített Office 2007 csomagot újra meg lehet nyitni, frissíteni SP1-re, majd lezárni. A menedzsment konzolon megadható, hogy az új csomag az előző frissítése. A felhasználó a már elindított alkalmazást gond nélkül használhatja, a következő indításkor pedig -- hip-hip barbatrükk -- már az SP1-el frissített csomag indul el. Tehát nem 3000 Office-t kell frissíteni, hanem csak egyet! (A frissítési technológia ennél még sokrétűbb, de a cikken belül ezt nem taglaljuk.)

Felmerülő problémák

Ez idáig szép és jó. Öreg rókákat azonban nem vakít el talmi csillogás: a MAV -- bármilyen sok problémát old is meg -- számos kérdést generál. Mindenekelőtt mi lesz az olyan gépekkel, amelyek sohasem találkoznak a hálózattal? Eldugott helyen üzemelnek, vagy éppen biztonsági okokból sohasem kerülnek fel oda. Hogyan lehet ezután szoftverleltárt készíteni? Ha egy alkalmazás pusztán egy SFT állomány, akkor sem a Control Panel Programok részében, sem a fájlrendszer átfésülésével, sem a regisztrációs adatbázis böngészésével nem lehet megállapítani, milyen alkalmazások vannak ténylegesen egy gépen.

Mi lesz a gépeket megcélzó szoftverdisztribúciós mechanizmusokkal? Nem telepíthetünk géphez kötődő szoftvert? Mi a sorsa a WSUS-nak? Végül -- és talán ez a legnehezebb kérdés -- ha nekünk van már egy jól bejáratott szoftverdisztribúciós mechanizmusunk, akkor azt most le kell cserélnünk? El kell dobnunk mindazt, amit eddig felépítettünk? (A szoftverterítő alkalmazások megnevezése angolul "Electronic Software Distribution", és az ESD rövidítés használatos, mi is ezt követjük.) Ahhoz, hogy a fenti kérdésekre megnyugtató válaszokat adhassunk, meg kell ismernünk a MAV építőelemekből létrehozható szoftverterítési modelleket.

[oldal:Szoftverterítési modellek]

MAV infrastruktúrát a négy fázis alkotóelemeiből építhetünk. Csak ismétlésképpen: Csomagolás (Sequencing) – Közzététel (Publishing) – Célba juttatás (Streaming) – Futtatás (Launching and running). A fázisokat megfelelő szoftver-komponensek támogatják. A MAV 4.5-től ezek a komponensek külön-külön felhasználhatók. Ezek alapján három alapstruktúra képzelhető el.

Teljes kiépítés: minden komponenst felhasználunk, ahogy azt a fentiekben leírtuk. Ezt a modellt többnyire az adatközpontok követik.

Egyszerű kiépítés: A csomagolás után kihagyjuk a publikációt és csak a streaming kiszolgálót meg a klienst használjuk. A megoldás előnye, hogy sem AD-re, sem SQL kiszolgálóra nincs szükség (ideális megoldás távoli telephelyek esetén), viszont le kell mondanunk a szoftverhasználat méréséről és gondoskodni kell a publikálásról. Utóbbira jó lehet a központban felállított MAV Management server, vagy megoldható scripttel, de többnyire az ESD szoftverek végezik majd el.

Szerver nélküli kiépítés: A MAV 4.5-ös csomagolója az eljárás végén felajánlja, hogy az elkészült MAV csomagot még egy MSI kerettel is körbeveszi. A funkció opcionális, de a szerver nélküli kiépítésnél nagyon hasznos. Az MSI állomány CD-re, DVD-re másolható és bármikor "telepíthető", sőt, remekül felhasználhatják azok az ESD termékek, amelyek nem ismerik az alkalmazásvirtualizáció fogalmát. Az MSI keret összesen két feladatot lát el: a MAV csomagot 100%-ban betölti a MAV kliens cache-be, továbbá egy regisztrációs kulcs segítségével megjelenteti a szoftvert a Control Panel "Programok" részében, hogy a szoftverleltár helyes adatokat mutasson. Mindez azonban nem telepítés, a szoftver továbbra is virtualizált és élvezi a MAV kliens hordozta előnyöket: egymással inkompatibilis alkalmazások futtatása, az intakt operációs rendszer megőrzése stb. stb.

Az opcionális MSI-keret egyébként nem a 4.5-ös verzió újdonsága: 2007 decemberében a SoftGrid 4.2-höz jelent meg egy ingyenesen letölthető segédprogram, amely még különálló módon, de a fenti funkcionalitást biztosította.

Az MSI-keret, ahogy láttuk, megoldja a gordiuszi csomót. Ha egy IT-szervezet csak a kliensen tapasztalható alkalmazásvirtualizáció előnyökre vágyik, de meg kívánja tartani a hagyományos ESD rendszerét és nem szeretne dupla disztribúciós mechanizmust, ezt könnyűszerrel megteheti. Az integrációnak azonban van ennél magasabb szintje is: a System Center Configuration Manager 2007 R2 egyik legfontosabb képessége a MAV-val való igen szoros együttműködés.

SCCM 2007 R2 integráció

A MAV és SCCM együttműködés négy területre terjed ki.

1. Csomagolás és alkalmazás-disztribúció
2. Csomagterítés az SCCM hirdetéses (advertisement) mechanizmusával
3. Alkalmazás-futtatás
4. Leltár- és jelentéskészítés

Az SCCM 2007 R2 szerver- és kliens oldali komponensei is "ismerik" a MAV 4.5-öt. Ha például előzőleg az Application Virtualization Streaming szervert telepítettük, egy disztribúciós ponton tulajdonságként állítható, hogy a kliensekre hagyományos módszerrel, vagy streaming-el juttassa le a csomagokat. (Olyasfajta integráció ez, mint a WSUS és a WDS integráció: az SCCM az eredeti szoftvert további képességekkel ruházza fel)

A SCCM kliens is ismeri a MAV-os "kollégáját", regisztrálja magát, és intelligensen eldöntik, melyik csomag letöltését melyik kliens hajtja végre. Sőt! Az is előfordulhat, hogy az MSI-vel keretezett virtuális alkalmazásokat az SCCM kliens tölti le (hagyományos módon), de azután a MAV cache-be másolja, az indításról pedig a MAV-kliens gondoskodik.

Az integráció fő célja az, hogy a MAV infrastruktúrából az aktuális igényeknek megfelelően mindig annyit használjunk, amennyire szükség van. A szerverek vonatkozásában a legizgalmasabb együttműködési terület kétség kívül a disztribúciós pontok integrációja. A virtuális alkalmazások meghirdetésekor meghatározhatjuk, a kliens milyen módon indítsa a virtuális alkalmazást. Ha "Stream from DP" (Streaming delivery) opciót állítunk be, a felhasználói asztalra telepített ikonok a disztribúciós pontra mutatnak és az SFT állományok onnan is indulnak. (Hacsak le nem töltődtek korábban 100%-ban.) A "Download and Execute" (Local Delivery) ezzel szemben a parancsikonokat mindig a helyi MAV cache-ben lévő, 100%-ig letöltött SFT állományokra irányítja.

A SCCM funkcionalitását felhasználva a MAV-kliens mindig a legközelebbi disztribúciós pontról indítja a letöltést. Ehhez csupán arra van szükség, hogy az alkalmazások indításakor az SCCM kliens lekérdezze az SCCM menedzsment pont szervert, melyik a telephelynek megfelelő legközelebbi disztribúciós pont. A kapott eredmény alapján az SCCM ügynök módosítja a MAV kliens paramétereit, amely azután a helyes streaming-képes disztribúciós ponthoz fordul.

De nem csak a szoftverdisztribúció, hanem a szoftverfrissítés is integrált. Miután a MAV sequencerrel elkészítettük a frissített SFT-t, az SCCM bináris delta replikációval csak a különbséget replikálja át előbb a telephelyekre, majd a disztribúciós pontokra. A frissítésről a munkaállomások akkor értesülnek, amikor a rendszergazdák újrafuttatják az SCCM hirdetést. Ha a szoftvert a disztribúciós pontról indítjuk (Streaming Delivery) az új verzió azonnal elérhető. A helyi futtatás (Local delivery) opciónál a különbség BITS-el kerül a MAV cache-be és csak akkor indul el a frissített verzió, amikor a teljes csomagfrissítés befejeződött.

Az SCCM 2007 R2-nek már nem kell az MSI keretekre hagyatkoznia, amikor a virtuális alkalmazásokat szeretné számba venni. A MAV 4.5 egy új kliens WMI-providerrel rendelkezik, így már le lehet kérdezni a cache tartalmát, a letöltött programokat, azok verzióját, használatukat stb.

Licencelés

Számtalan alkalmazás virtualizáció témájú megbeszélés után biztosan állíthatom, a legnagyobb kavarodás a fejekben a licenszelés körül alakul ki. A villámgyors szoftverdisztribúció és gyors alkalmazás-eltávolítás miatt úgy tűnhet, mintha a MAV alapvetően befolyásolná a megvásárolandó szoftverek számát. Minderre még ráerősít a termékben található licenszelési funkció, a csomagok használatának időbeli korlátozás. Öntsünk tiszta vizet a pohárba ezzel kapcsolatban.

Az első és legfontosabb szabály, hogy a MAV egy technológia, tehát semmilyen módon nem változtatja meg a becsomagolt szoftverre vonatkozó licenszelési szabályokat. Konkrétan: ha a licensz egy adott géphez köti a szoftvert (tipikusan OEM konstrukciók), akkor a felhasználó alapú disztribúció megsérti a licensz jogokat. Ha viszont a licensz szerződés konkurrens használatra szól, vagy adott felhasználóhoz kötött, akkor a MAV kifejezetten segíti a konstrukció betartását. Jogi szempontból ugyancsak problémamentes azon szoftverek használata, amelyek egy teljes telephelyre vagy a teljes vállalatra vonatkoznak. (A Microsoft Enterprise Agreement tipikusan ilyen) A MAV az ilyen konstrukciókat korlátlan (Unlimited) típusnak ismeri. A szoftverhasználatról gyűjtött statisztika azonban még ekkor is hozzásegítheti az IT szervezetet, hogy a licensz költségeit csökkentse.

Külön megér néhány mondatot a MAV licenszelése is. A termék önmagában nem érhető el, hanem ahogy a cikk elején már említettük, a Microsoft Desktop Optimization Pack (MDOP) része, egyik komponense. Maga az MDOP egy éves előfizetéses konstrukcióban vásárolható, de csak azon szervezetek számára, amelyek érvényes Desktop frissítés-védelemmel (Desktop Software Assurance, vagy Desktop SA) rendelkeznek. A MAV komponensek külön nem igényelnek licenszt. Amennyiben a munkaállomások lefedettek MDOP licensszel, szerver-komponenst akárhányat telepíthetünk. Az MDOP licensz igény az SCCM 2007 R2 integráció esetén is érvényes. Vagyis az SCCM integrációs képességei csak meglévő MDOP-licenc esetén használhatók ki.

Zárszó

Az alkalmazásvirtualizáció legalább akkor potenciállal rendelkezik, mint a nála ismertebb hardvervirtualizáció, és éppúgy gyökeresen átalakítja az üzemeltetők életét. A változás- és konfiguráció-kezelési (change and configuration manangement) feladatokat teljes mértékben újra kell gondolni. Sajnos? Szerencsére? A választ nem nekem kell megadni. Egyben viszont bizonyos vagyok: a ma végfelhasználója borzasztóan kiábrándult az informatikából. Lassúnak, rugalmatlannak, nyögvenyelősnek tartja. Az alkalmazásvirtualizáció visszaadhatja a hitet a rendszerüzemeltetőknek és felhasználóknak egyaránt: lehet IT-t sokkal jobban is csinálni.

Lepenye Tamás
Microsoft Magyarország