Virtual Desktop Infrastructure in der Praxis

,

Erfahrungen mit einer VDI-Umgebung im Testbetrieb

Motivation und Ausgangssituation

Die Gelegenheit, ein Büro als Projekt „auf der grünen Wiese“ komplett neu mit Arbeitsplätzen auszustatten, ergibt sich nicht mehr allzu häufig. Finden wir sonst in der Regel gewachsene Strukturen vor, lässt für ein solches Projekt die Frage stellen, welche Arbeitsmittel denn genutzt werden sollen.

  • „Traditionelle“ PCs (Windows), Workstations (Linux) oder Apple Macintosh Computer in Form von „Blechkisten unter dem Schreibtisch“. Diese Geräte sind sperrig, aber bieten hohe Performance am Arbeitsplatz. Soll auch remote oder im Home Office gearbeitet werden, muss ein zusätzliches Notebook gestellt werden. Hier stellt sich als nächstes die Frage, wie gut die Synchronisation der Daten zwischen mehreren Geräten funktioniert. Selbst bei Verwendung von Active Directory-Profilen oder mobilen Homeverzeichnissen am MacOSX Server klappt es inder Praxis oft nicht, auf zwei verschiedenen Geräten gleichzeitig mit den gleichen Anwendungen auf den gleichen Daten arbeiten zu können. Und die Zahl der Menschen, die ausschließlich an ihrem Büro-Arbeitsplatz arbeiten, nimmt sicher stetig ab.
  • Notebooks mit Dockingstation, die angedockt als vollwertige Workstation funktionieren. Hier entfällt das Synchronisationsproblem, man arbeitet nur noch an einem Gerät. Probleme entstehen hier bei Anwendungen mit hohem Resourcenbedarf, die das Notebook überfordern, weil dieses zu langsam ist, nicht über genug Arbeitspeicher verfügt und -vor allem bei modernen Notebooks mit SSD- nicht genug Platz für das Arbeiten mit Sammlungen grosser Dateien hat. Ebenfalls problematisch ist, dass Unternehmensdaten auf mobilen Geräten gespeichert sind. Im Falle von Spionage oder dem Diebstahl des Notebooks besteht die Gefahr, dass wichtige Daten in die falschen Hände geraten. Notebooks sind außerdem über verschiedene Hardware-Schnittstellen wie USB und Firewire besonders effizient angreifbar. Im Zweifelsfall kann selbst eine Datenverschlüsselung (Full Disk Encryption) überwunden werden. Ausserdem müssen auch hier mobile Homeverzeichnisse, Profile oder automatische Datensicherungen mit entsprechendem Synchronisationsaufwand benutzt werden, um sicherzustellen, dass ein verlorengegangenes oder defektes Notebook schnell und ohne Datenverlust wieder hergestellt werden kann.
  • BYOD: Der Anwender bringt sein eigenes Notebook mit („Bring Your Own Device“). Hier stellen sich diverse Fragen nach Datensicherheit auf privaten Geräten, der Verstrickung von IT-Support in selbstgepflegte und nicht standartisierte Betriebssystem-Installationen und der Trennung von Firmen- und privaten Daten. In Deutschland sind gesetzliche Regelungen zu beachten, die das Verhältnis zwischen Arbeitnehmer und Unternehmen bezüglich des Datenschutzes regeln. Ein vielversprechender Ansatz ist, den Firmen-Desktop als virtuelles Image auf dem vom Benutzer verwalteten Gerät laufen zu lassen. So sind der Firmen-Arbeitsplatz und der private Desktop voneinander getrennt. Dieses Image muss aber auch synchronisiert werden. Die Alternative ist, überhaupt keine Daten auf dem Gerät mehr vorzuhalten, indem man einen Terminalserver oder Anwendungsvirtualisierung verwendet. Hier laufen alle Programme auf dem Server im Unternehmen, und der Client dient quasi nur noch als Display und Eingabegerät, auf dem sich keine Daten mehr befinden. Dieses Konzept funktioniert natürlich nur, so lange eine ausreichend performante Netzwerkanbindung besteht. Für das Arbeiten im Zug oder Flugzeug ist ein Terminalserver nicht geeignet.
  • Mobile Geräte. Werden ausschliesslich Web-Applikationen (oder gar native Apps für mobile Geräte) benutzt, lassen sich ganz neue Wege gehen. Hier muss nur noch ein absolut minimal installiertes Gerät bereitgestellt werden, das im Wesentlichen nur einen Web-Browser mitbringt. Es kann ein Tablet verwendet werden, oder ein Chromebook. Bis auf bestimmte Sicherheitseinstellung wie der VPN-Zugang muss nach dem Kauf des Gerätes fast nichts mehr angepasst werden. Aber die wenigsten Unternehmen werden in der Praxis auf Desktop-Computer und entsprechende native Anwendungen verzichten können.

