Az előző részben azt taglaltam, hogy mérete ellenére a Microsoft viszonylag hamar felült a virtualizáció “vonatára”, de a ma is érvényben lévő stratégia csak évek alatt állt össze – körülbelül 2005-re. Kárhoztatták is eleget ezért. Azóta sok víz lefolyt a Dunán, a Microsoft pedig előrukkolt jópár termékkel, amely a virtualizációs üzlethez tartozik. A teljesség igénye nélkül – 2005 óta:

1. Virtual PC 2007; SP1; Windows Virtual PC
2. Microsoft Enterprise Desktop Virtualization (MED-V)
3. Softgrid 4.1; 4.2; App-V 4.5
4. Virtual Server 2005 R2; R2-SP1
5. System Center Operations Manager 2007; SP1; R2
6. System Center Configuration Manager 2007; SP1; R2
7. System Center Data Protection Manager 2007; SP1
8. System Center Virtual Machine Manager 2007; 2008; 2008 R2
9. Windows Server 2008 with Hyper-V; SP2; R2
10. Hyper-V Server 2008; SP2; R2
11. Microsoft Assesment and Planning 3.0; 3.1; 3.2; 4.0
12. Offline Virtual Machine Servicing 1.0; 2.0

Azt már nehéz jelezni, hogy a 2008 R2-ben connection broker található, meg a VDI megoldáshoz kiegészítő szolgáltatások. Szintén a 2008 része a RemoteApp (mint a prezentáció-virtualizáció alapja); hogy megújult a Microsoft Operations Framework; új "Infrastructure Plannig Guide”-ok jelentek meg a korábbi WSSRA helyett. Új licencek jelentek meg, mint a VECD, az SMSE, az SMSD, az ECI vagy a VDI. A desktop operációs rendszer is kiegészült új fejlesztésekkel, mint az RDP7. Végül de nem utolsó sorban úttörő lépéseket tett a Microsoft az SVVP program létrehozásával vagy azzal, hogy vállalati szabvánnyá tette a termékei számára a virtualizáció támogatásának követelményét, valamint meglepte a piacot a Linux IC nyílt forráskódúvá tételével.

Akárhogy is, a piac mégis csak a VMware utáni, második szereplőként tekint a Microsoftra. Sőt! Itt-ott felmerül, hogy tulajdonképpen a Microsoftnak rossz a virtualizáció. Most akkor fontos, vagy sem? Lehetőség, vagy veszély?

Meglátásom szerint a Microsoft úgy tekint a virtualizációra, mint az iparág egyik meghatározó trendje, amely az IT rendszereket alapjaiban alakítja át, és amely potenciálisan a teljes IT ökoszisztéma üzleti modelljét befolyásolhatja. Olyan alapvető innováció, amelyet nem lehet figyelmen kívül hagyni (Cisco), nem lehet ignorálni (Google), lebecsülni (Oracle), mellőzni (IBM). Ha nem tudod megakadályozni, akkor állj az élére! Értsd meg, tedd magadévá, használd fel arra, hogy átalakulj és túlélj. – Szerintem a Microsoft így tekint a virtualizációra. Belülről így látom.

Profitál-e a Microsoft a virtualizációból, és ha igen, hogyan?
Igen, profitál, méghozzá sokféleképpen. Rövidtávon:

• A szerverkonszolidáció és a Windows szerver licencelése miatt nőtt a magasabb hozzáadott értékű Datacenter verziók eladása. Ez jó az ügyfélnek, mert korlátlan számú virtuális gépet üzemeltethet processzoronként, és jó a Microsoftnak, mert homogénebb és korszerűbb infrastruktúrák jönnek létre, amelyekhez könnyebb újabb szoftvereket kínálni. Persze most éppen válság van, és ez a vasbeszerzéseken és ez a szerver operációs rendszerek értékesítésén látszik. Ezzel együtt én azt tapasztalom, hogy éppen a virtualizáció miatt a korábban frissítésvédelem (SA) nélküli kiszolgáló licenceket részben kidobják és új, SA-s licenceket vásárolnak az ügyfelek.
• Az alkalmazás- és a desktop virtualizáció a (Microsoftnál legalábbis) a nagyvállalati Windows licence-hez kötődik. Ez megint csak megújult architektúrát, korszerűbb rendszereket és a Windows licenceken keresztül árbevételt jelent.
• A virtualizáció belépési lehetőség (enabler technology) akár az adatközpontok, akár a desktop infrastruktúra felügyelet megújítására. Ha nyerünk egy virtualizációs tenderen, akkor az ügyfelek többnyire a teljes rendszerfelügyeletüket megújítják Microsoft alapon. Ha veszítünk, akkor – bár szerver licencek tekintetében nincs különbség – a menedzsment vonatkozásában árbevételtől esünk el. Világszinten a Microsoft ezen a területen relatíve jól muzsikál. Egyrészt a “Server and Tools” (S&T) üzletág szenvedte el a legkisebb visszaesést az utolsó, legdurvább negyedévben (-6%), éves szinten még növekedett is, másrészt a az S&T-n belül működő System Center részleg jó eséllyel pályázik a következő milliárd dolláros üzlet címre. Mindezt úgy, hogy mára mind a SCOM, mind pedig az SCCM a világ legnagyobb installált bázisával rendelkezik a maga kategóriájában, a Gartner elemzésekben pedig “Leader” illetve “Challenger” minősítéseket kapunk.

Mindezek azonban – bármennyire is jövedelmezők – csak részsikerek ahhoz képest, amit azzal lehet nyerni, hogy egy korszerű architektúrával és sikeres projekttel elnyerhető az ügyfél bizalma és “megbízható tanácsadóvá” (trusted advisor) lehetünk. A megbízható tanácsadó potenciálisan újabb és újabb üzleteket hozhat – hosszútávon.

A fenti előnyök “azonnaliak”. Azt gondolom azonban, hogy vannak hosszútávon jövedelmező dolgok is, amelyek jelenleg még akár viszik is a pénzt. Ilyen az Azure. Bizonyos, hogy az Azure rugalmassága mögött a virtualizáció (is) ott van. Hogy ez, vagy ilyen lesz-e a jövő informatikája, azt nem tudni. Annyi viszont bizonyos, hogy a jövő az automatizmus, az önhangoló, adaptálódó rendszereké. A Microsoft stratégiájából fakadóan ezek a termékek meg fognak születni. Ha az üzleti modell is releváns lesz a termékek mellett, akkor a Microsoft nem lesz vesztese a virtualizációs csatának.

Veszélyt jelent-e a Microsoft számára a virtualizáció?
Azt gondolom, hogy csak abban az esetben, ha a virtualizáció indukálta változásokat és a változások üzleti modellekre gyakorolt hatását a Microsoft nem ismeri fel. Mivel azonban ma már elég sok stratéga dolgozik a témán, és a Microsoft derékig benne áll a virtualizációs piacban, ennek az esélye kicsi. A virtualizáció jelentett múltban a Microsoft számára elmaradt bevételt, hiszen ha lett volna olyan “okos”, hogy a VMware helyett feltalálja az x86-os hypervisort, akkor a  VMware árbevételének java a Microsofthoz csengett volna. Ha azonban megnézzük, hogyan fest a Microsoft árbevétele az elmúlt harmincegynéhány évben, akkor ez nem látszik (Saját képeim a 2007-es MGXFY08-ról – a következő évben az árbevétel 60 milliárd dollár volt, majd a most záruló pénzügyi év végén 58,44 milliárd dollár volt, ez 3%-os csökkenés, a vállalat történetében először történt ilyen):

Külön érdemes foglalkozni a desktop virtualizáció témakörével. Sokan azt gondolják, hogy a virtualizáció egyúttal a Windows desktop, egyáltalán a Windows végét is jelentheti egyben. Ebben nem hiszek. A mai virtualizációs technológiák ugyan sokat gimnasztikáznak, de a végeredmény egy Windows gép becsomagolása és a használata. A Microsoft itt is veszíthet rendszerfelügyeleti árbevételt, de nem igazán látom, hogy tényleges Windows licence árbevételt veszítsen. – A böngésző ezzel szemben valód veszély a Windows világra, ez viszont nem témája ennek a cikknek.

Összegzés
A Microsoft számára a virtualizáció nagyon fontos. Óriási iparági trendnek tartjuk, egyúttal üzleti lehetőségnek is a rendszerfelügyelet és a felhő-informatika területén. Mivel a cég idejében meglátta mind a késlekedésből fakadó veszélyeket, mind a üzleti-potenciált, valójában a Microsoft a virtualizáció egyik nagy nyertese. Meglehet, hogy jelenleg még a VMware mögött, de a vele hasonló nagyságban lévő Cisco, Oracle és IBM előtt.

Bognár Attilának az előző cikkben feltett kérdése elgondolkodtatott. A Microsoft régóta itt van a virtualizációs piacon, de vajon mennyire fontos a cégnek ez a terület? Lehetőség, vagy inkább veszély? Ha lehetőség, akkor minek a lehetősége? Ha veszély, akkor milyen jellegű?

Kezdetek
Az egész – szerintem – azzal kezdődött, hogy a Microsoft létrehozta az MSN-t, 1995. augusztusában. Ekkor kezdődött annak a szerverparknak a kiépítése, amely 1998-ban kiegészült a Hotmail-lel, 1999-ben az MSN Messengerrel és még sorolhatnánk. Az egyre nagyobb szerverpark egyre komolyabb kihívást jelenthetett üzemeltetési szempontból. Gondolom részben ezért, részben meg a rendszerüzemeltetési piac vonzása miatt a Microsoft 2000 őszén licence megállapodást kötött a NetIQ-val, 2001-ben pedig kiadta a “Microsoft Operations Manager 2000” nevű terméket, amelynek legfrissebb utódja a “System Center Operations Manager 2007 R2”. Biztos vagyok benne, hogy a MOM 2000 nagy előrelépés lehetett a maga idejében, de gondolom azt is lehetett látni, hogy az óriási adatközpontok sokezer vagy sok tízezer szerverrel, elképesztő üzemeltetési feladatot jelentenek. (“For scale-out environments, management is not just important -- it's fundamental, and we're making it a major area of investment for Microsoft” – forrás innen.)

2001. egy másik szempontból is fontos éve. Ekkor jelent meg az 1998-ban alapított VMware nevű cég VMware ESX (Elastic Sky X) rendszere. A VMware, akárcsak a Google vagy Softricity, egy dotcom cég volt, amely – szemben a tényleges lufi vállalatokkal – egy valóban zseniális ötletet valósított meg, sőt, a lufi kipukkadása előtt az ESX-szel belépett a nagyvállalatokhoz, és a Google-höz hasonlóan óriásit alakított a maga területén. (Csak az időrend kedvéért: 1997-ben jelent meg egy Virtual PC nevű termék a Connectix-től Mac-re.)

A Virtual PC, meg a VMware Workstation – bár izgalmas termék volt – nem hozott földrengésszerű változást. Az ESX azonban más volt: aki tudta, hogy mi a hypervisor (mert tanulta az amerikai egyetemen, vagy éppenséggel használt a hatvanas években olyan az IBM gépeken), az hamar rájött, milyen potenciál van egy ilyen megoldásban és milyen változást hozhat egy adatközpont életében. Szerintem a Microsoft erre 2002. táján jöhetett rá, mert 2003 elején felvásárolta a Connectix-et, egy hónappal később pedig bejelentette a Dynamic System Initiative kezdeményezését. Későn történt mindez? Az első Xen is 2003-ban jelent meg, a Virtual Iron 2005 környékén fordul elő először a hírekben. A Sun Solaris container 2005-ben debütált. 2004. decemberi hír, hogy a RedHat és a Novell beépítik a Xen-t a saját rendszereikbe. Ha figyelembe vesszük a Microsoft méretét, diverzifikált erőfeszítéseit, azt kell mondani, hogy viszonylag gyorsan reagált az iparági változásokra. Persze nem szeretném azt állítani, hogy a Microsoft pontosan tudta, milyen lesz a jövő. De a sejtések nem voltak rosszak. Annyi bizonyos, hogy 2003 áprilisában a Direction on Microsoft által megjelentetett “Microsoft Management Roadmap Update” még nem tartalmazza azt a szót, hogy “virtual”, csupán azt, hogy a MOM és az SMS egy közös jelzőt kap, ez lesz a “System Center”. Egy évvel később megjelent a dolgozat frissítése, amely már megemlíti a Virtual Server-t is, de még érdekesebb az, amit a DSI-ről és az SDM-ről lehet olvasni. A 2004-es d dolgozat egyébként így kezdődik:

“Systems management is becoming a major priority at Microsoft: by the end of 2004 the company will deliver several new and substantially enhanced management products and technologies, and all development teams for systems management are now organized under a single leader, Kirill Tatarinov. While details about its radical and long-term Dynamic Systems Initiative (DSI) remain sketchy, the company will continue taking incremental steps to incorporate systems management into its entire business product line. These changes will deliver important benefits to customers even as work on DSI churns away in the background.”

Érdekes dolgok találhatók már ekkor a DSI-ról:

“A precise definition of the DSI is still evolving, but the company envisions it as a radical change in the way applications are developed, deployed, and operated over their life cycles. Most important: rather than support manageability through add-on, generic management products that incorporate little or no knowledge of specific applications or hardware, manageability will be built into applications, system software, and hardware from the outset.

DSI will accomplish this with a common management infrastructure that spans all elements needed for an application to function properly, and a System Definition Model (SDM) that will provide a Microsoft-standard method for building management knowledge into each hardware or software component during its design. Each component will have its own SDM, an XML document with all the information required to manage that component, including dependencies on OS components or other services, definitions of settings that can be configured through OS policy, definitions of variables and counters required to monitor the health of the component, and so on. Among other things, this will enable a new breed of business applications that use SDM information to form operational policies, and management tools which can detect when the overall system departs from those policies and flag what caused the departure.”

Mit is csinál a SpringSource?…

Visszatérve a Microsofthoz: a teljes kép, és az a fajta stratégia, amit ma is látunk, 2004 végén állhatott össze, és 2005. áprilisában hírdette meg a cég. Ekkor jelentette be, hogy hypervisort fog a Windows szerverekbe építeni; hogy a System Center termékcsalád képességeit kiterjeszti a virtualizáció irányába stb. stb.

Hogy hová csúcsosodott ki az DSI, az SDM, a virtualizáció (Hyper-V), a System Center és a Visual Studio együttesen? Nos, mindezen kezdeményezések, szabványok, termékek, szoftverek együttese tette lehetővé, hogy olyan szolgáltatások indulhassanak el a Microsoftnál, mint a Windows Azure.

Ah, és még valami: Igen, ezt is Hyper-V támogatja. Biztos, hogy nem érett még a nagyvállalatokhoz?

Folytatom

Azt hiszem, hogy kevés olyan terméke van a Microsoftnak, amelyet ennyire nem értenek a piacon, mint az épp most megjelent Hyper-V Server 2008 R2-t. Többnyire legendák terjednek róla, minthogy “kis és középvállalatoknak szánt”, meg a “Windows szerverbe integrált Hyper-V kistestvére”, meg “belépő szintű rendszer” stb. stb. Ezeket tessék gyorsan elfelejteni, a Hyper-V Server valami egészen más dolog…

Eredete és képességei
A Hyper-V Server technológiai értelemben egy olyan Windows Server Enterprise Editon, amely

• Csupán egyetlen szerepkört (Role) tartalmaz – ez a Hyper-V.
• Tartalmaz minden olyan “Feature”-t, vagyis tulajdonságot, amely a Hyper-V-vel kapcsolatba hozható (Fail-over cluster, WoW64, MultipathIO, .Net Framework)
• Kizárólag “Server core” módon telepíthető.
• Nem tartalmaz Windows Server licencet – ezért nem szerepel a nevében a “Windows” szó.

Mivel az Enterprise Edition lényegében csak licencelés szempontjából tér el a Datacenter verziótól, ezért nyugodtan mondhatjuk, hogy egy teljes értékű hypervisorral van dolgunk.  A “kistestvér”, meg “belépő szintű” jelzők elfelejtendők. Elég csak ránézni a Hyper-V Server skálázhatóságára:

• 64 processzormag támogatás, hyperthreading esetén akár 128 végrehajtási szál. Akár 8 magos processzorok is támogatottak.
• 1 TB fizikai memóra támogatás
• Maximálisan 384 futtatható virtuális gép
• Maximálisan 512 virtuális processzor.
• 256 TB lemezterület LUN-onként (!)
• 16 node-os fürt, maximum 1024 virtuális géppel
• Földrajzilag eloszott fürtrendszer támogatása, többfajta fürt-modell
• Clustered Share Volume
• Multipath IO támogatás
• VMQ, Jumbo Frames, TCP Offload, 10 GBitE támogatás
• Pass-through lemez támogatás 256 TB LUN-ig.

A helyi GUI-t leszámítva minden képességében megfelel a Windows szerverbe 2008 R2-be beépített Hyper-V-vel. Ezek közül van néhány meglehetősen érdekes:

• RD-Virtualization szolgáltatás – Ez a szolgáltatás kapcsolatot tart a 2008 R2 szerverben debütáló connection brokerrel és annak kérésére bekapcsolja/felébreszti az igényelt desktop operációs rendszereket. Vagyis a Hyper-V Server a Microsoft VDI megoldások építőköve is lehet, nem kell hozzá a Windows Datacenter változatát használni.
• VHD hozzáadás virtuális géphez működés közben. Egy futó virtuális géphez bármikor hozzáadhatunk még egy vagy több virtuális lemezt.
• Magas rendelkezésre állás (High availability) – a fürtszolgáltatásból ered.
• Quick / Live Migration – szintén a fürtszolgáltatásból ered
• VHD Boot – Érdekes felállás, hogy maga a fizika rendszer is egy VHD-ben található. 2008 R2 képesség.
• Boot from SAN – Már régóta meglévő Windows szerver képesség.
• Bitlocker – akár TPM modullal is támogatott, teljeskörű merevlemez titkosítás .
• Remote Desktop kapcsolat – akárcsak a Windows szervereknél, a Hyper-V-nél is létre lehet hozni két, felügyeleti célokat szolgáló RDP kapcsolatot. Ebből adódóan egy Remote Desktop Gateway-t elé pakolva a világ bármely pontjából 443-as porton kereszül grafikus konzolon át elérhető a rendszer.

Ezen kívül van egy olyan tulajdonsága is, amellyel az “eredeti” hyper-v nem rendelkezik: USB-ről is indítható, vagyis az OEM szerver gyártók merevlemez (pontosabban: system diskhez tartozó merevlemez) nélküli rendszereket is építhetnek a segítségével. Elegendő érvet soroltam fel, hogy a “belépő szintű” jelzőt töröljük? ;-)

Beépített felügyeleti eszközök
Mivel a Hyper-V Server 2008 R2 technikai értelemben egy Windows Server Enterprise “Server Core” telepítéssel, ezért mindazon eszközök használható a menedzselésére, amely a teljes verziónál rendelkezésre áll. Vagyis:

• Server Manager – WinRM segítségével rá lehet kapcsolódni a távoli Hyper-V kiszolgálóra és hajrá. A Server Manager egy kivételével valamennyi, a Hyper-V-hez szükséges MMC beépülő modult képes magába foglalni. Ezek: Hyper-V Management, WSUS, Fail-over cluster management, Group Policy Management, eseménykezelés, Teljesítmény-monitorozás, Eszközkezelés, Lemezkezelés stb. stb.
• Authorization Manager MMC konzol – Ha szerepköröket szeretnénk definiálni a Hyper-V kiszolgálóhoz, korlátozottabb jogokkal, akkor az ebben a modulban végezhető el.
• SCONFIG – A Hyper-V konzolon automatikusan elinduló, karakteres konfigurációs ablak.

Mivel jópár olvasó lehet, aki talán még 2008-as kezelőfelületet sem látott, ezért készítettem egy képsorozatot a Hyper-V kezeléséről. Néhány megjegyzés a képek kapcsán:

1-7 kép: A Hyper-V server 2008 R2 felülete a konzolból.
6-7 kép: az iSCSI és a Multipath IO konfigurálására is van parancssori eszköz, de akinek az bonyolult, annak ott van ez a két panel.
8-16 kép: A Server Manager. Egyetlen ablakban tartalmaz (szinte) mindent, amely a felügyelethez szükséges. Mindezt összecsukható, kinyitható áttekintő panelekkel.
17-19 kép: A Server Managerbe begyógyul a Hyper-V konzol. Ha kell, akár futás közben is felvehetünk újabb VHD-t.
20-22 kép: A Server Manager-ből működik a fail-over cluster modul is. A Hyper-V Server clusteremnek csak az egyik kiszolgálója futott, ezért a jobb oldalon a “Live Migration” menü most épp szürke. Mellesleg a jobb oldalon a menü folyamatosan változik a környezettől függően.
23-25 kép: Az eseménykezelés többszintű. Tetszőleges szűrő készíthető, de van beépített a szerepkörökre vonatkozóan (itt, ugye, csak egy szerepkör van, a hyper-v), és van administrativ események szürő, ami meg megmutatja, milyen hibák vannak ténylegesen a rendszerben. Akinek nagyon részletes napló kell, az igény szerint leáshat.
26-29 kép: A Windows szervereknél megszokott teljesítmény-monitorozás és adatgyűjtés (nálam az RC bugos, a gyűjtéssel kapcsolatos varázslót nem tudtam lefuttatni.)
30-36. kép: Időzített és ütemezett feladatokat lehet végrehajtatni a Hyper-V-vel. A képeken például készítettem egy e-mail riasztást.
37-40. kép: Tűzfalkezelés, több profillal, kimenő/bemenő szabályokkal, előre felvett protokollokkal stb.
41-42. kép: Szolgáltatások távoli kezelése; A Hyper-V kiszolgáló felhasználóinak és felhasználói csoportjainak kezelése.
43-44. kép: Teljeskörű távoli lemezkezelés. Jól látható, hogy a boot disk egy VHD. :-)
45-48. kép: Még néhány áttekintő ábra a Hyper-V MMC modul képességeiről.
49. kép: Server Manager szerrepkör áttekintő tábla. Egy képen a legfrissebb események, a futó szolgáltatások, támogatás, dokumentáció stb.
50. kép: Csoportházirend alkalmazása. Ezzel egészen összetett elvárt konfigurációt lehet létrehozni és kikényszeríteni.
51. kép: Authorization Manager – szerepkörök létrehozása a hyper-v rendszer felügyeletének delegálására.

Egy jó kliens
A képek mellett érdemes megjegyezni, hogy egy Hyper-V Server 2008 R2 mindazon felügyeleti képességek alanya lehet, amelyet egy Active Directory tartomány nyújthat, vagy alanya lehet minden olyan menedzsment eszköznek (Microsoft vagy nem Microsoft), amely Windows szervereket felügyel. Megint néhány példa:

• Ha van egy Windows rendszerek lemezképeit elkészítő és disztributáló eszközünk, akkor azok használhatók a Hyper-V szerverhez, nincs szükség másikra. A Microsoft egyébként rendelkezik ilyennekkel. A lemezképeket készítő eszköz a Microsoft Deployment Toolkit 2010 (ingyenesen letölthető, használható). A disztribúciós eszköz a Windows Deployment Service, minden Windows szerver verzió része.
• Ha van egy Windows rendszerek frissítését elvégző eszköz, akkor az használható a Hyper-V szerverhez, nincs szükség másikra. A Microsoft egyébként rendelkezik ilyennel, Windows Software Update Service a neve, és minden Windows szervernek része. (Mellesleg Magyarország legnépszerűbb szoftverfrissítő eszköze.)
• Ha van egy hardver/szoftver leltárt készítő eszközünk, amely a Windows kiszolgálókat és/vagy desktopokat felméri, akkor az jó lesz a Hyper-V szerverhez is, nincs szükség másikra. A Microsoftnak többféle szoftvere is van erre a feladatra. Ezek közül a Microsoft Assesment and Planning (MAP) 4.0 ingyenes, az MDOP részeként elérhető Asset Inventory Service (AIS) előfizetés jellegű, de nem igényel helyi infrastruktúrát, míg a System Center Configuration Manager (SCCM) teljes értékű nagyvállalati megoldás.
• Ha van egy rendszerüzemeltetést segítő szoftverünk, amellyel Windows szerverek felügyelhetők, akkor az használható a Hyper-V szerverhez, nincs szükség másikra. A Microsoftnak van ilyen, úgy hívják System Center Operations Manager és külön megvásárolható.
• Ha van egy mentő rendszerünk, amely kompatibilis a Windows Server 2008 R2 Hyper-V változatával, az működni fog a Hyper-V Server 2008 R2-vel is. A Microsoftnál készül a DPM v3, amely ezt a képességet tartalmazza majd.
• Ha van Active Directory, akkor használhatók a csoportházirendek. Így egyetlen helyen beállítható elég sok minden. Például:
  • Tűzfalszabályok, akár többféle profillal. Naplózási beállítások.; Helyi felhasználói csoportok tagjai; IPSec házirendek (Domain izoláció); Szolgáltatások automatikus indítása/tiltása.; Eseménynaplók konfigurációja.; Auditálási szabályok.; Fájlok, mappák, registry értékek. Ugyanezek hozzáférési szabályai
  • GPO-val tanusítványok oszthatók
  • GPO-val különböző menedzsment ügynökök telepíthetők (MSI csomagból).

A csoportházirendek jelentőségét nem lehet eléggé hangsúlyozni. Nemcsak beállításról, de kikényszerítésről is szó van. Ehhez hasonló képesség a a VMware-nél a “Host Configuration Controls” vagy Host Profiles az ESX 4 Enterprise Plus – tehát a legdrágább -  csomagban érhető el, és a nyolc sub-profile-ból (memory reservation, Storage, Networking, Date & Time, Firewall, Security, Service, Advanced) a Date & Time, Firewall, Security, Service, Advanced részeket a GPO lefedi, nem beszélve néhány egyéb képességről, mint a szoftver telepítés.

Ára
A Microsoft Hyper-V Server 2008 R2 a Microsoft Download oldaláról ingyenesen letölthető és használható. Pont. Ezzel együtt a fenti funkciók teljeskörű kiaknázásához mégiscsak feltételez két dolgot a gyártó:

1. Van legalább egy  Windows 7 a közelben, amelyre telepíthetjük a Remote Server Administration Tool (RSAT) nevű eszközt. (Ez tartalmazza a Server Manger-t, a Fail-over cluster manager-t, a Hyper-V MMC konzolt, a Group Policy Management Console-t és minden más, szerver felügyeleti MMC modult.) Az RSAT ingyenes, de a Windows 7 nem.

2. Active Directory tartományban dolgozunk. A Hyper-V Server 2008 R2-nek természetesen NEM követelménye az AD, elvan anélkül is. De a fail-over clusterhez (High availability, Quick / Live Migration) szükség van AD-re, vagyis szükség van legalább egy Windows szerverre is. A ma kapható legolcsóbb Windows szerver változat a “Windows Server 2008 R2 Foundation Edition”. Ez már tartalmazza a WDS, a WSUS, a GPO-t, sőt az RSAT is használható rajta.

Azt gondolom, hogy ma vállalatok túlnyomó többsége a fenti kitételeket könnyedén megugorja. Számukra a Hyper-V server nem okoz többlet beszerzési költséget. Akik minden fent funkciót ki szeretnék próbálni, de nincs AD-jük vagy legalább egy Windows 7-esük, akkor nekik a Hyper-V server telepítése előtt ezeket az előfeltételeket be kell szerezni.

Figyelem! Mint minden más informatikai terméknek, a Hyper-V Server 2008 R2-nek is van üzemeltetési, birtoklási költsége: TCO-ja. Egy szoftvert fenntartani pénzbe kerül.

Jelentősége
A virtualizációs piacon ténylegesen két szereplő van, aki súlyánál, méreténél, piaci potenciáljánál fogva jelentős: a Microsoft és a VMware. A Microsoft most egy olyan hypervisort dobott a piacra, amely nemcsak hogy ingyenes, de a konkurrencia termékének számos olyan tulajdonságát is tartalmazza, amely vágyott, de éppen ezért eddig drága volt.

A Hyper-V Server 2008 R2 kétszeresen is naggyá tett szoftver. Egyrészt naggyá tette a Microsoft azzal, hogy az Enterprise változatból hozta létre, így minden, az Enterprise verzióra jellemző tulajdonsággal bír. Másrészt naggyá tette a VMware kereskedelmi gépezete: éveken keresztül a VMotion volt az a szent tehén, amely nélkül “virtualizáció elképzelhetetlen” (Naná! Olyan csak nekik volt.) Ez nem volt igaz, de az ügyfelek elhitték, a szoftver adoptációját pedig felgyorsította. Most mindenki működés közbeni migrációt szeretne. A Microsoft pedig azt ingyen adja. Hiába mondja mostantól a VMware partneri kör, hogy “a live migration már nem minden” – ezt elhitetni már sokkal nehezebb.

Az gondolom, hogy a legkevesebb, amikor azt mondjuk: a Hyper-V Server 2008 R2 figyelemre méltó.

Biztos vagyok benne, hogy nincs kishazánkban olyan rendszergazda, aki ne tudná: ha a felhasználók a saját gépeiken “felhasználók”, akkor az csupa-csupa előnnyel jár a rendszer birtoklását illetően.  A teljesség igénye nélkül:

• A felhasználó-felhasználók nem telepíthetnek (telepítgethetnek) illetéktelen, az IT által nem ellenőrzött szoftvereket.
• Nem kapcsolhatják ki a védelmi rendszereket (antivírus, tűzfal, automatikus frissítések) – és ezt trójai vagy egyéb kártévő kódok sem tehetik meg helyettük.
• Nem írhatnak olyan helyekre, mint a “Program Files”, meg “Windows” környtárak, meghosszabbítva ezáltal az operációs rendszer stabilitását. Ez hasznos tiltás, hiszen tudvalévő, hogy egy felhasználó-felhasználó ott potyogtat el állományokat, ahol csak tud.
• Egy felhasználó nem futtathatja a regedit-et, vagy ha igen, kritikus pontokat nem írhat felül.
• Egy felhasználó-felhasználó nem tudja megakadályozni a csoportházirendek lefutását – ezáltal a rendszerfelügyelet gördülékenysége megmarad.

Végeredményben a felhasználó-felhasználó nagyságrendekkel kisebb mértékben veszélyezteti saját rendszerét, a számítógépe védett VELE SZEMBEN is, ez pedig végeredményben kevesebb hibát, kevesebb incidenst, alacsonyabb üzemeltetési költségeket és kisebb TCO-t jelent. Tiszta nyereség, mindenki látja ezt, a felhasználó pedig – aki igazából nem ért az informatikához – belátja, hogy ezek a szabályok végeredményben érte és nem ellene vannak.

A felhasználókat valódi felhasználókká tenni Windows környezetben azért nem olyan könnyű. Ha a Windowsra fejlesztők nem lennének oly megátalkodott lusták és követnék Microsoft ajánlásait, már régen kivesztek volna a rendszergazda jogosultságot igénylő alkalmazások. De sajnos korunk fejlesztője életművének nem elhanyagolható része igényli a rendszergazda jogosultságot. Mégis, rendes IT szervezet küzd az ilyen ártány szoftverek ellen: alternatívákat vásárol inkább, vagy megveszi és bevezeti a legújabb verziót, amelyet már rendesen megírtak stb. stb. A szakma pedig mindig, MINDIG elismerően nyilatkozik, ha valahol a kollégák belevágják a fejszéjüket a kemény fába: legyen a felhasználó csak felhasználó. Végül, ha sikerül a projekt, és mindenki, aki nem része az üzemeltetésnek, csak felhasználói jogokkkal rendelkezik, a közösség elismerően bólogat: igen, ez egy biztonságosabb rendszer.

Teljesen őszintén: én sem vagyok kivétel. Korábbi munkahelyemen, a MAL-ban, ahol én voltam a felelős a szerverek és munkaállomások működéséért, mindenki felhasználó volt a gépén: a tulajdonosok, a vezérigazgató, a IT igazgató és az összes felhasználó, beleértve rendszergazdákat, de még a tulajdonosok gyerekeit is.(*) Sőt! Még ebben a webnaplóban is beszámoltam a “Zéró Domain Admin” projektről, amelynek az volt a lényege, hogy szerepkör-megosztással szétosszuk a “Domain Admin” jogosultságokat és kiürítsük a csoportot. Nálunk még a rendszergazdák is felhasználók voltak, legalábbis azon igyekeztem, hogy a nem rendszerüzemeltetési feladatokhoz a saját, korlátozott, felhasználói fiókjukat vegyék igénybe.

Mindabból, amit leírtam, egyenesen következik, hogy igencsak meglepődtem, amikor a Microsofthoz kerültem, és azt találtam, hogy itt mindenki helyi rendszergazda a gépén. Éppenséggel nem bántam: egy kicsit aggódtam, mi lesz, ha én is csak felhasználó leszek a gépemen. Én tudom, hogy mikor, mit és miért kell feltenni a gépemre. Rendszergazda jogosultság mellett sem szedek össze vírusokat, és ha netán összebarmolnám a gépemet (nem szoktam), magam meg tudom javítani. Feltéve, hogy van jogom rá. Lett jogom, és ezt ma sem bánom.

De hogy is van ez? A felhasználóimnak korlátozom a jogait, de ha magamról van szó, akkor már nem is tetszik annyira ez a módszer? És még tovább: hogy van az, hogy a Microsoft, amelynél több, mint százezer ember dolgozik, amely a világ egyik leginkább támadásoknak kitett IT rendszerével rendelkezik, és amely cég úton útfélen azt hirdeti (karöltve a Gartnerrel), hogy a “lezárt, jól menedzselt gép az üdvözítő”; szóval ez a cég mégis megengedi, hogy a munkatársai tetszés szerint garázdálkodhassanak a gépeiken?

