VDI-Lösung nutzt den Windows Server 2008 Release 2, Teil 2

Die Komponenten einer reinen Microsoft-VDI-Lösung bestehen aus vielen Diensten, die optimal zusammenspielen sollten. Dabei ist für verschiedene Module die Hochverfügbarkeit ein wesentliches Kriterium, denn wenn die Pools mit den Desktops ausfallen, „geht gar nichts mehr“.

Für das Gehirn der VDI-Umgebung, den Remote Desktop Connection Broker, empfiehlt sich der Einsatz des Failover-Clustering, denn dieser Rollendienst ist für den Einsatz in einem Cluster konzipiert – er ist „Cluster aware“. Damit ist seine Verfügbarkeit mit einem entsprechend hohen Prozentsatz sichergestellt: Wenn irgendein Knoten ausfällt, übernimmt ein anderer.

Wenn man – wie es in den meisten Fällen wohl üblich ist – den Remote Desktop Session Host (im Redirection-Modus) mit dem Remote Desktop Connection Broker auf derselben Hardware betreibt, muss man lediglich auf einen Punkt achten: Der Remote Desktop Session Host muss auf allen Knoten des Clusters installiert und auf allen Knoten des Clusters auch in den Redirection-Modus gebracht werden.

Sieben Schritte gilt es zu beachten, wenn man eine VDI-Umgebung auf der Basis des Windows Server 2008 Release 2 (oder des Hyper-V Server 2008 Release 2) aufbauen möchte. Diese einzelnen Stufen und ihr Zusammenspiel wurden bereits im ersten Beitrag aus dieser Reihe skizziert. In diesem zweiten Beitrag werden die einzelnen Dienste genauer beschrieben, die für eine derartige Lösung nötig sind.

Den ersten Einstiegspunkt bildet der „Remote Desktop Web Access“. Er stellt den Anwendern ein Web-basiertes Interface zur Verfügung, über das sie die gewünschte Virtual Desktop Infrastructure (VDI) oder die veröffentlichten Desktop- oder Applikationen als Ziele angeben können. Diese Komponente ist zwar nicht unbedingt nötig, doch sie hat einen großen Vorteil: Über ein einfach zu bedienendes Portal, das die Authentifizierung abwickelt (und dabei ein Single Sign On, SSO, unterstützt), kann auch über öffentliche und private Computer unterschieden werden.

Mit Windows 7 kommt das Feature “RemoteApp and Desktop Connections” ins Spiel. Das ist kein direkter Bestandteil des Remote Desktop Web Access, doch es erlaubt einen Feed vom Remote Desktop Web Access zu beziehen, damit derselbe Inhalt, der auf der Website (dem Portal) zu sehen ist, auch direkt im Start-Menü der Benutzer auftaucht. Damit brauchen die Benutzer dann nicht einmal mehr diese Website aufsuchen. In der ersten Abbildung oben sind zum einen das lokale Start-Menü und die Ansicht über die Website zu sehen.

Möchte der Administrator eine Konfigurationsdatei erzeugen, die “RemoteApp and Desktop Connections” automatisch für Windows-7-Clients konfiguriert, sollte er die Option “Create Configuration File” im Remote Desktop Connection Manager verwenden. Mit dieser Option wird eine Datei angelegt die man auf Systemen mit Windows 7 verwenden kann, um den Client automatisch zu konfigurieren. Vor allem für umfangreiche Einsatzszenarien ist das eine sehr wertvolle Hilfe.

Remote Desktop Connection Broker

Der Rollendienst “Remote Desktop Connection Broker” des Windows Server 2008 R2 ist eine der Basiskomponenten, mit deren Hilfe eine reine Microsoft-VDI-Lösung erstellt werden kann. Damit bekommt der Remote Desktop Service (RDS) die Möglichkeit, die Verbindungen zu Nicht-Terminaldienste-Servern zu verfolgen und zudem die Fähigkeit, Verbindungen zu den Client-Betriebssystemen zu verwalten.