Im vorliegenden Fall spielten Sicherheitsüberlegungen eine entscheidende Rolle. Unternehmensdaten sollten sich nicht auf Notebooks befinden, denn auch gute Festplattenverschlüsselung wie TrueCrypt oder FileVault wurde als nicht ausreichend sicher gegen physikalische Angriffe (das laufende Gerät wird im Hotelzimmer oder bei einer Zollkontrolle mit Malware infiziert bzw der Arbeitsspeicher durch physikalischen Zugriff ausgelesen) empfunden.

Aus diesem Grund wurde eine Evaluationsumgebung für eine Virtual Desktop Infrastruktur (VDI) aufgebaut.

Überblick der VDI-Charakteristiken

VDI wird von mehreren Herstellern (VMWare, Microsoft und Oracle) angeboten. Die Idee dahinter ist, Desktop-PC’s zu virtualisieren und auf einem entsprechenden Server laufen zu lassen. Das Display der Anwender wird nun nur noch als Anzeigegerät verwendet, das Betriebssystem und sämtliche Applikationen laufen auf dem Virtualisierungsserver, und sämtliche Daten und Speicherinhalte bleiben auf dem Storage-Server.

Hieraus ergeben sich eine Reihe von Vorteilen:

  • Die Clients bzw. Terminals, die die PCs und Workstations ersetzen, sind kostengünstig, energieeffizient und langlebig. Sie enthalten nur wenige und unkomplizierte Komponenten und keine beweglichen Teile.
  • Notebooks oder iPads als mobile Zugriffs-Clients müssen nur minimal konfiguriert werden (der VPN-Zugang muss eingerichtet und die Virtual-Desktop-Software installiert werden) und enthalten dann keine Unternehmensdaten, sondern dienen immer nor als Sichtgeräte. Auch bei Verlust und Diebstahl ist damit nicht viel anzufangen, sie sind einfach zu ersetzen (weil einfach neu zu installieren), und da sie keine Daten enthalten, können diese nicht nur nicht gestohlen, sondern deren Herausgabe auch nicht erpresst werden, indem etwa die Herausgabe eines Verschlüsselungspasswort abgepresst wird.
  • Durch eine Web-Schnittstelle (bei Oracle Global Desktop genannt) kann in der Regel auch ganz ohne eigenes Endgerät über einen Web-Browser auf den Unternehmens-Desktop zugrgriffen werden. Dieser läuft dann im Browser-Fenster wie ein Film ab.
  • Da die Desktops im Data Center laufen, laufen sie auf Server-Hardware, die Ausfälle durch Versagen billiger PC- oder Notebook-Komponenten lassen sich vermeiden. Redundant ausgelegt, kann eine hohe Zuverlässigkeit des Gesamtsystems erreicht werden.
  • Aus dem gleichen Grund kann eine systematische Datensicherung erfolgen, ohne das ein Notebook synchronisiert werden muss.
  • Desktops lassen sich versionieren und klonen. Eine Windows- oder Linux-Desktop-Installation inklusive der benötigten Applikation kann einmal als Master erstellt und dann in kurzer Zeit geklont und für die einzelnen Anwender bereitgestellt werden. So kann es einfacher sein, eine einheitliche Installationsbasis zu erreichen. Ebenso können Updates zentral und systematisch ausgerollt und Bedrohungen zentral erfasst werden, da sich alle Desktops für die IT-Administration immer im Zugriff befinden.
  • Der Desktop eines Anwenders kann nacheinander auf verschiedenen Geräten (Workstation/Terminal, Notebook, iPad, Web) verwendet werden, ohne das er neu gestartet werden muss. Eine Anwendung kann also weiterlaufen, während sie heute auf dem einen und morgen von unterwegs auf einem anderen Gerät verwendet wird. Ein Anwender kann also seinen tagsüber verwendeten Desktop mit allen Apps abends im Zug oder zu Hause weiterverwenden, und alle Apps sind sind währenddessen weitergelaufen, und ihre Netzwerk-Verbindungen blieben erhalten.
  • Ein Anwender kann auf einem Gerät mehrere Desktops unterschiedlicher Betriebssysteme oder Terminalserver gleichzeitig bzw. nacheinander nutzen.
  • Sicherheitsentscheidungen sind sofort umsetzbar: Ein gesperrter Account ist sofort nicht mehr benutzbar, und alle damit erreichbaren Daten sind sofort nicht mehr zu erreichen.
  • Ein kompromittierter, mit Malware oder Viren verseuchter oder einfach defekter Desktop kann vergleichsweise einfach und schnell neu bereitgestellt werden, indem ein neuer Klon des Master-desktop gezogen wird.