Bevallom, nem tettem volna fel ezeket a kérdéseket magamnak (és a webnaplónak), ha a minap nem beszélgetek hosszan egy partnerünk tapasztalt rendszermérnökével a Microsoft Optimimális Desktop ajánlatáról. A beszélgetés során kiderült, hogy náluk is éppen “racionalizálják” a hozzáférési jogosultságokat, és tulajdonosi támogatás mellett (“eszi, nem eszi, nem kap mást”) megindult az átállás, amelynek eredményeképp ők – a teljes rendszerintegrációs csapat, beleértve a konzulenseket meg mindenkit - “felhasználókká” válnak. Így aztán már most gondolkodnak azon, hogy milyen módszerrel jutnak majd olyan eszközhöz, amivel dolgozni is lehet…

Ahhh. Leesett a tantusz.

Az “Optimális desktop ajánlat” első lépése (többről, másról most nem is lesz szó), hogy mérd fel a felhasználóid igényeit és sorold őket ez alapján kategóriákba. Mindjárt fel is dobunk 5 általunk kitaláltat, ötletek ezek, sokak számára azonnal használatba vehetők. A történet azonban attól szép, hogy itt nincs semmi kőbe vésve. Vannak fejlesztőid és külön kategóriába sorolnád őket? Legyen úgy! A kereskedők különös állatfajta nálatok? Semmi gond, legyenek ők is egy kategória. Stb. Stb. A lényeg az, ahogy kezded: “Mérd fel a munkájukat, igényeiket.”

Szóval miért is helyi rendszergazdák a Microsoft dolgozók? Azért, mert ez legitim igényük. Nem úgy igény ez, mint ahogy az igazgató kisfia sír admin jogért, hogy játékot tehessen fel.  Hanem a felelős cselekvésé: az MS alkalmazottak informatikai értelemben képzett és felelős felhasználók. Tudnak bánni rájuk bízott jogokkal. A rendszer agilisebb, vagyis gyorsabban reagáló, ha az emberek megtehetik azt, amihez egyébként értenek. Ha senki sem lenne rendszergazda, egy ilyen szervezetben ez olyan mértékű incidens EMELKEDÉST jelentene, amelyet semmilyen támogató csapat nem tudna lekezelni. Mindenki minden esetben a helpdeskhez fordulna a telepítésekért, átkonfigurálásért, beállításokért stb. stb.

Tudják ezt az MSIT-nál is. Ezért aztán több dolgot is (jól) csinálnak:

• A kezdőket és a bíbelődni nem akarókat Standard lemezképpel támogatják. Tedd fel, minden benne van, ami az alap munkához kell (Office, antivírus, VPN csatlakozási lehetőség, RMS kliens, Bitlocker, management kliensek stb. stb.)
• A telepítéseket – akinek szüksége van rá – precíz leírásokkal támogatják.
• A saját utjukon járóktól a MÉLYSÉGI VÉDELEM módszerével kényszerítik ki azt, amit a józan ész megkíván:
• Biztonsági ellenőrzés, egészség-ellenőrzés VPN-es bejelentkezéskor (tűzfal, antivírus, hotfixek megléte stb.)
• SCCM és SCOM ügynökökkel távoli felügyelet, patch management stb. – interneten keresztül is.
• IPSEC és Domain izoláció (nem domain tag gépek nem tudnak domain tagokkal kommunikálni)
• Titkosítás mindenütt: kliens forgalomban, állományokon, leveleken, wireless hálózaton stb. stb. stb.
• Alkalmazás szintű publikálás – csak a szükséges forgalom, ellenőrizve, titkosítva (Outlook anywhere; TS WebAccess stb.)
• Totális védelem a szerver oldalon (jogosultság-ellenőrzés, szerepkör-szétválasztás, auditálás stb. stb.)

Szummázat (az enyém):

A “felhasználó legyen felhasználó” szabály egy ökölszabály. Többnyire helyes. Az informatikailag képzetlen, félművelt vagy felelőtlen (magán segíteni nem tudó) felhasználók támogatása olcsóbb, ha a “hibázás lehetőségét” csökkentjük. Okos dolog, ha a gyufát és a gyógyszert olyan helyen tároljuk a lakásban, ahol kisgyermek nem éri el.

Ugyanakkor a “felhasználó legyen felhasználó” szabály CSAK egy ökölszabály. A tényleges igények, munkamódszerek felmérése után vezethető be. Ha olyan helyen is alkalmazzuk, ahol nem kellene, kárt okozunk: jobb esetben csak megemelkedett támogatási költségeket, rosszabb esetben egy kevésbé hatékony szervezetet eredményezhet az intézkedés bevezetése. Az előbbi példával: ha a családban mozgássérült felnőtt is van, gyógyszereinek elzárása akár életveszélyt is okozhat.

A biztonságnak lehet ez segítője, de rossz esetben csak pótcselekvés: a valódi veszélyekkel szemben a valódi védelmi intézkedéseket kell hozni. Mélységi védelemre van szükség. És még valami. Részlet a “10 Immutable Laws of Security” írásból: Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore

Te, olvasó, aki értesz az informatikai eszközökhöz, sőt, esetleg biztonsági szakértő vagy, mit szólsz a partnerünk biztonsági csapatának ötletéhez? Megosztod a gondolataidat, hogy a IT biztonsági csapat a legjobb döntést hozhassa?

-----------------------

(*) Kivéve egyet: egy egyetemet végzett, a számítógéphez profi módon értő srácról volt szó. Először persze ő is csak felhasználó volt. De mivel annyiféle dolgot csinált, és mindig tudta, hogy mit, és okos volt és felelősségteljes, végül engedtem, és kapott helyi rendszergazda jogot. Attól kezdve tizedannyit hívott. A * után részből tudható, hogy miért.

Az első budapesti virtualizációs nap legvégén, a kerekasztal beszélgetés kezdetén, azt a kérdést kaptam nyitásképpen, milyen Linux verziók támogatottak Hyper-V alatt (vagyis: felett). Ezzel rögtön bele is futottunk a LINUX-támogatottság-IC problémakörbe. Nagyjából vázoltam a jelenlegi (akkori) helyzetet, és hamar kibukott, hogy a most (akkor) elérhető IC csak a 2.6.19-es kernel verzióig képes működni, annál újabbak esetén el sem indul. Rögtön jött a kérdés, hogy vajon a Microsoft miért nem GPL alatt fejleszti az integált komponenseket a Linuxhoz. Erre azt válaszoltam, hogy “Nem tudom, pedig logikus lenne.” majd mindjárt hoztam egy példát, nevezetesen a System Center Operations Manager 2007 R2 Cross Platform Extension fejlesztését, ahol a Microsoft aktívan beszállt az OpenPegazus projektbe.

Úgy látszik, nem csak én gondoltam, hogy van értelme egy ilyen lépésnek. A minap a Microsoft bejelentette, hogy kb. 20 000 sornyi forráskódot, a Hyper-V Linux Integrált komponensét (rövidítve: IC),  a GPLv2 licence alá helyezi, az IC eszközmeghajtók pedig a Linux kernel eszközmeghajtó ágában fognak megjelenni. Juhéjj!! A világ persze a szenzációt keresi, és az, hogy “Microsoft és GPLv2”, így együtt, szenzációsnak tűnik. Meg az is, hogy “a Microsoft részt vesz a Linux kernel írásában”, ami meg, ugye, nem egészen pontos fogalmazás.

Azt gondoltam, hogy a magam tudásával összeütök egy kis “Gyakori kérdések" listát, hátha sikerül néhány fehér foltot eltüntetni a témába.

K: Milyen szoftvert tett nyílt forráskódúvá a Microsoft?
V: A Hyper-V-n futó Linuxos virtuális gépekhez tartozó integrált komponensek forrása lett nyílt.

K: Mi az, hogy Hyper-V?
V: A Hyper-V a Microsoft nyers vason futó (angolul. bare metal, vagy type I.) hypervisora. Olyasmi, mint a Xen, vagy a KVM.

K: A teljes Hyper-V nyílt lett?
V: Nem. Távolról szemlélve a Hyper-V három részből áll: Maga a hypervisor, a szülő partíció (mint a Xen-ben a Dom0) komponensei és a gyermek partíciókba (virtuális gépekbe) telepítendő, operációs rendszer függő, integrált komponensek. E három közül az utolsó, abból is a Linuxhoz tartozó lett nyílt.

K: Pontosan mit jelent, hogy integrált komponens, és mit csinál?
V: Leegyszerűsítve olyasmi, mint a Xen-es paravirtualizált driverek.

K: Ok. És nem leegyszerűsítve?
V: Az Integált komponensek is három részre oszthatók:

1. Paravirtualizált driverek, jelenleg:
   - Hálózati csatoló
   - IDE csatoló
   - SCSI csatoló
   - Videó kontroller
   - Egér vezérlő
2. Integrációs szolgáltatások, jelenleg:
   - Hyper-V Heartbeat Service
   - Hyper-V Guest Shutdown Service
   - Hyper-V Data Exchange Service
   - Hyper-V Volume Shadow Copy Requestor
   - Hyper-V Time Synchronization Service
3. VMBus (Virtual Machine Bus)

Ha az IC-t telepítette a rendszergazda, akkor a szülőpartíció és a gyermek-partíciók (virtuális gépek) között egy pont-pont adatkapcsolat jön létre, ez a VMBus. A paravirtualizált driverek ismerik a VMBus-t és ezen keresztül, a Hypervisort tehermentesítve küldenek illetve fogadnak nagy mennyiségű adatot. A vituális gép I/O (és minden egyéb) teljesítménye ugrásszerűen javul, a virtualizációs többletteher pedig jelentősen csökken.

K: A most nyílttá tett Linux IC minden komponenst tartalmaz?
V: Nem. Tartalmazza az VMBus-t és a paravirtualizált drivereket a videó kontroller kivételével.

K. Tehát nincs például a virtuális gép és a gazdagép között időszinkronizáció?
V: Linux IC esetén, a virtuális gép futása során nincs, csak a VM bootolásakor.

K. És nincs Guest Shutdown Service sem?
V: Linux IC esetén nincs. A VM-ben futó operációs rendszerből kell kiadni a leállítási parancsot, a Hyper-V MMC konzoljából vagy SCVMM-ből ez nem működik.

K: A zárt forráskódban ez még megvolt?
V: Nem, ott sem volt. A most nyílttá tett kód volt régen a zárt kód.

K: Mi az, hogy “Hyper-V Volume Shadow Copy Requestor”?
V: Az egy olyan képesség, amelynek a segítségével nyitott állományokat is le lehet menteni. A Hyper-V esetén ez azt jelenti, hogy a virtuális gépek futás közben konzisztens állapotban menthetők. A Linux IC-ben ez a képesség még nincs meg.

K: És a hiányzó részekkel mi lesz? Ezek nem is kerülnek bele a nyílt kódba?
V: A Microsoft elkötelezte magát, hogy továbbfejleszti a kódot és minden, a Windowsos IC-ben megtalálható funkció elérhető lesz a Linux IC-ben is. Épp azért történt a nyílt forráskódúvá tétel, hogy ez a folyamat felgyorsuljon.

K. Tehát az IC-től jobban fog futni majd egy Linuxos gép Hyper-V felett. Van a most megjelent IC-ben vSMP támogatás?
V: Nem, a mostaniban nincs, és az RTM-ben sem lesz. De később belekerül a kódba.

K. Ha egy disztribúcióban benne lesz a Hyper-V IC, akkor azt a disztribúciót támogatja majd a Microsoft?
V: Nem. A “támogatás” kifejezést a Microsoft széles értelmezi, ezért óvatosan bánik vele. A most megjelent Linux IC-vel a következő disztribúciók támogatottak:

· Red Hat Enterprise Linux 5.2 (x86/x64)
· Red Hat Enterprise Linux 5.3 (x86/x64)
· SUSE Linux Enterprise Server 10 SP2 (x86/x64)
· SUSE Linux Enterprise Server 11 (x86/x64): (hamarosan)

Ezen disztribúciók esetén a Microsoft ügyfelek a Linuxos kérdéseiket is továbbíthatják a Microsofthoz, amelyeket az MS gyártói keresztszerződések segítségével megválaszol/megold. A többi disztribúció esetén az lesz a helyzet, hogy a Microsoft a nyílt forráskódú IC-t támogatja majd, a disztribúciókkal kapcsolatos problémákkal viszont a disztribúció gyártójához kell fordulni.

K: Ez a verzió egy végleges változat?
V: Nem, hivatalosan “Release Candidate 2” a megjelölése. A RTM kód szeptember végéig várható.

K: Kér pénzt azért a Microsoft, hogy egy virtuális Linuxos gépet Hyper-V felett futtatok?
V: Nem, nem kér. A Hyper-V ingyenes abban az értelemben, hogy letölthető és használható. Természetesen birtoklási költsége mindennek, így a Hyper-V-nek is van.

K: Én úgy tudtam, hogy a Hyper-V a Windows része, az meg pénzbe kerül.
V: Igen, a Hyper-V a Windows operációs rendszer része. A Microsoft azonban kiadott egy Hyper-V Server változatot is, az viszont nem kerül pénzbe. Ez a változat a virtualizációs képességeket tekintve teljes értékű a Windows Serverbe beépítettel összevetve.

K: Miért éri meg a Microsoftnak nyílt forráskódúvá tenni a Hyper-V IC-t? Megtérnek?
V: A Linux IC fejlesztése lassan halad és a megfelelő eredmény (értsd: sebesség, válaszidő, késleltetés stb) elérése érdekében szorosabb együttműködésre van szükség a a Linux kernel fejlesztőivel. Ebben az esetben a nyílt forráskód és a GPLv2 a megfelelő megoldás. Az várható, hogy hamarabb jelenik a Linux IC, gazdagabb funcionalitással és folyamatosan követni fogja a Linux kernel változásait.

K: Várható, hogy a Microsoft megnyitja a teljes Hyper-V forráskódot?
V: Nem, erről nincs szó.

K: A Microsoft a Linuxszal való erőlteljes verseny miatt kényszerült kinyitni a kódot?
V: Nem. A heterogén környezet támogatása elengedhetetlen követelmény egy platformként működő hypervisor esetén. A Hyper-V jól teljesít a Windows virtualizációja során, de elmarad a többi platform befogadásában, ideértve nem csak a Linux disztribúciókat, de a Unixokat is. A Lemaradás különösen a VMware-rel szemben jelentős. A nyílt forráskód nem csak a Linux adaptációt segíti, de a többi platform felé is segítség lehet. Vagyis a Microsoft ebben az esetben nem a Linuxszal vetélkedik, hanem inkább a VMware-rel.

K: Elképzelhető, hogy a Microsoft egyszer majd visszavonja a kódot?
V: Nem. Szándék sincs rá, és ezt a GPLv2 is kizárja.

K: Ez az első eset, hogy a Microsoft nyílt forráskódot fejleszt?
V: Nem. A Microsoft korábban részt vett több, nyílt forráskódú projektben, így a PHP és a Firefox Windows-on való optimalizálásában, vagy az OpenPegasus programban. Viszont most fordul elő először, hogy a Microft által írt kód a Linux kernel módú komponensei közé kerül.

K: Mi lesz a többi platformmal? Én a FreeBSD-t favorizálom.
V: Egyelőre a Linux disztribúciók integrált komponensekkel való ellátása a cél. A nyílt forráskód és a GPLv2 viszont előre vetítheti, hogy a jövőben más platformokba is bekerüljenek a Hyper-V VM oldali komponensei. Erre vonatkozóan egyelőre nem jelentett be semmit a Microsoft.

K: Tervez-e újabb nyílt forráskódú projektet a Microsoft?
V: Bizonyára, bár erről semmilyen hivatalos információ nincs. Fantáziálni azonban lehet. Ha például valódi VSS támogatást szeretnénk adni a Linuxos virtuális gépekben, akkor szükség van Linux oldalon egy VSS szolgáltatásra is. Ha esetleg ennek megalkotásában (vagy egy már elkezdődött projektben) részt vesz a Microsoft, akkor megnyílik az út például a System Center Data Protection Manager számára, hogy nem csak Windows-okat mentsen. Még egyszer: mindez csak találgatás.

K: Érdekel, hogy mit csinál a Microsoft a nyílt forráskódú világban. Van erről egy tájékoztató oldal?
V: Igen, több is:

• Open Source at Microsoft
• Port 25: The Open Source Community at Microsoft
• Interop Vendor Alliance

Megvolt, szép volt. Hogy volt? Másfél hónapig még a webnaplót is elhanyagoltam, most következik a beszámoló – persze a magam szemszögéből.