Mit dem Release 2 des Windows Server 208 kommt noch eine Erweiterung ins Spiel: Der Rollendienst des „Remote Desktop Connection Broker“ erlaubt ein Ausbalancieren der remoten Applikationen und die Unterstützung von Servern mit verschiedenen publizierten Anwendungen. Das ergibt einen kompletten Überblick über alle verschiedenen Applikationen von allen Servern in der Server-Farm für den Benutzer. Damit wird es hinfällig, dass auf allen Server immer die gleichen Applikationen liegen müssen.

Der Rollendienst „Remote Desktop Connection Broker” stellt sozusagen das Gehirn der gesamten VDI-Umgebung dar. Es kommuniziert mit den anderen Komponenten und kontrolliert sie. Eine besonders enge Zusammenarbeit besteht dabei mit dem Remote Desktop Session Host (im Redirection Mode). Das ist auch der Grund, warum der Remote Desktop Connection Broker und der Remote Desktop Session Host (im Redirection Mode) häufig auf derselben Betriebssysteminstanz zum Einsatz kommen. Wenn in einer Umgebung allerdings mehr als 250 gleichzeitige Verbindungen nötig sind, sollte man sich überlegen, ob es nicht doch besser ist, diese beiden Rollendienste auf verschiedenen physischen Systemen auszuführen.

Die einzelnen VDI-Pools werden vom Rollendienst Remote Desktop Connection Broker erzeugt. Genauer gesagt durch das Verwaltungs-Tool „Remote Desktop Connection Manager“. Es verwaltet die publizierten Applikationen, die publizierten Sessions und die virtuellen Desktop-Ressourcen. Beim Remote Desktop Connection Manager handelt es sich um ein Tool, das sich beim Verwalten einer VDI-Umgebung als extrem wertvoll erweist.

Es lässt dem Administrator nicht nur VDI-Pools anlegen, sondern es konfiguriert die Rollendienste  Remote Desktop Virtualization Host, Remote Desktop Web Access und Remote Desktop Session Host. Zudem versetzt das Tool den angegebenen Remote Desktop Session Host in den Redirection-Modus. Damit spart man sich den Aufwand, jeden Dienst von Hand für seine VDI-Rolle zu konfigurieren.

Legt der Administrator einen VDI-Pool an, gibt er die Hyper-V-Server an, die die VMs beherbergen. Danach werden die Client-VMs ausgewählt, die ein Teil dieses Pools sein sollen. Der Assistent für das Erzeugen des VDI-Pools kümmert sich dabei auch um die meisten der anderen notwendigen Konfigurationsaufgaben.

Der Rollendienst des Remote Desktop Connection Broker kümmert sich um alle ankommenden VDI-Anfragen und prüft zuerst, ob er erkennen kann, dass der Benutzer eine unterbrochene Session in dem VDI-Pool hat. Wenn das der Fall ist, wird der Benutzer erneut damit verbunden. Im anderen Fall wird ein derzeit unbenutzter virtueller Desktop dem Benutzer zugewiesen.

Der Remote Desktop Session Host (im Redirection-Modus)

Das Konzept, einen Remote Desktop Session Host im Redirection-Modus einzusetzen, ist nicht neu. Es kam schon zum Einsatz, wenn es bei früheren Windows-Server-Versionen darum ging, eine große Terminalserver-Farm zu betreiben. Damit sich ein Benutzer nicht mit verschiedenen Terminalservern zu verbinden hatte, wurde als ursprünglicher Einstiegspunkt immer ein bestimmter (vorgegebener) Session-Host definiert. Dieses System macht nichts anderes, als mit dem Broker zu kommunizieren und dann die RDP-Verbindung an den korrekten RDP-Endpunkt umzuleiten.

