3
Windows Server Cluster 2008 R2 - Quorum Failed - Network Configuration
Hallo Zusammen,
folgende Konfiguration besteht in unserem Cluster:
2x Windows Server 2008 R2 Enterprise Edition SP1
Konfiguriert im Windows Failover Cluster - Node and Disk Majority (Quorum)
4x Gigabit-Ethernet Interfaces pro Server
- 2x im Team durch HP Network Configuration Utility im Switch-assisted Load Balancing with Fault Tolerance (SLB) (1 IP-Adresse)
-- Verbunden mit unserem sogenannten "Produktions-Netz" (physikalisch separates Netz Subnet 0.0 /23)
- 2x separate Interfaces (2 IP-Adressen)
-- Verbunden mit unserem sogenannten "MGMT-Netz" (physikalisch separates Netz Subnet 10.0 /24)
Cluster-Konfiguration
- Node-1 - Network: "MGMT - Heartbeat" - MGMT_2 IP-Adresse 10.95
- Node-1 - Network: "Prod" - Team_1 IP-Adresse: 0.91
- Node-2 - Network: "MGMT - Heartbeat" - MGMT_2 IP-Adresse 10.96
- Node-2 - Network: "Prod" - Team_1 IP-Adresse: 0.92
Wir haben heute Nacht bereits den 2ten Ausfall unseres SQL-Server-Clusters gehabt.
Nach Durchforstung aller uns bekannten Logs sieht es irgendwie nach einem Netzwerkfehler aus.
Wenn ich den eigenen „Validate This Cluster“-Check ausführe, dann bekomme ich folgende Meldung:
Adapters MGMT_2 and MGMT_1 on node SQL-1 have IP addresses on the same subnet.
Multiple adapters on node SQL-1 have addresses on the same subnet.
Adapters MGMT_2 and MGMT_1 on node SQL-2 have IP addresses on the same subnet.
Multiple adapters on node SQL-2 have addresses on the same subnet.
Kann dies zu einem Fehler führen?
Aus den Logs können wir sehen, dass Node-1 das Quorum gehalten hat.
Die erste Meldung war, dass Node-2 und Node-1 sich anscheinend nicht mehr erreichen konnten und sich gegenseitige aus dem Cluster geworfen haben.
Daraufhin wollte Node-2 eine Cluster-Gruppe von Node-1 hochfahren, obwohl diese noch aktiv im Node-1 war und das Quorum auch von Node-1 gehalten wurde.
Das versuchte er 3x und danach hat Node-1 alle Cluster-Gruppen ausgeschaltet und auch das Quorum war weg.
Wir können uns nicht erklären was da genau passiert ist und die Tatsache, dass auf beiden Servern jeweils 2 Interfaces im selben Subnet konfiguriert sind, ist nicht von der Hand zu weisen – könnte dies zu solchen Fehlern führen? Kann man nicht 2 Interfaces einem Cluster-Network hinzufügen?
Einem Netzwerkfehler auf den Switchen oder Kabeln, können wir erst nächste Woche nachgehen.
Der Fehler ist heute Nacht um 02:25 zum 2ten mal aufgetreten. Das letzte Mal beim Umzug auf die neuen Server am 29.06.2012 um 11:18.
Eine Parallele kann ich irgendwie nicht erkennen.
Vielleicht hat wer einen Wink in die richtige Richtung...
Vielen Dank!
mfg Sersch
folgende Konfiguration besteht in unserem Cluster:
2x Windows Server 2008 R2 Enterprise Edition SP1
Konfiguriert im Windows Failover Cluster - Node and Disk Majority (Quorum)
4x Gigabit-Ethernet Interfaces pro Server
- 2x im Team durch HP Network Configuration Utility im Switch-assisted Load Balancing with Fault Tolerance (SLB) (1 IP-Adresse)
-- Verbunden mit unserem sogenannten "Produktions-Netz" (physikalisch separates Netz Subnet 0.0 /23)
- 2x separate Interfaces (2 IP-Adressen)
-- Verbunden mit unserem sogenannten "MGMT-Netz" (physikalisch separates Netz Subnet 10.0 /24)
Cluster-Konfiguration
- Node-1 - Network: "MGMT - Heartbeat" - MGMT_2 IP-Adresse 10.95
- Node-1 - Network: "Prod" - Team_1 IP-Adresse: 0.91
- Node-2 - Network: "MGMT - Heartbeat" - MGMT_2 IP-Adresse 10.96
- Node-2 - Network: "Prod" - Team_1 IP-Adresse: 0.92
Wir haben heute Nacht bereits den 2ten Ausfall unseres SQL-Server-Clusters gehabt.
Nach Durchforstung aller uns bekannten Logs sieht es irgendwie nach einem Netzwerkfehler aus.
Wenn ich den eigenen „Validate This Cluster“-Check ausführe, dann bekomme ich folgende Meldung:
Adapters MGMT_2 and MGMT_1 on node SQL-1 have IP addresses on the same subnet.
Multiple adapters on node SQL-1 have addresses on the same subnet.
Adapters MGMT_2 and MGMT_1 on node SQL-2 have IP addresses on the same subnet.
Multiple adapters on node SQL-2 have addresses on the same subnet.
Kann dies zu einem Fehler führen?
Aus den Logs können wir sehen, dass Node-1 das Quorum gehalten hat.
Die erste Meldung war, dass Node-2 und Node-1 sich anscheinend nicht mehr erreichen konnten und sich gegenseitige aus dem Cluster geworfen haben.
Daraufhin wollte Node-2 eine Cluster-Gruppe von Node-1 hochfahren, obwohl diese noch aktiv im Node-1 war und das Quorum auch von Node-1 gehalten wurde.
Das versuchte er 3x und danach hat Node-1 alle Cluster-Gruppen ausgeschaltet und auch das Quorum war weg.
Wir können uns nicht erklären was da genau passiert ist und die Tatsache, dass auf beiden Servern jeweils 2 Interfaces im selben Subnet konfiguriert sind, ist nicht von der Hand zu weisen – könnte dies zu solchen Fehlern führen? Kann man nicht 2 Interfaces einem Cluster-Network hinzufügen?
Einem Netzwerkfehler auf den Switchen oder Kabeln, können wir erst nächste Woche nachgehen.
Der Fehler ist heute Nacht um 02:25 zum 2ten mal aufgetreten. Das letzte Mal beim Umzug auf die neuen Server am 29.06.2012 um 11:18.
Eine Parallele kann ich irgendwie nicht erkennen.
Vielleicht hat wer einen Wink in die richtige Richtung...
Vielen Dank!
mfg Sersch
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 187991
Url: https://administrator.de/contentid/187991
Printed on: April 16, 2024 at 22:04 o'clock
3 Comments
Latest comment
Hallo!
Kurze fragen:
Über welche Netzwerkschnittstelle baust du die Verbindung zum zentralen Speicher (z.B. iSCSI-SAN) auf?
Sind die Interfaces an getrennte Switche bzw. eigene VLANs angeschlossen, oder einfach alles an 1 Switch ohne trennung?
Bei der Fehlermeldung "Adapters MGMT_2 and MGMT_1 on node CPMS-SQL-1.intra.delkeskamp.de have IP addresses on the same subnet" sieht es so aus als ob 2 Adapter auf z.B. SQL1 ins gleiche Subnetz zeigen. <- das selbe natürlich auch beim SQL2
Als Beispiel:
Wir haben einen Hyper-V-Failovercluster laufen. Dort gibts pro Host 1xMGMT + 1xLivemigration + 1xCSV + 2xISCSI.
MGMT -> 10.0.0.0/24
Livemigration ->172.16.0.0/24
CSV->172.16.1.0/24
ISCSI1->192.168.1.0/24
ISCSI2->192.168.2.0/24
Grund für die Trennung ist, das der Server immer ganau weiß welches Netz er über welches Interface erreicht. Evtl kann es ja sein das 2 Interfaces das gleiche Subnetz bedienen aber gar nicht am selben Switch hängen...dann gehen zwangsläufig Pakete verlornen bzw. der Serve routet falsch durch
Schau doch noch einmal in den IP-Einstellungen nach und überprüfe ob wirklich jedes interface pro Host in einem separaten Subnetz ist. Evtl. kriegt der Server das Routing nicht richtig hin, da prinzipiell jedes Interface im richtigen Netz "hängt" aber (da du vielleicht das Switch durch VLANs aufgeteilt hast) phyisikalisch eben nicht...
Kurze fragen:
Über welche Netzwerkschnittstelle baust du die Verbindung zum zentralen Speicher (z.B. iSCSI-SAN) auf?
Sind die Interfaces an getrennte Switche bzw. eigene VLANs angeschlossen, oder einfach alles an 1 Switch ohne trennung?
Bei der Fehlermeldung "Adapters MGMT_2 and MGMT_1 on node CPMS-SQL-1.intra.delkeskamp.de have IP addresses on the same subnet" sieht es so aus als ob 2 Adapter auf z.B. SQL1 ins gleiche Subnetz zeigen. <- das selbe natürlich auch beim SQL2
Als Beispiel:
Wir haben einen Hyper-V-Failovercluster laufen. Dort gibts pro Host 1xMGMT + 1xLivemigration + 1xCSV + 2xISCSI.
MGMT -> 10.0.0.0/24
Livemigration ->172.16.0.0/24
CSV->172.16.1.0/24
ISCSI1->192.168.1.0/24
ISCSI2->192.168.2.0/24
Grund für die Trennung ist, das der Server immer ganau weiß welches Netz er über welches Interface erreicht. Evtl kann es ja sein das 2 Interfaces das gleiche Subnetz bedienen aber gar nicht am selben Switch hängen...dann gehen zwangsläufig Pakete verlornen bzw. der Serve routet falsch durch
Schau doch noch einmal in den IP-Einstellungen nach und überprüfe ob wirklich jedes interface pro Host in einem separaten Subnetz ist. Evtl. kriegt der Server das Routing nicht richtig hin, da prinzipiell jedes Interface im richtigen Netz "hängt" aber (da du vielleicht das Switch durch VLANs aufgeteilt hast) phyisikalisch eben nicht...
Hallo Philipp,
danke für deine Antwort!
Für das SAN haben wir ein separates Netz mit eigenen Controllern.
Die beiden Interfaces von Team_1 sind auf Switch #1 in unserem Produktionsnetz und die beiden Interfaces von MGMT_1 und MGMT_2 sind auf Switch #2 in unserem MGMT-Netz. Diese beiden Netze sind nur durch eine Firewall/Router verbunden.
Derzeit ist es tatsächlich so, dass MGMT_1 und MGMT_2 beide in ein Netz gehen ... ob es tatsächlich ein Switch ist, weiß ich nicht, aus der Verkabelungsaktion halte ich mich immer bewusst raus
Mir ist aber irgendwie nicht ganz klar, warum die beiden Interfaces nicht in das selbe Subnetz zeigen dürfen...
danke für deine Antwort!
Für das SAN haben wir ein separates Netz mit eigenen Controllern.
Die beiden Interfaces von Team_1 sind auf Switch #1 in unserem Produktionsnetz und die beiden Interfaces von MGMT_1 und MGMT_2 sind auf Switch #2 in unserem MGMT-Netz. Diese beiden Netze sind nur durch eine Firewall/Router verbunden.
Derzeit ist es tatsächlich so, dass MGMT_1 und MGMT_2 beide in ein Netz gehen ... ob es tatsächlich ein Switch ist, weiß ich nicht, aus der Verkabelungsaktion halte ich mich immer bewusst raus
Mir ist aber irgendwie nicht ganz klar, warum die beiden Interfaces nicht in das selbe Subnetz zeigen dürfen...
Wärst du so nett und könntest das mal skizzieren? Ich blick da irgendwie grad nicht durch
