Planung von Desktop-Umgebungen auf VDI-Basis, Teil 2

Die Desktop-Virtualisierung und eine VDI (Virtual Desktop Infrastructure) unterscheiden sich deutlich: Eine VDI nutzt Desktop-Virtualisierungstechniken, um ein Betriebssystem, das im Rechenzentrum agiert, für die Clients zur Verfügung zu stellen. Auch wenn eine VDI für bestimmte Benutzertypen die optimale Lösung darstellt, kann eine Desktop-Virtualisierungsumgebung – egal welcher Ansatz – eine Verbesserung für die Anwender bringen. Vor allem beim Rollout von Windows 7 sollte man als Administrator diesen Aspekt mit in seine Überlegungen einbeziehen.

Auch wenn es dann im Vorfeld einige Arbeiten zu erledigen gilt, rentiert sich die Sache allemal: Die Umgebung wird agiler, spart Verwaltungsaufwand und nutzt die vorhandenen Ressourcen besser aus.

Im ersten Teil dieser Beitragsreihe wurden bereits die grundlegenden Herausforderungen skizziert, die heutige Arbeitsplatzumgebungen mit sich bringen. Vor allem die enge Verzahnung der Bereiche

• Anwendungen des Benutzers,
• das Betriebssystem und
• die Daten und Einstellungen für den Benutzer

bereitet hier große Herausforderungen.

Dabei hat sich gezeigt, dass es für die Bereitstellung der Anwendungen – je nach Aufgabenstellung – durchaus verschiedene Möglichkeiten gibt, die Applikationen für die verschiedenen Benutzertypen bereit zu stellen. Im Folgenden wird konkreter auf die Anwendungs-Virtualisierung eingegangen.
Der große Unterschied zwischen Anwendungs- und Präsentations-Virtualisierung (sprich dem Terminalserver-Ansatz) lautet:

Bei der Applikations-Virtualisierung laufen die Anwendungen auf einer eigenen Instanz des Betriebssystems. Und in diesem Zusammenhang ist es auch sehr wichtig, dass die Anwendungen nicht auf den lokalen Systemen installiert sein müssen. Denn die virtuelle Umgebung erlaubt es, dass die Anwendungen ausgeführt werden können, ohne dass sie am lokalen Betriebssystem des Desktops etwas ändern müssen.

Im traditionellen Desktop-Ansatz wurden beim Installieren einer Applikation Änderungen am lokalen Dateisystem ausgeführt – die ausführbaren Dateien einer Applikation und die zugehörigen DLLs wurden gespeichert, meist unter C:\Program Files, Änderungen an der Registry wurden bei der Installation ausgeführt und verschiedene Dienste – unter Umständen – installiert.

Das Sequencing hilft beim Abstrahieren

Die Applikations-Virtualisierung fängt alle diese Änderungen am System ab. Der entsprechende Mechanismus trägt die Bezeichnung „Sequencing“ (so nennt es Microsoft bei seinem App-V-Ansatz). Dabei wird die Installationsroutine einer Anwendung in einen Bytestream konvertiert, der dann im Rahmen der Applikations-Virtualisierung Verwendung findet.

Das  Sequencing fängt die Systemänderungen bereits bei der Installation einer Anwendung ab. Diese Änderungen werden dann in verschiedenen virtuellen Ebenen – wie der für das Dateisystem, der Registry-Ebene, der Dienste-Ebene, den Ebenen für die Fonts, für das OLE (Object Linking and Embedding) und für die Konfiguration abgespeichert. All diese Ebenen lassen sich dann beim Start der Applikation in die virtuelle Umgebung laden.

Die Applikation geht dann davon aus, dass die zugehörigen Dateien, Registry-Einträge und Dienste alle vom lokalen Betriebssystem kommen. Doch eigentlich sieht die Applikation nur die virtuellen Ebenen, die über die Applikations-Virtualisierung bereitgestellt werden. Es erfolgen dabei keinerlei Einträge in das darunterliegende, lokale Betriebssystem.

In Abbildung 3 sind die verschiedenen Ebenen der Applikations-Virtualisierung zu sehen. Hier ist noch eines anzumerken: Auch wenn die virtualisierten Applikationen praktisch nichts in die Betriebssystem-Ressourcen schreiben können, so sind sie doch in der Lage Informationen aus dem Host-Betriebssystem zu lesen.

