Terminalserver-Farm (Lastenausgleich)

Hallo Jungs,

dieser Artikel ist für mich ehr als Gedankenstütze für den einfachen Aufbau einer Terminalserver-Farm über Lastenausgleich.

Welche Szenarien für Terminal-Farmen beschreibt Microsoft?
Lastenausgleich per DNS-Round Robin, hierbei werden nur die IP’s der RDS/Terminalserver vom DNS-Server pro Anfrage gemischt zurückgegeben.
Daher nennt Microsoft dies auch nur als einfache Lösung zum Lastenausgleich aber nicht zum realen Farm-Betrieb in dem ein Server ausfallen kann.

Lastenausgleich per Dienst, hierbei werden alle Server über den Dienst einer gemeinsamen, zusätzlichen IP zugeordnet. Beispiel: Heinz, Paul und Peter heißen nun auch Vlad.
Die Farm-Ordnung wird über den RDS-/Terminal-Broker realisiert, der eine Sitzungsdatenbank bereitstellt um sicherzustellen, dass der Client immer an seine offene Sitzung zum richtigen Terminalserver verbunden wird.

Ich denk mal, dass fast es zusammen…

Terminalserver-Farm (Lastenausgleich)

Begriffserklärung:
  • RDS = Remote Desktop Services (Terminaldienste seit 2008R2)
  • DNS = Dynamic Name System/Server
  • Heinz, Paul, Peter, Vlad = Vornamen
  • Broker = Transaktionsdienstleister, Dienst mit Sitzungsdatenbank für RDS
  • DC = Domänen-Controller (Verzeichnisdienst-Server)
  • Active Directory = (Microsofts Verzeichnisdienst)
  • NLB = Network Load Balancer/Netzwerk-Lastenausgleich
  • IP = Internet Protokoll, ggf. auch Internet Protokoll Adresse
Vorbereitung:
Für die Umsetzung einer Terminalserver-Farm sind mindestens 4 Server-Installationen notwendig, diese schlüsseln sich wie folgt auf:
  • Terminalserver A
  • Terminalserver B
  • Sitzungsbroker
  • Domänen-Controller
Bei einer Farm der Hochverfügbarkeit sollte der Sitzungsbroker definitiv getrennt zum Domänen-Controller installiert werden, Grund hierfür ist der Netzwerklastenausgleich-Dienst – Domänen-Controller synchronisieren sich und können daher nicht als eine Einheit abgebildet werden.

Ablauf der Einrichtung:

1. Vorbereitung des Brokers

Abbildung 1: Rolle des Broker hinzufügen
Machen wir es uns mal nicht zu schwer, Server-Manager/Rollen/Rolle hinzufügen…

Ab Windows Server 2012 werden wahrscheinlich dank Metro sogar die RDS in der Core-Version installiert.

Abbildung 2:  Hauptrolle Remotedesktopdienste
Der Sitzungsbroker ist ein Teil des Themenparks RDS.

Bitte wählen Sie Remotedesktopdienste aus und gehen Sie weiter zum nächsten Fenster.

Abbildung 3: Rollendienst Remotedienste-Verbindungsbroker 
Die sogenannte Subrolle kommt während der Hauptrolle aber nicht ohne Vorrolle…ich könnt mich rollen.

Bitte nicht auf Domänen-Controllern installieren falls Sie vorhaben den Netzwerk-Lastenausgleich-Dienst zu installieren. (dies wird meist aus Gründen der Redundanz/Ausfallsicherheit auch auf Brokern getätigt)

Abbildung 4: Features kontrollieren
Wieder den Server-Manager öffnen und im Bereich Features kontrollieren, dass Abbildung 5 der Fall ist.

„Thats not a Bug, thats a feature.“

Abbildung 5: Netzwerk-Lastenausgleich-Manager
Mit diesem wird später der Lastenausgleich auf den Terminalservern konfiguriert, selbst sollte der Netzwerk-Lastenausgleich nicht auf dem Server installiert sein – wenn er nicht auch redundant ausgelegt werden soll.
Tipp:
Zwecks Reihenfolge würde ich den Netzwerk-Lastenausgleich erst später installieren, die meisten Server stellen die RDP-Kommunikation umgehend nach Aktivierung ein.

2. Installation Netzwerk-Lastenausgleich Terminalserver

Abbildung 6: Überprüfung der installierten Rollen auf dem RDS-Host
Hier zur Überprüfung im Server-Manager die einzig installierte Rolle sollte der RDS/Terminalserver selbst sein.

Abbildung 7: Installation des Netzwerk-Lastenausgleichs
Unter den Features des Server kann nun der Netzwerk-Lastenausgleich ausgewählt werden.

Der Manager muss auf dem Terminalserver nicht installiert werden,
findet sich aber für Administratoren die auf dem Terminalserver arbeiten unter den Verwaltungstools…

Abbildung 8: Wahl des Interfaces
Man gehe nun zu den Netzwerk-Adaptern des Servers und öffne die Eigenschaften des Adapters auf dem der Server per Netzwerk-Lastenausgleich erreichbar sein soll.

Tipp:
Ggf. bietet es sich an einen weiteren Netzwerk-Adapter zu haben, über den bei Problemen Zugriff über RDP auf den Server ermöglicht wird. (auf diesem sollte der NLB dann nicht aktiviert werden)

Abbildung 9: Aktivierung des Dienstes NLB
Unter den nun Verfügbaren Protokollen/Diensten des Adapters tauch neu der NLB auf. (dieser ist nicht als Protokoll/Dienst über Netzwerk-Adapter installierbar)

