W2012 R2 RDS Cluster hängt sich auf

[edocom 10]

Hallo Leute

 

Ich habe folgende Struktur aufgebaut:

 

Server1

Windows 2012 R2 RDS Host

LAN1_mgmt: 192.168.1.10 GW: 192.168.1.254 DNS: 192.168.1.1

LAN2_nlb: 192.168.2.10 GW: 192.168.2.254 DNS: Kein

 

Server2

Windows 2012 R2 RDS Host

LAN1_mgmt: 192.168.1.11 GW: 192.168.1.254 DNS: 192.168.1.1

LAN2_nlb: 192.168.1.11 GW: 192.168.2.254 DNS: Kein

 

Server3

Windows 2012 R2 Session Broker / Lizenz

LAN1: 192.168.1.12 GW: 192.168.1.254 DNS: 192.168.1.1

 

Dann habe ich einen NLB Cluster Multicast nach Standard erstellt, keine Änderungen vorgenommen!

Multicast Adresse 192.168.1.9

 

Das ganze auf VMWare 5.5 (keine speziellen Einstellungen)

 

Netzwerk:

3 Com Switch mit Trunk Ports auf die ESX Server.

 

Auf den Switch folgende Befehle ausgeführt:

 

undo arp check enable

arp static 192.168.1.9 xxxx-xxxx-xxxx

mac-address multicast xxxx-xxxx-xxxx Interface gig1/1 Interface gig2/1 vlan 1

 

Dann passiert folgendes:

 

1. Der Cluster funktioniert im Normal Fall für ca. 24h, und dann ist die Cluster IP 192.168.1.9 nicht mehr erreichbar! Auch nicht von den Switch aus!

2. Die einzelnen NLB IPs sind erreichbar.

3. Nach einem reboot, funktioniert alles wieder für ca. 24 h!

 

Kenn jemand das Problem oder hat einen ähnliche Konstelation, oder habe ich vielleicht einen Fehler gemacht? 

 

Danke...!

 

[Dunkelmann 96]

Moin,

 

warum nutzt Du noch NLB unter Server 2012R2? Nebenbei hat Multicast NLB auch so seine Tücken (Unicast IP und Multicast MAC Adresse gefällt nicht jedem Switch)

Seit Server 2012 laufen die Verbindungen zentral auf dem Broker auf und werden von dort auf die Hosts in der Sitzungssammlung verteilt. Es soll sich i.d.R. kein Client mehr direkt mit den Hosts verbinden.

 

Schau Dir mal den TLG an:

http://blogs.technet.com/b/tlgs/archive/2012/08/10/spotlight-on-the-new-remote-desktop-services-in-windows-server-2012-tlg-stack.aspx

[edocom 10]

Hallo, NLB nutze ich aus Lastgründen, so werden die Leute zwischen den zwei Hostservern verteilt.

Das mit dem Broker stimmt so nicht! Du kannst nicht einfach die IP des Broker anwählen und dich dann mit Usernamen/PW von Benutzernanmelden.

Das geht vielleicht wenn du diese vereinfachte Installation von RDS Verwendest aber nicht in in einer prof. Lösung. :)

Und der Client verbindet sich ja nicht direkt mit dem Host, er wählt ja die NLB Cluster IP!

 

Übrigens habe ich eine solche Umgebung auf W2008 R2 Unicast auf einer VM Ware 4.1 bereits am laufen.

 

Ich vermute auch, dass hier das Problem Unicast/Multicast auf den Switchen ist :(

Aber sowohl MS wie auch VM empfehlen Multicast!

[Dunkelmann 96]

Hallo, NLB nutze ich aus Lastgründen, so werden die Leute zwischen den zwei Hostservern verteilt.

Das mit dem Broker stimmt so nicht! Du kannst nicht einfach die IP des Broker anwählen und dich dann mit Usernamen/PW von Benutzernanmelden.

Das geht vielleicht wenn du diese vereinfachte Installation von RDS Verwendest aber nicht in in einer prof. Lösung. :)

Und der Client verbindet sich ja nicht direkt mit dem Host, er wählt ja die NLB Cluster IP!

 

Übrigens habe ich eine solche Umgebung auf W2008 R2 Unicast auf einer VM Ware 4.1 bereits am laufen.

 

Ich vermute auch, dass hier das Problem Unicast/Multicast auf den Switchen ist :(

Aber sowohl MS wie auch VM empfehlen Multicast!

Unter 2008R2 war ein Setup mit NLB und ggf. Dedicated Redirector üblich.

Seit 2012 ist ein Setup mit Broker und Sitzungssammlungen der bevorzugte Weg. Besonders für große Umgebungen mit separatem SQL Backend und Broker im Cluster ist das Model dem 2008R2 Ansatz überlegen.

 

Falls Du Zweifel hast, baue einfach mal eine 2008R2 Umgebung und eine 2012R2 Umgebung nach und verfolge die Kommunikation mit dem Netzwerkmonitor oder Wireshark.

[edocom 10]

Irgendwie kann ich dir nicht folgen.

Ich habe ja eine Umgebung 2012 R2 mit Broker und einer Sammlung.

Aber wenn du kein NLB machst mit einer virtuellen NLB IP, wie willst du dich an der Sammlung anmelden?

Ich hab hier ein Buch von MS und da steht es Schritt für Schritt, also ich weiss nicht wie du das meinst, hast du eine RDS Farm?

[Dunkelmann 96]

Bei RDS wird mittlerweile auch eine BYOD-Architektur von Microsoft präferiert - egal ob man es mag oder nicht.

 

Die verfügbaren Ressourcen werden als Feed vom WebAccess Server bereitgestellt und können von den Benutzern aboniert werden. Sie erscheinen dann unter Windows 8 als Kachel oder bei Windows 7 unter 'RemoteApp und Desktopverbindungen' im Startmenü.

Im Dialog des Remotedesktop Clients sind die sammlungsspezifischen Optionen nicht verfügbar. Sie stehen aber in den rdp Dateien.

 

Möchte man einen eher klassischen Ansatz fahren, kann man

- dem Broker eine default Farm mitgeben, mit der sich die Clients verbinden sollen sofern nicht anderes angegeben wird.

- die RDP Dateien extrahieren und z.b. per GPP an die Anwender verteilen und sich so den Weg über das Abo sparen

[edocom 10]

Aha, jetzt nochmal:

 

Ich baue eine RDS Farm auf welche die User per RDP zugreifen! Keine Remote App oder ähnliches! Ich glaube wir sind am Thema vorbei, ich schaue mich mal im Netzwerk Teil um.

 

Danke...