Virtuelle Desktops mit Horizon View und RDSH-Farmen bereitstellen

Seit Horizon 6 lassen sich mit View virtuelle Desktops auch über RDSH-Farmen bereitstellen. Die Konfiguration erfolgt in wenigen Schritten.

Durch VMware Horizon 6.0 mit View hat sich die Art, wie IT-Abteilungen RDSH-Desktops (Remote Desktop Session Host) nutzen können, signifikant verändert.

Eine der neuen Fähigkeiten ist die RDSH-Farm, die sich deutlich vom Desktop-Pool unterscheidet, den Mitarbeiter für den Zugriff auf ihre virtuellen Desktops nutzen. Eine RDSH-Farm aufzusetzen und von dort aus einen Desktop auszuliefern ist dabei vergleichsweise einfach.

Mit View-Versionen vor Horizon 6.0 konnten IT-Abteilungen einen Pool an Terminal Services erzeugen und darin mehrere RDSH-Server aggregieren. Dies ermöglichte die Auslieferung von Desktops an eine bestimmte Nutzergruppe. Jeder RDSH-Server hostet mehrere Benutzer-Desktops, wodurch der Terminal-Services-Pool zu jeder Zeit mit wechselnden Desktop-Zuweisungen arbeitet.

In den älteren Versionen von View stand RDSH aufgrund der fehlenden PCoIP-Unterstützung noch eher in der zweiten Reihe. Ab Horizon 6.0 können aber jetzt auch RDSH-Desktops VMwares PCoIP-Protokoll verwenden.

Bereitstellung einer RDSH-Farm mit Horizon 6

Eine RDSH-Farm ist ein View-Konstrukt, mit dem IT-Abteilungen mehrere identische RDSH-Server gruppieren und diese wie einen Ressourcen-Pool für laufende Desktops und Anwendungen behandeln können.

Die RDSH-Server im Pool sollten dabei identische Konfigurationen und Builds der virtuellen Maschine aufweisen, damit sie austauschbar sind. Der einfachste Weg, sie identisch zu halten, ist die Verwendung derselben VM-Vorlage für das Deployment aller RDSH-Server und erst später bei Bedarf dann die Anpassung der Gast-Betriebssysteme.

Der View-Agent sollte in dieser Vorlage allerdings nicht enthalten sein. Idealer wäre es, wenn ein Trigger-Mechanismus auf dem Gast-Betriebssystem eingerichtet wird, der den Agent zur Neuregistrierung beim Verbindungs-Server auffordert. Dabei muss in jedem Fall die Vorlage ihren VM-Namen beibehalten, damit die Registrierung beim Verbindungs-Server Erfolg hat.

Eine Möglichkeit hierzu besteht darin, einen RunOnce-Wert einzurichten, der den Agent im Hintergrund startet. Das könnte dann beispielsweise so aussehen:

VMware-viewagent-y.y.y-xxxxxx.exe /s /v"/qn VDM_VC_MANAGED_AGENT=0 VDM_SERVER_NAME=MyView.lab.local"

Der Platzhalter VDM_SERVER_NAME muss dabei durch den tatsächlichen Namen des Verbindungs-Servers ersetzt und die automatische Anmeldung an der VM aktiviert werden. Anschließend kann entweder ein Domänen-Konto mit dem Recht genutzt werden, View einen Agent hinzuzufügen, oder aber über die Kommandozeile werden für die Agent-Installation Benutzername und Kennwort eingegeben.

Sind die RDSH-Server schließlich erstellt, kann die Farm in View angelegt werden. Unter Identification and Settings können einige der Eigenschaften festgelegt werden, die auf einen Desktop-Pool üblicherweise zutreffen. Die Werte für Access group und einige Anzeige-Protokolleinstellungen werden auf sämtliche Pools dieser Farm angewendet.

Einstellungen der RDSH-Farm

Eine weniger bekannte Gruppe von Eigenschaften beschäftigt sich mit Timeouts. Dies betrifft vor allem die Eigenschaften im Zusammenhang mit Anwendungs-Pools, in denen Nutzer Anwendungen vom View-Client statt von einem vollständigen Desktop aus abrufen.

Die vom Nutzer gestarteten Anwendungen teilen sich eine gemeinsame Sitzung auf einem RDSH-Server. Dadurch werden nachfolgende Anwendungsstarts beschleunigt, etwa ein Anmeldeskript. Die Abarbeitung des Benutzerprofils und des Gruppenrichtlinienobjekte treten nur beim Start der ersten Anwendung auf.

Timeouts legen fest, wann eine Sitzung automatisch abgemeldet wird. Eine Sitzung befindet sich im Leerlauf, wenn der Nutzer sämtliche von ihm geöffneten Anwendungen wieder geschlossen hat. Startet der Nutzer bei noch laufender Sitzung eine Anwendung neu, so muss nur die neue Anwendung geöffnet werden.

Ein Benutzerprofil wird dennoch erst entladen, wenn die Sitzung abgemeldet wird. Der Host nimmt bis zum Schließen der Sitzung nur wenige Ressourcen in Anspruch. Hat sich der Nutzer aus der vorherigen Sitzung abgemeldet, so müssen für den Start einer neuen Anwendung vom View-Client aus Anmeldeskript, Profil und Gruppenrichtlinienobjekt erneut abgearbeitet werden.

Je höher die Werte für Empty session timeout und Log off disconnected sessions sind, was eine entsprechend längere Zeitdauer der Sitzung bedeutet, desto wahrscheinlicher ist es, dass der Nutzer neue Anwendungen schnell laden kann. Bei kürzeren Zeitwerten wird dafür die Last auf dem RDSH verringert, außerdem geht das sichere Entladen von Profilen schneller vonstatten. Die optimalen Werte hierfür sind dabei immer abhängig von der jeweiligen Umgebung. Es kann durchaus vorkommen, dass Administratoren diese Einstellungen auch später noch optimieren, nachdem die Nutzer sich an den Umgang mit RDSH-Anwendungs-Pools gewöhnt haben.

Sind die Timeout-Werte einmal festgelegt, müssen aus der Liste der mit den Verbindungs-Servern registrierten Hosts noch die gewünschten ausgewählt werden. Jeder Host kann aber höchstens einer Farm angehören.

RDSH-Desktops veröffentlichen

Das Einrichten von RDSH-Desktop-Pools funktioniert nicht anders, als das Einrichten beliebiger anderer Desktop-Pools: Zunächst muss RDS Desktop Pool als Typ des Desktop-Pools ausgewählt werden.

Auswahl von RDS Desktop Pool

Da die RDSH-Hosts bereits verteilt sind und die Remote-Displays über die RDSH-Farm steuern können, hat der Pool selbst vergleichsweise wenige Einstellungsmöglichkeiten. Administratoren können aber beispielsweise die Bandbreite und die Nutzung auf vorgegebene Verbindungs-Server einschränken. Nach dem Einrichten des Pools kann schließlich den Nutzern der Zugang dazu gewährt werden.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!

Erfahren Sie mehr über Serverbetriebssysteme

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close