Derselbe Vorgang ist in einer VDI-Umgebung nötig. Es ist nach wie vor ein anfänglicher RDP-Verbindungspunkt für die RDP-Clients nötig. Das ist genau das, was der Remote Desktop Session Host im Redirection-Modus bietet. Er leitet dann den RDP-Client an die korrekte Client-Betriebssystem-VM um, die dann das Desktop-Betriebssystem liefert.

Den Remote Desktop Session Host kann man sich auch als einen Terminalserver vorstellen: Es ist ein System, das ein Hosting von Sessions bietet. Da aber der Windows Server 2008 R2 über so viele RDS-Teile verfügt, muss man hier etwas genauer zeigen, wann ein Server tatsächlich Sessions vorhält – daher kommt der Begriff des Remote Desktop Session Host ins Spiel.

Es besteht auch die Möglichkeit, einen Remote Desktop Session Host von Hand zu konfigurieren, dass er im Redirection-Modus agiert. Doch wenn man den Assistent zum Erzeugen von VDI-Pools des Remote Desktop Connection Manager einsetzt, wird die Konfiguration des Remote Desktop Session Host automatisch erfolgen, wie das auch im Abbildung 3 zu sehen ist. Hier gilt es noch anzumerken: Wenn ein Remote Desktop Session Host in den Redirection-Modus gebracht wurde, kann er nicht mehr verwendet werden, um normale Sessions zu beherbergen. Er ist dann nur mehr in der Lage, die Umleitungen – Redirections – auszuführen.

Der Remote Desktop Virtualization Host

Der Rollendienst des Remote Desktop Virtualization Host ist auf jedem Hyper-V-Host installiert, der zu dem VDI-Pool gehört. Dieser Rollendienst lässt den Rollendienst des Remote Desktop Connection Broker mit den Hyper-V-Systemen kommunizieren, erledigt das Starten und Stoppen von VMs und holt interne Informationen, um Client-Verbindungen zu ermöglichen.

Das Remote Desktop Gateway

Beim Remote Desktop Gateway handelt es sich ebenfalls um einen Rollendienst. Er kümmert sich darum, dass der RDP-Verkehr in HTTPS-Pakete gekapselt wird. Damit sind sichere RDP-Verbindungen durch die Unternehmens-Firewall möglich, ohne dass man zusätzliche Ports auf der Firewall öffnen oder eine zusätzliche VPN-Lösung installieren müsste. In diesem Einsatzbeispiel findet das Remote Desktop Gateway Verwendung, um zu konfigurieren, wer sich durch diesen Dienst verbinden darf, wohin er sich verbinden darf und wie die zugehörigen RDP-Einstellungen aussehen – wie etwa die Geräteumleitung.

Hochverfügbarkeit für die VDI

Der Einsatz einer VDI-Umgebung bringt eine Zentralisierung der Desktop-Umgebungen in das Rechenzentrum mit sich. Wenn in einem „normalen Szenario“ ein der Server ausfällt, können die Benutzer immer noch ihre lokalen Ressourcen auf ihrem PC nutzen, lediglich die Server-Verbindung entfällt. Anders dagegen bei einer VDI:

In diesem Fall liegt der komplette Desktop im Rechenzentrum. Wenn nun ein Teil der VDI-Umgebung ausfällt, verliert der Benutzer seine Desktop-Umgebung und kann folglich auch nicht arbeiten. Daher ist es sehr wichtig, alle Elemente in einer VDI-Umgebung ausfallsicher auszulegen. Aber es gibt für alle Elemente der VDI-Architektur eine passende Lösung.

Für das Gehirn der VDI-Umgebung, den Remote Desktop Connection Broker, empfiehlt sich der Einsatz des Failover-Clustering, denn dieser Rollendienst ist für den Einsatz in einem Cluster konzipiert – er ist „Cluster aware“. Damit ist seine Verfügbarkeit mit einem entsprechend hohen Prozentsatz sichergestellt: Wenn irgendein Knoten ausfällt, übernimmt ein anderer.