Pár héttel ezelőtt egy kollégám hívta fel a figyelmemet, hogy szerveződik egy “Virtualization-day” a HUP-on. Hamar látszott, hogy sokkal többeket érdekel, mintsem hogy egyetlen lakásban elférjen a társaság. Nosza, egy gyors kupaktanács után felajánlottam a nagytárgyalónkat. A dolog azonban ettől csak még nagyobbra nőtt, hogy végül már Microsoft tárgyaló sem volt elegendő. Ráadásul a várható látogatók száma eltolta a nap jellegét a “reszelésből” az előadások felé, hiszen 200 ember vasát az isten tápellátása sem bírja. Szerencsére az esemény fontosságára felfigyelt szinte minden gyártó hazai leánya (meg jó néhány partner), így aztán hamar összejött egy kis sponzori pénz, hogy rendes helyet lehessen keresni. Réz Andrisék, bár kezdő szervezők, a lelküket is kitették, hogy a nap tényleg összejöjjön.

Nem kis fejtörést okozott, hogy mit is mutassak. A virtualizáció egy kicsit mindig varázslat, egy kicsit mindig sci-fi. De vajon mennyire legyen az az előadás? A hallgatóság várhatóan inkább hűvös távolságtartással fogad majd. (A HUP-on jópáran nem szimpatizálnak bármivel, amihez a Microsoft név társítható.) Ráadásul a VDI – úgy önmagában - nekem nem túl szimpatikus téma. Egyszerűen azért, mert az általános megközelítése szerint túlságosan technológia-centrikus, ahelyett, hogy probléma-centrikus lenne. Az azonban, hogy véletlenül az első előadás az enyém lett, egyúttal lehetőséget adott, hogy definiáljam a témát mind a technológia, mind a probléma szempontjából. (Ezt majd egy későbbi cikkben itt is megteszem.) Végül abban maradtam magammal, hogy néhány dia erejéig bemutatom, mit jelent egyáltalán a VDI, hiszen az egy nagy elefánt, aztán esetleg egy-egy lábát, meg ormányát szemlélve nem látszik az egész állat. Ehhez a “Bevezetés a VDI világába” képeit használtam fel. Ugyanakkor a technológia általános leírása mellett mindenképp rá szerettem volna mutatni, hogy divatossága ellenére itt mégiscsak egy eszközről van szó egy probléma – nevezetesen a munkakörnyezet biztosítása – kapcsán. Márpedig ebben igen sok minden beletartozik, bele is kell, hogy tartozzon. Ezért volt része az előadásnak az alkalmazás-virtualizáció, a dinamikus kövér-kliens, a RemoteApp, a Remote Desktop Web Access. stb. stb.

Körülbelül keddre készültem el a teljes demóval, szerdától péntekig pedig négyszer előadtam gyakorlásképpen. Egy alkalommal a feleségemnek – ha ő, aki nem szakember, nem alszik el rajta, akkor valószínűleg más sem. Közben itt ott hibák és bukfencek jöttek elő, úgyhogy minden alkalommal összeírtam mit kell még javítani, hogy szombaton tényleg gördülékeny legyen minden. Kimértük az időt, fontos, hogy első előadóként ne csússzak és ne raboljam mások perceit. Hiba ezzel együtt mindig lehet. Az előadást úgy terveztem, hogy a notebookra, amelyen dolgozom, USB-ről kerül majd fel egy Office 2007. De akkor hogyan fogom a kezdeti diákat megmutatni? Azt találtam ki, hogy a demó környezetemet egyben “élesen” is használom, vagyis a rendszergazda számára elérhetővé tettem a demó terminál szerveréről kiajánlott Powerpointot. Ezzel nem is volt semmi gond, hiszen az első demó amúgy is az USB-s App-V, onnantól kezdve pedig már van mindenem. Csakhogy azzal nem számoltam, hogy a RemoteApp Powerpoint nem jól fütyülte össze magát a kivetítővel, és egy óriási felbontással próbálkozott, vagyis a diák harmada látszott csak. Ott helyben (fejben) kellett átszerkesztenem az előadást úgy, hogy az USB-s demót előrehoztam – mert csak így lett olyan eszközöm, amelyről a diák már vetíthetők voltak. Nem tudom, hogy ez a nézőtérről mennyire látszott, de amikor elindult a kivetítő, egy halvány tapsot kaptam, ez igen jól esett. (Azt a demót egyébként, hogy bedugok egy USB kulcsot, és van azonnal egy működő Office-om fájl-asszociációkkal, nos ilyet először mutattunk be Magyarországon.)

Az előadás nagyobb része ettől kezdve nagyjából a TechNet-re készül screencast vázát követte, kivéve a legutolsó részt, a HD-videó bemutatását. (Ezt screencastban “elég nehéz” megmutatni.) Egyébként azt hiszem, ezt Mo.-n megint csak először láthatta nagyérdemű. Személy szerint a kedvenc funkcióm, a virtuális gép RDP-kapcsolaton keresztüli felélesztése volt. Abba különösen bele lehet szeretni.

Bármennyire készültem, azért bennem is volt lámpaláz. Elfelejtettem megmutatni, hogy az egész bemutató “Internetes” részéhez mindössze négy tűzfal-publikációs szabályra volt szükség. Ki kellett ajánlani a Remote Desktop gateway-t és a WebAccess szerepkört (1 szabály, HTTPS); az App-V publikációs funkcióját (2. szabály HTTPS); az App-V streaming képességét (3. szabály RTSPS), végül a PKI rendszer CRL elérését (4. szabály HTTP). Egyéb dolog nem is kell, főleg nincs szükség VPN-re. Másrészt megmutathattam volna a Connection Broker felületét, meg hogy mi mindent lehet ott beállítani. Két percem még maradt volna. No sebaj, majd máskor.

Az első előadás után végre néző lehettem és figyelhettem, tanulhattam. Utánam Macskásy Attila következett, szintén VDI témakörben. Bevallom újat nem hallottam, de ez inkább csak “szakmai ártalom”, a VMware-t munkaköri kötelességem ismerni, a Microsofttal kapcsolatban gondolom Attila is így van. Az előadás jó pattogósra sikerült – az ívet nem mindenhol követtem –, de  örömmel vettem, hogy Attila, hasonlóan az én bemutatómhoz, nem szűkítette le a mondandóját egyetlen területre (pl, hypervisor, vagy connection broker), hanem teljes valójában mutatta meg, mit jelent a VDI ma, a piacvezető szemszögéből. Azért nagyon fontos ez, mert így látszott, hogy egyről beszélünk. Sajnos a SUN-os VDI elmaradt, pedig jó lett volna, ha ugyanazok a funckiók egy harmadik gyártó szemszögéből is előkerülnek. Sebaj, majd legközelebb.

Érdekes volt hallani mit hangsúlyoz Attila. Pl. az USB átirányítást. Nálunk ez talán már az RDP 5.0-tól létezik, de erősen operációs-rendszer függő. Az XP kevesebbet tud, az Vista “nem-Enterprise” verziók már kicsit többet, a Vista-Enterprise még többet, a Windows7 (RDP7) pedig teljes értékű átirányítást nyújt. Igaza volt Attilának, hogy ezt megemlítette, a szívemből beszélt. A VDI projektek egyik nagy buktatója lehet, ha nem elégítjük ki a felhasználók igényeit maradéktalanul. Márpedig ahhoz a desktop élményt a lehető legteljesebben biztosítani kell. Örülök, hogy ez elhangzott, rímelt egy márciusi bejegyzésemre.

Délután – vagyis, pontosabban: ebéd után, tehát a legutálatosabb időpontban, “emésztés idején” – következett a XEN-es bemutató. Az előadás váza jó lett volna, viszont előadói gyakorlat híján az előadás csak nagy odafigyeléssel volt követhető. Inkább kisebb nézőközönség, 6-10 ember számára lett volna megfelelő, interaktív formában. Segíthetett volna egy-két áttekintő ábra is. A dolognak az volt a szépsége, hogy szinte ugyanazt csinálta meg az előadó parancssorból, mint amit mi grafikus felületen. Az előadó – Endrész Attila – pechére a livemigration nem jött össze, így a csattanó elmaradt. Pedig látszott, hogy sok-sok munka volt az előadás mögött. A HUP-on volt, aki citrom-díjat adott volna. A magam részéről ezt nem tartomk igazságosnak. Attilának – szemben minden más szereplővel – nem szakmája előadni valamit. A virtualizációt is csak a maga eszközeivel és lehetőségeivel ismerte meg, nincs mögötte tanfolyam, multi-cég stb., csak szorgalom és lelkesedés. Ezt a lelkesedést, meg a szakma szeretetét szerette volna átadni nekünk. Szóval csak csínján azzal a citrommal.

(Érdekes volt egyébként, hogy többször elejtett olyan megjegyzést, hogy “ezt nem is tudom pontosan, miért van”, meg hogy “nem is értem, hogyan működik” stb. Én viszont pontosan tudtam a kérdéseire a választ, mégha nem is volt a kezem között XEN. Ezt teszi a hasonló, mikrokerneles architektúra.)

A nap leghektikusabb előadása Nagy Zolié volt, de erről nem ő tehetett. Az előadás előtt tönkrement a szervezők által biztosított kivetítő, aztán később meg a Wifi is, így hiába hozta el a SUN-os csapat a többtízmilliós demóját, nem lehetett kivetíteni. Zoli gép és kép nélkül próbálta továbbvinni az előadását – egyből kiderült róla, hogy született előadó, a társaság jókat nevetett a poénjain, s az előadás ezen része már csak azért is fantasztikus volt, mert én tudom, hogy milyen frusztráló, hogy “nincs tovább” mert nem lehet az előadásban továbbmenni, de közben meg szóval kell tartani a nagyérdeműt. Zoli ráadásul előző előző este 2 órát aludt – persze a demót reszelte.

Egy ideig próbáltunk új vetítőt szerezni, amikor aztán ez nem sikerült azonnal, Zoli “LiveMigrálta” a csapatot a kisterembe. (Nagy röhögés mellett). Itt volt kivetítő, meg ott voltak a demó gépek is, viszont nem lehetett leülni, és a gépek miatt meglehetősen nagy volt a zaj. Egy darabig ilyen áldatlan állapotban zajlott az előadás, később, amikor mégis lett hálózat, meg kivetítő is, visszaballagtunk a nagy előadóba. Ezzel együtt a demóból lényegében nem lett semmi, a JAVA-s kezelőfelület rengeteg hibát dobott, úgyhogy itt is elmaradt a csattanó. Zoliról viszont még biztosan fogok hallani, mert nagy tehetség. Egy apróságot megfigyeltem és megjegyeztem. A SUN is ismeri a Microsoft által “Quick Migration”-nek nevezett technológiát (save state – failover – restore), csk ők éppen “Warm Migration”-nek nevezik. Nocsak, ez másnak is fontos volt?

A SUN-os bemutató után ismét Macskásy Attila következett, aki  - felbuzdulva azon, hogy mindenki live migration-t mutogat – gyorsan bejelentkezett a demó adatközpontjukba és bemutatott egy live migration-t, majd rögtön ezután egy hibatűrés demót is. Miközben kattintgatott, megjegyezte, hogy igazság szerint nem érti pontosan miért kell ezen annyit rugózni, hiszen a VMware évek óta tud már ilyet. Nos, itt az idő ezt elmondani: azért rugózott mindenki ezen, mert a VMware éveken keresztül megkülönböztető képességként árulta a VMotiont (és valóban, csak ők tudták), s miközben így tettek, a Virtualizáció alapkövévé emelték a funkciót. A VMotion volt valójában az a dolog, amely eladta a virtualizációt, ahogy erről korábban már többször írtam. Aztán, most, amikor már mindenki tud live migration-t (vagy, ahogy a demók mutatták, már tényleg majdnem tud), mindenki olyan lett, mint Kispipi Szutyejev Kispipi és Kisréce meséjében. Én is! Én is! Attila teljes joggal mondja, hogy ez önmagában semmi, kell mögé a menedzsment és kell mögé az alkalmazás (például a DRS, vagy a Power Management), csakhogy ezt NEHÉZ lefordítani olyan egyszerű üzenetté, amelytől az ügyfelek nem a legolcsóbban kapható LiveMigration-t veszik meg. Pedig, még egyszer: Attilának igaza van, a LiveMigration önmagában nem “A” megoldás.

Őszintén szólva azon viszont csodálkoztam, hogy a VMware milyen demó központtal rendelkezik. Arről én is írtam korábban, hogy van nekünk egy mssalesdemos.com oldalunk, ahol idősávokat lehet lefoglalni és kész demókörnyezeteket kaphatunk. Csakhogy azok a demók virtuális gépek. A VMware viszont FIZIKAI gépeket bocsátott egy előre igényelt idősáv erejéig a mérnöke rendelkezésére, amelyeken aztán TÉNYLEG mindent le lehetett demózni. Ahh, nekem össze kellett várnom, míg három gép kerül hozzám. Igaz, azokat viszont megbecsültem, a demóimat magam építettem, és birtoklom is őket teljes egészében.

Az utolsó előadó újra én voltam. Egy Hyper-V Server 2008 R2 cluster felépítését vállaltam, és egy apró kitérővel ezt sikerült is megvalósítanom. Mutattam egy WIM2VHD-t, amivel Sysprep-pelt virtuális merevlemezre rakott operációs rendszert lehet készíteni. Ezt BCDEdittel betettem a boot menübe, majd el is indítottam. (Indítható VHD…) Mivel voltak “üresjáratok”, vagyis olyan időrések, amikor a gép dolgozott, a köztes időket áttekintő ábrák bemutatására szántam. Többször próbáltam ezt a demót is, így pontosan tudtam, hogy mennyi időm van egy-egy parancs kiadása után. Csak annyi problémám volt, hogy a notebookom nem tudott egyszerre kivetíteni és az LCD panelen is képet megjeleníteni, mert a Hyper-V server grafikus meghajtóját erre nem készítették fel. Sebaj, egy újraindítás után a kivetítőre tereltem a képet, így lehetett látni, milyen a felület. Megmutattam egy hálózati kártya telepítési módot (a mikrokernel hypervisor előnye ;-)), meg megmutattam, milyen felület áll rendelkezésre az általános szerver-beállításokra és az iSCSI konfigurálására. Ezután elindítottam egy olyan VHD-t, amely már cluster-tag, hogy jusson idő a LiveMigration-re (Én is! Én is! :-)) Sajnos a fürttag elsőre nem akarta meglátni az iSCSI lemezeket – sosem fogjuk megtudni, miért – úgyhogy az előadást a Server Manager, a Hyper-V Manager és a Fail-Over cluster Manager bemutatásával zártam, plusz megígértem, hogy az ittmaradóknak összehozom a demót. A többség nem mozdult, és megérte: egy újabb reboot után már minden működött, úgyhogy abszolváltunk előbb egy Quick Migration-t, majd egy Live Migration-t is. Mindeközben még elmondhattam, hogy milyen képességekkel rendelkezik a Hyper-V Server 2008 R2, no meg a végén, hogy ez “csak úgy” letölthető. Hmm! A végén záporoztak a kérdések, és vagy egy tucat névjegykártyát szétosztottam. Azt hiszem sikerült valami izgalmasat mutatni.

A nap végére (értsd: szombat este fél nyolc után) még vagy negyven ember állt körül minket, Macskásy Attilát és engem, és tették  fel az újabb és újabb kérdéseket. Jó volt látni, hogy nem is olyan kicsi ez a “kemény mag”. Volt vagy fél kilenc, mire eljöttem, csupa jó érzéssel.

Nem ejtettem még szót a virtualizációs nap kiállító részlegéről. A nagy előadói terem mellett volt egy kisebb is, ahová a gyártók, partnerek hozhatták el gépeiket, s akiket kevésbé kötött le egy előadás, azok átballaghattak és megnézhettek élőben egy vSphere infrastruktúrát, vagy egy SUN xVM rendszert. De nem csak azt! A Hunnet csapata, akik virtuális szervereket kínálnak Hyper-V alapon (is) egy kis Hyper-V környezettel lepték meg a nagyérdeműt. Van aki az üzletét bízza rá a Hyper-V-re? De még mennyire! Persze, még nem “divat”. De bizonyosan megéri. Sok sikert a Hunnet-nek!

A berhelős rész egyébként jó ötlet. A kiállítóknak reklámhely, az unatkozóknak egy jó élmény, az érdeklődőknek varázslat. A sok-sok beszéd után pedig mégis jó látni, hogy az egész összerakható, működik, kipróbálható – bérelhető (;-)).

Összességében nagyon jól éreztem magam, tanultam, ismerkedtem, és tapasztalhattam, hogy sokakat érdekel, izgat a téma, fontosak az előadások és fontos ez a webnapló is.

Ez úton köszönöm Réz Andrásnak és Juhász Gergelynek, a Virtualizációs nap szervezőinek, hogy összehozták nekünk ezt az élményt. Köszönöm Rideg Marci és Kovács Zoli kollégáimnak a felkészülésben való segítségüket.  Köszönöm a sok kérdést, meg gratulációt, remélem személyesen/ a fórumon / ezen a webnaplón / e-mail-ben stb. stb. találkozunk.

