10
MS Server 2k12R2 Failover-Cluster node-switch Problem
Hallo zusammen,
in meinem Szenario; Failover-Cluster mit zwei nodes, habe ich folgendes Problem:
Wenn ich die sekundäre Instanz abschalte ist mein Cluster-Knoten nicht mehr erreichbar.
Wieso das nicht klappt will einfach nicht in meinen Kopf, denn wenn ich die primäre Instanz abschalte wird sauber auf die sekundäre Instanz umgelenkt.
Das Szenario ist wie folgt aufgebaut:
DC01 (AD DS)
SQL01 (Primär)
SQL02 (Secondary)
W7 (für Client-Connections)
Angebunden sind die Server jeweils über zwei bonds in zwei verschiedenen Subnetzen.
Mein Test sah wie folgt aus:
- Tracert auf den Cluster-Knoten, dann abschalten von SQL01 -> Tracert läuft weiter, ich sehe auch im Failover-Cluster-Manager, dass die Instanz als "offline" gemeldet wird und SQL02 nun als Besitzerknoten eingetragen ist.
Danach wieder alles auf "Startzustand".
- Tracert auf den Cluster-Knoten, dann abschalten von SQL02 -> Tracert endet in Zeitüberschreitungen, im Failover-Cluster-Manager steht weiterhin SQL01 als Besitzerknoten doch die Verbindung zum Knoten kann nicht aufgebaut werden und das egal von welchem der oben genannten Server.
Fällt euch irgend etwas zu dem Thema ein? Ich bin mehr als ratlos!
LG,
meTzla
in meinem Szenario; Failover-Cluster mit zwei nodes, habe ich folgendes Problem:
Wenn ich die sekundäre Instanz abschalte ist mein Cluster-Knoten nicht mehr erreichbar.
Wieso das nicht klappt will einfach nicht in meinen Kopf, denn wenn ich die primäre Instanz abschalte wird sauber auf die sekundäre Instanz umgelenkt.
Das Szenario ist wie folgt aufgebaut:
DC01 (AD DS)
SQL01 (Primär)
SQL02 (Secondary)
W7 (für Client-Connections)
Angebunden sind die Server jeweils über zwei bonds in zwei verschiedenen Subnetzen.
Mein Test sah wie folgt aus:
- Tracert auf den Cluster-Knoten, dann abschalten von SQL01 -> Tracert läuft weiter, ich sehe auch im Failover-Cluster-Manager, dass die Instanz als "offline" gemeldet wird und SQL02 nun als Besitzerknoten eingetragen ist.
Danach wieder alles auf "Startzustand".
- Tracert auf den Cluster-Knoten, dann abschalten von SQL02 -> Tracert endet in Zeitüberschreitungen, im Failover-Cluster-Manager steht weiterhin SQL01 als Besitzerknoten doch die Verbindung zum Knoten kann nicht aufgebaut werden und das egal von welchem der oben genannten Server.
Fällt euch irgend etwas zu dem Thema ein? Ich bin mehr als ratlos!
LG,
meTzla
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: 261421
Url: https://administrator.de/contentid/261421
Ausgedruckt am: 23.11.2024 um 08:11 Uhr
10 Kommentare
Neuester Kommentar
Hi,
mach mal den selben Test, während von dem SQL01 ein Dauerping auf sein Gateway läuft. Ändert das was?
Wie sind die Server überhaupt verkabelt? Logisch wie physisch? Am selben Switch?
Netzwerkkonfiguration der beiden Kisten sind analog? (u.a. auch Protokollreihenfolge, FW-Konfiguration usw.)
Das Vershieben der Instanz zwischen den Knoten geht hin wie her problemlos? Die Clients können anschließend sofort wieder verbinden?
E.
mach mal den selben Test, während von dem SQL01 ein Dauerping auf sein Gateway läuft. Ändert das was?
Wie sind die Server überhaupt verkabelt? Logisch wie physisch? Am selben Switch?
Netzwerkkonfiguration der beiden Kisten sind analog? (u.a. auch Protokollreihenfolge, FW-Konfiguration usw.)
Das Vershieben der Instanz zwischen den Knoten geht hin wie her problemlos? Die Clients können anschließend sofort wieder verbinden?
E.
Guten Abend,
was ich nicht verstehe, die SQL-Server stehen einzeln gesehen in zwei verschiedene Subnetze. In welchen Netz befindet sich dann die virtuelle IP-Adresse des Clusters?
Gruß,
Dani
was ich nicht verstehe, die SQL-Server stehen einzeln gesehen in zwei verschiedene Subnetze. In welchen Netz befindet sich dann die virtuelle IP-Adresse des Clusters?
Gruß,
Dani
Zitat von @Dani:
Guten Abend,
was ich nicht verstehe, die SQL-Server stehen einzeln gesehen in zwei verschiedene Subnetze.
Kannst Du hellsehen oder woraus schlussfolgerst Du das?Guten Abend,
was ich nicht verstehe, die SQL-Server stehen einzeln gesehen in zwei verschiedene Subnetze.
E.
@emerkis
Irgendwie falsch gelesen...
Gruß,
Dani
Irgendwie falsch gelesen...
Angebunden sind die Server jeweils über zwei bonds in zwei verschiedenen Subnetzen.
Aber es könnte trotzdem daran liegen... Gruß,
Dani
Hey zusammen,
danke für eure Antworten.
Ich versuche die Fragen so gut wie möglich aufzuklären, wenn nicht hakt bitte nach
Cluster: 172.22.1.110/24 & 172.22.2.110/24
DC01: 172.22.1.100/24 & 172.22.2.100/24
SQL01: 172.22.1.101/24 & 172.22.2.101/24
W7: 172.22.1.102/24
SQL01: 172.22.1.103/24 & 172.22.2.103/24
Somit stehen alle Server, außer der W7 Kiste, in zwei Subnetzen. An Protokollreihenfolgen und der gleichen habe ich nichts verändert, somit sollten sie analog konfiguriert sein. Auf was genau zielst Du ab?
Die Server sind aktuell VM's in unserer Citrix Umgebung und daher am gleichen Switch verkabelt. Somit Testumgebung bevor wir dann final die Hardware besorgen.
Könnte es sein, dass ich keine Verbindung zum Subnetz 2 bekomme, wenn ich den SQL02 abschalte? Der Cluster somit über 2.110 erreichbar ist und mein Tracert weiterhin auf 1.110 läuft? Aber das ist doch der eigentliche Grund ein Failovercluster zu haben, oder? Dass das Cluster weiterhin erreichbar ist, auch wenn die Putzfrau mit dem Staubsauger ein Kabel trennt.
LG
danke für eure Antworten.
Ich versuche die Fragen so gut wie möglich aufzuklären, wenn nicht hakt bitte nach
Cluster: 172.22.1.110/24 & 172.22.2.110/24
DC01: 172.22.1.100/24 & 172.22.2.100/24
SQL01: 172.22.1.101/24 & 172.22.2.101/24
W7: 172.22.1.102/24
SQL01: 172.22.1.103/24 & 172.22.2.103/24
Somit stehen alle Server, außer der W7 Kiste, in zwei Subnetzen. An Protokollreihenfolgen und der gleichen habe ich nichts verändert, somit sollten sie analog konfiguriert sein. Auf was genau zielst Du ab?
Die Server sind aktuell VM's in unserer Citrix Umgebung und daher am gleichen Switch verkabelt. Somit Testumgebung bevor wir dann final die Hardware besorgen.
Könnte es sein, dass ich keine Verbindung zum Subnetz 2 bekomme, wenn ich den SQL02 abschalte? Der Cluster somit über 2.110 erreichbar ist und mein Tracert weiterhin auf 1.110 läuft? Aber das ist doch der eigentliche Grund ein Failovercluster zu haben, oder? Dass das Cluster weiterhin erreichbar ist, auch wenn die Putzfrau mit dem Staubsauger ein Kabel trennt.
LG
Hallo,
ich würde zuerst die Konfiguration in soweit abändern, dass die Server in einem Subnetz stehen. Denn Multi-Homed bei einem Domain Controller bringt einige Probleme mit sich. Bei SQL bin ich mir gerade nicht sicher, ob in einem Cluster supportet...
Gruß,
Dani
ich würde zuerst die Konfiguration in soweit abändern, dass die Server in einem Subnetz stehen. Denn Multi-Homed bei einem Domain Controller bringt einige Probleme mit sich. Bei SQL bin ich mir gerade nicht sicher, ob in einem Cluster supportet...
Gruß,
Dani
Du hast den SQL01 2x aufgeführt. Versehen?
Hast Du schon mal die SQL-Instanz explizit an die eine (oder beiden) IP-Adresse gebunden? Standardmäßig wird sie ja an 0.0.0.0 gebunden, also "alle" Adressen.
E.
Hast Du schon mal die SQL-Instanz explizit an die eine (oder beiden) IP-Adresse gebunden? Standardmäßig wird sie ja an 0.0.0.0 gebunden, also "alle" Adressen.
E.
Copy + Paste Fehler - sorry!
Ich kann über das SQL Management Studio, von der W7 Kiste aus, sowohl den Cluster als auch SQL01 und SQL02 ansprechen.
Ich kann über das SQL Management Studio, von der W7 Kiste aus, sowohl den Cluster als auch SQL01 und SQL02 ansprechen.
Vermutlich wird es einfacher sein nachzuvollziehen was passiert, wenn ich für jede Rolle einen eigenen Server aufsetze, oder?
Habe das Problem gelöst bekommen:
Zwei Instanzen sind eine zu wenig:
Entweder man hat 3 DB-Server oder 2 DB-Server + 1 Quorumlistener. Dann läuft das System reibungslos.
Zwei Instanzen sind eine zu wenig:
Entweder man hat 3 DB-Server oder 2 DB-Server + 1 Quorumlistener. Dann läuft das System reibungslos.