Wenn man – wie es in den meisten Fällen wohl üblich ist – den Remote Desktop Session Host (im Redirection-Modus) mit dem Remote Desktop Connection Broker auf derselben Hardware betreibt, muss man lediglich auf einen Punkt achten: Der Remote Desktop Session Host muss auf allen Knoten des Clusters installiert und auf allen Knoten des Clusters auch in den Redirection-Modus gebracht werden.

Dazu wird noch ein DNS-RR (Resource Record) für die Session Hosts erzeugt, zu denen die IP-Adressen jedes konfigurierten Session-Hosts gehören. Wenn sich dann die Clients verbinden, werden alle IP-Adressen in verschiedener Reihenfolge gesendet. Sollte einer der Server nicht verfügbar sein, dann nehmen die Clients einfach die nächste IP-Adresse.

Der Dienst NLB (Network Load Balancing) findet Verwendung, um die Last zwischen den verschiedenen Instanzen des Remote Desktop Gateway zu verteilen. Der NLB-Dienst  – als ein Bestandteil von Windows – lässt sich daher gut verwenden. Doch es  besteht auch die Möglichkeit, ein Lastverteilungssystem mit eigener Hardware einzusetzen – das dann aber nicht zum Flaschenhals in Bezug auf die Hochverfügbarkeit werden darf. Mit demselben Ansatz – NLB – lässt sich auch der Remote Desktop Web Access hochverfügbar gestalten.

Auch die Hyper-V-Serversysteme können in einem Failover Cluster zusammengeführt werden. Sollte einer der Hyper-V-Hosts ausfallen, können die Client-VMs auf einen anderen Host im Cluster verschoben  werden. Mit der Live Migration können sogar laufende Client-VMs zwischen Hosts verschoben werden – das ist nützlich, wenn zum Beispiel Wartungsarbeiten an einer Server-Hardware (mit dem Hyper-V) anfallen. Da aber der Benutzer-Status und die Daten separat von der Betriebssystem-Instanz liegen, muss der Benutzer nur mit einer anderen Betriebssystem-Instanz verbunden werden. Dann sind der Benutzer-Status und die Daten des Benutzers wieder verfügbar.

Persönliche oder gepoolte Desktops

Bisher wurde immer nur von Pools für VDI-Clients gesprochen. Bei dieser Konfiguration sind mehrere VMs, in denen die Client-Betriebssystem laufen, in einem Pool gruppiert. Wen sich Benutzer mit dem Pool verbinden, werden sie automatisch einer VM, die derzeit nicht benutzt wird, zugewiesen. Nachdem sich der Benutzer abgemeldet hat, wird die VM wieder zurück in den Pool gegeben. Da ein Benutzer womöglich (und das ist sogar sehr wahrscheinlich) jedes Mal eine andere VM bekommt, müssen verschiedene Desktop-Virtualisierungslösungen zur Verfügung stehen (wie etwa Roaming Profiles, Ordnerumleitung, Applikations-Virtualisierung), um eine konsistente Desktop-Umgebung liefern zu können.

Die gepoolten Desktops sollten die Standardvorgabe für alle Benutzer sein. Doch es kann sein, dass bestimmte Anwender genau dieselbe Betriebssysteminstanz bekommen, wenn sie sich anmelden. Entweder weil sie das Betriebssystem irgendwie abändern oder aber weil sie noch eine Anwendung mit installiert bekommen, die sich nicht anderweitig virtualisieren lässt.

Was auch immer der Grund für ein Abweichen von der Regel ist, man braucht die Option, dass eine bestimmte VM für einen bestimmten Benutzer gehört – und zwar immer wenn er sich mit der VDI verbindet. Dies wird auch als „Personal Desktop“ bezeichnet und wird mit Hilfe der MMC (Microsoft Management Console) und dem Snapin Active Directory Benutzer und -Computer konfiguriert (siehe Bild 4).