Amióta összeállítgatom a webnapló statisztikáját, rendre hozom fél évenként az 50 000 találatot. Vagyis ez inkább fordítva van: ötvenezrenként statisztikát csinálok ;-). Most is így történt. Nagyjából 2006. júniusa óta tart ez a látogatottsági trend, néha egy hajszálnyit laposabban, most éppen egy másik hajszálnyit meredekebben. (A függőleges vonal a munkahelyváltás időpontja.)

A cikkek téma szerinti kumulatív megoszlása folytatja a korábbi tendenciákat. Az “IT 2.0” még nagyobb teret nyert, de a “Munkahely” kategória növekedése megállt. A teljes blogra vonatkozóan a cikkek majdnem 70%-a négy téma köré csoportosul (IT Üzemeltetés, Munkahely, IT 2.0 (Virtualizáció) és “IT közösség”). Ha az elmúlt fél évet tekintem, akkor a fő téma a virtualizáció volt, emellett a megelőző félévhez képest képest kicsit többet írtam az üzemeltetésről és kevesebbet a munkahelyről.

Ami sajnálok, hogy keveset írtam a kommunikáció megoldásokról és keveset a licencelésről – ez utóbbira pedig a szóbeli visszajelzések alapján szükség lenne.

Ez egy régi történet, még 2008 februárjában vetette fel Mike DiPetrillo. Az utóbbi napokban Bognár Attila megjegyzéseiben újra előbukkant a téma, és vele egyetértésben úgy gondoltam, megér egy bejegyzést.

A probléma
Az bizonyára tudjátok, hogy a modern virtualizációs megoldások nem emulálják a processzorokat, hanem csak virtualizálják. Ez azt jelenti, hogy a virtuális gépek bár virtuális CPU-t látnak, annak funkcionalitása lényegében mindenkor megegyezik a fizikai processzor funkcionalitásával. No, mármost a processzorgyártók a közöttük folyó verseny miatt újabb és újabb utasításkészlettel vértezték fel a termékeiket, amelyeket viszont nem engedtek megjelenni a konkurenciánál. Így azután egy Intel és egy AMD utasítás-készlete, regisztereinek száma és funkciója ma jelentősen eltér egymástól. Ha egy virtuális gépet átmozgatunk egyik fizikai kiszolgálóról a másikra, a mozgatásnak van egy olyan fázisa, amikor a forrás-gépen megállítjuk a virtuális processzort, az éppen futó utasításokat és regiszter-értékeket pedig a cél-gépre másoljuk, egy új virtuális processzorba. Ha azonban az új gépen nincsenek meg a forrás-gép regiszterei és utasításai, akkor a másolás nem történik meg, a gép futása pedig kárt szenvedhet. Hasonló a helyzet akkor is, azonos gyártótól származik a forrás- és a célprocesszor is, de a forrás-CPU olyan utasítás-készlettel rendelkezik, amely nem található meg a cél-CPU-n.

Megoldás a VMware-től
Hogy az esetleges virtuálisgép-összeomlásokat megakadályozza, a VMware ESX a VMotion művelet elvégzése előtt ellenőrzi a forrás- és a célprocesszort. Ha azt látja, hogy az utasítás-készletek eltérnek egymástól, akkor megakadályozza a művelet végrehajtását. Az ESX 3.5 U2 még ennél is tovább megy és bevezeti az “Enhanced VMotion Compatibility” funkciót. Ennek lényege, hogy egy fürtön belül minden processzorra maszk húzható, vagyis a virtuális gépek elől elrejthetők az új utasítás-készletek. A fürt szinten egységes utasítás-készlet lehetővé teszi, hogy a VMotion műveleteket sikeresen végre lehessen hajtani. Miután a fürt minden tagja j processzort kapott, a maszkot le lehet venni és az utasítás-készlet használatba vehető.

A Hyper-V működése
Mike DiPetrillo rosszul tudta: mind a Virtual Serverben, mind pedig a Hyper-V-ben VAN processzor kompatibilitás ellenőrzés. A mozgatás során először lementjük a virtuális gép állapotát, majd a célgépen, a mentett állapot betöltése előtt, ellenőrizzük, hogy betölthetők-e a lementett virtuális processzor utasításai. Ha nem, akkor nem történik meg az adott gépen a visszaállítás, az erőforrás csoportnak keresnie kell egy kompatibilis processzorral rendelkező node-ot. Ha nincs ilyen, akkor a mozgatás meghiúsul – de a virtuális gép stabilitása nem kerül veszélybe. Mellesleg van mód arra, hogy inkompatibilis processzorok között mozgatni lehessen gépeket. Nem kell nagy csodára gondolni: pusztán arról van szó, hogy a Quick Migration során be lehet állítani, mi legyen az erőforrás kikapcsolt állapotba tételekor a teendő a virtuális géppel (Offline action). Ha az állapotmentés (save state) helyett azt mondjuk, legyen lekapcsolás (Shut down), máris nincs állapot, amit át kellene vinni, tehát a virtuális gép átköltözhet egyik fizikai kiszolgálóról a másikra – egy újraindítással megfűszerezve.

A történet itt véget is érhetne, a a vmware-es kollégák nem nyugodtak és összehoztak egy videót arról, mennyire “nem működik” a processzor kompatibilitás ellenőrzés a Hyper-v esetén. Intel-AMD demót nem lehet bemutatni a fentiek miatt, maradt hát az azonos gyártó de eltérő utasítás-készlet szituáció. Ha valaki megnézi a videót, első az elszörnyülködés. Te jó ég! Hogy még ezt sem tudja! Hogy lehet egy ilyen termékben megbízni! Mielőtt azonban mindenki teljes letargiába esik, érdemes néhány dolgot “észrevenni”:

1. A videón egy desktop alkalmazás az állatorvosi ló. Nem egy levelező kiszolgáló, nem egy adatbázis-kezelő, nem egy ERP rendszer, nem egy fájl- és nyomtatókiszolgáló, nem egy webszerver stb. stb. Miért? Nem lenne hatásosabb, és főleg, életszagúbb, ha ismert szerver-alkalmazást mutattak volna be? Nem lehetséges, hogy azért ezt az alkalmazást használták a videó készítői, mert nem ismernek olyan szerver szoftvert, amely a fenti utasítás-készlet különbség hatására összeomlik?
2. OK, rendben. Lehet, hogy nincs ilyen szerver alkalmazás. Akkor miért nem olyan utasítás-készletet mutatnak, amely releváns? Nem lehet, hogy azért, mert az SSE 4.1-es utasításkészletet az egyetlen, amin be lehet mutatni ezt a hibát?
3. Az SSE 4.1-et tipikusan multi-média alkalmazások használják. Gyakori használata ez a szerver-virtualizáció termékeknek? Aligha.

Persze adódik a kérdés: ez esetben tulajdonképpen lényegtelen az utasítás-készlet ellenőrzés? Nem, nem az. Látni kell, hogy a VMware ESX lassan nyolc éves termék. Ez idő alatt rengeteg processzor került ki a piacra és bizonyára sokkal könnyebb lenne demózni egy 2002-2003 táján kiadott proci és egy mai közötti inkompatibilitást. A VMware-nek, már csak a termék története miatt is, létre kellett hoznia ezt a funkciót.

A Hyper-V, az ESX-hez képest, az újabb processzorokon fut (megköveteli a hardveres virtualizáció támogatást). Bár a processzorok erőteljesen fejlődnek, a fejlődés jelenleg a magokra, és olyan képességekre koncentrál, amelyet a virtualizációs gazdagépek tudnak kiaknázni, az utasítás-készlet bővülés ritkább (de amint láttuk nem szűnt meg teljesen). Ahogy haladunk előre az időben, úgy válik egyre valószínűbbé, hogy újabb utasítás-készletek lesznek elérhetők. Ha ezeket a szerver alkalmazások is kihasználják, akkor majd a Hyper-V is szembesül azokkal a problémákkal, amelyekkel az ESX már korábban találkozott. Ma még ez nincs így.

Vagyis, összefoglalva: a vmware-es kollégák által készített demó egy ténylegesen meglévő, de jelenleg még marginális probléma felnagyítása. A célja pedig, hogy a bizonytalan ügyfeleket elriassza a hyper-v-től. Úgy szokás ezt nevezni, hogy FUD.

Ki a fene az a Joe Wilcox? – gondolhatjátok most páran. Nos, ő egy újságíró, és az EWEEK-en több blogot is vezetett. Ezek egyike a Microsoft-Watch. 2006. novemberében vette át a feladatot, és azt gondolom, hogy nagyon magas szinten végezte a munkáját. Az ő írásai révén értettem meg például:

• hogyan működik a Microsoft, mint üzleti vállalkozás.
• miért fontos a keresés témaköre
• miért fontos a mobil informatika
• hogyan működik a Microsoft marketingje
• milyen hibkat követett el a Microsoft a Vista piacra dobásakor és hogyan igyekszik azt elkerülni a Windows 7 bevezetése során.
• stb. stb.

Nem mondom, hogy mindig egyet értettem vele, de a gondolatai segítettek eligazodni nem csak a Microsoft, de a teljes IT iparág világában. Joe kritikusan, de igazságosan írt a Microsoftról, precízen elemezte az üzleti eredményeit, kommentálta a reklámjait, megjegyezte a vezető jóslatait, aztán megnézte teljesülnek-e. Fantasztikus módon ismeri a cég belső szerkezetét, vezetőit, elemzéseket írt, amikor valaki távozott, amikor valakit előléptettek, vagy átcsábítottak a konkurenciától.

Hát, most kirúgták. Recesszió van. Azt hiszem túl értékes a tudása, hogy egy másik orgánumnak ne kellene, úgyhogy előb-utóbb újra írogatni fog majd. Azért mégis sajnálom: munkanélkülésig, bizonytalanság – kemény világ, velünk is megeshet.

Ha látom majd hol bukkan fel jelezni fogom.

És még valami: több mint 100 webnaplót követek – néhányat nagyon alaposan, néhányat csak felületesen. Viszont csak 5 RSS előfizetésem van a mobiltelefonomban. A Microsoft-Watch az egyik – volt.

Az úgy volt, hogy a munkám során egyre többször kellett az ügyfelek számára, munkatársak számára stb. összehasonlítgatni az ESX VMotion és a Microsoft Quick Migration funkcióit. A dolog egyre sűrűbben előfordult, rengeteg ködös gondolattal találkoztam szóban és írásban, ezért elkerülhetetlenné vált egy cikk megírása. El is kezdtem, de aztán rájöttem, hogy alapok nélkül nincs értelme, így született meg a majd fél éven át írt összehasonlító cikksorozat, melynek megírása során én magam is sokat tanultam. Végül a konkrét Quick Migration – VMotion elemzés a 10. cikkben íródott meg – s milyen furcsa  - ez a cikk egyetlen megjegyzést sem kapott. (Igaz, a HUP-on megtárgyaltuk a téma egy részét). Az érvelést senki nem cáfolta, még csak nem is kritizálta. Ez egyrészt jó, másrészt azt sejtem, hogy a Excel táblába valójában senki nem kukkantott bele.

Én viszont az egyik ügyfélnél a napokban eljátszottam vele, és úgy gondoltam, néhány képet érdemes megosztani ezen a helyen is. Az eredeti tábla adataival egy “Lehetőségelemzést (What..If Analysis)” végeztem. Ilyenkor meg lehet adni, hogy melyek legyenek a változó adatok, illetve melyek legyenek a megjelenítendő eredmény-cellák. Változónak a negyedik sor három oszlop adtam meg (A gépek száma, amelyen az elosztott alkalmazás fut C4:E4), eredmény-cellák pedig a 22. sorban a rendelkezésre állás értékei (C22:E22) Az eredeti cikkben is említettem ezt a módszert, de nem készítettem róla ábrákat. A vizsgálat, ugye, arra vonatkozik, miként csökken a rendelkezésre állás, ha egyre több – nem redundáns – kiszolgáló alkotja. Az ábrán jó látható, hogy a fizikai kiszolgálók esetén jobban csökken, a QM és a VMotion esetén kevésbé, ez utóbbi kettő szinte fedik egymást. Az ábra léptékéből kevésbé látszik, de el kell mondani, hogy a QM és a VMotion vonala nem párhuzamos, a Quick migration esetén a csökkenés nagyobb, a különbség viszont elenyésző. Mit mond az ábra:

1. VMotion és a Quick Migration technológiák hasznosak, mert növelik a szolgáltatások rendelkezésre állását.
2. A három szituáció közül a legjobban a VMotion teljesít.
3. A Quck Migration karakterisztikája nem a fizikai eszközökéhez, hanem a VMotion-höz hasonlatos .
4. Amekkora a különbség a QM és a VMotion vonal között, annyi rendelkezésre állást lehet “nyerni” a technológiai váltással. (Vagyis elenyészőt.)
5. A kiszolgálók számára növekedésével a rendelkezésre állás erősen csökken, ez a QM/VMotion csak lassítja/csökkenti, de nem szünteti meg.

A következő esetet úgy készítettem, hogy a fizikai és a VMotion adatokat változatlanul hagytam, a Quick Migration-nél viszont 2 VM-es környezettől kezdődően egy tartalék VM-et iktattam a rendszerbe, vagyis az egyik rész-szolgáltatást redundássá tettem (pl. egy webszervernek van egy párja és NLB-ben működnek együtt.) Az összehasonlítás persze “igazságtalan”, de a célom az volt, hogy megvizsgálja, hogyan hat a rendszerre, ha a hypervisor szintű fürtözést legalább egy vendég-gép magas rendelkezésre állásával ötvözöm.

Jól látható, hogy, a Quick Migration-ös eset “jól reagál” a plusz VM-re, a szolgáltatás rendelkezésre állása javul, méghozzá sokkal jobban, mintha QM helyett Live Migration-t kezdenénk használni. Tegyük rögtön hozzá, hogy abban az esetben, ha a VMotion-ös rendszernél alkalmaztuk volna ugyanezt, a vonal éppúgy megugrott volna. Az ábrából az alábbi következetés vonható le:

1. A vendég rendszerekben megvalósított magas rendelkezére állás biztosítása hatékonyabb (jobban tartja vízszintesen a vonalat, illetve magasabban fut a vonal), mint akár a Quick Migration, akár a VMotion alkalmazása.
2. Lehet a Quick Migration-ös rendszerekkel magasabb rendelkezésre állást biztosítani, mint a VMotion-ösökkel, ha az utóbbinál a tervezés során elhanyagolják a vendég VM-ekben implementálható magas rendelkezésre állási technológiákat.
3. A Quick Migration és a VMotion nem váltja ki az alkalmazás szinten biztosított magas rendelkezésre állási technológiákat.

A harmadik ábra az előző kiteljesítése. Itt úgy módosítottam az adatokat, hogy a Quick Migration esetében minden VM teljes, alkalmazás szintű rendundanciát élvez. (Ez megint “igazságtalan”, de a vizsgálatnak megint csak “hatás” vizsgálata a célja.)

Az ábrából levonható következtetések:

1. Az alkalmazás szinten megvalósított magas rendelkezésre állásnak nincs párja. (Legalábbis itt nincs :-)). Sokkal jobban tűri a rendszer összetettebbé válását, mint bármely más módszer.
2. Virtualizált környezetben sem szűnik meg az alkalmazás szintű technológiák haszna, sőt, akinek igazán számít a HA, az ezt a módszert alkalmazza.

Összességében elmondható, hogy:

1. Akinek számít a magas rendelkezésre állás, az nem mond le az alkalmazás szintű (VM szintű) eszközök használatáról. Ebben az esetben mindegy, hogy VMotion vagy Quick Migration segíti.
2. Akinek nem számít a magas rendelkezésre állás, annak lényegtelen, hogy a Quick Migration kapcsolat-kiesést okoz.

Miért fontos ezen gimnasztikázni? Azért, mert a VMotion-t ma kötelező elemnek érzik az ügyfelek(*), míg a Quick Migration-t alkalmatlannak tartják arra, amire a Microsoft javasolja. Az is igaz, hogy csupa olyan ügyfél gondolja ezt, aki maga még nem használta. Ahol implementálták, elégedettek vele.

Idáig az eredeti cikk kiegészítése. Ugyanakkor már a HUP-on is leírtam, ezért itt is elmondom, hogy az érvelés ugyan helyes, de van olyan szituáció, amikor nem állja meg a helyét. Idézek magamtól:

“A fenti okfejtésből egy dolog maradt ki: mi van akkor, ha maga a virtuális gép léte és működése a szolgáltatás? Akkor fordul elő ez a helyzet, ha a “vas” szolgáltatója és a tényleges, VM-ek hordozta szolgáltatás gazdája egymástól független, vagy azért mert eleve valamilyen hostolás/Outsource stb. helyzetről van szó, vagy pedig azért, mert olyan irdatlan nagy az IT. Nos ekkor a QM könnyűnek találtatik, nem elégséges.” (2008. dec. 6. - HUP)