…und Nachteilen:

  • Das Setup der Server ist nicht zu unterschätzen: Virtualisierungs-, Storage und Management-Server müssen eingerichtet, überwacht und betrieben werden.
  • Ein entsprechendes Skillset der IT-Administration muss aufgebaut werden.
  • Ohne Netzwerkanbindung ist kein Arbeiten an den Desktops mehr möglich.
  • Die verwendete Server-Hardware ist durchgehend teuerer als billige Notebook- oder Workstation-Hardware. Da auch triviale Operationen wir beispielsweise das immer wieder ausgeführte Laden von Windows und Office für jeden Desktop auf dem Server abgearbeitet werden muss, relativiert sich die Kostenersparnis schnell.
  • Das zentrale System lässt sich zwar redundant auslegen und absichern, aber wenn es doch einmal ausfällt, kann kein Anwender mehr arbeiten.
  • Es kann schwierig sein, Anwendungen voneinander zu isolieren, und zu verhindern, dass eine CPU- und speicherhungrige Applikation die Ressourcen anderer Anwender „auffrisst“.
  • Die Güte der Grafik und das Antwortzeitverhalten eines optimal konfigurierten PC’s mit hochwertiger Grafik kann in der Regel nicht erreicht werden.
  • Auf Grund technischer und lizenzrechtlicher Einschränkungen lassen sich Macintosh-Desktop’s in keiner der VDI-Umgebungen virtualisiert einsetzen.

Nach einer grundsätzlichen Marktübersicht wurde entschieden, die Evaluationsumgebung als Proof-of-Concept mit der Sun / Oracle Lösung bereitzustellen.

Aufbau der Virtual Desktop Infrastruktur

Als Grundlage dienten zwei VDI-Server: Ein Server für das VDI-Management, der den VDI-Dienst selbst sowie die Software für das Mangement der SunRay-Clients (Sun Ray Server Software, SRSS) und den Secure Global Desktop (SGD, früher als Tarantella benannt) beherbergt. Als Datenbank für die Statusinformationen aller Komponenten sollte eine bereits vorhandene zentrale MySQL-Datenbank verwendet werden, dies gestaltete sich bei der Installation allerdings als so schwierig, dass schließlich eine separate MySQL-Instanz auf dem VDI-Management-Server erzeugt wurde – diese Möglichkeit sehen die Installationsskripte selbst vor. Dieser Server wurde mit Solaris 11 eingerichtet und direkt danach wurde Oracle VDI 3.5 installiert.

EIn weiterer Server wurde als Virtualisierungsserver konfiguriert. Hier wurde aus Kompatibilitätsgründen Solaris 10 verwendet, und danach im Wesentlichen VirtualBox installiert. VDI steuert Virtualbox über SSH-Kommandos und die Ausgabe über RDP, daher ist für das Management kein spezieller Adapter notwendig. Virtualbox muss in einer speziellen Version, die zu VDI kompatibel ist, und der Entwicklung von VirtualBox etwas hinterher hängt, verwendet werden.

