dante2191
Goto Top

Cluster-IP plötzlich nicht mehr erreichbar!!!

Hallo allerseits,

bin gerade am verzweifeln...

Hab ein Cluster aus 3 Windows Server 2008R2 Terminalservern auf einem VMWare ESX aufgesetzt.
Unsere Testuser melden sich unter der Cluster-IP .161 an.
Aus Auslastungsgründen ist momentan nur ein oder zwei Server hochgefahren.
Bisher hat auch alles super funktioniert und wir wollten die neuen Server demnächst in den Produktivbetrieb nehmen.

Nun ist heute ohne ersichtlichen Grund die IP .161 nicht mehr erreichbar und die User verlieren ihre RDP-Sitzungen.
Erst durch einen Neustart der Server ist diese IP wieder erreichbar.

Die Ereignisanzeige der Server zeigt mir auch nichts aufschlussreiches.

Wo kann ich mit der Fehlersuche weitermachen??

Bitte dringend um Hilfe

Content-Key: 268635

Url: https://administrator.de/contentid/268635

Ausgedruckt am: 28.03.2024 um 16:03 Uhr

Mitglied: killtec
killtec 09.04.2015 um 11:25:12 Uhr
Goto Top
Hi,
hast du dir denn schon mal die Clusterconfig angeschaut? GGf. die Neu aufbauen?

Gruß
Mitglied: falscher-sperrstatus
falscher-sperrstatus 09.04.2015 um 11:26:11 Uhr
Goto Top
Hallo,

wenn aus Performancegründen nur zwei von drei oben sind - wer sagt dir, dass die Performance dann noch genügt um diesen zu bedienen?

Grüße
Mitglied: SeaStorm
SeaStorm 09.04.2015 um 11:26:44 Uhr
Goto Top
sagt der ESX was dazu? Evtl. hat der ja ein Problem mit dem Netzwerk?
Sind noch andere Server auf dem ESX ? Die müssten dann ja das gleiche Problem haben.

Was ist die "ClusterIP" ? Ein Connectionbroker/NLB ? Evtl. ist nur da das Problem?
Ein bisschen mehr Infos zum Aufbau wären evtl. hilfreich
Mitglied: Dante2191
Dante2191 09.04.2015 aktualisiert um 12:10:15 Uhr
Goto Top
Auf dem ESX betreiben wir mehrere Server, hatten noch nie ein solches Problem.
Das Cluster ist folgendermaßen konfiguriert:

Server 1: 192.168.1.162
Server 2: 192.168.1.163
Server 3: 192.168.1.164
Cluster-IP: 192.168.1.161

Mit der Cluster-IP ist die IP gemeint, über welche das Cluster angesprochen werden muss, bevor man auf einen der 3 Server geschmissen wird.
Weiterhin hab ich den Verbindungsbroker auf unseren Fileserver installiert.

Könnte es vielleicht mit den VMWare-Tools o.ä. zusammenhängen?
Mitglied: SeaStorm
SeaStorm 09.04.2015 um 12:18:32 Uhr
Goto Top
OK also ist 161 ein Loadbalancer.
Sind zum Zeitpunkt des Ausfalls die IPS 162-164 auch nicht erreichbar?
Wenn nein, dann hat ja nur der Balancer das Problem und man kann davon ausgehen, das es kein allgemeines Netzwerkproblem ist, sondern irgendwie mit dieser einen Maschine zusammenhängt.
Was läuft denn auf dem 161?

Funktioniert es erst wieder, wenn du den Server mit 161 neu startest, oder wenn du die anderen neu startest ?

Kannst du während der Ausfälle von 161 aus ins Netzwerk pingen ?

Evtl. reserviert sich ein anderes Gerät die IP 161 ?
Mitglied: Dante2191
Dante2191 09.04.2015 um 12:32:04 Uhr
Goto Top
Die Server IP´s (162-164) sind erreichbar. Lediglich geht es um die 161.

