VDI-Einsatz vereinfacht Migration der Desktop-Betriebssysteme

Herausforderungen durch moderne Endgeräte, Kostendruck und Sicherheitsanforderungen –all diese Faktoren im IT-Bereich führen dazu, dass sich die IT-Verantwortlichen mit alternativen Konzepten auseinandersetzen müssen, wenn es um ihre „Desktop-Infrastruktur“ geht.

Die Verwaltungskosten aber auch die Investitionen bei einem Umstieg auf eine neue Desktop-Plattform, wie etwa der Umstieg von Windows XP auf Windows 7, sind gute Zeitpunkte, um sich mit dem Aufbau einer Virtual Desktop Infrastructure (VDI) etwa mit VMware View 4.6 zu befassen.

Bei einer Virtual Desktop Infrastructure (VDI) laufen die Desktops der Benutzer sozusagen im geschützten Rechenzentrum ab. Die Endgeräte bekommen dagegen „nur“ die Daten angezeigt – somit ergibt sich fast automatisch eine höhere Sicherheitsstufe für die Unternehmens-IT.

Vor allem wenn man sich vor Augen führt, wie viele mobile Geräte – wie Notebooks, iPADs oder Smart-Devices – im täglichen Einsatz verloren gehen. Welche Probleme auf ein Unternehmen zukommen, wenn zum Beispiel der Chef sein iPAD mit allen wichtigen (und meist auch noch unverschlüsselten) Informationen im Taxi verliert, lässt sich schnell hochrechnen.

Um eine recht flexible Lösung für eine VDI aufzubauen, sollte die eingesetzte Technologie einige Funktionen mitbringen und bestehende Technologien unterstützen. Denn der Einsatz einer VDI eignet sich für jedes Unternehmen – nur eventuell nicht für jeden Arbeitsplatz. Daher gilt es, verschiedene Abstufungen zu beherrschen.

Mit VMware View 4.6 lassen sich verschiedene Ansätze realisieren. Vor allem der Einsatz von geeigneten Übertragungsprotokollen, die ein Darstellen der Desktops auf den Endgeräten erlauben, erweist sich als ein wichtiger Faktor.
Zudem wird mit VMware View auch Thinapp zur Verfügung gestellt, um bei bestehenden Applikationsinkompatibilitäten durch Paketierung die Anwendungen im Streaming-Modus auf die Desktops dynamisch auszurollen.

Beim Konzept von View spielen einige Komponenten zusammen (siehe Abbildung 1). In jeder View-Lizenz sind bereits die nötigen Lizenzen für die vSphere-4-Hosts und das VMware vCenter mit dabei. Sie bilden sozusagen als Virtualisierungs-Hosts die Plattform, auf der die verschiedenen Desktops der Anwender als virtuelle Maschinen (VMs) im Rechenzentrum laufen. Mehr Details zu den einzelnen Versionen beziehungsweise Paketen von View 4.6 sind auf der VMware-Website zu finden.

Als minimale Voraussetzung ist ein Virtualisierungs-Server mit ESX nötig. Da es aber beim Ausfall eines derartigen Virtualisierungs-Host zum Ausfall der kompletten VDI-Umgebung führt, sollte man bei den entsprechenden Vorgaben in Bezug auf die Ausfallsicherheit schon mit mindestens zwei Virtualisierungs-Host planen. Des Weiteren muss noch die Management-Komponente für die vSphere-Umgebung vorhanden sein: Diese Aufgabe übernimmt der vCenter Server.

Ein weiteres Modul der View-Umgebung ist der View Manager. Dabei handelt es sich um eine Instanz eines Windows-basierten Servers – das kann auch eine VM auf dem Virtualisierungs-Host sein. Sie liefert die Managementoberfläche für die View-Umgebung und besitzt zudem eine eigene Datenbank, die alle Konfigurationsinformationen für die View-Umgebung enthält. In umfangreichen Umgebungen mit vielen VMs – sprich virtuellen Desktops – empfiehlt sich auch noch der Einsatz eine Storage-Optimierungs-Komponente, wie sie in der Premier Edition von View gegeben ist.