Der Ansatz von Microsoft für die Applikations-Virtualisierung, App-V, arbeitet mit einer Streaming-Technik. Wenn eine virtualisierte Applikation das erste Mal auf einem Betriebssystem zum Einsatz kommt, kommuniziert der App-V-Client mit einem App-V-Streaming-Server. Der sendet dann an den Client einen Teil des Binär-Stroms der Applikation, der zu ihrem Start nötig ist – der so genannte Feature Block 1. Er umfasst typischerweise 10 bis 20 Prozent des gesamten Binär-Stroms der Applikation. Damit wird diese Teil sehr schnell an den Client übertragen. Bei Office 2010 ist eine Verzögerung von etwa 3 Sekunden zwischen den ersten Klick des Anwenders auf das Icon der Applikation und dem Start des Fensters der Applikation zu messen (in einem lokalen Netzwerk).

Dabei bestimmt der Sequencing-Vorgang, welche Informationen im Feature Block 1 stehen müssen. Dazu startet dieser Vorgang die Applikation und überwacht beim Sequencing, welche Teile des Streams nötig sind. So sind dann alle notwendigen Bestandteile im Block 1 enthalten, und der Feature Block 2 wird dann im Hintergrund an den Client gesendet. Das lokale Betriebssystem auf dem Desktop legt diesen Binär-Stream in einem Zwischenspeicher ab. Falls die Applikation ein zweites Mal aufgerufen wird, muss die Information nicht noch einmal über das Netzwerk gesendet werden.

Zwischenspeichern bringt Unabhängigkeit

Auch wenn es zuerst geheißen hat, die Applikations-Virtualisierung führt keine Änderungen am lokalen Betriebssystem des Desktops aus, wird in der Realität aber dieser Stream zwischengespeichert. Der Speicherort dafür liegt im Profil für alle Benutzer  und diese Cache-Datei wird auch von allen Benutzern und Applikationen geteilt. Doch die Applikationen selbst schreiben nichts an einen anderen Ort im lokalen Dateisystem – sie führen auch keine Änderungen an der Registry oder andere Konfigurationsaktionen aus.

Das Zwischenspeichern hat aber auch noch einen weiteren Vorteil: Die virtualisierten Anwendungen stehen auch dann zur Verfügung, wenn der Zugriff auf das zentrale System nicht zur Verfügung steht. In einer VDI-Umgebung kann man diesen Zwischenspeicher sogar auf eine Freigabe legen, der für alle VDI-Clientsysteme zur Verfügung steht. Das spart Festplattenplatz und beschleunigt den Aufruf der Applikation.

Die standardmäßige Verteilungsmethode bei App-V ist das Streaming. Doch zudem erlaubt App-V auch die Erzeugung eier MSI-Datei, die den kompletten Stream für die betreffende Applikation enthält. Damit lassen sich dann auch noch andere Technologien für die Bereitstellung unterstützen. Dazu gehört der Einsatz der Gruppenrichtlinien für die Softwareverteilung oder der des Microsoft System Center Configuration Managers (SCCM) 2007 Release 2 (R2). Aber auch der Einsatz von traditionellen Methoden, wie etwa über Dateifreigaben oder die Internet-Informationsdiensten (IIS), eignet sich für die Verteilung der App-V-Streams. Generell steht eine Vielzahl von Optionen bereit – ganz wie es die Anforderungen eines Unternehmens vorgeben.

Für die Benutzer ist es dabei sehr wichtig, dass das übliche Ausschneiden-Einfügen, das Objekt Linking und Embedding (OLE) auch zwischen virtualisierten Applikationen unterstützt wird. Doch für eine tiefere Integration muss man entsprechende Abhängigkeiten zwischen virtualisierten Applikationen erzeugen. Eine dynamisches Anlegen von „Suiten“ erlaubt es den eigenständigen virtualisierten Anwendungen, dass sie sich gegenseitig in einer kontrollierten Art und Weise „kennen“.

Mit der Applikations-Virtualisierung werden einige der Bereitstellungsprobleme von Anwendungen behoben:

• Anwendungen können sehr schnell für einzelne Benutzer bei Bedarf bereitgestellt werden – fast schon in Echtzeit. Dadurch können Administratoren bei Bedarf schnell Anwendungen in der Desktop-Umgebung zum Einsatz bringen.
• Die Kompatibilitätsprobleme zwischen einzelnen Applikationen sind damit gelöst. Denn eigenständige virtualisierte Applikationen „sehen“ sich nicht. Sie verfügen über eigene virtuelle Dateisysteme, Registry und so weiter. Diese Isolation macht auch die üblichen Regressionstests überflüssig, wenn man neue oder aktualisierte Applikationen in eine Umgebung einspielt.
• Das Ausrollen von Updates wird zu einem einfachen Vorgang. Die sequenzierte Anwendung muss nur einmal aktualisiert werden und App-V liefert alle Änderungen über das Streaming an alle Clients aus. Dazu muss der Benutzer keine Aktionen ausführen.
• Das Betriebssystem wird nicht unnötig aufgebläht, da die Applikationen nicht auf dem Desktop installiert werden.

