5
Merkwürdiger Failover im im 2-Node-Cluster mit Node and Disk Majority
Guten Abend liebe Leute,
erstmal Hallo, habe mich soeben angemeldet und hoffe ihr könnt mir helfen. Stehe irgenwie auf dem Schlauch...
Bitte verzeiht wenn der Text auf Grund der Länge ein wenig erschlägt.
Vorab zu meiner HW-konfig:
2 Nodes, Cluster01 und Cluster02 mit jeweils,
1 NIC für das Public-Netz (192.168.0.0/24)
1 NIC für das Heartbeat (10.10.1.0/24)
2 NIC's für iSCSI "geteamt" als Network-Failover_Tolerance und mit MS iSCSI-Initiator auf's Target verbunden. (10.10.5.0/24)
Mein SAN ist redundant und besteht aus 3 Nodes über die sich die Daten spiegeln, nach außen hin erreicht man das SAN über eine VIP (10.10.5.100). Jede NODE aus dem SAN hat auch wieder 2 NIC's für das iSCSI-Netz, welche geteamt sind.
Angebunden wird das ganze über 2 Switche, nennen wir die mal Switch 1 und Switch 2.
Ich vermute den Fehler in der iSCSI-Ecke, also beschreibe ich mal die Anbindung:
Cluster01 geht mit einem Kabel auf Switch1 und mit einem Kabel auf Switch2, die NIC's sind wie gesagt "geteamt". Gleiches gilt für Cluster02.
Storage-Node01 geht auch mit einem Kabel auf Switch1 und mit dem anderen auf Switch2, auch hier ist ein Teaming über beide NIC's. Wenn also Switch1 ausfällt, geht alles über Switch2. Storage-Node02 und 03 sind genauso angebunden.
Clustervalidierung läuft fehlerfrei durch und der Cluster wurde erstellt. Installiert ist testweiße ein Filecluster, das scih problemlos schwenken lässt. Wenn ich aber einem Node das ges. Storage wegnehme (also einen ausfall simuliere) dann wird manchmal das Quorum nicht wieder Online geschaltet.
Sieht jemand von euch den Fehler, oder ist das Verhalten in einem 2-Node-Cluster normal? Ist mein erster Cluster, kenne mich daher nicht so mit dem Verhalten eines Clusters im Fehlerfall aus. Evtl. liegt ja auch hier der Hund begraben
Vielen lieben Dank,
Waldo
2 Nodes, Cluster01 und Cluster02 mit jeweils,
1 NIC für das Public-Netz (192.168.0.0/24)
1 NIC für das Heartbeat (10.10.1.0/24)
2 NIC's für iSCSI "geteamt" als Network-Failover_Tolerance und mit MS iSCSI-Initiator auf's Target verbunden. (10.10.5.0/24)
Mein SAN ist redundant und besteht aus 3 Nodes über die sich die Daten spiegeln, nach außen hin erreicht man das SAN über eine VIP (10.10.5.100). Jede NODE aus dem SAN hat auch wieder 2 NIC's für das iSCSI-Netz, welche geteamt sind.
Angebunden wird das ganze über 2 Switche, nennen wir die mal Switch 1 und Switch 2.
Ich vermute den Fehler in der iSCSI-Ecke, also beschreibe ich mal die Anbindung:
Cluster01 geht mit einem Kabel auf Switch1 und mit einem Kabel auf Switch2, die NIC's sind wie gesagt "geteamt". Gleiches gilt für Cluster02.
Storage-Node01 geht auch mit einem Kabel auf Switch1 und mit dem anderen auf Switch2, auch hier ist ein Teaming über beide NIC's. Wenn also Switch1 ausfällt, geht alles über Switch2. Storage-Node02 und 03 sind genauso angebunden.
Clustervalidierung läuft fehlerfrei durch und der Cluster wurde erstellt. Installiert ist testweiße ein Filecluster, das scih problemlos schwenken lässt. Wenn ich aber einem Node das ges. Storage wegnehme (also einen ausfall simuliere) dann wird manchmal das Quorum nicht wieder Online geschaltet.
Sieht jemand von euch den Fehler, oder ist das Verhalten in einem 2-Node-Cluster normal? Ist mein erster Cluster, kenne mich daher nicht so mit dem Verhalten eines Clusters im Fehlerfall aus. Evtl. liegt ja auch hier der Hund begraben
Vielen lieben Dank,
Waldo
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: 182692
Url: https://administrator.de/contentid/182692
Printed on: April 19, 2024 at 15:04 o'clock
5 Comments
Latest comment
Moin,
was für Switches setzt um im SAN-Netzwerk ein?
Sprich Switch1 mit 10.10.5.0/24 und Switch2 als 10.10.6.0/24. Das Teaming macht nur Sinn wenn es der Switch auch unterstützt. Ansonsten kannst du es vergessen!
Grüße,
Dani
was für Switches setzt um im SAN-Netzwerk ein?
Cluster01 geht mit einem Kabel auf Switch1 und mit einem Kabel auf Switch2
Aha...und das Ganze mit dem selben IP-Bereich. Das ist schon mal Mist! Du musst das beides als seperates Netzwerk ansehen.Sprich Switch1 mit 10.10.5.0/24 und Switch2 als 10.10.6.0/24. Das Teaming macht nur Sinn wenn es der Switch auch unterstützt. Ansonsten kannst du es vergessen!
Grüße,
Dani
Hi,
Das sind HP Procurve. Wieso 2 getrennte Netze? Die NIC's haben doch nur eine IP nach dem Teaming...Die HP Software zum Teamen macht doch aus 2 NIC's eine virtuelle.
Waldo
Das sind HP Procurve. Wieso 2 getrennte Netze? Die NIC's haben doch nur eine IP nach dem Teaming...Die HP Software zum Teamen macht doch aus 2 NIC's eine virtuelle.
Waldo
Das sind HP Procurve. Wieso 2 getrennte Netze? Die NIC's haben doch nur eine IP nach dem Teaming...Die HP Software zum Teamen macht doch aus 2 NIC's eine virtuelle.
Das bringt dir nur etwas, wenn die beiden Netzwerkkarten auf dem selben Switch terminieren und dort auch als Team konfiguriert sind. Alles andere macht nur Probleme! Wiki
Im Beispiel eben nur ein Storage.. aber es sieht bei mehreren gleich aus.
Glaube ich verstehe in etwa was du meinst, aber wieso kann ich problemlos ein Kabel abziehen ohne das die Verbindung zum SAN zusammenbricht? Das dürfte ja nicht gehen sonst...wie ist denn das verhalten eines Clusters wenn ein Node das Storage verliert?
Waldo
Waldo
Moin,
mach doch bitte eine Visiozeichung wie die GEräte im Moment verbunden, wer welche IP-Adresse hat und welches Kabel zu gezogen hast.
Grüße,
Dani
mach doch bitte eine Visiozeichung wie die GEräte im Moment verbunden, wer welche IP-Adresse hat und welches Kabel zu gezogen hast.
Grüße,
Dani