Ein Benutzer kann aber nur einen Personal Desktop zugewiesen bekommen und eine VM kann nur zu einem einzigen Benutzer als Personal Desktop reserviert werden. Zudem ist ein Personal Desktop nicht in einem VDI-Pool abgelegt. Es ist lediglich eine normale VM in dieser Umgebung. Dabei muss der Administrator aufpassen, dass der Name des Personal Desktops genau dem Namen der VM entspricht. Das muss zudem ein FQDN (Fully Qualified Domain Name) wie etwa client.savilltech.net sein. Sprich man muss die betreffenden VMs mit dem FQDN der Client-Betriebssystem-Instanz benennen.

Die Konfiguration der Client-VMs

Für die hier beschriebene Aufgabe soll Windows 7 als Client-Betriebssystem in den VDI-VMs zum Einsatz kommen. Bei einem RDS-basierten VDI-Ansatz muss der Administrator alle VMs im Vorfeld erzeugen, dann das Betriebssystem in die VM einspielen und diese Einheit dann dem Pool hinzufügen.

Es gibt leider kein dynamisches Erstellen oder ein Streaming des Betriebssystems, um damit die VMs zu belegen. Eine derartige Fähigkeit bringt erst der Citrix XenDesktop mit sich. Um das Bereitstellen der VMs und der Betriebssysteme in den VMs zu vereinfachen, lassen sich bei einem Microsoft-Only-Ansatz die Hilfe des SCVMM hinzuziehen.

Es sind innerhalb der Client-VMs einige bestimmte Konfigurationsarbeiten auszuführen, um die Verwaltung der Client-Betriebssysteme durch den Remote Desktop Virtualization Host  zu erlauben und um die Verbindung zu den Clients herzustellen. Die folgenden Schritte sind dabei wichtig:

• Aktivieren des Remote Desktops
• sich verbindende Benutzer sind der Gruppe der Remote Desktop User hinzuzufügen.
• RPC erlauben
• Ausnahmen für die Firewall konfigurieren, um das Verwalten der Remote Services zu unterstützen,
• Konfigurieren der RDP-Berechtigungen für den Remote Desktop Virtualization Host.

Alle nötigen Schritte lassen sich von Hand für jede VM ausführen. Genauere Details dazu bietet der Technet-Beitrag „Remote Desktop Services in Windows Server 2008 R2, Appendix A“ . Dazu kann man noch die Gruppenrichtlinien einsetzen, um diese Schritte automatisch der Konfiguration hinzuzufügen, oder aber man kann das von einem Skript erledigen lassen, das Microsoft bereitstellt – um den gesamten Vorgang zu vereinfachen.

Es gibt aber noch einen weiteren interessanten Aspekt in einer Client-VM-Betriebssystemumgebung. Es sind mehrere Client-Betriebssystemumgebungen im Einsatz, die von mehreren Benutzern gemeinsam verwendet werden. Daher sollte man diese gemeinsame Client-Umgebung absichern, damit die Benutzer die Betriebssystemkonfiguration nicht ändern können beziehungsweise Software wegnehmen oder neue hinzunehmen können.

Aber je nach der eingesetzten Umgebung empfiehlt es sich womöglich, dass nach jedem Abmelden eines Benutzers wieder ein klar definierter Anfangszustand entsteht – also eine Art Reset ausgeführt wird. Mit Hilfe des Hyper-V und den Snapshot-Fähigkeiten der RDS lässt sich das realisieren.
Für jede VM kann der Administrator einen Snapshot erzeugen, der RDV_Rollback im Snapshot-Namen enthält.

Dieser Snapshot könnte gemacht werden, wenn die VM sich in einem sauberen Zustand befindet, denn man möchte ja einen Reset für das Betriebssystem bekommen, wenn sich der Benutzer abmeldet. Der Snapshot kann bei laufender oder auch bei angehaltener VM erzeugt werden. Doch der Administrator muss sicherstellen, dass zum Zeitpunkt des Snapshots in der VM niemand angemeldet ist.

