Clustern des RD Connection Brokers 8. Januar 2012

Wenn die Anzahl der Terminalserverbenutzer in einem Netzwerk eine bestimmte Größe erreicht, macht es Sinn, über eine Terminalserverfarm nachzudenken. Dadurch kann man die Remote Desktop Session Hosts zum Einen hochverfügbar gestalten und zum Anderen auch eine Lastverteilung erreichen. Allerdings steht man dann sofort vor neuen Herausforderungen. Wenn die Terminalserversitzung eines Benutzers z.B. durch den Verlust der Internetverbindung getrennt wird, dann soll der Benutzer bei einem erneuten Verbindungsversuch mit seiner alten Sitzung verbunden werden.

Durch die Farm könnte es aber theoretisch passieren, dass ein Benutzer nicht mit dem Terminalserver verbunden wird, mit dem er ursprünglich verbunden war. Um das zu vermeiden, muss man einen Remote Desktop Session Broker einsetzen. Der Session Broker verfügt über eine Datenbank (tsesdir.edb), in der alle Benutzersitzungen innerhalb der Farm registriert sind. Wenn ein Benutzer eine Verbindung mit der Farm herzustellen versucht, dann fragt der Terminalserver, mit dem die initiale Verbindung hergestellt wird, den Session Broker ab. Der Session Broker gleicht anhand des Benutzernamens ab, ob der Benutzer auf einem Terminalserver der Farm bereits eine bestehende Sitzung hat. Wenn das der Fall ist, dann wird die Verbindungsanforderung des Benutzers an den entsprechenden Terminalserver in der Farm umgeleitet.  Wenn der Session Broker ausfällt, dann funktioniert dieser Mechanismus nicht mehr und es könnte vorkommen, dass Benutzer, die sich zu ihrer getrennten Sitzung wieder verbinden wollen, einfach eine neue Sitzung auf einem völlig anderen Terminalserver innerhalb der Farm bekommen. Deshalb könnte man das Clustern des Session Broker Dienstes in Betracht ziehen. Das Clustern dieses Dienstes war bis Windows Server 2008 nicht möglich bzw. wurde durch Microsoft nicht supported. Ab Windows Server 2008 R2 kann man diesen Dienst innerhalb eines Windows Failoverclusters als Anwendung ausführen, der die notwendige Redundanz für diesen wichtigen Dienst zur Verfügung stellen kann.

Um das Clustern des Remote Desktop Session Brokers zu demonstrieren, habe ich eine kleine Testumgebung aufgebaut. Diese besteht aus den folgenden Rechnern:

  1. Ein Domänencontroller DC1 (Windows Server 2008 R2 Enterprise)
  2. Zwei Clusterknoten (CLU1 und CLU2) (Windows Server 2008 R2 Enterprise)
  3. Zwei Terminalservern (TSNLB1 und TSNLB2) (Windows Server 2008 R2 Enterprise)

Aufbau der Testumgebung

 

 

 

 

 

 

 

 

Der Failovercluster verfügt über keine gesharten Datenträger. Diese sind für das Clustern des Remote Desktop Session Brokers auch nicht notwendig. Jeder der beiden Clusterknoten verfügt über seine eigene “tsesdir.edb”. Als Quorummodell habe ich in diesem Fall “Node and File Share Majority” ausgewählt. Nach dem der Cluster konfiguriert ist, kann man sich an die Installation des Remote Desktop Session Brokers auf den beiden Clusterknoten durchführen.

 

 

 

 

 

 

 

 

 

Nach der erfolgreichen Installation des Session Brokers, kann man diesen als Anwendung über die Failover Clusterverwaltung installieren.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nachdem die Installation durchgeführt wurde, müssen beide Terminalserver in die lokale Benutzergruppe “Sitzungsbrokercomputer” auf BEIDEN Clusterknoten hinzugefügt werden.

 

 

 

 

 

 

 

 

 

Jetzt geht es an die Konfiguration der beiden Terminalserver. Der Lastenausgleich für die beiden Terminalserver wird über DNS Round Robin realisiert. Für die Terminalserverfarm gibt es einen A-Eintrag “tsfarm.spielwiese.intern”, der auf die IP Adressen 192.168.2.30 und 192.168.2.31 zeigt. Der FQDN “tsfarm.spielwiese.intern” wird von den Clients genutzt, um sich mit der Terminalserverfarm zu verbinden.

 

 

 

 

 

 

 

 