Hier übernimmt der View Composer die Aufgabe, Pools von sogenannten Linked Clones anzulegen. Dabei werden nicht alle Vorlagen für einen Desktop als VM-Vorlagen komplett gespeichert, wie das bei den „Full Clones“ der Fall ist. Vielmehr werden von einem „Golden Image“ aus weitere Images über das Abspeichern von Delta-Dateien angelegt.

Golden Image spart Speicherplatz

Diese Dateien enthalten lediglich die Änderungen gegenüber dem Ausgangspunkt. Damit lässt sich eine Reduzierung der Speicheranforderungen erzielen: Der Umfang eines Basisimages für eine Desktop-VM mit einem aktuellen Microsoft-Client-Betriebssystem liegt bei etwa 20 GByte. Dagegen fallen bei den davon abgeleiteten Linked Clones jeweils nur 25 bis 30 MByte als Delta-Information an. Sprich beim zweiten Image spart man sich bereits fast die ursprünglichen 20 GByte. Je mehr unterschiedliche Desktop-VM-Varianten in einer Umgebung nötig sind, umso größer ist die Einsparung an Speicherplatz.

Der Administrator ist aber auch in der Lage, einen „Refresh“ dieser Linked Clones durchzuführen und damit die Betriebssystempartition wieder als „frische“ Partition bereitzustellen – ohne dass die User-Daten verloren gehen. Der Grund dafür: Jeder kennt das Verhalten eines Betriebssystems: Je länger es in Betrieb ist, desto langsamer wird es. Mit dem Refresh erreicht man wieder einen schnellen virtuellen Desktop.

Es kann aber auch der Ausgangs-Master (also das Golden Image) geändert werden. Das macht Sinn beim Patchen von Betriebssystem. So könnte man nach dem Patchen die neue Version des Images eine Zeitlang ausprobieren und wenn keine Probleme auftreten, wird die gepatche Version als neuer Ausgangspunkt festgelegt. Ein weiterer Vorteil in diesem Konzept: Die User- und Anwendungsdaten bleiben erhalten, wandern mit ins nächste Image.

Offline-Modus für Clients

Eine andere Komponente wird nötig, wenn man in seiner Desktop-Umgebung mit Offline-Clients (VMware View Funktion: Locale Mode) arbeiten möchte. Dann müssen die Informationen auf den Desktops, die zeitweise nicht mehr über Verbindung ins Rechenzentrum zu den dort gehosteten Desktops verfügen, sozusagen beim Auftrennen der Verbindung ausgecheckt und später, wenn die Verbindung wieder zum Rechenzentrum erfolgt, eingecheckt werden – sprich die Informationsstände auf beiden Seiten sind zu synchronisieren.

Damit wird auch das Thema Backup dieser Images adressiert.
Der View Connection Server agiert als der Broker für die einzelnen Client-Verbindungen mit den virtuellen Desktops im Rechenzentrum. Hier fallen viele Aufgaben an. Zum einen muss diese Komponenten die Authentifizierung der Benutzer – eventuell unter Einbeziehen des Active Directory (AD), aber auch durch Smartcards beziehungswiese Secure Token – abwickeln.

Dann muss der Connection Server die Anfrage zur passenden VM leiten. Hier ist zu unterscheiden, für welchen Pool oder für welche Gruppe das gemacht werden muss – diese Information kann allein über die Anmeldeinformationen des Benutzers erfolgen – im Falle einer Single-Sign-On-Lösung.

Unter Umständen ist auch das Bereitstellen von Applikationen, die mittels Thinapp als Pakete für das Streaming erstellt wurden, nötig sein. Auch dies veranlasst der Connection Server.

Im internen Unternehmensnetzwerk – abgesichert durch eine Firewall – sollte man eine Gruppe aus zwei oder mehreren Instanzen des Connection Server installieren. Damit wird diese Einheit ausfallsicherer und kann auch keinen Flaschenhals darstellen. Denn sämtliche Verbindungen zwischen den Clients und den gehosteten Desktops werden über den Connection Server erstmals aufgesetzt. Die Konfigurationsdaten für den Connection Server liegen in einem integrierten LDAP-Verzeichnis (einer ADAM Datenbank). Diese Daten werden unter allen Connection Servern in einer Gruppe auch automatisch repliziert.

Security Server reduziert Verbindungsprobleme

