4
Windows 2008 R2 Failover Cluster - Knoten nach Schwenk nicht erreichbar
Guten Tag,
ich habe einen Windows 2008 R2 Failover Cluster für SQL Server 2008 mit zwei Knoten konfiguriert. Alles soweit auch wunderbar. Auf einem Knoten habe ich nur folgendes Phänomen, allerdings nur auf dem einen Knoten:
1. Wenn ich auf der Knoten, der dieses Phänomen verursacht, aktiv ist und ich auf diesem per RDP angemeldet bin
2. und dann hier über die GUI auf den anderen Knoten schwenke
3. hängt sich meine RDP-Session auf - der Schwenk funktioniert aber
4. Ein sofortiger erneuter Verbindungsaufbau per RDP auf den nun passiven Knoten schlägt fehl.
5. Ebenso schlägt der sofortige Rückschwenk vom nun aktiven auf den neu passiven Knoten fehl (und zwar bei Online nehmen des virtuellen Hostnames für den Cluster).
6. Nach wenigen Minuten (in etwa) funktioniert der Schwenk wieder und auch die RDP-Session kann ich wieder aufbauen.
Zusammengefasst: Kurzzeitig scheint der neu passive Knoten seiner Public-Netzwerkverbindung zu verlieren. Ich gehe im Übrigen selbstverständlich über die "echten" Hostnames auf die Knoten und nicht über die virtuellen Hostnames. Dann wäre es ja klar, dass mir die RDP-Session kurz wegfliegt.
Kennt jemand dieses Phänomen? Kann sich das jemand erklären?
Vielen Dank im Voraus
Michael
ich habe einen Windows 2008 R2 Failover Cluster für SQL Server 2008 mit zwei Knoten konfiguriert. Alles soweit auch wunderbar. Auf einem Knoten habe ich nur folgendes Phänomen, allerdings nur auf dem einen Knoten:
1. Wenn ich auf der Knoten, der dieses Phänomen verursacht, aktiv ist und ich auf diesem per RDP angemeldet bin
2. und dann hier über die GUI auf den anderen Knoten schwenke
3. hängt sich meine RDP-Session auf - der Schwenk funktioniert aber
4. Ein sofortiger erneuter Verbindungsaufbau per RDP auf den nun passiven Knoten schlägt fehl.
5. Ebenso schlägt der sofortige Rückschwenk vom nun aktiven auf den neu passiven Knoten fehl (und zwar bei Online nehmen des virtuellen Hostnames für den Cluster).
6. Nach wenigen Minuten (in etwa) funktioniert der Schwenk wieder und auch die RDP-Session kann ich wieder aufbauen.
Zusammengefasst: Kurzzeitig scheint der neu passive Knoten seiner Public-Netzwerkverbindung zu verlieren. Ich gehe im Übrigen selbstverständlich über die "echten" Hostnames auf die Knoten und nicht über die virtuellen Hostnames. Dann wäre es ja klar, dass mir die RDP-Session kurz wegfliegt.
Kennt jemand dieses Phänomen? Kann sich das jemand erklären?
Vielen Dank im Voraus
Michael
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: 142158
Url: https://administrator.de/contentid/142158
Ausgedruckt am: 18.11.2024 um 09:11 Uhr
4 Kommentare
Neuester Kommentar
Also soweit ich das verstanden habe, was durch den Satzbau nicht ganz so einfach war, verbindest du dich via RDP mit dem aktivem Node, um diesen dann zu schwenken?
Sowas macht man auch nicht... Zumal ich den Sinn auch nicht verstehe hin und herzuschwenken, um dabei festzustellen, dass die RDP Verbindung abreisst. Steuer das mal von dem dritten Server aus.
Also auf Server A verbinden und im Clustermanager den Cluster von Server B auf C schwenken...
Zu dem Problem an sich: Während des Schwenkens werden Informationen und Daten zwischen den Knoten ausgetauscht, was eine zusätzliche Verbindung (deine RDP) stören kann..
An alle: korrigiert mich bitte, wenn ich was fachlich Falsches schreib =) Meine Angaben sind zwar nach bestem Wissen und Gewissen verfasst, bin aber ein noch junger Admin, der zumindest versucht zu helfen ;)
Grüße, Dennis
Sowas macht man auch nicht... Zumal ich den Sinn auch nicht verstehe hin und herzuschwenken, um dabei festzustellen, dass die RDP Verbindung abreisst. Steuer das mal von dem dritten Server aus.
Also auf Server A verbinden und im Clustermanager den Cluster von Server B auf C schwenken...
Zu dem Problem an sich: Während des Schwenkens werden Informationen und Daten zwischen den Knoten ausgetauscht, was eine zusätzliche Verbindung (deine RDP) stören kann..
An alle: korrigiert mich bitte, wenn ich was fachlich Falsches schreib =) Meine Angaben sind zwar nach bestem Wissen und Gewissen verfasst, bin aber ein noch junger Admin, der zumindest versucht zu helfen ;)
Grüße, Dennis
Du hast es richtig verstanden - außer dass wir keinen dritten Knoten haben. Ich gebe dir auch recht, dass man soetwas eigentlich auch nicht macht. WItzig ist nur, dass es funktioniert, wenn Knoten A aktiv ist, ich auf diesem eingeloggt bin und dann schwenke. Die Verbindung bleibt bestehen. Wenn ich dann auf Knoten B bin und dieser ja nun aktiv ist und dann schwenke, bricht mir die RDP-Sitzung ab. Das alleine wäre für mich nicht tragisch...
Er scheint aber kurzzeitig komplett den Connect zum Public-Netzwerk zu verlieren, denn wenn ich danach sofort von Knoten A wieder auf B zurückschwenken will, schlägt das fehl. Und zwar an dem Punkt, an dem der virtuelle Hostname im DNS registriert wird. Vermutlich, weil er - ohne Netzwerkverbindung ins Public-Netz - den DNS-Server nicht kontaktieren kann. Die Eventlog-Einträge deuten auch darauf hin. Diesen kurzzeitigen Verlust des Connects erlebe ich aber nur auf Knoten B. Das ist das Seltsame!
Nach wenigen Minute "fängt" sich Knoten B wieder von alleine und er ist wieder erreichbar und empfänglich für Schwenks
.
Er scheint aber kurzzeitig komplett den Connect zum Public-Netzwerk zu verlieren, denn wenn ich danach sofort von Knoten A wieder auf B zurückschwenken will, schlägt das fehl. Und zwar an dem Punkt, an dem der virtuelle Hostname im DNS registriert wird. Vermutlich, weil er - ohne Netzwerkverbindung ins Public-Netz - den DNS-Server nicht kontaktieren kann. Die Eventlog-Einträge deuten auch darauf hin. Diesen kurzzeitigen Verlust des Connects erlebe ich aber nur auf Knoten B. Das ist das Seltsame!
Nach wenigen Minute "fängt" sich Knoten B wieder von alleine und er ist wieder erreichbar und empfänglich für Schwenks
.
Mit einem Failover Cluster lässt dich die Ausfallzeit natürlich stark reduzieren, jedoch nicht vollständig absichern =)
Ich habe auch immer noch nicht den Sinn dahinter verstanden, sofort wieder zurückzuschwenken =)
Wie hast du den Knoten denn aufgebaut? Ich hoffe doch mit drei Netzwerkverbindungen oder?
1x -> Server 2 (Heartbeat)
1x -> Shared Storage
1x -> Switch
Ich habe auch immer noch nicht den Sinn dahinter verstanden, sofort wieder zurückzuschwenken =)
Wie hast du den Knoten denn aufgebaut? Ich hoffe doch mit drei Netzwerkverbindungen oder?
1x -> Server 2 (Heartbeat)
1x -> Shared Storage
1x -> Switch
Den Sinn gibt es nicht, sofort wieder zurückzuschwenken, aber wir sind gerade in Restore-Tests und da versucht man soetwas schon mal und stellt fest, dass es nicht sofort, aber nach 2-3 Minuten funktioniert.
Der Server hat drei Netzwerkverbindungen, allerding keine zum Shared Storage. Das ist SAN bzw. in unserem Testfall VMware Shared Storage. Das dritte Interface ist ein dediziertes Backup-LAN.
Um mich zu wiederholen: Mich wundert ja nur, dass ich diesen Verbindungsabbruch und kurzzeitigen "Ausfall" des Knoten nur auf dem einen Knoten B bemerke. Vom Knoten A kann ich hin- und herschwenken, wie ich lustig bin.
Der Server hat drei Netzwerkverbindungen, allerding keine zum Shared Storage. Das ist SAN bzw. in unserem Testfall VMware Shared Storage. Das dritte Interface ist ein dediziertes Backup-LAN.
Um mich zu wiederholen: Mich wundert ja nur, dass ich diesen Verbindungsabbruch und kurzzeitigen "Ausfall" des Knoten nur auf dem einen Knoten B bemerke. Vom Knoten A kann ich hin- und herschwenken, wie ich lustig bin.