Bitte für das entsprechende Interface zur Konfiguration in der Farm auswählen.

Zwecks Leistungsoptimierung sollten nicht alle für den Terminalserver überflüssigen Dienste & Protokolle aktiviert sein.

Aber nicht vergessen, der Datei- & Druckerfreigabe-Dienst ist notwendig wenn Sie auf Systemfreigaben wollen oder der Terminalserver Drucker direkt frei gibt.

Der RDS/Terminaldienst läuft in jedem Falle weiter und wird über die Firewall gesteuert. (ohne Konfiguration des NLB läuft dieser aber kurzzeitig ins Leere)

Abbildung 10: Prüfung nach NLB-Konfiguration
Unter den IP-Einstellungen des Terminalservers sollten spätestens wenn im Netzwerk-Lastenausgleichs-Manager die Farm mit der gemeinsamen IP konfiguriert wurde zwei Adressen stehen.
Die „192.168.33.90“ ist in diesem Beispiel die IP der Farm, die „192.168.33.20“ ist die private IP des Servers an die die spätere RDP-Sitzung umgeleitet wird.

3. Hinzufügen der Terminalserver zu der Farm

Abbildung 11: Terminaldienstekonfiguration
Guck mal was man da so findet, möchten Sie den Server einem Verbindungsbroker hinzufügen?
Nee, lass mal.

Doch, siehe Abbildung 12.
Ach und bitte die Abbildungen 11-13 für jeden Terminalserver der Farm durchführen…

Abbildung 12: Terminalverbinungsbroker
Hier wird der Server (Broker) angegeben, der die Sitzungs-Datenbank bereitstellt.

Außerdem wird hier auch die Gewichtung des Servers angegeben, ich würde Schritte in Form von 10 verwenden. (Abschätzend nach den Ressourcen der Maschine)

Hier sieht man auch die per Lastenausgleich definierten IP-Adressen des Servers.
(die Konfiguration beginnt erst ab Abbildung 14)

Abbildung 13: Art des Farm-Beitritts
Auch relativ unkompliziert stellt sich der Beitritt des Servers in der Farm da.
Ohne weitere Szenarien beschreiben zu wollen: Farm-Mitglied ist die richtige Wahl für unsere kleine Farm.
Der Farm-Name muss bei jedem Server der gleiche sein, sonst ordnet der Broker die Server verschiedenen Sitzungs-Datenbanken zu.

Abbildung 14: Netzwerklastenausgleich-Manager 
Zur Konfiguration unserer Terminalserver nutzen wir nun den durch den Broker installierten Manager.

Den schlanken Namen ggf. im Suchfeld eingeben, falls er noch nicht unter den häufigeren Programmen auftauchen sollte.

Abbildung 15: Anlegen eines neuen Cluster
Das sind diese Dinger, die wenn sie explodieren weitere Dinger wegschleudern…oops falsches Thema.

Abbildung 16: Hinzufügen des ersten RDS/Terminalserver
Bitte die erste Maske nicht als Namen für den Cluster verstehen, der Netzwerklastenausgleich-Manager möchte den ersten Hot wissen. (kein Listenfeld)

Abbildung 17: Priorität festlegen
Hier wird das erste Mal aus dem Manager sichtbar, dass der Terminalserver eine eigene IP benötigt um die späteren Sitzungen auf sich abzubilden.

Abbildung 18: Globale IP des Cluster
Nun kann endlich festgelegt werden unter welchen IP-Adressen der Server antwortet.

In den meisten Fällen gehe ich von einem Client-Netzwerk aus und würde daher auch nur eine IP vergeben.

Abbildung 19: Verifizierung der primären IP des Cluster
Hier kann noch einmal die primäre IP des Cluster überprüft werden, dass wichtigere Feld ist dennoch der FQDN des Clusters.

Über diesen wird dieser identifiziert, falls man den Manager einmal schließen sollte.

Falls das DNS genau diesen Namen auch noch hostet: nicht schlecht!

Abbildung 20: Verbindungseinstellungen des Hosts
Hier wird noch einmal festgelegt wie der Host antwortet, der Standard geht soweit in Ordnung.

Diese Einstellungen werden pro Server der Farm festgelegt.

Abbildung 21: Weitere Hosts hinzufügen
Wenn man sich die Mühe macht, dann sollte schon ein weiterer Server hinzugefügt werden…

Alleine macht die Lastenverteilung auch irgendwie wenig Spaß…

Abbildung 22: Finale
Und so sollte sich der Manager präsentieren wenn alles richtig konfiguriert wurde.

Als Test würde ich empfehlen jeden Host an zu pingen, sollte einer der Terminalserver nicht antworten bitte noch einmal die IP-Einstellungen prüfen. (siehe Abbildung 10)

Per „mstsc“ – Remotedesktopverbindungs-Client kann wenn jeder Terminalserver auf das Ping antwortet ein Test gestartet werden.

4. Ablauf der Kommunikation Terminalserver-Farm

Abbildung 23: Ablauf der Kommunikation Terminalserver-Farm
Die Abbildung bezieht sich auf ein lokales Netzwerk, daher wurde der Weg über das Terminal-Gateway ausgespart. (dieses würde als Client auftreten)
Sollten Endgeräte über ein VPN angebunden werden reicht es also diesen auf irgend einem Wege per DNS die IP der Farm zu übergeben.

Ich empfehle hierbei DNS, da so einfacher Anpassungen an den Verbindungen vorgenommen werden können, also wenn die IP festgeschrieben werden würde.
(Beispiel: NAT)