Außerhalb der Firewall, also in der DMZ (Demilitarisierten Zone), kann man ab der Version View 4.6 den Connection Server auch noch so konfigurieren, dass er die Funktionalität eines „Security Servers“ noch übernimmt. Dazu muss der Security Server als separate Instanz in eigener VM agieren, die auf einem Host in der DMZ liegt. Hier empfiehlt es sich, die üblichen Vorgehensweisen für das „Hardening“ des Servers (ein System auf der Basis von Windows Server) zu befolgen – also möglichst wenig Angriffsfläche durch die Reduzierung der absolut minimal notwendigen Dienste zu berücksichtigen.

Ein derartiger Security Server kommuniziert dann mit den Connection Servern hinter der Firewall des Unternehmens. Diese Konfiguration soll sicherstellen, dass nur der Verkehr für die remoten Desktops mit entsprechend authentifizierten Benutzern in das Unternehmensnetzwerk – also bis ins Rechenzentrum mit den gehosteten Desktops kommen kann. Zudem wird den Benutzern nur der Zugriff auf die Ressourcen eingeräumt, die für sie freigegeben sind.

Die meisten Verbesserungen für die Sicherheit ergeben sich bei Security Server, wenn man als Protokoll zwischen den Clients und den Desktop-VM das PCoIP (PC over IP; dieses Protokoll verschlüsselt selbst die Daten nach AES 128) verwendet.

Der Security Server ab View 4.6 erlaubt ein Tunneling des PCoIP. Er eignet sich aber auch für das Remote Desktop Protocol (RDP), das üblicherweise in Windows-Umgebungen zum Einsatz kommt – aber weniger Performance bietet als das PCoIP. Dieses Protokoll konnte früher (also vor der Version 4.6) nicht über den Security Server von View (also vor der Version 4.6) transportiert werden, da PCoIP zuerst zwar das TCP, dann aber das UDP als Transport-Protokoll verwendet. Das wurde nun geändert. Falls ein Unternehmen eine eigene VPN-Lösung verwendet, ist der Einsatz eines Security Servers nicht nötig.

Allerdings ist für die Freigabe des PCoIP-Verkehr ein spezieller Port (der Port 4172, zuerst TCP, dann UDP) auf der Firewall zu öffnen. Das ist in vielen Unternehmen nicht gern gesehen, denn aus Sicherheitsgründen möchte man – etwa für die Gastnetze in einem Unternehmen – nur die Ports 80 und 443 offen lassen – alles andere wird strikt geblockt.

Allerdings hat der Anwender bei View 4.6 immer die Wahl, ob er das traditionelle RDP oder das neuere und leistungsfähigere PCoIP verwendet. Hier sollte man aber auch die Anforderungen ins Kalkül ziehen, die ein remote angebundener Benutzer hat. Wenn sich die Bildschirminhalte nicht besonders häufig ändern, kommt man auch recht gut mit RDP zurecht – für das Durchsehen der Mail zum Beispiel reicht das auf alle Fälle aus.

Clients wie das iPAD benötigen eigene Software

Auf den Clients muss für den Einsatz von View ebenfalls Software zum Einsatz kommen: der View Client. Er liegt für Endgeräte auf der Basis von Windows und MacOS (PCs, Notebooks, Thin Clients) sowie für das iPAD als native Applikation vor. Allerdings muss es für die Darstellung der Desktop-Inhalte auch eine passende Auflösung unterstützen.

Das ist zum Beispiel bei Blackberry nicht gegeben, daher wird diese Gerätegattung auch nicht unterstützt. Für Android-Plattform ist ein Client in Vorbereitung. Wer einen Thin Client verwendet, der kann View Client for Linux einsetzen und dann auch dieses Endgerät in der View-Umgebung verwenden.

Streamen von Applikationen durch Thinapp-Integration

In der Premier Edition von View ist auch noch die Thinapp-Funktionalität enthalten. Der Package Server kümmert sich dabei um das Paketieren der Applikationen. Über das sogenannte Sequenzing werden Applikationen so umgebaut, dass sie gestreamt werden können.

