Beslutningspunkt: VDI og terminalservices

To grundlæggende koncepter konkurrerer om fremtrædende plads – hvis teknologier overhovedet bekymrer sig om det – når det gælder fjernbaserede grafiske skrivebordsgrænseflader: VDI (virtual desktop infrastructure) og terminalservices. Ideen bag begge er enkel: placér ressourcer og behandling på en server, og lad slutbrugere tilgå den grafiske grænseflade fjernbaseret via et netværk. Det, der grundlæggende adskiller VDI og TS, er forskellen mellem at den fjernbaserede server leverer en one-to-many-oplevelse, hvor mange brugere får deres skriveborde fra ét enkelt operativsystemimage (TS), og at hver bruger får sin egen dedikerede server (formodet virtualiseret og kaldet VDI), hvor der ikke er nogen deling af individuelle operativsystemressourcer.

Der er en vis antagelse, delvis ud fra navnekonventionerne, om at VDI indebærer et desktop-operativsystem frem for et serveroperativsystem – men dette bør ikke ses som en implikation. Faktisk er der uden for Windows-verdenen ingen reel adskillelse mellem desktop- og serveroperativsystemer, så det ville ikke give mening at have en sådan skelnen på teknologiniveau. Det er dog vigtigt at huske, at Microsoft definerer VDI-licensering ud fra brugen af forskellige OS-licensmuligheder, og at de fleste VDI-installationer er til Windows-operativsystemer. Selvom VDI ikke indebærer dette, er det i praksis generelt vigtigt at holde for øje, at der på tekniksiden ikke er nogen skelnen, mens der på Microsoft-licensieringssiden er stor forskel.

Af de to er VDI det nyere koncept. Terminalservices har eksisteret i årtier og er velkendte – de er alt andet end spændende eller flotte i dag. Terminalservices forudsætter Windows og er fælles for næsten alle operativsystemfamilier og er så udbredte i UNIX-verdenen, at de ofte bruges uden nærmere omtale. Terminalservices er den grafiske fortsættelse af de gamle “grønne skærm”-terminaler, der har været brugt siden computerens “gamle dage”. I gamle dage var terminalerne ofte serielt forbundne VT100-terminaler, og i dag bruger vi TCP/IP-netværk og protokoller til at overføre grafik, men konceptet er det samme: mange brugere på én server.

Med VDI opnår vi de samme mål, men giver hver bruger alle deres egne ressourcer. Deres operativsystem er fuldt ud deres eget og deles ikke med nogen. Det betyder, at der er al den overhead, der følger med hukommelsesstyring, CPU-styring, procestabeller, kopier af biblioteker og lignende for hver enkelt bruger – en betragtelig overhead. Tænk på alle de ressourcer, et inaktivt grafisk skrivebord kræver blot for at starte op og vente på brugeren – det kan være ganske meget. Nyere Windows-operativsystemer er blevet leaner og mere effektive, sandsynligvis for at gøre dem mere egnede til VDI-infrastrukturer, men overhead'en forbliver en væsentlig faktor. VDI var reelt ikke muligt, før virtualisering gjorde det til en realitet, så i praktisk forstand er det en ny anvendelse af teknologi og bliver ofte misforstået.

Det vi nu står over for er, når vi skal beslutte os for en fjernbaseret beregningsinfrastruktur, at vælge mellem disse to arkitekturideer. Det skal selvfølgelig bemærkes, at disse to meget let kan sameksistere, og det vil ofte være hensigtsmæssigt at gøre dette. I mindre virksomheder ville det faktisk være meget nemt for de to at sameksistere på den samme fysiske platform. Der er mange faktorer at overveje her, og denne beslutningsproces kan faktisk være ret kompliceret.

