Tags: RDS, Hochverfügbarkeit, Performance, Windows Server 2012 R2
Um ausreichende Ressourcen für hohe Anforderungen zu bereitzustellen, kann man mehrere RD Session Hosts zu Farmen (auch "Sammlungen" oder "Collections") zusammenfassen. Der RD Connection Broker ist in der Lage, neue Verbindungen gleichmäßig über die Terminal-Server einer Sammlung zu verteilen. Um eine Farm im RDP-Client direkt ansprechen zu können, bedarf es einer entsprechenden DNS-Konfiguration.
Seit Windows Server 2008 R2 ist der Connection Broker nicht nur für Sessions auf Terminal-Servern zuständig, sondern verwaltet auch die Verbindungen zu virtuellen Desktops. Für Sammlungen von Session Hosts übernimmt er zwei wesentlichen Funktionen: Zum einen verbindet er die Benutzer mit (schon existierenden) Session-basierten Desktops und RemoteApp-Programmen, zum anderen verteilt er die Last zwischen den Hosts. Bei Ausfall eines Servers kann er zudem die Benutzer automatisch auf einen anderen umleiten.
Connection Broker als Komponente eines Deployments
Während das Einrichten eines Connection Brokers und seine Zuordnung zu Sessions Hosts unter früheren Versionen von Windows Server relativ umständlich war, ist dieser Vorgang nun Teil der Szenario-basierten Installation der Remote Desktop Services. Legt man einen neue Bereitstellung (Deployment) an, dann wird neben der Rolle des Session Hosts auch die des Connection Brokers hinzugefügt.
Innerhalb eines Deployments muss man Session Hosts in Sammlungen aufnehmen, bevor sich Benutzer mit ihnen verbinden können. Eine solche Collection kann im einfachsten Fall aus bloß einem Server bestehen, aber normalerweise hat sie mehrere Mitglieder, zwischen denen der Connection Broker die Arbeitslast verteilt.
Gewichtung der Session Hosts
Dabei besteht die Möglichkeit, die einzelnen Session Hosts zu gewichten, um bestimmte Maschinen bei der Zuteilung von Verbindungen zu priorisieren. Die entsprechenden Einstellungen nimmt man in den Eigenschaften einer Sammlung unter den Menüpunkt Lastenausgleich vor.
Standardmäßig haben dort alle Terminal-Server eine relative Gewichtung von 100. Sie werden somit gleich stark beansprucht. Darüber hinaus kann man die Zahl der Sitzungen auf einen Maximalwert begrenzen.
Die Einrichtung eines Connections Brokers, die Gruppierung von Session Hosts in Sammlungen und die Konfiguration der relativen Gewichtung sind die wesentlichen Elemente für das Load-Balancing zwischen den Servern.
In einer solchen Konstellation kann man aber nicht direkt einen bestimmten Session Host ansprechen, weil sich der RDP-Client sonst über die Weiterleitung der Verbindung an einen anderen Terminal-Server beschwert.
DNS-Eintrag für eine Sammlung
Der letzte noch fehlende Schritt besteht somit darin, die Farm in den DNS-Server einzutragen. Zu diesem Zweck startet man das DNS-Plugin für die MMC (DNS Manager) und öffnet im linken Fenster den Zweig Forward-Lookupzonen. Aus dem Kontextmenü der gewünschten Domäne führt man den Befehl Neuer Host (A oder AAAA) aus.
Dort wählt man unter Name jenen der RDSH-Sammlung (er muss nicht mit jenem übereinstimmen, den man in der RDS-Konfiguration verwendet hat, es ist aber aus administrativer Sicht sinnvoll). Als IP-Adresse gibt man jene des ersten Session Hosts ein und wiederholt den Vorgang für alle weiteren Terminal-Server der Sammlung.
Im Ergebnis finden sich mehrere Einträge mit dem Namen der Sammlung im DNS, die jeweils eine IP-Adresse eines Session Hosts enthalten.
Session Hosts kontaktieren Broker
Diese Konfiguration führt zu einem Round-Robin-DNS, das Verbindungen abwechselnd zu den eingetragenen Hosts herstellt, wenn man im RDP-Client den Namen der Sammlung in das Feld Computer eingibt.
Der angesprochene Terminal-Server kontaktiert dann den Connection Broker, der die letzte Entscheidung darüber trifft, mit welcher bestehenden Session er einen Benutzer verbindet oder wo er eine neue Sitzung erzeugt.
Eine letzte Hürde für die Nutzung der Terminal-Server in einer Farm besteht nun darin, dass sich der RDP-Client bei der Verbindung mit der Collection über ein Zertifikatsproblem beschwert.
Die Ursache liegt in nicht übereinstimmenden Server-Namen, weil man den Server über den Namen der Farm anspricht, während das Zertifikat auf seinen eigenen ausgestellt ist. Daher muss man auf allen Session Hosts ein Zertifikat installieren, das auf die Sammlung ausgestellt ist.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- ThinPrint 12: Erweiterte Hochverfügbarkeit für Druck-Server, Health-Check für Spooler
- Windows 10 und Server 2016 verschlanken mit dem Citrix Optimizer
- Terminal-Server und virtuelle Desktops abspecken mit VMware OS Optimization Tool
- Hochverfügbarkeit beim Drucken mit ThinPrint 11
- Citrix-Alternative: Parallels veröffentlicht Remote Application Server v15
Weitere Links
1 Kommentar
Hallo, Danke für die gute Erklärung.
Ich hab aber noch eine Verständnisfrage:
Warum muss ich im DNS Eintrag alle Session-Hosts der Sammlung eintragen?
Reichen nicht nur die Broker?
Der über DNS angesprochene Session-Host fragt doch eh erst der Broker und leitet ggf. auf einen anderen Session-Host um.