Dazu ist ein eigener Windows-Server nötig, der quasi im Filesharing genutzt wird: Auf dem System liegt dann ein Ordner, in dem die gesamten Thinapp Informationen liegen. Für das Aufzeichnen eines Applikations-Pakets benötigt der Administrator ein „leeres“ Betriebssystem. Dann wird sozusagen vorher – vor dem Paketieren – ein Snapshot gemacht, mit allen Informationen im Dateisystem und in der Registry. Dann zeichnet man die Installation auf (dazu wird sie ganz normal durchgeführt). Und anschließend wird erneut eine Art Snapshot gemacht.

Über einen Vergleich von „vorher-nachher“ lässt sich ermitteln, was sich auf dem zuvor leeren System geändert hat. Nach diesem Vergleich werden die entsprechenden Dateien gespeichert. Damit die nicht auf dem System liegen, auf dem es aufgezeichnet wurde, legt man das auf ein neues „leeres“ System auf einem separaten Server – beziehungsweise auf einer Server-Instanz.

Dort sind dann die Pakete alle zentral abgelegt. Das lässt sich dann auch ein Repository nutzen für alle Packages, die man in seinem Unternehmen anlegt. Ein derartiges Package enthält somit alle Änderungen durch Installation der Applikation im Dateisystem und in der Registry.

Welche Art der Bereitstellung der Desktops – ob und wenn ja, welche Applikationen gestreamt werden sollen – entscheiden die Anforderungen im Unternehmen. Üblicherweise werden dabei mehrere Benutzertypen anhand ihrer Arbeitslasten definiert.  Dabei stellt sich oftmals die Frage des kleinsten gemeinsamen Nenners für den standardisierten (virtuellen) Arbeitsplatz im Unternehmen:

Was brauchen „alle“ Mitarbeiter in einem Unternehmen. Diese Basis wird dann als Vorlage genommen und dann bei der Anmeldung einen User  je nach Benutzertyp  zusätzliche Applikationen zum Beispiel via Thinapp bereitgestellt. Sprich man passt nicht das Template an, sondern liefert zusätzlich zum Template noch weitere Applikationen aus. Das lässt sich über die Zugehörigkeit zu bestimmten Benutzergruppen realisieren und wird somit gleich bei der Anmeldung des Benutzers  bestimmt.

Umstieg in eine VDI-Umgebung

Angenommen ein Unternehmen hat normale AD-basierte Umgebung am Laufen und möchte nun einen Umstieg in eine VDI absolvieren. Hier ist für die View-Umgebung bereits eine Einbindung in das AD vorhanden. Das erfolgt sozusagen auf  zwei Ebenen:  Eine ist das klassische Verwenden von AD-Benutzern. Damit lässt sich zum Beispiel die Zuordnung zu den angelegten VDI-Pools realisieren.

Einzelne Benutzer oder Benutzergruppen im AD können dabei herangezogen werden. Dazu benötigt die View-Umgebung kein spezielles Tool, um die Daten aus dem AD zu extrahieren. Der View Manager wird mit AD verbunden und kann nativ auf das Verzeichnis zugreifen. Dazu legt der View Manager legt bei seiner Installation eine Datenbank an und verwendet dabei den ADAM (Active Directory Application Mode).

Für die Integration der View-Umgebung im AD ist keine Schema-Erweiterung des AD nötig.  Der View Manager holt sich die Informationen von einem Domänencontroller und baut daraus die Datenbank auf, die auf jedem View Manager vorhanden ist. Damit hält jeder View Manager seine eigene ADAM-Datenbank. Über die klassischen AD-Techniken werden die Datenbanken aktuell und synchron gehalten.

Zusammenspiel mit dem Active Directory

Als zweite Ebene lassen sich die ESX-Server auch in das AD einhängen. Daraus resultiert ein Vorteil: Benutzer, die ESX administrieren dürfen, sind dann auch über das AD definiert. Doch in der Praxis erweist sich das als kein besonders großer Vorteil , da es in der Regel nur wenige Administratoren  gibt, die diese Rechte haben sollen. Es ist dann eben kein Root-Account mehr auf dem ESX nötig – dieses Objekt wird über AD bezogen.

Doch damit ergibt sich aus Compliance-Vorteilen ein wichtiger Grund: Denn nur wenige Benutzer sollten über die Root-Rechte verfügen. Und damit werden die Aktionen am ESX-Host auch besser nachvollziehbar.

Rainer Huttenloher