Als Storage-Provider wurde ein ZFS-iSCSI-Filer verwendet. Da keine Sun Storage Appliance zur Verfügung stand, wurde ein weiterer Server mit Solaris 10 und ZFS eingerichtet. Leider ist Solaris 11 mit seinen vielen Verbesserungen im ZFS (zum Beispiel -endlich- Encryption) nicht als VDI Storage Provider verwendbar, da Oracle den iSCSI-Stack ausgetauscht hat. Hier kommt nun COMSTAR zum Einsatz, und Oracle VDI 3.5 ist leider nicht damit kompatibel. Ansonsten ist die Einrichtung des Storage Providers aber einfach, der iSCSI-Servide muss nur eingeschaltet werden, dann kommuniziert die VDI über SSH mit dem ZFS Server und richtet die ZFS-Filesysteme für die „Festplatten“ der Desktops und die ZFS-Snapshots der Desktop-Templates selbstständig ein. Die Datensicherung erfolgte über „zfs send“ bzw das Skript „zetaback“ auf einen zweiten ZFS-Server.

Der Zugriff auf die Desktops sollte mehrschichtig möglich sein:

  • Über Thin Clients. Hier wurden Sun Ray Clients angeschafft. Diese Terminals von Sun bzw. Oracle werden schon sehr lange in verschiedenen Versionen produziert. Allen gemeinsam ist, dass sie einen SmardCard-Reader zur Authentifikation besitzen. Die ersten Versionen (SunRay-1 und -2) waren kleine Desktop-Boxen mit VGA- und/oder DVI-Anschluss für externe Displays sowie USB für Tastaturen und Eingabegeräte. Spätere Versionen kamen mit FC-Netzwerkinterfaces für gesicherte Netzwerke (Baureihe -FS) und integriertem Display (Modell 270). Die Baureihe wird von Oracle weitergeführt und ist aktuell auch mit 21″-Displays erhältlich.
  • Über vorhandene Notebooks und MacBooks, auch mobil über das VPN. Hier wird die Oracle Virtual Desktop Client (OVDC) verwendet, die es für Windows. Linux und MacOSX gibt. Diese simuliert einen Sun Ray Client und unterstützt auch gängige USB-SmartCard-Reader, die dann wir ein Original-SunRay-SmardCard-Reader zur Anmeldung verwendet werden können.
  • Über iPad-Tablets. Für IOS gibt es im Apple App Store die Oracle OVDC App. Wird ein Cisco VPN verwendet, kann sich das iPad direkt im VPN anmelden und dann die OVDC App direkt verwendet werden. Ein SmardCard-Schnittstelle fehlt hier leider. Eine externe Bluetooth-Tastatur funktioniert, und die Maus wird per Touch simuliert.
  • Über das Web mittels SGD / Tarantella. Einzelne virtualisierte Anwendungen oder komplette Desktops können so über das Web erreicht werden. Auch hier fehlt natürlich die SmartCard-Unterstützung.

Die Authentifikation der Benutzer kann über Usernamen und zusätzlich über SmardCards erfolgen. Von Oracle gibt es ein Demo-Pack mit 100 SC-Cards, die in den SunRay Clients und in gängigen USB-Lesegeräten funktionieren. VDI kann so konfiguriert werden, dass eine SmardCard („Token“) mit einem Benutzer und einer Menge an vorgandenen Desktops assoziiert wird. Wird die Karte eingesteckt, ist der damit assiziierte Benutzer vorausgewählt, und Desktops, die an die Karte gebunden sind, können nur verwendet werden, wenn sie eingesteckt ist. Wird die Karte aus einer SunRay entfernt, und in eine andere gesteckt, erscheint der aktuell verwendete Desktop sofort am neuen Terminal. Es ist also möglich, seinen Desktop von einem Raum in den anderen „mitzunehmen“. Diese Möglichkeit macht das System im Gesundheitssektor interessant, wo es neben Regierungsbehörden in den USA relativ häufig verwendet wird, da es dem medizinischen Personal ermöglicht, von Zimmer zu Zimmer zu gehen und beispielweise Röntgenbilder überall zu zeigen – eine Möglichkeit, die aber mittlerweile auch mit Tablet’s besteht.

Wird die Smartcard als Zugriffsberechtigung eingesetzt, ergibt sich unmittelbar eine Two-Factor-Authentication für den Desktop-Zugriff. Für die Anmeldung ist neben einem Faktor, den nur der Benutzer kennt, also dem Passwort („something you know“) immer auch ein Gegenstand im Besitz des Anwenders („something you have“) erforderlich.