Vielleicht sollte ich noch dazuschreiben, dass ich das Cluster nach folgender Anleitung installiert hab:
http://openbook.rheinwerk-verlag.de/windows_server_2008/windows_server_ ...

Unter der 161 läuft keine Maschine. So wie ich das verstanden wird auf der 161 lediglich gelauscht, dass die ankommenden RDP-Sessions verteilt werden können. Oder lieg ich da falsch?? Oo

Ich könnte mir vorstellen, dass es daran liegt, dass nicht alle Server hochgefahren sind. Die Server sind ja alle 3 in den NLB-Einstellungen hinterlegt. Vielleicht liegt da das Problem??
Mitglied: Dante2191
Dante2191 09.04.2015 um 12:35:31 Uhr
Goto Top
@certifiedit.net
Meinst du die Performance um den Cluster zu bedienen?
Momentan arbeiten nur 3 User auf dem Cluster, also kann ich mir nicht vorstellen, dass das so viel Ressourcen zieht, oder?

Gruß
Mitglied: Dani
Dani 10.04.2015 aktualisiert um 09:22:45 Uhr
Goto Top
Moin,
du nutzt also den NLB für den "Cluster"... ich kann dazu unter Server 2008(R2) leider nur negatives berichten. An deiner Stelle würde ich mir als Loadbalancer haproxy anschauen. Läuft unter Linux und sollte in 2-3 Stunden laufen. Du brauchst ja kein spezielles Setup. Mit Server 2012R2 sieht es besser aus, da geht es mit OnBoard-Mitteln.


Gruß,
Dani
Mitglied: Dante2191
Dante2191 10.04.2015 um 10:31:35 Uhr
Goto Top
Moin,

danke für die Info. Ich schaus mir mal an. Bin für alles was unter Linux läuft face-wink
Was für Probleme könnten denn noch beim Server 2008 auf mich zukommen?

Gruß
Mitglied: Dani
Lösung Dani 12.04.2015, aktualisiert am 15.04.2015 um 10:01:01 Uhr
Goto Top
Moin,
ansonsten ist die Rolle "Remote-Desktopverbindungsbroker" ebenfalls eine Alternative. Zwar kann haproxy auch Sessionbased-Verbindungen umgehen, ob er allerdings sauber bei RDP arbeitet, weiß ich leider nicht.

Was für Probleme könnten denn noch beim Server 2008 auf mich zukommen?
Bei uns war von heute auf morgen der Cluster im NLB wech... nicht einmal der Microsoft Support konnte sich einem Reim dadrauf machen.


Gruß,
Dani
Mitglied: Dante2191
Dante2191 13.04.2015 um 12:55:04 Uhr
Goto Top
Moin,

langsam bin ich am überlegen, ob ich das Thema Load-Balancing nicht ganz sausen lasse. Da wir 3 Standorte mit relativ gleicher Userzahl haben, was das Cluster e nur "Nice-to-have".

Nur noch eine Frage dazu:
Wenn ich nun erreichen will, dass sich bei Ausfall der IP .161 der Client direkt zum Server verbinden soll, reicht es dann wenn ich in der Konfiguration des Remoteserver-Sitzungshost unter "Für erneute Verbindungen zu verwendende IP-Adressen" die IP des Servers direkt eintrage und den Haken hier neben der .161 setze?

Danke schon mal face-smile
Mitglied: Dani
Dani 13.04.2015 um 13:02:12 Uhr
Goto Top
Moin,
langsam bin ich am überlegen, ob ich das Thema Load-Balancing nicht ganz sausen lasse. Da wir 3 Standorte mit relativ gleicher Userzahl haben, was das Cluster e nur "Nice-to-have".
Warum, ist doch kein Hexenwerk...


Gruß,
Dani
Mitglied: Dante2191
Dante2191 13.04.2015 um 13:56:21 Uhr
Goto Top
Ja bis jetzt hab ich mir das auch gedacht und was bisher auch recht zufrieden.
Aber nun ist mein Vertrauen zu Windows wieder ein wenig mehr verloren gegangen face-wink