Nos, pontosan ezt történt a Microsoft esetében is. A Microsoft IT rendszere az egyik legnagyobb elosztott vállalati IT a világon. Számos szempontból különleges, egyedi. Többek között abban például, hogy a saját vállalati szoftvereinket rendre béta3 körüli állapotukban bevezetjük, majd a bevezetés tapasztalatai alapján szükség szerint módosítunk a szoftveren. “Edd meg, amit főztél!”, angolul dogfooding. Így történt ez a Hyper-V-vel is. A Quick Migration gyenge pontja, ahogy azt decemberben leírtam, rendesen meg is jelent.

A cikk címébe is beleírtam, hogy a témát utoljára feszegetem. A Windows Server 2008 R2 megjelenésével a VMotion megszűnik “megkülönböztető képesség” lenni, megfutjuk a kötelező kört. Lesz persze a vSphere-ben “teljes hibatűrés” – de az más lapra tartozik.

Már “csak” azt kell a fejekben tisztában tenni, hogy mikor használjuk a hypervisor szintű és mikor vendég-OS szintű HA technológiát. Függetlenül a hypervisor gyártójától.

--------------------------------

(*)  A virtualization.info-tól idézve (kiemelés tőlem): “Microsoft will join the party in early 2010, when it will finally have that live migration (available for free as well) that customers perceive as a mandatory feature of every hypervisor.”

Mostanában szomszédékkal gyakrabban beszélgetünk számítástechnikai témákról. És ahogy az már a papokkal és a doktorokkal is lenni szokott, hogy tudnillik kiderül, hogy ekkor meg akkor nem tartotta a böjtöt, (orvos esetén: itt meg ott fáj), no nálunk előbb-utóbb előkerül egy-két gép, amit “meg tudnál nézni"?” És persze ahogy a szakmáját szereti az orvos meg a pap, úgy mi szívesen segítünk. Na jó, embere válogatja, de én a szívesen segítők kategóriájába tartozom. Még akkor is, ha be kell vallani, már rég messze vagyok attól, hogy azt mondhassam magamról, értek a PC-hez, attól pedig főleg, hogy támogatni is tudom. De hát ott van, ugye, az elárvult szomszéd, meg aztán milyen az már, hogy egy informatikus azt mondja, hogy még a PC-hez sem ért?

Elkalandoztam, jöjjön a történet. Pár napja szólt Zsuzsa, hogy van egy kis gond a gépével, nem jön be rajta az Internet, ha volna egy kis időm, akkor nézzek rá. Hétfő délután átugrottam, és gyorsan dobtam egy csont nélküli kosarat. Pár napja pakolták ki a szobájukat, amely korábban irodaként szolgált, és az ADSL router ment a “céges holmikkal” együtt az új irodába. Maradt egy pucér Ethernet kábel, Rubicom Internet hozzáférés. Ebből aztán már adódott a megoldás, a notebook – mert egy hordozható gépről van szó  - MAC-címét kellett regisztráltatni a szolgáltatónál, hogy a hozzáférés működjön. Betelefonáltunk, azonosítottuk magunkat, negyed óra múlva jött is a net, ahogy kell. Ha úgy nézem, itt véget érhetett volna a szerepem, de engem zavart, hogy egy notebookot csak úgy kiraknak pucéran a Netre, gondoltam megnézem, napra kész-e a gép, hogy ezt a kockázatot vállalni lehessen. Naív voltam. XP SP1, tűzfal nélkül, nem működő automatikus frissítéssel és Trend-Micro 2002 (!) próbaverziós antivírussal. No ez már mégsem maradhat így! Az világos, hogy egymagam nem küzdhetek a nagy botnetekkel, de nehogy már a szomszédtól kapjak spam-et! Az a minimum, hogy a gépre SP3, meg új böngésző, meg tűzfal kerüljön. A szomszédasszonynak nem volt ellene kifogása, úgyhogy el is kezdtem egy SP2 telepítést. Mivel azonban egy ilyen dolog sokáig tart, azt mondtam neki, hogy ha kérdez valamit a rendszer, akkor válaszoljon mindig igent, én meg majd később átnézek. Megegyeztünk, így is történt. Mikor visszaértem látom ám, hogy egy fájl másolásánál elakadt a telepítés, CRC hiba vagy ilyesmi, biztos a fájlrendszer sem tökéletes. Na, nem baj, gondoltam, majd letöltök én kézzel egy SP2-t, és kicserélem azt a hibás fájlt, aztán mehet tovább a telepítés. Mondtam az asszonykának, hogy hagyják így a gépet, este mindenképpen jövök, mert így nem maradhat.

Mentem is, de egy kis meglepetés ért. Közben “kicsit használták” a gépet és “azokat az ablakokat bezárták”. Hmm!! SP2 telepítés közben! Most aztán derítsem ki, hogy milyen állapotban van a gép. Félig SP2, félig SP1. A logok alapján ugyan visszagörgött a MSI, de azért ez így veszélyes helyzet. Megpróbáltam újraindítani a telepítőt, de erre csak annyit mondott a notebook, hogy “nice try”, előbb a korábbi telepítést koronázzam meg egy újraindítással. Bátraké a szerencse: megtettem.

Ahogy az igazi rossz álmokban lenni szokott: Home Edition, indulás, majd újra csak indulás, majd újra csak indulás…. a bejelentkezésig sohasem jutottam el. Safe Mode-ban sem, VGA módban sem, az utolsó jó konfiguráció betöltésével sem (ami érthető, hiszen fájlokat írtam felül, nem registry bejegyzéseket.) Hmm. Hétfő este volt, nekem szerdára egy fontos demót kellett összeraknom. Ebbe a slamasztikába viszont már belemásztam, nem lehet itthagyni. Megkérdeztem, folytathatnám-e szerdán, akkor több időm lesz. Persze. OK. Hibajavítás szerdára halasztva. Addig meg felkészülök a lehetetlenre: kipucolni egy félig felment SP2-t.

A szerdából csütörtök este lett, a készülésből meg semmi, de azért nekiugrottam. Volt talonban egy ERD Commander 5-ös lemezem, először azt néztem meg, hogy ha minden kötél szakad, akkor lementhetem-e az állományokat. Ez működött. Indítottam “Safe mode”-ban a gépet, az agp440.sys-ig jutott, aztán újraindult. Netezés: kapcsoljuk ki az agp440.sys-t mert megsérülhetett. Az ERD5-tel ezt megtettem. Változott a helyzet, most a mup.sys nem indult. Mi az a mup.sys? Egy UNC Provider driver. Jó, akkor most megleszünk nélküle. Az állományok dátuma szerint ugyan SP1-es, de lehet, hogy megsérült. Kikapcsoltam azt is. Ekkor az ndisproxy.sys-nél akadt el: tovább hátráltam. A következő az NTFS.SYS-volt. Hát ennek a próbasornak itt a vége. Fájlrendszer nélkül nincs semmi. Különben is, valamennyi driver SP1-es, úgy tűnik, hogy működött a telepítő visszagörgetési funkciója.

Egyik-másik oldalon olvastam, hogy a mup.sys kiakadásának számos oka lehet, de valahogy nem passzolt egyik sem az én problémámhoz. Ezek a cikkek ugyanis azt feltételezték, hogy az állományok, amelyekkel dolgoznia kellene a Windowsnak, jók, csak a registry mutat rossz helyre vagy tartalmaz rossz bejegyzéseket. Ezért a cikkek lényege az volt, hogy produkáljunk egy alap registry-t (OEM Windows esetén ez újabb aktiválást jelent), majd ha van System Restore (nálam volt), akkor álljunk vissza egy korábbi verzióra. Nekem viszont az volt az ideám, hogy nem jók a fájlok – csak éppen azt nem tudom, melyik nem jó.

Végiggondoltam az egészet és rájöttem, hogy fordítva kell elindulni. Nem azokkal az állományokkal van baj, amelyeket nem tölt be a rendszer, hanem azokkal amelyeket betölt, de nem jó verziót használ, mert az SP2 már felülvágta. Így aztán előbb elvégeztem egy olyan indítást, amikor nem a safe mode-ot, hanem az “Enable boot log” opciót választottam, majd az ERD5-öt indítva megnéztem milyen naplót produkált a gép, mit töltött be illetve mit nem. Elég érdekes eredményt kaptam. Láttam például, hogy egy PCIDump.sys állomány betöltése sikertelen volt. Mi ez a PCIDump? Aha, sok minden lehet: vírus, rootkit, trójai. Úgy tűnik, hogy nincs a gépen, de ha rootkit, akkor esetleg elrejtette magát. Van itt más is:

Az első egy nagyon különös helyre települt eszközmeghajtó ;-). A másik képen meg egy látszólag telepítéshez való szolgáltatás. Minek ilyen szolgáltatás, amikor van a rendszerben egy saját, beépített? Csak nem egy Win32/IRCBot.IW? Szóval itt vírusok is lesznek, vagyis lesz még dolgom az életre lehelés után is. Nagyjából így tértem nyugovóra csötörtök éjjel.

Nem tudom, ki hogy van vele, de elalvás előtt pörög a legjobban az agyam. Ilyenkor még 4-5 ötletet összegyűjtök és teljes nyugalommal alszom el. Most is így történt. Az egyik ötletem az volt, hogy mindent kikapcsolok, azokat a szolgáltatásokat is, amelyek működnek. Aztán arra is gondoltam, hogy leellenőrzöm, hogy az így, szűkítetten induló gép egyes dll-jei milyen dátumúak. Csak SP1-esnek szabad lennie. Ha valamelyik kilóg a sorból, akkor meglesz a ludas.

Másnap ezt is tettem. Leállítottam mindent, amit csak tudtam, hogy elég kevés eszközkezelő maradjon, azok meg mind SP1-esek voltak (és SP1-es volt a kernel is, természetesen). Vagyis az ötlet nem jött be. Közben azonban kigondoltam valami mást. Az ERD5-ben van egy összeomlás elemző is. Hátha elemzi, mi történik. Itt sem jártam sikerrel. 2007 decemberében volt ugyan egy összeomlás a sentinel eszközkezelő miatt (hardverkulcs, ugye?), de a mostani újraindulások semmilyen naplóba sem kerülnek be, túl korai fázisban történik.

No de milyen összeomlás ez? Azonnal újraindul a rendszer, mert úgy van beállítva, hogy a kékhalál után legyen újraindulás. Kapcsoljuk ki. (HKLM\SYSTEM\CurrentControlSet\Control\CrashControl ban kell az AutoReboot értéket 0-ra állítani). Szépen meg is állt a megfeleleő pillanatban:

STOP: c000021a {Fatal System Error}
The Windows Logon Process system process terminated unexpectedly with a status of (0xc0000080 0x00000000 0x0000000)
The system has been shutdown.

Találtam rögtön egy cikket (Q156669), ami szerint ilyen hibák például akkor szoktak előfordulni, ha nem sikerül felrakni egy javítócsomagot. Bingó! Most már csak végig kell haladni a cikken és kész. Aha. Nem ilyen egyszerű az élet. A cikk azt feltételezte, hogy NÉHA így dobja el magát a rendszer, de minden esetre legalább egy safe mode-ban el lehet indítani, hogy aztán a Dr.Watson-t regisztrálni lehessen mint alapértelmezett debuggert. Ez nekem nem ment. Nem működött az utolsó jó konfiguráció sem, a harmadik gyártótól származó kódokat meg már rég kikapcsoltam. Marad a helyből frissítés? Hátha mégse… Esetleg egy ASR (Advanced System Recovery). Ahhoz kellene egy SP1-es telepítő. Felhívtam Gál Tamást – nem volt neki. (Home Edition, ne feledjük!) Aztán felhívtam öcsémet, hátha neki van. Volt. Megígérte, hogy beküldi Pomázról, mert egy kollégája épp jött be Pestre. Ez nagyszerű. Egy fél órával később eszembe jutott, hátha van neki valami olyan CD-re, amely bebootol és vírust írt. (Hiába, na, nem dolgom, akkor nem tartok magamnál ilyet. Az ERD5-ben nincs ilyen. Az ERD6-ban van, de az meg csak Vistához jó.). Megkaptam a CD-ket, el is indítottam az ASR-t, de csak akkor jutott eszembe, hogy ja, ide floppy is kellene – az meg ebben a notebookban már nincs. A vírusírtót is futtattam, de régi lehetett az adatbázisa, mert nem talált semmit.

Így jött el a szombat. Beszta Janit kerestem telefonon, hátha ő tud olyan helyet, ahonnan működö Antivírus rescue disket lehet letölteni. Sajnos nem vette fel. A c0000021a hibára keresgettem cikkeket, fórumbejegyzéseket, de csak olyan oldalakat találtam, ahol ugyanez a hiba és nincs más megoldás, mint az újratelepítés. Ez nem igaz! Én ezt a gépet NEM fogom újrahúzni. Ez már preztizskérdés! Szombat délután, amikor a feleségem a gyerekekkel a játszótérre indult, úgy búcsúztam tőle, hogy már nem sok munícióm maradt, és ha minden kötél szakad, akkor újra kell húznom a gépet. Aztán ahogy nagy csend lett a lakásban, hirtelen támadt egy ötletem.

Hátha a Winlogon-t vírus írta felül? Megnéztem, dátum szerint a fájl érintetlen volt. Viszont sikerült találnom a merevlemezen egy i386 könyvtárban egy ugyanolyan dátumú winlogon.exe-t. Egy mappába másoltam őket, íme az eredmény:

A .orig végződésűvel szeretett volna indulni a rendszer, csak hát férges a szentem. Csere-bere, és BINGÓ! Elindult a masina.  Csupán azért nem ugráltam körbe a lakást, mert még nem gyógyult meg a bokám. :-)

Jani továbbra sem volt elérhető, pedig a vírus vonal egyre valószínűbb. Az is lehet, gondoltam, hogy egy Rootkittel van dolgunk. Gyorsan letöltöttem a SysInternals oldalról a RootkitRevealer-t, ami hozott is némi eredményt:

Jó, ezeket a kulcsokat lehet törölni, de ettől még szükség van egy Offline vírusírtásra. Vajon melyik vírusírtó cégnek van boot CD-je naprakész vírusírtó adatbázissal letölthető, formában? Kutakodtam a neten, de egyetlen használható rendszer sem volt. Annyi legalább kiderült, hogy minden vírusírtóhoz SP2 kell, és hogy a ForeFront kínálja a leghosszabb próbaperiódust – 120 napot.

Amíg meglesz a bootolható CD, gondoltam, felteszem az SP2-t (meg az SP3-at). Így is tettem. És ha már van SP3, akkor feltettem egy 120 napos ForeFront Client-et is, hátha nem fut a vírus, akkor szerencsém van. Azt tudtam, hogy a ForeFront adatbázisának frissítéséhez nem Windows, hanem Microsoft Update kell. Viszont amikor át szerettem volna állni, és a frissítéseket leszedni, úgy találtam, hogy nincs internet hozzáférésem. Hmm. Pont a Windows Update-hez? Ez tipikus vírus-szokás. Esetleg a host állományt írta volna felül? A kis huncut! Nem beleírta magát NtKrnlpa.info-ként! Ez a W32.Virut.CF szokása.

Most akkor fut a vírus, vagy nem? A Microsoft Update-et valahogy sikerült elindítanom, és le is jött az új motor meg a szignatúra-adatbázis, ekkor azonban a rendszer teljesen megkergült. A Forefront gyakorlatilag azonnal mindent karanténba zárt, bármihez értem, bármit indítottam és W32Virut.AC vírusra panaszkodott. Újra kellett indítanom a gépet és bár elindult, elfogadta a felhasználók jelszavát is, a bejelentkezés azonban 2 másodperc után kijelentkezéssé alakult, vagyis a gépbe nem tudtam belépni. Szerencsére a safe mode működött, de a a Forefront 2 másodperc után abbahagyta az ellenőrzés. Szereztem egy egyedi, kifejezetten a Virut eltávolítására való szoftvert is a Symantec oldaláról, de csalódnom kellett: két futó processz kiírtásán túl egyetlen vírust sem talált. Ennyi töketlenkedést!

Ekkor sikerült végre beszélnem Beszta Janival. Fantasztikus javaslata volt! Az ESET cég NOD32-es vírusírtója tartalmaz egy Rescue Disk előállító alkalmazást is, és ha van a gépen Windows Automated Installation Kit (WAIK), akkor az abban lévő WinPE segítségével készít egy naprakész antivírus adatbázissal ellátott, bootolható CD-t. Hoppá! Van, aki támaszkodik a Microsoft ingyenes eszközeire? Ez igen! A hír szombat este érkezett, és tudtam, hogy egy ESET letöltés telepítés, WAIK telepítés, majd diszk készítés barátok között is legalább két óra, feltéve, hogy van használható XP a közelben. Nekem szerencsére volt egy, virtuális gépben futtatott példány. Vacsora és gyerekfürdetés közben/alatt/mellett kipreparáltam a gépemet, telepítettem rá egy NOD32 4-es verziót, illetve emlékeztem, hogy a Windows 7-hez letöltöttem már egy WAIK-ot, felraktam hát azt.

