Desktop-Virtualisierung mit Windows Server 2012: neue Funktionen

    RDS-Architektur in Windows Server 8Microsoft integrierte in Windows Server 2008 R2 eine rudimentäre Unterstützung für die Desktop-Virtualisierung, die einerseits kompliziert einzurichten war, sich andererseits aber nur für die einfachsten Anforderungen eignete. Windows Server 2012 erhält eine Reihe neuer VDI-Funktionen, die es erlauben, zumindest in kleineren Installationen ohne Produkte von Drittanbietern wie XenDesktop oder VMware View auszukommen.

    Microsofts Ambitionen bei der Desktop-Virtualisierung waren bisher sehr zurückhaltend. Die Lizenzpolitik für Windows-Clients, also primär die so genannte Windows Virtual Desktop Access (VDA), trug dem Hersteller sogar öfter den Vorwurf ein, VDI verhindern zu wollen.

    Microsoft VDI bisher mit wenig Management-Tools

    Die Implementierung von VDI-Funktionen im Server 2008 R2 setzte auf der Infrastruktur der Terminaldienste auf. Im Zuge dieser Erweiterung für Desktop-Virtualisierung wurden sie auf Remote Desktop Services umbenannt. Ihnen fehlten jedoch wesentliche Management-Funktionen für virtuelle Desktops, beispielsweise für die Verwaltung von Images oder das automatische Provisioning von VMs.

    Auch in Windows Server 2012 beruhen die Funktionen zur Einrichtung virtueller Desktops aus naheliegenden Gründen auf der gleichen technischen Basis wie die Terminaldienste. Das betrifft unter anderem den Einsatz des Remote Desktop Protocol für beide Arten des Server Based Computing, aber auch einen gemeinsamen Broker für Sessions und Desktops oder ein Gateway, das den sicheren Zugriff auf Desktops und zentrale Anwendungen erlaubt.

    Aus diesem Grund profitieren beide Formen von den Fortschritten der RDS-Basisfunktionen in Windows Server 2012. Dazu zählen besonders die Unter­stützung von RemoteFX für WANs oder der neue Remotedesktop-Client.

    Zentrale Verwaltung über Plugin für Server Manager

    Ein Manko der bisherigen Umsetzung des VDI-Features bestand darin, dass sein Management über mehrere Tools verstreut und nicht mit der Verwaltung von Remote Desktop Sessions Host integriert war. Hier wartet Windows Server 2012 mit einer grundlegenden Änderung auf, indem er den neuen Server Manager um ein Plugin für den Remote Desktop Management Service (RDMS) ergänzt. Beim RDMS handelt es sich um ein zentrales Verwaltungs-Tool für alle RDS-Rollen. Ein eigener Discovery-Prozess entdeckt sie auf allen Maschinen, die im Server Manager zu einem Rechner-Pool hinzugefügt werden.

    Voraussetzung für die zentrale Verwaltung einer RDS-Installation ist die Einrichtung eines Remote Desktop Management Servers, der seinerseits an die Rolle des RD Connection Broker gebunden ist. Diese ist im Unterschied zu Windows Server 2008 R2 nun erforderlich. Daher muss im neuen Installations-Wizard eine Maschine ausgewählt werden, der diese Funktion zukommen soll.

    Einfachere Installation mittels Wizard

    Die Installation wird generell durch Möglichkeiten des neuen Server Manager vereinfacht, weil dieser für die Remote-Verwaltung ausgelegt ist und zu diesem Zweck Rechner in Pools organisiert. Auf diese Weise lassen sich die benötigten RDS-Rollen zentral auf alle vorgesehen Maschinen installieren und diese bei Bedarf auch remote neu starten. Ein Quick Start Deployment beschleunigt die Einrichtung kleiner RDS-Umgebungen, indem sie sämtliche erforderliche Rollen auf einem Server installieren kann.

    Für die Installation von Terminaldiensten und virtuellen Desktops ist jetzt ein gemeinsamer Wizard zuständig.

    Collections für VDI und Terminal-Server

    Die Zusammenfassung zu Gruppen soll nun auch dabei helfen, virtuelle Desktops leichter zu verwalten. Dieses Konzept ist bei den Terminaldiensten nicht neu, dort ist es unter der Bezeichnung RD Session Host Farms bekannt. Ein VDI-Gegenstück fehlte bisher, Windows Server 2012 holt dies nach. Microsoft verwendet nun den Begriff der Sammlungen (Collections), die sowohl Session Hosts als auch Virtualization Hosts jeweils zu Management-Einheiten zusammenfassen. Die Einstellungen für alle Mitglieder einer Collection lassen sich zentral setzen.

    Vier Arten von Sammlungen für VDI

    Bei der Verwaltung einer VDI unterscheidet Windows Server 2012 mehrere Arten von Collections, die sich an den zwei grundlegenden Typen von virtuellen Desktops orientiert. Es handelt sich dabei um persistente Desktops, die Microsoft Personal Desktops nennt, und nicht-persistente, die synonym sind mit Pooled Desktops. Für beide Arten führt der Remote Desktop Services Manager eine zusätzliche Fallunterscheidung nach Managed und Unmanaged ein.

    Persönliche und Pooled Desktops werden in jeweils eigenen Collections zusammengefasst.

    Mit Managed Desktops ist nicht gemeint, dass die Gastbetriebsdysteme mit Hilfe von GPOs oder Management-Tools administriert werden. Vielmehr bezieht sich diese Unterscheidung darauf, ob man die neuen Funktionen des RDMS für das automatische Bereitstellen von Desktops in Anspruch nehmen möchte.

    Hinter der dafür zuständigen Option Virtuelle Desktops automatisch erstellen und verwalten verbergen sich wesentliche Verbesserungen wie das automatische Erzeugen bzw. Wiedererzeugen von virtuellen Desktops auf Basis von Templates, das Einspielen von Patches, lokales Caching der VM-Images oder das Einrichten einer User Profile Disk.

    Automatisches Provisioning von Desktops

    Während man persönliche virtuelle Desktops auf Basis von Templates (also von VHDs) erzeugen kann, entfällt dort die Notwendigkeit für das Wiedererstellen (Recreate). Das liegt einfach daran, dass persönliche Desktops persistent sind, also einem Benutzer fest zugeordnet und alle Änderungen aufbewahrt werden. Dagegen verwerfen pooled Desktops alle User-spezifischen Anpassungen und Daten, sie werden nach dem Neustart auf Basis des Templates wieder frisch erzeugt.

    Windows Server 2012 bringt insgesamt einige wichtige Neuerungen bei den Storage-Funktionen, die vor allem dazu beitragen sollen, virtualisierte Umgebungen ohne teures Shared Storage zu ermöglichen. Bei der Desktop-Virtualisierung spielen diese eine besondere Rolle, weil dort die Kosten für ein SAN als ein großes ökonomisches Hindernis gelten. Windows-Clients produzieren nicht nur große Mengen temporärer Daten und belasten damit den Netzspeicher, so dass dessen Performance leidet. Die führenden VDI-Anbieter Citrix und VMware bieten daher Funktionen für ein Tiered Storage, mit denen sich temporäre Daten auf lokale Platten verlagern lassen.

    Lokales Caching von VHDs bei Pooled Desktops

    Windows Server 2012 leistet nun dafür ebenfalls einen Beitrag, indem er eine Live Migration von VMs mit lokalem Caching unterstützt. Templates können daher auf einem Netzlaufwerk eines File-Servers abgelegt werden, und sobald auf dieser Basis ein virtueller Desktop erzeugt wird, überträgt eine Streaming-Funktion die zu dieser VM gehörende VHD auf ein lokales Laufwerk.

    User Profile Disk für individuelle Änderungen

    Das lokale Caching steht nur für Pooled Desktops zur Verfügung und nicht für persönliche. Zusätzlich werden diese gemeinsam genutzten virtuellen Clients gegenüber den persönlichen durch ein exklusives Feature namens User Profile Disk aufgewertet. Es handelt sich dabei um einen Mechanismus, der Änderungen durch die Benutzer nicht in der VM speichert, wo sie verloren gingen, sondern in einer User-spezifischen externen VHD.

    Bisher konnten solche Daten nur über Roaming Profiles und Ordnerumleitung beibehalten werden, die für VDI aber nur bedingt tauglich sind. Sie lassen sich künftig jedoch mit User Profile Disks kombinieren, um zu steuern, welche Daten dort landen sollen und welche auf einem File-Server.

    Persönliche Desktops als Auslaufmodell

    Die beiden Neuerungen führen dazu, dass die Notwendigkeit für speicherfressende und schwerer administrierbare persönliche Desktops entfällt. Mit Pooled Desktops lässt sich das VDI-Ideal weniger Master-Images als Basis für alle Desktops leichter umsetzen. Dieses Modell erleichtert beispielsweise das zentrale Einspielen von Patches. Allerdings steht dem das lokale Caching von Images entgegen, weil damit die VHDs dezentral vorgehalten werden.

    Patching für lokale VHDs

    Microsoft nutzt jedoch die Streaming-Funktion auch dafür, um Änderungen in Templates an die lokalen Instanzen zu übertragen. Unproblematisch ist das bei ungenutzten virtuellen Desktops, jedoch sperren sich jene gegen Updates, an denen ein User angemeldet ist. Der Administrator kann sich dabei mit einem Zeitplan helfen, der festlegt, bis wann Patches spätestens eingespielt sein müssen. Notfalls wird der Benutzer dann dazu gezwungen, sich am System abzumelden.

    Keine Kommentare