Zu meiner letzten Frage: Könnte mir da auch jemand weiterhelfen?
Mitglied: Dani
Dani 13.04.2015 um 19:06:50 Uhr
Goto Top
Ja bis jetzt hab ich mir das auch gedacht und was bisher auch recht zufrieden. Aber nun ist mein Vertrauen zu Windows wieder ein wenig mehr verloren gegangen
Wasn los? Klappt es mit haproxy nicht wie gewünscht oder woher kommt die Depression? face-big-smile

Wenn ich nun erreichen will, dass sich bei Ausfall der IP .161 der Client direkt zum Server verbinden soll, reicht es dann wenn ich in der Konfiguration des Remoteserver-Sitzungshost unter "Für erneute Verbindungen zu verwendende IP-Adressen" die IP des Servers direkt eintrage und den Haken hier neben der .161 setze?
Gute Frage, probier's aus. Aber das ist nicht Sinn eines Clusters. Dann kannst du dir den Aufwand sparen.


Gruß,
Dani
Mitglied: Dante2191
Dante2191 14.04.2015 um 12:06:30 Uhr
Goto Top
Den HAProxy konfiguriere ich gerade. Hab momentan recht viel um die Ohren, deswegen könnte die ganze Geschichte mit Test noch ein wenig dauern face-wink
Ich melde mich auf jeden Fall noch mal wenn ich mehr weis.

Vorerst vielen Dank an euch alle face-smile
Mitglied: Dante2191
Dante2191 15.04.2015 aktualisiert um 10:00:45 Uhr
Goto Top
Guten Morgen,

hammer klasse Teil dieser HAProxy face-big-smile
Debian aufgesetzt, Grundkonfig drauf, haproxy installiert und die Konfig angepasst. Mehr war hier nicht zu machen, damit eine RDP-Verbindung aufgebaut werden kann.
Hatte nur noch ein kleines Problemchen über das ich mich noch hermachen musste:
Nach ca 10 Minuten ist in der Sitzung der Bildschirm schwarz und baut sich nach ca 1 sek wieder auf. Ist halt ziemlich nervig face-confused

Lösung: Ein falsch konfigurierter Timeout im Config-File

Viele Grüße und ein großes DANKESCHÖÖÖN!!!!
Mitglied: Dani
Dani 15.04.2015 um 17:45:42 Uhr
Goto Top
Moin,
freut mich zuhören... würdest du eine anonymisierte Konfiguration von haproxy für die Nachwelt posten?!


Gruß,
Dani
Mitglied: Dante2191
Dante2191 08.05.2015 um 10:37:10 Uhr
Goto Top
Grüß euch,
sorry hatte in letzter Zeit ein wenig zu viel um die Ohren face-wink

Die Lösung mit haproxy habe ich bisher keinesfalls bereut. Läuft bisher vollkommen stabil *thumbsup*

Hier mal meine Config:
Der Load-Ballancer bekommt die IP 192.168.1.5
Die drei Server die IPs 192.168.1.1 bis .3

global
log /dev/log	local0
log /dev/log	local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
	
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private

# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL).
ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL        
ssl-default-bind-options no-sslv3

defaults
log	global
mode	tcp
option	tcpka
option	tcplog
timeout connect 1h
timeout client  1h
timeout server  1h
	
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http	
errorfile 504 /etc/haproxy/errors/504.http

listen cattail 
192.168.1.5:3389

mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if RDP_COOKIE
persist rdp-cookie
balance leastconn
option tcpka
option tcplog

server Servername1 192.168.1.1:3389 weight 1 check inter 2000 rise 2 fall 3
server Servername2 192.168.1.2:3389 weight 1 check inter 2000 rise 2 fall 3
server Servername3 192.168.1.3:3389 weight 1 check inter 2000 rise 2 fall 3

option redispatch