Persze a lusta ember kétszer dolgozik. Az ISO készítő rutin gyorsan elhasalt. A neten való keresgélés során hamar kiderült, hogy a hiba az új (béta) WAIK-kal van. No, ekkor gyorsan visszaálltam az eredeti XP preparátumra (Hyper-V snaphot), NOD32 újra letölt, telepít, aktuális WAIK letölt, telepít. Az antivírus adatbázisa február 20-a volt, és nem akart frissülni, nem baj, jó lesz ezzel is. Az ISO elsőre sikerült, de amikor visszatértem, a NOD32 jelezte, hogy van mai adatbázisa. Na, akkor még egyszer ISO készítés. Az elkészültét azonban nem vártam meg, véget ért a szombat, elmentem aludni.

Vasárnap reggel az első dolgom a ISO kiírása, majd futtatása volt. Legnagyobb meglepetésemre egyetlen vírust sem talált. Ez hihetetlen! És ami még furcsább, a lemezen nem volt felület, ahol meg lehetett volna nézni, milyen dátumú adatbázissal dolgozik a program. A könyvtár kilistázása meg azért nem segített, mert ott a ISO elkészítési dátuma szerepelt. Hogyan lehetne leellenőrizni ezt a merevlemezt? Kell, hogy legyen vírus! Megint következett egy óra gondolkodás.

Végül a megoldás egyszerű volt, mint a pofon: az ERD5 képes megosztani meghajtókat! Megosztottam, majd távolról a NOD32 BIZTOSAN naprakész adatbázisával végeztem egy ellenőrzést. Először csak egy javítás nélküli átfésülést, majd egy tényleges írtást hajtottam végre. Több mint ezer víruspéldányt találtam (valószínűleg a Forefront ellenőrzés szórta szét a nagy részét), de típus szerint is gazdag volt a felhozatal:

1. 1. Win32/Virut.AV – vírus
2. 2. Win32/Hatob.E – féreg
3. 3. Win32/Injektor.KT – trójai
4. 4. Win32/Injektor.MM – trójai
5. 5. Win32/Rbot – trójai (image.jpg-ben!)
6. 6. Win32/Injektor.KT változat – trójai
7. 7. Win32/IRCBot.ANC

A kép tanusága szerint mindet le is irtotta. Ezután már be tudtam lépni a gépbe, naprakészre frissítettem a ForeFrontot, és mivel volt néhány tömörített állomány, amelyet az NOD32 a hálózaton át nem nyitott meg, még egy ellenőrzést végeztem. Megérte. A hálón fennakadt még további hat példány és még egy típus. TrojanDownloader.BAT/FTper.gen. Ezzel a javítás befejeződött. Már csak annyi dolgom volt, hogy naprakészre frissítsem a gépet, bekapcsoljam a tűzfalat és feltegyek egy IE8-at, abban legalább van adathalász-szűrő, meg ha kell automatikusan frissül.

Vasárnap estére elkészültem, átkopogtam a szomszédhoz, majd amennyire csak lehetett mellőztem a szakmai fogalmakat, de elmeséltem, mi történt. Ezután egy gyorstalpaló következett: mi mindent kell megtenni annak érdekében, hogy az ember biztonságosan Internetezhessen.

Csodálkoztak rajta, hogy ennyi vírus hogyan kerülhetett rá, hiszen nem is volt hálózaton. Aztán amikor a férj megjött, kiderült a működési üzemmód: előkerült egy mobil internetes kártya és már jött is a net. Aha. Hát így.

Szakmai szempontból – utólag persze – a sok kanyar símán levágható lett volna. Élni lehetett volna a gyanúperrel, hogy “ilyen környezetből” vírusos gép várható, ezért mindjárt az ESET-tel kellett volna kezdeni – vagyis, tulajdonképpen bármilyen naprakész vírusírtó megtette volna, csupán az ERD5 megosztási képességét kellett volna igénybe venni mindjárt az elején.

Ebből is látszik, hogy ez a feladat nem a szakmám. Megoldottam, mert meg akartam oldani, de egy otthoni felhasználókat nap mint nap támogató mellékállásos rendszergazda egy óra alatt elintézte volna. Lehet, hogy nem tudta volna kideríteni, hogy a winlogon.exe miatt nem indul a gép, de a vírusírtó megoldotta volna helyette a problémát. A frissítés nem már rutinművelet.

Jó kaland volt. Egy időre elég is belőle :-)

Megoszlanak a rendszergazdák abban a tekintetben, hogy a kiszolgálók számára inkább rögzített címet adnak, vagy hagyják, hogy a DHCP szolgáltatás végezze a dolgát. Én egy járható középutat képviselek: hacsak egy alkalmazás (pl: DHCP szerver, DNS szerver stb.) nem követeli meg a fix IP-címet, én a dinamikus – de lefoglalt címkiosztást (reservation) konfigurálom be. Így állandó IP-címeket kapok, mégis központi felügyeletet. Egy gond van csak ezzel, az, hogy macerás a rekordok rögzítése. Megnézni a MAC címet, majd bepötyögni, ellenőrzni, hogy a kiszolgáló biztosan az a címet kapja… Fárasztó, na.

A fejlesztők is ezt gondolhatták, mert a minap telepített Windows Server 2008 R2-es DHCP konzolban észrevettem egy új funkciót. Egy kiosztott címre jobb egérgombbal kattintva azonnal “rögzíthetjük” a foglalást az “Add to Reservation” menüvel. Ah, minő kényelem!

 
Persze lehet, hogy ez csak nekem új és már a Windows Server 2008-ban is megvolt (nem jártam utána). Ez mindenesetre pár tucat kattintással rövidíti a munkát egy-egy gép esetén. Örülök.

Jópár napja egy viszonylag összetett demókörnyezetet építek két fizikai géppel. Az egyik az augusztusban kapott demó PC-m, a másik meg a pár héttel későbbi Lenovo notebookom.

Ma délután egyszer csak elszürkültek a virtuális gépek képernyői. Hirtelen azt hittem, hogy megszűnt a hálózatom, aztán azt, hogy kékhalálba dőlt a fizikai kiszolgálóm, de aztán kiderült, hogy egyik sem. A Lenovo mellé kaptam egy külső merevlemezt is, amit korábban már telepakoltam mindenfélével. Most, mielőtt a munkát elkezdtem, elfelejtettem letörölni, és az a banális apróság akasztott meg, hogy elfogyott a hely a diszken.

Ilyenkor a Hyper-V nem hasaltatja el a gépeket, csak pillanat-álljba kerülnek. Ritka helyzet, gondoltam megörökítem, mielőtt újra elindítom a masinákat ;-)

Ja, igen. Windows Server 2008 R2 (Béta).

Február közepén, amikor eltörtem a bokámat(*), a kollégáim gyorsan lemondták az arra a hétre és a következőre szervezett értekezleteket és ügyfél-találkozókat. Két nap kórházi ágyban fekvés után rájöttem, hogy ha még két hónapig ezt (a semmit) kell csinálnom, akkor halálra unom magam. Elgondoltam, hogy milyen érdekes lenne, ha otthonról, az webkonferencián keresztül kapcsolódhatnék be egy-egy megbeszélésbe. Mivel a kollégák nap mint nap hívtak, el is mondtam nekik az ötletet. Jót nevettünk, hogy akkor rajta, próbáljuk ki. (A kórházban, az ismert közállapotok miatt, nem vittem be a notebookomat.)

Azt tudni kell, hogy a Microsoft előszeretettel használja a saját termékeit, így vagyunk az Office Communications Server 2007 –tel is. A gépeinken fut a Communicator (nekem ráadásul telefonintegrácóval, mert majdnem két évig “vittem” ezt a terméket, és lehetőségem volt ezt bekapcsoltatni) és van persze Live Meeting kliensünk – ennek a segítségével lehet webkonferenciát tartani. A cég által felépített OCS infrastruktúráról most itt nem írok, de akit érdekel, annak érdemes egy pillantást vetni az Microsoft IT Showcase ide vonatkozó oldalára. A prezentációban látszik, hogy három adatközpontban találhatók a szerverek, a mi általunk használtak Írországban, Dublinban vannak.

De nem csak az adatközpontokra áldoztunk, hanem kiépítettük a “végeket” is. A magyarországi tárgyalók többségében elhelyeztek már egy-egy RoundTable-t, amely nem csak webkamera, hanem egyben mikrofon és hangszóró is. (A kivetítők már korábban is a tárgyalók tartozékai voltak.)

Szóval meggyőztük az ötletről a kereskedőt, akinek az ügyfelével találkoznunk kellett volna, megkértük az ügyfelet, hogy a megbeszélés nálunk legyen, aztán amikor megérkeztek a kollégák, akkor elmeséltük nekik, hogy miért épp így fogunk társalogni. Én meg itthon létrehoztam egy webkonferenciát, meghívtam rá a munkatársaimat, feltöltöttem a powerpoint előadást, bekapcsoltam a webkamerát, és vártam, hogy kezdhessek.

Annak idején volt egy belső videó arról, hogyan képzeli el a Microsoft az egységes kommunikációt 2010-ben. Ez persze később nyilvános lett, én meg most jót mosolyogtam, hogy akárcsak a film végén, amikor Eli Bowen zakóban, nyakkendőben, de (nem látható)  rövidnadrágban tartotta meg az előadását, most én látszom pólóban, miközben ténylegesen pizsamában, felpolcolt lábbal feküdszem az ágyamon.

Persze az ügyfelek az első negyed órában nem a tényleges témával foglalkoztak, hanem hogy milyen ez a rendszer, hogyan épül fel, milyen sávszélesség kell hozzá. (A Roundtable-es előadásokhoz nagyjából 512 Kbit/sec), Aztán megszokták a helyzetet és minden ment a maga útján. Én előadtam, ők meg kérdeztek, beszélgettünk, maradtunk valamiben – szóval majdnem olyan volt, mintha ott lettem volna.

Így néz ki az előadás a gépen keresztül. Sajnálom, hogy a panorámaképes képernyőt elfelejtettem lelopni, majd pótolom.

A sikeren felbuzdulva további előadásokat is szerveztünk. Marci kollégám vette a bátorságot és (RoundTable nélkül) kiment egy – mellesleg a infokommunikációs szektorban tevékenykedő ügyfélhez – és egy mobil szélessávú kapcsolattal jelentkezett be a webkonferenciába. Az első pár percben bekapcsoltam a kamerát, elmeséltük a szituációt, majd a sávszélességel való takarékoskodás érdekében kamera nélkül, csak hanggal tartottam meg az előadást. Teljesen jó volt, kiváló hangminőséggel, ami azért szerintem még a RoundTable-nél is nagyobb mutatvány. Két notebook, az egyik egy Wireless házi hálózaton, a másik egy mobil-internet eléréssel; mindkettő kint lóg az interneten az OCS infrastruktúrához képest, mégis, VPN nélkül, jó minőségben előadást lehet tartani. Komolyan, még én is meglepődtem.

De van még tovább is. Egy harmadik alkalommal azt kérték tőlem, hogy “ugyan már demózzad le azt a System Center Operations Manager”-t, mert az ügyfél kíváncsi rá. Az OpsMgr azért szép állatfajta, mert egy rendszerfelügyeleti szoftver, amit elég nehéz demonstrálni, ha nincs mögött legalább egy icike-picike rendszerecske. Az én notebookomat bőven ellátták ugyan erőforrással, már amennyire ez egy notebook esetén elmondható, de a maximális 4 GB memóriába még egy Opsmgr is csak cipőkanállal fér bele, nemhogy még egy mini hálózat is fusson.

Nagyjaink azonban bölcsen leszerződtek egy partnerünkkel, és ez új lehetőséget adott a kezünkbe. Az MSSalesDemos oldalt és a mögöttes infrastruktúrát nem a Microsoft üzemelteti. Mégis ADFS segítségével a saját, microsoftos nevemmel és jelszavammal bejelentkezhetek és kiválaszhatok több, “előfőzött” demókörnyezetet. Valahogy így:

Előre beléptem, kiválasztottam a “System Center data center solution” környezetet és kértem időpontot – a webkonferencia előtt két órával kezdve. Miután a demókörnyezet elindult, RDP kapcsolat-ikonok jelentek meg a képernyőn, és valóban rájuk kattinva be is jelentkezhettem a gépekre. A virtuális gépek hyper-v-n futnak (naná!) és az általuk használt összes memória kb. 40 GB. Mit ne mondjak: demó a kezem között még nem volt olyan gyors, mint akkor.

És hogy működik ez a Webkonferenciával? Egyszerűen: nem csak PPT-t lehet megosztani, de ablakokat, sőt az egész Windows asztalt is. Csupán annyit tettem, hogy megosztottam az RDP ablakot, és máris átváltottam demó nézetre.

r

Ráadásul még egy apró kapaszkodót is készítettem magamnak. Egy olyan funkciót kellett bemutatnom, amelyet korábban én sem használtam még. Előző nap gyakoroltam és a környezethez készült demóleírás alapján felkészültem. Ezzel együtt – jobb a biztonság – a leírást – nem megosztva – az RDP ablak mellé tettem. Végül is nem volt rá szükség, de ha kellett volna, leshettem volna.

No, hát ilyen az igazi távmunka. Nem csillog annyira, mint az a sci-fi UC 2010-ből, viszont működik. Web’n’walk-kal, RoundTable-lel, alkalmazás-megosztással, webkamerával – interneten, QoS nélküli hálózaton. Nem kell hozzá speciális terem, különleges kamera, előzetes foglalás. Nem kell hozzá rang és kiváltság, hogy “bebocsáttassunk” a terembe. Az OCS a “mindenki” konferencia-szoftvere.

Szeretek a Microsoftnál dolgozni, mondtam már?

---------------------

(*) – Köszönöm, a körülményekhez képest jól vagyok. Szerdán levették a járógipszet, most a gyógytornázós periódus következik. A lakáson belül egészen jól elközlekedem, estére viszont jól jön, ha a mankó könnyít a műtött lábamon.

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:

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:

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.

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.

2. 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.
   
3. 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.)
   
4. 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.)
   
5. 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.
   
6. 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.
   
7. 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.
   
8. 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.

2. 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.
   
3. 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.
   
4. 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.
   
5. 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.
   
6. 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.

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.

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!

Pár napja olvastam a virtualization.info-n, hogy a VMware a végén még  “infrastructure management company” lesz. Az az igazság, hogy mi, a Microsoftnál, azóta látjuk így, amióta a elindítottuk a magunk DSI stratégiáját, az pedig nem most történt. 2006-ban érkeztem a céghez, és azóta mondjuk, hogy a virtualizáció végső soron rendszerfelügyelet, és hogy nem a hypervisor a legfontosabb – bár persze azért el nem hanyagolható.

Nem véletlen, hogy a Microsoft nem kezdett bele valami teljesen újba (na jó, régebben azért nem volt Virtual Machine Manager), hanem a meglévő System Center termékeit okosította fel. Csak néhány példa:

• A fizikai és virtuális gépek monitorozását az Operations Manager végzi, nem pedig az új SCVMM.
• A virtuális alkalmazások terítését rá lehet bízni az Configuration Manager-re.
• Az Offline patching feladatokat az a komponens végzi, amely az “online” frissítéseket: az SCCM.
• A PRO tippeket – a teljesítmény-paraméterek figyelésével – a Operations Manager adja, viszont az SCVMM hajtja végre.

Nem csak mi gondoljuk, hogy a rendszerfelügyelet a lényeg. Ezt gondolja a VMware is. Olyannyira, hogy az ő termékük – egyelőre – meg sem kerülhető. Azt tudtam, hogy az SCVMM felügyelheti az ESX kiszolgálókat, és azt is tudtam, hogy ehhez VMware Virtual Centerre is szükség van. Most viszont már azt is tudom, hogy miért.

A Microsoft viszont a hypervisor körül másképp alakította ki az API felületet. Bárki készíthet a System Center termékeknél jobb megoldásokat úgy, hogy a System Center családot teljesen elhagyja.  Íme két kis videó, amit a Citrix mérnökei készítettek. A Citrix Essentials (a lényeg, ugye :-)) egy készülő rendszerfelügyeleti megoldás, amely egyaránt képes lesz Hyper-V, XenServer és ESX felügyeletére. Az egyik fantasztikus szolgáltatásuk a StorageLink lesz, érdemes megnézni mit fog tudni, ha elkészül.

Csak néhány finomság: sokszor emlegetett hátránya a hyper-v-nek, hogy mivel nem tartalmaz fürtözött fájlrendszert, ezért minden VM-nek külön LUN-t kell biztosítani, ami meg elviselhetetlen terheket ró a storage-ot felügyelőkre. Itt meg az történt, hogy a StorageLink elkészítette a LUN-okat, ráadásul úgy, hogy a tényleges tevékenységet maga a storage végezte. Hmm. Derék. Aztán, hogy hasítson mint a villám, pass-through lemezként adta oda virtuális gépeknek. És a felület? Tisztára SCVMM érzés.