En af de vigtigste faktorer, vi skal overveje, er softwarekompatibilitet. Dette er den største drivkraft bag skiftet til VDI frem for terminalservices. I Windows-verdenen er det ikke ualmindeligt, at applikationer kræver ting som et desktop-operativsystemsignatur (vægrer sig ved at køre på server-OS-varianter), enkeltbrugermiljøer, at brugere har administratorniveau-rettigheder, at brugere kører med specifikke konti, eller bibliotekskrav, der ofte konflikter med andre pakker. På grund af disse problemer ser mange virksomheder til VDI for at efterligne den måde, individuelle desktops fungerer på, hvor disse problemer let blev ignoreret, fordi hver bruger kørte i et diskret miljø. VDI bringer denne samme funktionalitet til fjernaktiveringsverdenen og giver problemfyldte applikationer de nødvendige forhold. Isolation af OS tilføjer et lag af beskyttelse.

Denne drivende faktor eksisterer reelt ikke uden for Windows-verdenen og er primært årsagen til, at VDI aldrig har fundet fodfæste i andre miljøer. Selv om det er nemt at opnå med Linux eller FreeBSD har VDI ringe formål eller værdi i sådanne tilfælde.

En væsentlig bekymring med VDI er den ekstreme overhead, der er nødvendig for at administrere mange redundante operativsystemer, som hver har sine egne duplikerede processer, lager og hukommelse. I de tidlige dage gjorde dette VDI utrolig ineffektivt. Mere for nylig har avancerede VDI-systemer – primært centreret omkring virtualiseringsplatforme og lager – imidlertid adresseret mange af disse problemer ved at deduplikere hukommelse og lager, bruge fælles master-bootfiler og andre teknikker. Faktisk kan det i modsætning til de fleste antagelser endog være tilfældet, at VDI måske yder bedre end traditionelle terminalservices for Windows, fordi hypervisorplatformen kan håndtere hukommelsesstyring og opgaveskift endnu mere effektivt end Windows selv (et fænomen der første gang blev observeret i begyndelsen af 2000'erne, da Windows i visse tilfælde kørte hurtigere, når det var virtualiseret oven på Linux, så hukommelsesstyring delvist kunne uddelegeres til det underliggende Linux-system, der var mere effektivt). Dette er bestemt ikke altid tilfældet, men forbedringerne i VDI-håndtering er kommet så langt, at de to ofte er temmelig tæt på hinanden. Igen er dette dog en faktor, der gør VDI mere attraktiv i Windows-verdenen, men ikke nær så dramatisk i ikke-Windows-verdenen, hvor native OS-opgavestyring typisk er mere effektiv, og VDI ville forblive unødvendig overhead.

Et andet område, hvor VDI konsekvent har vist sig mere kapabelt end terminalservices, er inden for grafikintensive renderede miljøer som CAD og videoredigering. De samme områder, der stadig hælder kraftigt mod dedikeret hardware, tenderer mod at flytte til VDI frem for terminalservices på grund af en stærk investering i GPU-kapaciteter inden for VDI-løsningerne. Dette er ikke et universelt scenarie, men i situationer, hvor tung grafisk rendering skal finde sted, er det værd at undersøge muligheden for, at VDI vil yde væsentligt bedre.

På grund af måden VDI administreres på er det ofte forbeholdt meget store installationer, hvor skalaen – i antal slutbrugere inkluderet i løsningen – kan bruges til at opveje noget af implementeringsomkostningen. Terminalservices kan derimod, på grund af dens mere skalerbare pris, ofte implementeres til mindre miljøer eller delmængder af brugere mere omkostningseffektivt. Ingen af dem er almindelige i et meget lille miljø med kun få brugere, selv om et mærkeligt fænomen med manuelt administreret VDI ville gøre VDI sandsynligvis mere effektivt end terminalservices for et exceptionelt lille antal brugere – måske under ti – hvor VDI behandles mere som individuelle servere frem for som et samlet VDI-miljø.

Med kun de sjældneste undtagelser – primært på grund af licensoverhead skabt af Windows desktop-økosystemet i et virtualiseret miljø – er det en de facto startposition for fjernaktiveringens slutbrugersystemer at antage et startpunkt med terminalserviceteknologier og kun ty til de mere komplicerede og dyrere VDI-løsninger, når terminalservices viser sig ude af stand til at opfylde de tekniske krav til scenariet. Reelt er VDI en reservemetode – en brute force-tilgang til at få slutbrugervirtualisering til at fungere, der hvor de foretrukne metoder er kommet til kort.