Virtualisierung des Betriebssystems

Will ein Unternehmen seine Client-Systeme auf Windows 7 migrieren, kann es dazu kommen, dass Kompatibilitätsprobleme bei den bestehenden Applikationen auftreten. Falls eine neuere Version einer Applikation, die zu Windows 7 kompatibel ist, nicht zur Verfügung steht oder es kein ähnliches Ersatzprodukt gibt, kann man mit der Virtualisierung des Betriebssystems eine Lösung bekommen. Dabei stehen einem verschiedene Ansätze für die Betriebssystem-Virtualisierung offen.

Mit Windows 7 kommt der Windows XP Mode ins Spiel. Damit lassen sich Applikationen, die nicht auf Windows 7 starten, in einer lokalen virtuellen Maschine (VM) ausführen. Das Applikationsfenster ist dabei nahtlos in die Windows-7-Umgebung des betreffenden Benutzers eingefügt – sprich alles ist für den Anwender komplett transparent. In diesem Fall wird nach wie vor eine eigene Betriebssystemeben mit dem alten Betriebssystem (Windows XP) auf dem Windows-7-Rechner zum Einsatz gebracht. Damit sind aber auch entsprechende Verwaltungsaufgaben für diese Schicht nötig.

Die MED-V (Microsoft Enterprise Desktop Virtualization) – sie ist Bestandteil des Microsoft Desktop Optimization Pack (MDOP) – vereinfacht diese Aufgabe. Denn sie offeriert eine zentrale Methode, um nicht nur die XP-VM zu verteilen und sie zu aktualisieren, sondern sie erlaubt auch das Verwalten der Verknüpfungen auf dem Desktop und das Umleiten von URLs auf den Internet Explorer (IE) 6.0. Damit lassen sich die meisten Kompatibilitätsprobem lösen, die aus dem Zusammenspiel von IE und Windows 7 herrühren.

Ein anderer Ansatz zur Client-Virtualisierung kommt mit der reinen VDI-Lehre ins Spiel: Bei der Virtual Desktop Infrastructure (VDI) wird das komplette Desktop-Betriebssystem für einen Benutzer im Rechenzentrum virtualisiert. Dann bekommt der Benutzer ein lokales Client-System, über das er remote auf das Rechenzentrum zugreifen kann. Bei dem lokalen Client kann es sich um einen Thin Client handeln, aber auch herkömmliche PCs mit einem grundlegenden Windows-Betriebssystem oder jedes andere Gerät, das zum Beispiel RDP (Remote Desktop Protocol) unterstützt, ist als Endgerät geeignet.

Da der komplette Arbeitsplatz für einen Anwender im Rechenzentrum liegt, verlassen sensible Daten niemals diese „Hochsicherheitsumgebung“. Zudem steht der Arbeitsplatz – ganz egal von wo aus sich der Benutzer anmeldet – zur Verfügung. Das kann durchaus auch vom Home Office des Anwenders aus sein. Eine derartige Lösung hat auch große Vorteile, wenn man Katastrophenfälle einzuplanen hat.

Die Gemeinsamkeiten auf einem Blick

Wenn sich ein Benutzer an einer Betriebssysteminstanz das erste Mal anmeldet – egal ob an einem Fat Client, oder an einer Sitzung bei den terminaldiensten beziehungsweise bei einem VDI-basierten Ansatz – es sind immer die folgenden Schritte zu absolvieren:

1. Der Benutzer meldet sich am Betriebssystem über sein Benutzerkonto im Active Directory (AD) an.
2. Nachdem die Authentifizierung stattgefunden hat, werden die Teile des Profils (die nicht über Mechanismen wie die Ordnerumleitung abstrahiert wurden) vom System herunter gezogen. Dieser vergleichsweise geringe Umfang an Informationen lädt recht zügig. Danach liegen alle Anpassungen für die Sitzung des Benutzers vor, einschließlich der Einstellungen für die Ordnerumleitung. Damit sind dann alle Daten, Favoriten und sonstigen Einstellungen für den Anwender geladen.
3. Der App-V-Client kommuniziert mit dem App-V-Management-Server, um die Applikationen zu bestimmen, die zu dem angemeldeten Benutzer gehören. Danach werden noch die Verknüpfungen auf dem Desktop sowie das Start-Menü bestückt und dann noch die Zuweisungen für die Dateitypen erstellt.
4. Im nächsten Schritt hat der Benutzer dann den voll funktionsfähigen Desktop vorliegen und kann seine Anwendungen aufrufen und auf die Daten – ohne Verzögerungen – zugreifen.

John Savill/rhh