Zusätzlich müssen auf BEIDEN Terminalservern noch die Einstellungen für die Farm bzw. für den Session Broker konfiguriert werden. Wenn es sich um mehr als zwei Terminalserver handelt, dann könnte man diese Einstellungen auch über eine Gruppenrichtlinie konfigurieren.

  • Farmname: tsfarm
  • Remotedesktop-Verbindungsbroker: rdcp.spielwiese.intern
  • Priorität: 100 (dadurch werden die Clients auf beide Remote Desktop Session Hosts verteilt)

 

 

 

 

 

 

 

Wenn diese Einstellungen vorgenommen wurden, werden die Clientsitzungen ab sofort auf die beiden Terminalserver gleichmäßig verteilt. Wenn ein Benutzer seine Sitzung trennt und sich anschließend wieder verbindet, dann wird der Benutzer wieder automatisch mit seiner getrennten Sitzung verbunden.

Was passiert nun, wenn der Cluster einen Failover durchführt und dadurch der Remote Desktop Session Broker auf dem anderen Knoten ausgeführt wird? Wenn das geschieht, dann verfügt der Clusterknoten, der die Rolle des Remote Desktop Session Brokers jetzt ausführt, über keine Informationen zu den einzelnen Sitzungen auf Remote Desktop Session Hosts. Der aktuelle Remote Desktop Session Broker kontaktiert die einzelnen Server in der Farm und liest deren Sitzungsliste ein. Dadurch verfügt er über eine aktuelle Liste der Sitzungen und kann seine Arbeit aufnehmen. Dieser Vorgang dauert zwei bis drei Minuten. Während dieser Zeit kann es passieren, das getrennte Sitzungen nicht mehr korrekt verbunden werden und Benutzer, die sich wieder verbinden wollen, einfach eine neue Sitzung innerhalb der Farm bekommen. Den Ablauf der Kommunikation zwischen dem Remote Desktop Session Broker und dem Remote Desktop Session Host kann man in diesem Netzwerktrace schön sehen:

Failover des Clusters

 

 

 

 

 

 

 

 

Der Server “tsnlb1.spielwiese.intern (192.168.2.30)” versucht den Remote Desktop Connection Broker “rdcb.spielwiese.intern (192.168.2.40) zu erreichen und stellt fest, dass die TCP Sitzung nicht mehr existiert. Er versucht jetzt mehrmals einen TCP-Retransmit.

 

 

 

 

 

 

Da diese Versuche erfolglos sind, schickt der Server “tsnlb1.spielwiese.intern (192.168.2.30)” einen TCP Reset (Frame 75) und versucht dann einen erneuten TCP Threeway Handshake der von dem Server “rdcp.spielwiese.intern (192.168.2.40)” auch beantwortet wird (Frame 76 – 78).

 

 

 

 

 

 

 

 

Nachdem die TCP Sitzung eingerichtet wurde, beginnt die eigentlich RPC Kommunikation zwischen dem Remote Deskop Session Host und dem Connection Broker (Frame 79 – 111) . Ab dem Frame 115 werden zwischen den beiden Peers nur noch TCP KeepAlive Pakete ausgetauscht. Das lässt darauf schließen, dass die Kommunikation beendet ist und alle Daten zwischen den beiden Servern ausgetauscht wurden.

 

 

 

 

 

 

 

 

 

Wenn man sich den Netzwerktrace etwas genauer ansieht, dann stellt man fest, dass es in meiner Testumgebung etwa zwei Minuten gedauert hat, bis nach dem eingeleiteten Failover die Sitzungsdatenbank des Remote Desktop Connection Brokers aktualisiert war. Dieser Umstand ist eigentlich nicht weiter dramatisch, da bestehende Remote Desktop Sitzungen natürlich weiter bestehen bleiben. Wenn natürlich in diesem Zeitraum ein Benutzer sich mit seiner bestehenden Remote Desktop Sitzung innerhalb der Farm verbinden möchte, dann schlägt das fehl und er bekommt eine neue Sitzung auf einem beliebigen Terminalserver eingerichtet. Nach den zwei Minuten sollte alles wieder wie gewohnt ablaufen.

 

2 Comments
Marco Januar 9th, 2012

Hi!

Super Blogeintrag. Auf deiner Zeichnung ist eine andere IP für den TSBRCLU als in der DNS Konsole.

Frank Röder Januar 10th, 2012

Uups, da hat sich der Fehlerteufel eingeschlichen…..

Leave a Reply

*