VDI (Virtual Desktop Infrastructure) wordt door velen beschouwd als het antwoord op een stokoud probleem: hoe een goedlopende desktop te bieden zonder dat deze het beheer en kosten van een fysieke machine met zich meebrengt. VDI biedt gebruikers een manier om in te loggen op een server waar een Windows-sessie voor ze draait, via browser of een Javaclient op een thin (of fat) client.

Recent heb ik de VDI-software van VMware onder de ogen gekregen. Ik testte VMware View 3 in zowel een afgesloten testruimte als in een productie-omgeving met echte gebruikers. Van VMware View kan alvast gezegd worden dat het werkt, maar dat het beheer flink te wensen overlaat en de gebruiker zo af en toe in de kou wordt gelaten.

Uitrollen

Het aanmaken van een VMware View-omgeving is relatief eenvoudig, aangenomen dat je al iets van VMware in je infrastructuur hebt zitten. Is je serveromgeving al gevirtualiseerd, dan heb je een uurtje werk aan het uitrollen van VMware View. Zo nee, dan zal je dat eerst moeten doen voordat je View kunt gaan inzetten. Er wordt vanuit gegaan dat VDI een aanvulling is voor een gevirtualiseerde omgeving, en dat het niet een op zichzelf staande oplossing is. Nu is servervirtualisatie erg populair en dus is deze aanname redelijk logisch. Bovendien valt het ook echt aan te bevelen.

De installatie van View geschiedt op een bestaande vCenter server via VMware Composer. Daarbij maak je een gevirtualiseerde Windowsserver aan die de View services draait. Dit is de broker, die de gebruikers in moet laten loggen en ze moet doorverwijzen naar hun eigen View desktop. Deze server hoeft trouwens niet per sé gevirtualiseerd te zijn, maar het leek me wel het meest voor de hand liggen.

Het beheer van VMware View wordt niet uitgevoerd via de Infrastructure Client, maar met een webinterface die op de View-server zelf wordt gehost. Dit wijkt flink af van de andere VMware-producten, die weliswaar optioneel een webinterface bieden, maar eigenlijk altijd via de centrale client gaan. De vCenter Server ondersteunt gewoon plugins, dus het is eigenaardig dat zo'n belangrijk stuk infrastructuur geen deel uitmaakt van het centrale beheer.

De webinterface functioneert, maar hij is wel erg kieskeurig over welke browser je gebruikt. Ja, hij is te laden in Firefox, maar de layout is dan wel helemaal naar zijn grootje en alleen daarom al is het niet aan te bevelen voor dagelijks gebruik. Safari werkte, tot mijn verrassing, al een stuk beter, en geheel niet tot mijn verrassing was Internet Explorer ook een verbetering.

Helaas zijn sommige functies domweg slordig uitgewerkt. Als je na het invoeren van commando's in een JavaScript configvenster bijvoorbeeld een enter geeft in plaats van dat je op 'OK' klikt, dan loop je het risico teruggestuurd te worden naar het hoofdmenu zonder dat je instellingen worden bewaard. Dat is niet bepaald geruststellend als je verantwoordelijk bent voor de desktops van een paar honderd gebruikers.

Pooltjes

Als je eenmaal de basiscomponenten van View hebt geïnstalleerd, dan moet je tenminste één pool van desktops aanmaken voor je gebruikers. Daarbij gaat het in eerste instantie uit van een VM die is opgebouwd als elk ander Windows-VM. Het besturingssysteem wordt eerst geïnstalleerd, gevolgd door de patches en updates en de applicaties. De bron-VM wordt aan het domein toegevoegd, en als laatste wordt de VMware Agent geïnstalleerd. De Agent is een klein stukje software dat de desktop draait en de verbinding met de server onderhoudt.

Daarna moet alle Microsoft Sysprep-code geïnstalleerd worden op vCenter Server om het automatisch aanmaken van nieuwe desktops te automatiseren. Zo kunnen Windowsmachines gekloond worden en als afzonderlijke sessies draaien op hetzelfde netwerk, met eigen unieke eigenschappen (zoals de SID). Om het proces af te ronden wordt de oorspronkelijke VM uitgeschakeld en neemt de software er een snapshot. Die vormt de basis voor alle View virtuele desktops.