Für die passwort-basierte Authentifizierung wurde das Firmen-LDAP verwendet. Es ist in der VDI-Konfiguration direkt möglich, einen LDAP oder Active Directory Server einzubinden. Im vorliegenden Fall handelete es sich um einen Oracle Internet Directory Service.

Einrichtung der Desktops

Es wurden drei Desktop-Pools eingerichtet:

  • Linux Ubuntu LTS
  • Windows 7
  • Windows XP

Laut der Oracle Dokumentation müssen die Desktops mit der Virtualbox-Version, unter der sie nachher in der VDI betrieben werden sollen, installiert werden. Daher war es nötig, zur Installation VirtualBox direkt unter Solaris auf dem Virtualisierungs-Server zu starten und die Ausgabe über X11 zu leiten. Alternatv kann der VirtualBox Guest „headless“ betrieben und per RDP verwendet werden.

Die weitere Installation des Desktops erfolgt dann auf ein Disk Image, dass im Dateisysten des Virtual Box Servers liegt. Es kann dann das Installationsmedium als ISO-Image eingehängt und das Betriebssystem installiert werden. Bereits nach einer rudimentären, aber startfähigen Installation kann der Desktop als Template in VDI importiert werden. Dazu wird in VDI zunächst ein entsprechender Pool für diese Art von Desktops angelegt, und dann der Desktop importiert. Nun ist dessen Image bereits auf dem Storage-Server per iSCSI abgelegt, und das lokale Image aus der initialen Installation kann gelöscht werden.

In den Pool-Einstellungen werden die Ausführungsparameter, die zugeteilten Ressourcen (CPU, RAM) und die Art der Bereitstellung abgelegt. Grundsätzlich gibt es selbstständig und manuell klonende Pools. Bei automatisch bereitstellenden Pools (autocloning) wird ein Zielgröße angegeben, und das System sorgt dann dafür, das stets die entsprechende Anzahl von Desktops zur Verfügung steht. Jeder Desktop bleibt bestehen, bis er „wieder eingeschmolzen“ („recycle)“ wird. Je nach Konfiguration geschieht dies entweder nach Aufforderung, oder wenn der Desktop heruntergefahren, oder die Karte entfernt wird. In diesem Fall wird dem Anwender bei der nächsten Anmeldung ein frischer Desktop aus dem Pool zugeteilt, und der Pool im Hingerund mit einem neuen Desktop, der aus dem Template geklont wird, aufgefüllt.

Die Templates werden über Revisionen verwaltet. Bei Änderungen im Template wie der Installation von Updates oder neuer Software können diese zunächst getestet werden, ist alles zur Zufriedenheit, wird eine neue Version des Templates erzeugt und kann sofort oder zu einem bestimmten Zeitpunkt zur Erzeugung neuer Desktops als Grundlage verwendet werden. Dementsprechend kann auch auf jede alte Version des Templates zurück gewechselt werden. Dieses Szenario könnte zum Beispiel bei Malware-Attacken sehr nützlich sein – über Nacht können alle vorhandenen Desktops gelöscht und das Template korrigiert bzw auf einen Zeitpunkt vor dem Problem zurückgestellt werden.

Im Laufe der weiteren Installation sollten zunächst die VirtualBox-Guest-Additions installiert werden, damit Tastatur und Maus funktionieren und die Bildschirmauflösung korrekt angepasst wird. Nach der Installation der Software-Updates kann die Unternehmensanpassung vorgenommen werden, indem Authentifikation und Profileverwaltung sowie Sicherheitsrichtlinien eingestellt werden. In unserem Fall würde für Windows eine LDAP-Athentifikation am OID über die Open Source Software pGina eingerichtet. Für Linux wurde die Standard-LDAP-Konfiguration verwendet, die Home-Verzeichnisse wurden von einem NFS Server gemountet.

Erfahrungen aus dem Praxisbetrieb

Die Akzeptanz des Systems bei den Test-Benutzern war unterschiedlich und von der Alternative abhängig. Gut aufgenommen wurde das System, wenn es verfügbar und die Terminals gut ausgestattet waren (gutes Display mit nativer Auflösung). Anwender, die als alternative Arbeitsumgebung beispielweise ein aktuelles MacBook mit SSD und Retina-Display besassen, hatten ihre Mühe mit der virtualisierten Umgebung.Der Bildaufbau des Dektops ist über das Netz immer etwas langsamer als bei Desktop-Hardware mit entsprechenden Grafik-Chips.

