18
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 268635
Url: https://administrator.de/forum/cluster-ip-ploetzlich-nicht-mehr-erreichbar-268635.html
Ausgedruckt am: 12.01.2025 um 15:01 Uhr
18 Kommentare
Neuester Kommentar
Hi,
hast du dir denn schon mal die Clusterconfig angeschaut? GGf. die Neu aufbauen?
Gruß
hast du dir denn schon mal die Clusterconfig angeschaut? GGf. die Neu aufbauen?
Gruß
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
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
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
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
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?
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?
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 ?
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 ?
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??
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??
@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ß
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ß
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
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
Moin,
danke für die Info. Ich schaus mir mal an. Bin für alles was unter Linux läuft
Was für Probleme könnten denn noch beim Server 2008 auf mich zukommen?
Gruß
danke für die Info. Ich schaus mir mal an. Bin für alles was unter Linux läuft
Was für Probleme könnten denn noch beim Server 2008 auf mich zukommen?
Gruß
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.
Gruß,
Dani
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
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
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
Moin,
Gruß,
Dani
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
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
Zu meiner letzten Frage: Könnte mir da auch jemand weiterhelfen?
Aber nun ist mein Vertrauen zu Windows wieder ein wenig mehr verloren gegangen
Zu meiner letzten Frage: Könnte mir da auch jemand weiterhelfen?
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? 
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
Den HAProxy konfiguriere ich gerade. Hab momentan recht viel um die Ohren, deswegen könnte die ganze Geschichte mit Test noch ein wenig dauern
Ich melde mich auf jeden Fall noch mal wenn ich mehr weis.
Vorerst vielen Dank an euch alle
Ich melde mich auf jeden Fall noch mal wenn ich mehr weis.
Vorerst vielen Dank an euch alle
Guten Morgen,
hammer klasse Teil dieser HAProxy
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
Lösung: Ein falsch konfigurierter Timeout im Config-File
Viele Grüße und ein großes DANKESCHÖÖÖN!!!!
hammer klasse Teil dieser HAProxy
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
Lösung: Ein falsch konfigurierter Timeout im Config-File
Viele Grüße und ein großes DANKESCHÖÖÖN!!!!
Moin,
freut mich zuhören... würdest du eine anonymisierte Konfiguration von haproxy für die Nachwelt posten?!
Gruß,
Dani
freut mich zuhören... würdest du eine anonymisierte Konfiguration von haproxy für die Nachwelt posten?!
Gruß,
Dani
Grüß euch,
sorry hatte in letzter Zeit ein wenig zu viel um die Ohren
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
sorry hatte in letzter Zeit ein wenig zu viel um die Ohren
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