Wenn sich ein Benutzer von einer VM abmeldet, an der er über den Rollendienst des Remote Desktop Connection Broker verbunden war, wird die VM zurückgesetzt und zwar auf den Zustand des RDV_Rollback-Snapshots. Diese RDV-Rollback-Fähigkeit gehört nur zu den VMs, die in einem Pool liegen, nicht zu den Personal Desktops.

Wer diese Methodik mit RDV_Rollback verwendet, der baut eine Falle in seine VDI-Umgebung ein, die mit den AD Domänenmitgliedschaften zusammenhängt. Üblicherweise ändert sich das Kennwort für ein Computerkonto der Betriebssysteminstanz alle 30 Tage. Wenn aber regelmäßig eine Wiederherstellung zu einem bestimmten zeitlichen Fixpunkt erfolgt, etwa immer nach einem Abmeldevorgang, wird das alte Kennwort für das Computerkonto (das im RDV_Rollback vorliegt) nicht mehr gültig sein, wenn der Computer sein Kennwort ändert.

Das könnte vorkommen, wenn ein Benutzer nach den 30 Tagen angemeldet ist und das führt dann zu weiteren Fehlschlägen beim Anmelden. Der einzige Ausweg hierzu wäre dann das Zurücksetzen des Kontos.
Es gibt aber einige Optionen, um dieses Problem zu lösen. Eine Vorgehensweise wäre das Deaktivieren der Kennwortänderung für das Computerkonto – das wäre sogar mit Hilfe der Gruppenrichtlinien zu machen. Damit sind allerdings unter Umständen Verstöße gegen die Sicherheitsrichtlinie des jeweiligen Unternehmens zu befürchten. Daher sollte man das nur im äußersten Notfall so machen.

Eine Alternative wäre das Löschen aller Client-VMs, dann ein erneutes Erzeugen der VMs und das Anlegen eines neuen RDV_Rollback – und zwar regelmäßig in einem Zeitintervall, das kürzer ist als die Zeitspanne, nach der das AD eine Änderung des Kennworts für das Computerkonto vorgibt. Das hört sich zuerst etwas lächerlich an, doch man kann mit entsprechenden Skripts von Microsoft diese Sache angehen (VMM and Microsoft’s scripts for creating VMs for VDI).

Mit diesen Skripts wird das massenhafte Erzeugen von VMs für die VDI-Umgebung automatisiert. Das macht es für den Administrator viel einfacher, die VDI-VMs erneut anzulegen. Damit kommt das regelmäßige erneute Anlegen der VMs auch wieder in einen vernünftigen Bereich in Sachen Verwaltungsaufwand.

Wenn man die VMs für eine längere Zeitspanne verwendet, muss man sie Patchen und regelmäßige Desktop-Verwaltungsaufgaben ausführen. Wenn man dagegen die VMs immer alle vier Wochen erneut erzeugt, dann muss man nur ein Single-Master-Image patchen, das dann repliziert werden kann, um alle VMs im VDI-Pool zu erzeugen.

Die nächsten Schritte

Eine RDS-basierte VDI ist eine gute Lösung, die sich in Produktivumgebungen gut verwenden lässt. Für Einsatzszenarien im größeren Stil ist dagegen die statische Natur der Client-VMs ein gewisser Nachteil. Die Kooperation von Microsoft und Citrix soll hier helfen – das wird der Gegenstand eines Folgebeitrags sein. Wer schon jetzt tiefer in die RDS einsteigen möchte, dem sei der Technet-Beitrag „Getting Started: Remote Desktop Services“ mit einer Schritt-für-Schritt-Anleitung empfohlen. Binnen eines Arbeitstages sollte man seine VDI-Umgebung in einem Testlabor aufgesetzt haben – und dann kann man mit dem Experimentieren beginnen.

John Savill/rhh