Met de webinterface creëer je de pools waarin de desktops draaien. Dat kan op verschillende manieren. Waarschijnlijk zul je het vaakst grijpen naar de Linked Clones-functie. Deze methode wordt door View gebruikt om in een keer een groot aantal desktops aan te maken die niet elk een aparte basisimage nodig hebben. Normaalgesproken heeft zelfs een kleine desktopimage al snel zo'n 10 GB nodig, en met honderd werkplekken zit je dan al aan de terabyte. Met Linked Clones wordt geen aparte image aangemaakt van de basisimage, maar worden de desktopsessies verwezen naar een en dezelfde image. Elke gebruiker kan wel gewoon een eigen stukje schijf krijgen voor zijn eigen gegevens.

Wel wil je in een productieomgeving je gebruikers ervan weerhouden om aan de basisimage zelf te sleutelen, en dat kan met Active Directory Group Policy. Daarmee moet je gewoon de folder 'Mijn Documenten' doorverwijzen naar een plek waar de gebruikersgegevens wel welkom zijn.

Je kunt ook pools aanmaken voor algemene of gebruikersgebonden desktops. In een callcenter kun je bijvoorbeeld het beste een algemene (non-persistent) desktopomgeving gebruiken, omdat gebruikers niet meer dan een of twee applicaties nodig hebben en omdat ze geen aparte plek nodig hebben voor hun eigen bestanden. In andere gevallen kun je beter voor de persoonlijke (persistent) desktops gaan.

Hoe dan ook, het aanmaken van een pool gebeurt op ongeveer dezelfde manier, met een JavaScript wizard in de webinterface. Het ziet er niet uit, maar je krijgt het ermee gedaan. Wel zijn er een paar valkuilen, het is bijvoorbeeld niet mogelijk om een werkbare pool aan te maken als de bron-VM voortkomt van een floppy of cd-rom iso-image. Sterker, het gaat mis met de nergens op slaande melding dat het bestand niet kan worden gevonden. Alleen als de mappings wordt omgezet naar Client Device gaat het goed. Dit is absoluut niet duidelijk, en het was een flinke frustratie tijdens mijn uitrol. Afgaande op het aantal vragen op de VMware-fora is dit een niet vaak voorkomend probleem die eenvoudig op te lossen is, maar het is niet erg bekend en slecht gedocumenteerd. Net als bij ESX en vCenter het geval is, moet VMware ook hier nog duidelijk werken aan zijn foutmeldingen.

Snapshot

View maakt dus gebruik van de snapshot om een basissessie aan te maken, en de rest van de desktops wordt daar weer aan opgehangen. Elke desktop krijgt een naam die is opgebouwd uit de naam van de basisimage gevolgd door een nummer. Elke desktop is door sysprep heen gehaald en klaar voor gebruik. Hoe lang dit duurt hangt sterk af van heel veel factoren, waaronder de snelheid van de ESX-host, de snelheid van de opslag en het aantal aangemaakte desktops. De pool is vervolgens zichtbaar in ViewAdministrator, en dan kan je de beveiliging gaan instellen.

Het aantal aan te maken pools is oneindig, en ze zijn toe te voegen aan de verschillende gedefinieerde Active Directory-groepen. Je kunt bijvoorbeeld een pool bouwen voor de financiele afdeling, voor de technische afdeling en voor het management. Elke pool kan zijn opgebouwd uit een andere bron-VM met andere applicaties, RAM-toewijzingen en maximaal te gebruiken processorkracht. Eindgebruikers krijgen deze pools bij het inloggen te zien als client-opties.

Een van de grote voordelen van VDI is dat het snel en eenvoudig wordt om applicaties, patches en service pakcs toe te passen en te verwijderen. View doet dat door de pool te herbouwen van een nieuwe bron-VM, waarbij de oorspronkelijke VM wordt geboot, de veranderingen worden doorgevoerd en als nieuwe bron-VM wordt neergezet. De pool wordt met de beheertool aangepast en opnieuw opgestart. Dat kan onmiddellijk, maar dan moeten de gebruikers wel uitloggen, of niet.

Het updaten van de pool is op zich al een langzame aangelegenheid, en het is flink afhankelijk van de gebruikte storage. Bedenk dat ook kleine aanpassingen, zoals het virtueel bijprikken van RAM, een volledig nieuwe herbouw nodig heeft. Het blijft nog altijd minder werk dan bij een fysieke pc.

Eindgebruiker