Van itt egy másik kis videó is, ez is Citrix, a készülő “Dynamic Provisioning Services"-ről. Szervertelepítésindításhasználatbavételegyegérhúzással? Na, itt lehet megnézni:

A mögötte lévő technológia is megér egy misét. A Citrix az Ardence felvásárlásával jutott ehhez az érdekes funkcióhoz. Ahogy a videón is elhangzik, a HP kiszolgáló nem egy helyi lemezről indul, hanem a hálózatról. Az Ardence kifejlesztett egy, az iSCSI-nél hatékonyabb protokoll-t, amely segítségével a hálózaton át felcsatol egy mappát és onnan indul a gép. A történetben az az izgalmas, hogy ezt mind fizikai, mid virtuális gép esetén meg lehet tenni – sőt ez a technológia az alapja a Citrix alkalmazás-streamingnek is.

Szép kis verseny lesz itt jópár éven keresztül, de már nem a hypervisor a lényeg.

Manapság az IT szervezetek számára a virtualizáció az egyes számú költségcsökkentési fegyver és lehetőség. A technológia érettségével egyre kisebb kockázatú projektek indíthatók, miközben kombinált virtualizációs megoldásokkal az IT infrastruktúra újabb és újabb területei célozhatók meg korszerűbb architektúrákkal. Ezek a projektek viszont sokszor nem veszik figyelembe, hogy a virtualizáció alapvető változásokat hoz a licencelés területén, s néha egészen új konstrukciókra van szükség a jogitsztaság megőrzéséhez.

A VDI-ról röviden
A VDI rövidítés a Virtual Desktop Infrastructure-t takarja.  A megoldás lényege, hogy szerver virtualizációs infrastruktúrán, (Hyper-V, XenServer, VMware ESX stb.) virtuális gépekben desktop operációs rendszereket – tipikusan de nem kizárólag – Windows XP-t futtatunk, a felhasználók számára pedig egy kvázi állapot nélküli eszközről, általában vékonykliensről biztosítunk a fenti infrastruktúrához hozzáférést valamilyen távoli asztal elérési protokoll – RDP, ICA – segítségével. A felhasználóknak lehet dedikált virtuális gépe, de használhatnak “állapot nélküli” megosztott desktopot is – ilyenkor gondoskodni kell arról, hogy a felhasználót kövessék az adatai és az alkalmazásai. Egy szofisztikált VDI megoldás lényegében nem futtat több virtuális gépet, mint amennyi felhasználó ténylegesen bejelentkezett. A gépek provizionálásáról, indításáról, leállításáról, felhasználóhoz rendeléséről stb. megfelelő menedzsment környezet gondoskodik.

A takarékossági ötletek
Bár jelentős szerver infrastruktúrát kell kiépíteni, az összetett rendszer automatizmusai révén jelentős költségek megtakarítását ígéri. Ezek mindegyikét most nem elemezzük, de a licenceléssel kapcsolatos elképzeléseket vázoljuk – hogy aztán később elemezhessük őket:

• Egy VDI megoldásnál jelentősen eltérhet az összes felhasználó és a rendszert egy adott pillanatban ténylegesen használók száma. Ha – tegyük fel, 1000 PC-nk volt eredetileg, de csak 600 az egyidejű felhasználók száma – akkor szükséges desktopok száma is csak 600, tehát mintegy 40%-os megtakarítást érhetünk el.
• A fentiek alapján az Office szoftvereknél és minden produktivitási megoldásnál (BI eszközök) is hasonló költségcsökkentés valósítható meg.
• Mivel a szerver CAL-okat a virtuális gépek számához igazítjuk, ezért a Windows, Exchange, Sharepoint stb. CAL-ok számában is a fentiekhez hasonló megtakarítás érhető el. 
• Alkalmazásvirtualizációval tovább lehet finomítani a megcélzott felhasználók körét, még tovább csökkentve a szükséges licenceket.

Nem Microsoft szoftverek vonatkozásában nem tudok nyilatkozni, de az állíthatom, a Microsoft egészen másképp kezeli a VDI architektúrát és az abban futó szoftverek licenceit.

A VDI licencelés alapjai
Ahhoz, hogy a VDI környezet licencelését megértsük négy fontos fontos szabályt kell ismernünk: a licence modelleket, a nagyvállalati desktop operációs rendszer licence természetét, a multiplexelés kizárását, és az eszközhöz rendelés szabályát. Vegyük ezeket sorra:

A Microsoft a vállalati szoftvertermékeinek használati jogát a negyedévente frissített “Product Use Rights” dokumentumban írja le (Letölthető magyar nyelven is, a cikk a 2009 januári kiadásból idéz majd több alkalommal). A dokumentum eleje taglalja, hogy összesen kilenc licence modellt alkalmaz a cég, és minden egyes terméknél meghatározott, hogy mely modell alapján licencelődik. A VDI szempontjából a két fontos modell az “Asztali alkalmazások készülékenkénti licence” és az “Asztali operációs rendszerek – példányonkénti, készülékenkénti licenc” modell. Előbbi kategóriába tartozik az a Office termékcsalád valamennyi asztali komponense (Office Standard, Professional, Visio stb.), míg az utóbbiba a nagyvállalati desktop operációs rendszer – a Windows Vista Business (a frissítési garancia keretében pedig a Windows Vista Enterprise). Itt jegyezzük meg, hogy a nagyvállalati licencek mindegyike tartalmazza a korábbi verziók használatának jogát, tehát a cikkben példaként említett szoftverek korábbi verziói is használhatók, illetve azokra éppolyan szabályok érvényesek, mint az aktuálisakra.

Az “Asztali operációs rendszerek – példányonkénti, készülékenkénti licenc” modell általános leírása a PUR 6. oldalán található. Különösen az alábbi szabályok érdekesek (kiemelés tőlem):

“Licencet kell beszereznie minden olyan készülékhez amelyen, illetve amelyről eléri és használja a szoftvert (helyileg vagy távolról). A készülékre csak egy szoftverpéldányt telepíthet. Ezt a példányt a gazdagép operációs rendszerén, illetve egy virtuális (vagy egyéb módon emulált) hardverrendszeren telepítheti. Mennyiségi licencelés esetén az asztali operációs rendszer licence „frissítési licenc”. Frissítési licenceket kizárólag olyan készülékekhez szerezhet be, amelyekhez már rendelkezik „jogosító operációs rendszer” licenccel.” (Microsoft PUR, 6. oldal)

Az első kiemelt fél mondat azt jelenti, hogy Windows licenccel kell rendelkeznünk még a távoli eszközökön (értsd: vékonyklienseken) is, ha arról az eszközről Windows desktop operációs rendszert szeretnénk elérni. Vékonykliensre persze nem telepítünk Windows, de a licencet hozzá kell rendelni. Ez komoly beruházást igényel, és a VDI projektek szinte soha nem tartalmazzák. A második kiemelés még ennél is fontosabb. A frissítési licence azt jelenti, hogy a licencelt készüléken egy alap-rendszerrel, a PUR megfogalmazása szerint egy “jogosító operációs rendszerrel” kell rendelkeznünk. A hétköznapi életben ez többnyire egy OEM, jóval ritkábban egy dobozos Windows. VDI megoldásnál a készülék, amire az asztali operációs rendszert telepítjük, egy virtuális gép. Virtuális géphez OEM Windowst nem lehet vásárolni,  Az “ötletelés” során előkerül, hogy akkor rendeljünk 80 OEM licencet a szerverhez, amely a desktop operációs rendszereket futtatja majd – és máris lesz “jogosító operációs rendszerünk”. Azon túl, hogy mókás dolog XP vagy Vista OEM matricákkal teleragasztgatni a szervereket, ez a “megoldás” szintén nem működik. Az OEM szoftver ugyanis abban (is) különbözik a nagyvállalati verzióktól, hogy a hardverhez rendelést a OEM gyártó végzi el még vásárlás előtt, s azt vásárlás után sem lehet megváltoztatni. Az OEM hardver és OEM szoftver összenőtt dolgok. Első közelítésben úgy tűnik tehát, hogy marad a dobozos Windows. Az viszont – szemben az OEM-mel – jóval drágább, a 80 matrica helyett pedig 80 (vagy 100, 500, 5000!) doboz kezelhetetlen is.

A másik számunkra fontos modell az “Asztali alkalmazások, készülékenkénti licence“. Általános feltételei a PUR 5. oldalán láthatók. Különösen ez a mondat fontos:

“Licencet kell beszereznie minden olyan készülékhez amelyen, illetve amelyről eléri és használja a szoftvert (helyileg vagy távolról, hálózaton keresztül). A szoftver tetszőleges számú példányát és bármelyik korábbi verzióját telepítheti olyan készülékre, illetve hálózati készülékre, amely támogatja a szoftver használatát.” (Microsoft PUR 2009. január, 5 oldal)

Vagyis, akárcsak a desktop operciós rendszereknél, az office alkalmazásoknál is a végső berendezéshez kell a licencet rendelni, nem pedig a virtuális géphez – függetlenül attól, hogy arra a készülékre telepítettük-e a szoftvert, vagy éppen csak használjuk róla. Szó sincs egyidejűségről, a licencet akkor is meg kell venni és a “készüléken kell tartani” ha az a készüléket ideiglenesen senki sem használja. Ráadásul a kitétel érvényes az alkalmazás-virtualizációs technológiával csomagolt szoftverekre is, hiszen azoknak csak a disztribúciója nem pedig a használata tér el a hagyományosan telepített szoftverekétől.

Végezetül nézzük a multiplexálás szabályát (kiemelés tőlem):

“Olyan hálózati architektúrákat telepíthet, amelyek hardvereinek vagy szoftvereinek használatával csökkenthető azon készülékek vagy felhasználók száma, akik közvetlenül elérik a kiszolgálón futó szoftvert. Ezeket multiplexelő vagy halmozó megoldásoknak nevezik. Ezek a rendszerek azonban nem csökkentik a kiszolgálószoftver eléréséhez vagy használatához szükséges CAL licencek számát. CAL licencet kell beszereznie minden olyan készülékhez vagy felhasználóhoz, amely a multiplexelő vagy halmozó rendszer szoftvereinek vagy hardvereinek felhasználói felületéhez csatlakozik.

6. ábra

Multiplexelés: A felhasználók és a készülékek közvetett módon érhetik el a Windows vagy az SQL kiszolgálószoftvert az alábbi ábrán bemutatottak szerint. A kiszolgálószoftver közvetett módon történő elérése esetén is szükség van a CAL licenc beszerzésére.” (Microsoft PUR, 2009 január, 8. oldal)

Ha a fenti ábrán a halmozó rendszer helyébe egy Terminal Servert, vagy egy Hypervisor gazdagépet képzelünk, máris látható, hogy a CAL-ok megtakarítása ötlet sem működik. Azok ugyanúgy a végső készülékhez kell hozzárendelni, mint az Office vagy Windows esetén.

A fenti szabályokat összegezve tehát:

1. A nagyvállalati licencek közül sem az operációs rendszer, sem a Office és egyéb asztali alkalmazások, sem pedig a CAL-ok nem takaríthatók meg a VDI infrastruktúra kialakításakor.
2. Speciális licenc-konstrukció nélkül a VDI infrastruktúrban működi virtuális gépeken nem használhatók a nagyvállalati konstrukcióban vásárolt operációs rendszerek, azokhoz dobozos Windows licencet kellene vásárolni.

A Vista Enterprise Centralized Desktop licenc
Mindebből úgy tűnhet, hogy a Microsoftnak nincs VDI szituációra kialakított licencelési megoldása. Pedig már több mint két éve van. A konstrukció neve “Vista Enterprise Centralized Desktop” (VECD) – ahol az első két szó a nagyvállalati deskop operációs rendszer neve, a második két szó pedig a VDI infrastruktúrára való utalás. Nézzük, hogyan működik a VECD szabályrendszer.

A Microsoft kétféle VECD konstrukciója aszerint választható, hogy valaki rendelkezik-e élő nagyvállalati szerződéssel és ahhoz kapcsolódó frissítésvédelemmel (Software Assurance – SA), vagy sem. Ebben van ráció: vannak, akik már rendelkeznek Windows desktoppal és most tulajdonképpen ugyanazt használják, csak másképp. Mások viszont nem rendelkeznek Windows desktoppal (értsd: vékonykliens vagy nem MS desktopot használnak) – és mégis futtatni szeretnének egy Windows Vistát vagy Windows XP-t. Az első felhasználói kör szánára a “VECD for SA” a megoldás, míg a második kör a “Windows VECD” licencet veheti igénybe.

Mit az a VECD licenc:

• Legfeljebb 4, virtuális környezetben futó desktop operációs rendszerhez való hozzáférési és használati jog.
• Mindig az aktuális operációs rendszerre vonatkozik, tehát ha év közben pl. új desktop jelenik meg (jó ez nem gyakori, de idén épp itt jön a Windows 7) akkor automatikusan érvényes a jog az új verzióra
• Megengedett a korábbi verziók használata (Windows XP, Windows 2000 stb.)
• A licencelt készülék elsődleges használója otthonról, egy másik eszközről szintén elérheti a virtuális desktopokat (Home Use Right)
• A virtuális gépek nem hardverhez kötöttek. mozgatásuk a kiszolgálók között megengedett
• Windows Vista Enterprise változatának használati joga (Ezt a Windows verziót csak érvényes frissítésvédelemmel rendelkező felhasználók telepíthetik, és a Vista Businesshez képest számos szolgáltatással bővített. A Windows 7 esetében szinten lesz ilyen verzió)
• Többnyelvű felület (Multi Language Interface Pack)

Ezen felül a VECD tartalmaz minden olyan szolgáltatást, amelyet a Microsoft a frissítésvédelem körében nyújt, többek között a meghosszabbított hotfix támogatás, tréning voucher vagy éppen a TechNet előfizetés. Ezen kívül a VECD jogosít olyan termékek megvásárlására, amelyek érvényes SA meglétéhez kötöttek, mint a Microsoft Desktop Optimization Pack (MDOP), amely alkalmazás-virtualizációs és desktop virtualizációs szoftvert is magában foglal.

A VECD licencek havi előfizetés jellegű konstruktciók és azokra a készülékekre kell megvásárolni, amelyek mögött a végfelhasználók ülnek. A “VECD for SA” más áron kapható, mint a “Windows VECD”: az előbbi 1,3-2 Euro, míg az utóbbi 8-9 euro havonta.

Mi az, amit nem tartalmaz a VECD?

• Nem tartalmazza az Office alkalmazásokat
• Nem tartalmazza a szerver szoftverek CAL-okat (Windows CAL, Exchange CAL stb.) Ha szükség van szerver-hozzáférés licencekre, akkor célszerű azt nagyvállalati szerződés keretén belül megvásárolni.
• Nem tartalmazza az MDOP szoftvereket – ezeket külön előfizetés keretében árulja a Microsoft

Összegzés

Amikor ügyfelekkel, partnerekkel  virtualizációról beszélgetek, mindig megemlítem, hogy a virtualizáció sokkal több, mint csupán technológia. Jelent az rendszerfelügyeletet, együttműködést, kompatibilitást, támogathatóságot, és – nem utolsó sorban – változást a licencelésben. A virtuális desktopok licencelése más, mint a hagyományosoké, az erdeti licencek pedig nem használhatók. A virtualizáció sokféle előnyt hordoz magában, a desktop oldalon viszont egészen bizonyosan nem jelent licenc-megtakarítást a korábbi nagyvállalati konstrukciókhoz képest. Ha valaki mást állít, akkor kételkedjünk.

Bevallom nem szeretem a blogot hivatkozásjegyzékként használni, de most találtam két olyan fontos anyagot, amelyeket érdemes ajánlani bárkinek, aki desktop virtualizációval foglalkozik.

Brian Madden nevével még akkor ismerkedtem meg, amikor a MAL-ban rátaláltam a flexprofile nevű kis eszközre. Brian eredetileg Citrix és terminal szerver szakértő, és persze ahogy változik a technológia újabb és újabb területekre fokuszál és osztja meg az igencsak megszívlelendő gondolatait.

A múlt héten még a VMware VMWorld Europe 2009 konferenciáján jár, onnan készítette a Brian Madden TV aktuális adását. Azt hiszem, hogy aki rövid áttekintést szeretne arról, hol áll ma a VDI technológia, az nem fog unatkozni, ha megnézi ezt a 25 percet. Ha pedig valaki szeretné megnézni azt, hogy milyen előadást tartott Brian a konferencián, annak javaslom ezt az oldalt. Igaz, hogy a felvétel hét youtube részletből áll, amatőr kamerával készült és sokszor remeg, mégis megéri a 70-75 percet végigülni, mert végre valaki a VDI feltalálójának rendezvényén elmondta mit is ér jelenleg ez a technológia.

Néhány apró megjegyzést leszámítva teljes egészében egyetértek Briannel – és ezt később majd részletesen is kifejtem ez a kis fórumon. Addig jó tévézést. :-)