Laufen ressourcenhungrige Anwendungen in mehreren virtuellen Desktops, kam es in der Testumgebung recht bald zu einer Überlastung des Virtualisierungsservers und / oder des Storage Servers. Eine Anbindung des Storage über ein dediziertes Storage LAN brachte hier etwas Linderung. Gundsätzlich ist zu überlegen, inwieweit gerade eine Testumgebung von Beginn an optiomal ausgestattet werden kann. In einer produktiven Umgebung sollten mehrere Virtualisierungsserver mit einsprechender Kapazität bereitgestellt werden, ebenso eine redundante Auslegung des VDI-Verwaltungsservers (hier ist ein Parallelberieb möglich). Fehlt eine entsprechende Auslegung im Testbetrieb, besteht die reale Gefahr, dass die Anwender die gesamte Lösung nicht akzeptieren, da die Vorteile sich dem Anwender nicht unbedingt auf den ersten Blick erschließen, eine schlechte Performance oder Verfügbarkeit aber unmittelbar ins Auge fällt. Hier ist natürlich ein Problem, wenn für die Testumgebung nur ein begrenztes Budget zur Verfügung steht.

Gerade die subjektive Performance-Wahrnehmung wird gesteigert, wenn die Desktops so konfiguriert werden, dass keine oder nur einfarbige Hintergrundbilder eingestellt sind. In der Oracle Dokumentation sind weitere sinnvolle Tipps zur Konfiguration erwähnt, zum Beispiel entsprechende Windows-Grundeinstellungen. Bildschirmschoner müssen natürlich generell abgeschaltet werden, da sie die anderen Desktops lähmen. Einen sehr grossen Unterschied machen die unter Windows leider unvermeidlichen Virescnanner – bei allengetesteten Produkten verminderte sich die Performance des Desktops nach dem Einschalten spürbar. Bestimmte Produkte wie Symantec funktionieren in VirtualBox überhaupt nicht. Die besten Erfahrungen haben wir mit Kaspersky gemacht.

Laufen die VDI-Server im Single Instance Betrieb und sind nicht redundant ausgelegt, hat ein Ausfall den sofortigen Ausfall sämtlicher Desktops zur Folge. Sind die Ressourcen des VirtualBox-Servers erschöpft, wird der Start neuer Desktops ausgesetzt, und Anwender bekommen bei der Anmeldung die Meldung, dass Ihnen kein Desktop zur Verfügung steht.

Die Authentifizierung mit SmardCards klappt in der Praxis gut, so lange kiene nicht SmatCard-fähigen Geräte verwendet werden solllen – ist dies der Fall, ist das Konzept natürlich durchbrochen, weil die Desktops doch wieder auf Anmeldung mit Username und Passwort konfiguriert werden müssen. Es lassen sich dann beide Verfahren gleichzeitig nutzen, aber die Verwendung der Karte bringt nun keinen Sicherheitsgewinn mehr. Eine Lösung könnte hier eventuell sein, verschiedene Desktops bzw. Pools mit unterschiedlicher Sicherheitseinstufung einzurichten, von denen nur einer für die Anmeldung ohne Karte zugelassen ist.

Wird die Two-Factor-Authentication mit Karte aus Sicherheitsgründen erzwungen, bringt dies natürlich nur einen tatsächlichen Gewinn, wenn die Anwender Ihre Zugangskarten nicht im Terminal stecken lassen oder in den Rollcontainer legen – auch nicht bei kurzen Pausen. Eine gute Lösung wäre sicher, die Hausausweise oder Zugangskarten, wenn vorhanden, mit der SmartCard auf einer Karte zu integrieren, so dass die Karte aus dem Terminal entfernt werden muss, wenn das Gebäude verlassen und wieder betreten werden soll. Eine entsprechende Karte mit SunRay-kompatibler SmardCard-Funktionalität und KABA-kompatibler RFID-Kompatibilität war aber im Rahmen dieses Tests nicht mit vertretbarem Aufwand zu beschaffen. Andererseits muss natürlich auch erwähnt werden, dass die SunRay Terminals keine kryptographischen Funktionen der SmartCards nutzen – es wird lediglich die Sereiennummer der Karte ausgelesen und als Token-ID in VDI verwendet. Hier bieten sich auch interessante Ansätze zu weiteren Anwendungen, zum Beispiel für die PKI-Authentifikation gegenüber weiteren Systemen, auf der SmardCard.