Er zijn verschillende manieren om te verbinden met de View desktop-VM. Linux-, Mac OS X- en Windowsclients kunnen allemaal verbinding maken met de webinterface en de Javaclient, terwijl Windows ook de dedicated View-client kan gebruiken. Linuxsystemen hebben nog de View Open Client tot hun beschikking, een open source-variant van VMware zodat deze ook voor andere platformen beschikbaar komt.

Maar elke van de mogelijkheden heeft zijn mits en maren. De View Client voor Windows lijkt nog de beste, maar die is al raar omdat je al Windows op je pc moet hebben draaien; waar is de VDI dan nog voor? De Javaclient is erg functioneel en draait goed op ieder getest platform, al moet je geen video willen streamen. Aan Youtube moet je met deze client niet eens beginnen.

De Open Client is de snelste van de groep, maar hij ondersteunt geen audio en USB, waardoor hij voor de meesten onbruikbaar is. Jammer, omdat juist deze voor beheerders als brug kan dienen om over te gaan op VDI, zonder dat je meer (al dan niet tijdelijke) licenties moet kopen. Ik heb begrepen dat deze gebreken meer komen door politieke en juridische beleidskeuzes, en niet technisch van aard zijn. Hopelijk worden deze kunstmatige hordes snel genomen, en kunnen we verder. De Open Client moet gewoon geheel functioneel zijn, anders is het geen optie.

Naast de softwareclients zijn er ook thin cliëntsystemen van verschillende leveranciers die View ingebakken hebben. De verbinden zich met de View server en bieden alle mogelijkheden vie VMware biedt.

Hoe de verbinding ook tot stand komt, gebruikers krijgen een virtuele Windows-desktop voorgeschoteld die precies hetzelfde doet als de fysieke desktop die ze gewend zijn. Een verschil: de extra 'disconnect'-functie. Daarmee kunnen ze hun huidige sessie opslaan, van machine wisselen, en precies daar waar ze waren verder werken.

Op een verbinding van 100 Mbps is de ervaring ongeveer hetzelfde als op een lokale desktop. Uiteraard hangt veel af van de specs van de VM, zoals RAM en processorkracht, maar gebruikers voelen er niets van als de VM's goed zijn ingesteld.

Gebruikers die via internet inloggen krijgen last van de traagheid die inherent is aan RDP. Net als met Citrix en Terminal Services is het dus zaak om te weten wat je gebruikers nodig hebben voordat je ook maar denkt aan een virtuele desktop. Wie Photoshop moet draaien kan maar beter wegblijven bij VDI, net als dat ze ieder andere remote desktop dienen te ontwijken.

Over gebruikers gesproken, het is met VMware View mogelijk om ze toegang te verlenen van waar dan ook via de browser. Dit gaat via een aparte View Server die is opgebouwd als beveiligingsserver. Dat is dus eigenlijke een Windowsserver die op de DMZ zit en als proxy dient voor de interne View server. Zo hoeft de View server zelf geen verbinding met internet te onderhouden, en dat zorgt voor de nodige veiligheid tegen externe dreigingen. Het configureren van deze beveiligingsserver is extreem eenvoudig, en vereist alleen een open poort naar de beide hoofdserver en de beveiligingsserver naar het internet.

Conclusie

VMware View is een functionele VDI-implementatie met veel afwijkingen en probleempjes. Als je het zorgvuldig beheert, dan is het geschikt voor VDI. Maar een paar verbeteringen zijn op hun plaats, vooral het beheer van de desktop-pools en de webgebaseerde gebruiksinterface.

XenDesktop van Citrix is de belangrijkste concurrent , en die is een stuk geavanceerder op het gebied van beheer. Hij mist wel de VI3 backend van VMware. Het mag geen verrassing zijn dat Citrix beter desktopbeheer en VMware betere kernvirtualisatie biedt. Hoe je het ook ziet, uiteindelijk is de keus voor VDI meer een politieke dan een technische keuze. Gebruikers zullen snel iets vinden wat ze niet zint, ook al is de klacht fictief. Je wilt hoe dan ook dat de VDI direct zo robuust mogelijk is opgebouwd, nog voor je met een pilot begint.

Ook een probleem zijn de desktopmogelijkheden die VDI biedt. Windows XP is de meeste logische kandidaat, maar die is al acht jaar oud. Vista is een dood paard, en Windows 7 zit nog maar in de bèta, dus dat probleem zien we voorlopig niet opgelost.

Bron: Infoworld.com Bron: Techworld