Entscheidend für die Benutzbarkeit des Gesamtsystems ist die Transparenz neue geklonter Desktops. Müssen nach dem Bereitstellen viele Einstellungen angepasst oder gar fehlende Anwendungen nachinstalliert werden, stellt die Neubereitstellung ein erhebliches Hindernis dar. Hier ist besondere Geschicklichkeit im Umgang mit den Lizensierungsfunktionen von Windows und den eingesetzten Applikationen gefragt. Die VDI Umgebung sueht die Möglichkeit vor, die Windows-Lizensierung im Rahmen des Desktop Clonings automatisch vorzunehmen, in der Praxis hat dies mit den vorhendenen Windows-Lizenzen allerdings nicht funktioniert. Ebenso wichtig ist eine vollständige Profilverwaltung mit Active Directory, damit die persönlichen Verzeichnisse der Anwender eine Neubereitstellung des Desktops überdauern. Fehlen nach dem Neu-Klonen die im Benutzerverzeichnis abgelegten Dokumente, entsteht nachvollziehbare Frustration. In unserem Fall war dies mit pGina nicht möglich, daher musste das automatische Klonen neuer Desktops in den Windows-Pools abgeschaltet werden. Bei Linux war dies kein Problem, dafür hatten verschiedene Apps wie Firefox permamanente Probleme mit per NFS eingehängten Home-Verzeichnissen, aber dies ist eine andere Geschichte und gehört zu den Problemen, die nicht direkt mit VDI zusammenhängen.

Die User Experience war an den SunRay-Terminals am besten. Wichtig ist, Original-Sun-Tastaturen zu verwenden, denn bei normalen USB-Tastaturen wurde die Tatstaturbelegung nicht automatisch erkannt, so dass es zu Problemen bei der Passwort-Eingabe kommt. In Guest-OS selbst kann die korrekte Tastaturbelegung dann natürlich eingestellt werden.

Kleine Schwierigkeiten gab es mit den VirtualBox Guest Additions – diese waren teilweise instabil und erfüllten ihre Funktion nach einiger Zeit nicht mehr vollständig. Dies hatte zur Folge, dass Desktops nicht mehr durch den VDI Controller heruntergefahren oder in den Ruhezustand versetzt werden konnten und manuell in der VDI-Kontrolle ausgeschaltet werden mussten.

Als durchgehend positiv wurde die Möglichkeit wahrgenommen, bei Bedarf auch mehrere Desktops unterschiedlicher Betriebssysteme zur Verfügung zu haben. Ebenfalls sehr positiv wurde die Möglichkeit aufgenommen, die Arbeitsplätze nicht nur zentral administrieren, sondrn auch zentrall starten, stoppen und gegenenfalls auch komplett neu initialisieren zu können – und das sogar sehr schnell.

Fazit

VDI ist eine zu traditioneller IT alternative Methode, Desktops im Unternehmen bereitzustellen. Installation und Betrieb der Oracle-Umgebung erscheinen mittlerweile stabil und ausgereift.

Die Arbeit an den virtualisierten Desktops ist flexibel, aber die Benutzer-Erfahrung (snappiness) ist weniger direkt als bei einem gut eingerichteten lokalen Desktop.

Aus Sicht der Unternehmens-IT ist der Einsatz von VDI sicherlich sinnvoll, um Sicherheitsanforderungen abzubilden. Der Hauptvorteil ist, das die Daten das Unternehmen zu keiner Zeit verlassen, und der Zugriff, ebenso wie die verwendete Software, zentral administriert werden kann.

In der Kostenbetrachtung egalisieren sich die Unterschiede bei Betrieb von VDI und traditionellen Desktops. Für kleine Unternehmen wird es sehr schwierig sein, die hohen Kosten für eine hochverfügbare Serverumgebung mit ausreichender Leistung zu budgetieren.

Literatur und Verweise

/von