Hi zusammen,
Hat hier schon jemand einen Absturz eines Systems im Zusammenhang mit 7.1.1. Update 4 erlebt?
Zum Hintergrund: Wir haben bereits seit drei Jahren ein HA-Cluster aus RS3617RPxs in Betrieb. Erfahrung damit ist also vorhanden. ;-) Vor einem Monat haben wir nun auf SA3400 aktualisiert.
Auf den Systemen ist iSCSI aktiv. Diverse LUNs werden über ein Target mit zwei Cluster IPs physikalisch redundant mit zwei E10G21-F2 Karten an eine VMware vSphere Umgebung angebunden. Das das alles kein Spielplatz mehr ist, sondern Business mit richtig vielen VMs und Usern dahinter muss ich sicher nicht weiter erläutern.
Ich habe letzte Woche Freitag dieses SA3400 HA-Cluster, auf 7.1.1-42962 Update 4 aktualisiert. Zuvor war es Update 1. Das Cluster läuft also nun seit etwa 1 Monat und bisher war nur Node 0 aktiv und Node 1 passiv.
Nach dem Update war dann Node 1 aktiv und Node 0 passiv. Die Rollen wurden also getauscht.
Ich benutze seit jeher das schnelle Update, bei dem die Rollen einfach getauscht werden und hatte zuvor keine Probleme.
Normalerweise alles kein Thema, bei einer Übergabe laufen alle VMs weiter, die LUNs bleiben erhalten. Man bemerkt den Schwenk nicht.
Natürlich mache ich so etwas aber nur im Falle eines Updates und dann auch nur zu Zeiten, in denen nicht gearbeitet wird.
Und auch dieses mal lief alles einwandfrei. Zumindest für 3 Tage. Probleme hätten mir am Freitag direkt auffallen sollen.
Gestern
Aus mir unbekanntem Grund wurde gestern Mittag dann plötzlich ein Failover ausgelöst.
Node 0 konnte Node 1 nicht mehr erreichen und hat daher übernommen.
Nun aber das Katastrophale: Node 0 konnte keine der Cluster IPs übernehmen!
Es ist ja unmöglich, dass ausgerechnet ALLE IPs des Clusters, zudem aus verschiedenen Netzwerksegmenten, anderweitig hätten vergeben sein sollen, OHNE dass dies jemandem aufgefallen wäre ...
Das Einzige, was also möglich wäre: die IPs sind nicht vom Node 1 freigegeben worden, sodass Node 0 sie nicht übernehmen konnte.
Wie man am Screenshot sehen kann, war es mir aber möglich, mich auf dem Node 0 anzumelden um eben das zu sehen, was hier gezeigt wird. Node 1 hingegen war nicht mehr erreichbar. Hat man sich über den Cluster-UNC-Namen angemeldet ist man auch bei Node 0 raus gekommen.
Hardware stand und regierte nicht
Nachdem das passierte sind natürlich alle LUNs über die iSCSI LAN Adressen nicht mehr für vSphere zugreifbar gewesen und alle VMDKs waren nicht mehr erreichbar und abgestürzt. Die meisten VMs mögen es halt nicht, wenn man ihnen im laufenden Betrieb die Festplatten unterm Hintern wegreißt. :-(
Ich bin dann in unser RZ gedüst und habe festgestellt, dass auf dem Node 1 keinerlei HDD-Aktivität mehr zu sehen war. Normalerweise blinken die LEDs ja fröhlich auf beiden Nodes. Auf Node 0 war HDD-Aktivität zu sehen.
Meine Überlegung dazu: Node 1 muss abgestürzt sein, aber die Cluster-IPs hängen noch fest.
Also habe ich den Power-Taster an Node 1 für 4 Sekunden festgehalten. Die blaue LED hat auch angefangen zu blinken, aber nach weiteren 5 Minuten warten ist nichts passiert. Keine Regung, kein Zucken, keine HDD LED blinkt.
Also habe ich den Taster dann so lange festgehalten, bis das System ausgeschaltet war. Nach ca. 30 Sekunden habe ich es dann wieder gestartet.
Node 0 hatte nun wieder Zugriff auf die Cluster IPs, die LUNs konnten per iSCSI Target wieder an die vSphere Umgebung geleitet werden. Die VMs waren natürlich alle gecrasht und entsprechend musste noch eingegriffen werden, inkl Restore zweier VMs, die das nicht überlebt haben.
Nachdem Node 1 wieder online war hat sich auch das Cluster von selbst hergestellt und mit der Replizierung über den Heartbeat angefangen.
Viel unschöner hätte es kaum kommen können. Selbstredend habe ich debug Logs gezogen und diese an den Support gesandt. Das Problem wird da auch bearbeitet. Dennoch schadet es ja nicht hier mal nach zu haken.
Überlegung iSCSI Target Verbindung
Nun habe ich die iSCSI Verbindung über zwei Cluster Adressen an meine vSphere Umgebung angebunden. Dadurch, dass die Cluster IPs nicht erreichbar waren, war auch das Target nicht mehr erreichbar.
Wie wir wissen, sind die Host-IPs der aktiven Hardware erreichbar! Das bedeutet, theoretisch sollten die Host-NICs erreichbar sein, auch wenn die Cluster IP es nicht ist.
Ich überlege mir also, ob es sinnvoll ist, die Host-NICs, die für iSCSI zuständig sind, ebenfalls in der vSphere Umgebung einzurichten. Und nicht nur die virtuellen Cluster IPs. Eine Mehrwegverbindung ist für vSphere kein Problem und man kann auch priorisieren.
Sollte das nochmal passieren, wären zumindest die LUNs nicht weg, wenn ein Host auf den anderen übernommen hat und die Cluster IPs hängen wieder ...
Spräche was dagegen?
Danke fürs Lesen und Berichten, ob hier jemand ähnliches Erlebt hat.
Hat hier schon jemand einen Absturz eines Systems im Zusammenhang mit 7.1.1. Update 4 erlebt?
Zum Hintergrund: Wir haben bereits seit drei Jahren ein HA-Cluster aus RS3617RPxs in Betrieb. Erfahrung damit ist also vorhanden. ;-) Vor einem Monat haben wir nun auf SA3400 aktualisiert.
Auf den Systemen ist iSCSI aktiv. Diverse LUNs werden über ein Target mit zwei Cluster IPs physikalisch redundant mit zwei E10G21-F2 Karten an eine VMware vSphere Umgebung angebunden. Das das alles kein Spielplatz mehr ist, sondern Business mit richtig vielen VMs und Usern dahinter muss ich sicher nicht weiter erläutern.
Ich habe letzte Woche Freitag dieses SA3400 HA-Cluster, auf 7.1.1-42962 Update 4 aktualisiert. Zuvor war es Update 1. Das Cluster läuft also nun seit etwa 1 Monat und bisher war nur Node 0 aktiv und Node 1 passiv.
Nach dem Update war dann Node 1 aktiv und Node 0 passiv. Die Rollen wurden also getauscht.
Ich benutze seit jeher das schnelle Update, bei dem die Rollen einfach getauscht werden und hatte zuvor keine Probleme.
Normalerweise alles kein Thema, bei einer Übergabe laufen alle VMs weiter, die LUNs bleiben erhalten. Man bemerkt den Schwenk nicht.
Natürlich mache ich so etwas aber nur im Falle eines Updates und dann auch nur zu Zeiten, in denen nicht gearbeitet wird.
Und auch dieses mal lief alles einwandfrei. Zumindest für 3 Tage. Probleme hätten mir am Freitag direkt auffallen sollen.
Gestern
Aus mir unbekanntem Grund wurde gestern Mittag dann plötzlich ein Failover ausgelöst.
Node 0 konnte Node 1 nicht mehr erreichen und hat daher übernommen.
Nun aber das Katastrophale: Node 0 konnte keine der Cluster IPs übernehmen!
Es ist ja unmöglich, dass ausgerechnet ALLE IPs des Clusters, zudem aus verschiedenen Netzwerksegmenten, anderweitig hätten vergeben sein sollen, OHNE dass dies jemandem aufgefallen wäre ...
Das Einzige, was also möglich wäre: die IPs sind nicht vom Node 1 freigegeben worden, sodass Node 0 sie nicht übernehmen konnte.
Wie man am Screenshot sehen kann, war es mir aber möglich, mich auf dem Node 0 anzumelden um eben das zu sehen, was hier gezeigt wird. Node 1 hingegen war nicht mehr erreichbar. Hat man sich über den Cluster-UNC-Namen angemeldet ist man auch bei Node 0 raus gekommen.
Hardware stand und regierte nicht
Nachdem das passierte sind natürlich alle LUNs über die iSCSI LAN Adressen nicht mehr für vSphere zugreifbar gewesen und alle VMDKs waren nicht mehr erreichbar und abgestürzt. Die meisten VMs mögen es halt nicht, wenn man ihnen im laufenden Betrieb die Festplatten unterm Hintern wegreißt. :-(
Ich bin dann in unser RZ gedüst und habe festgestellt, dass auf dem Node 1 keinerlei HDD-Aktivität mehr zu sehen war. Normalerweise blinken die LEDs ja fröhlich auf beiden Nodes. Auf Node 0 war HDD-Aktivität zu sehen.
Meine Überlegung dazu: Node 1 muss abgestürzt sein, aber die Cluster-IPs hängen noch fest.
Also habe ich den Power-Taster an Node 1 für 4 Sekunden festgehalten. Die blaue LED hat auch angefangen zu blinken, aber nach weiteren 5 Minuten warten ist nichts passiert. Keine Regung, kein Zucken, keine HDD LED blinkt.
Also habe ich den Taster dann so lange festgehalten, bis das System ausgeschaltet war. Nach ca. 30 Sekunden habe ich es dann wieder gestartet.
Node 0 hatte nun wieder Zugriff auf die Cluster IPs, die LUNs konnten per iSCSI Target wieder an die vSphere Umgebung geleitet werden. Die VMs waren natürlich alle gecrasht und entsprechend musste noch eingegriffen werden, inkl Restore zweier VMs, die das nicht überlebt haben.
Nachdem Node 1 wieder online war hat sich auch das Cluster von selbst hergestellt und mit der Replizierung über den Heartbeat angefangen.
Viel unschöner hätte es kaum kommen können. Selbstredend habe ich debug Logs gezogen und diese an den Support gesandt. Das Problem wird da auch bearbeitet. Dennoch schadet es ja nicht hier mal nach zu haken.
Überlegung iSCSI Target Verbindung
Nun habe ich die iSCSI Verbindung über zwei Cluster Adressen an meine vSphere Umgebung angebunden. Dadurch, dass die Cluster IPs nicht erreichbar waren, war auch das Target nicht mehr erreichbar.
Wie wir wissen, sind die Host-IPs der aktiven Hardware erreichbar! Das bedeutet, theoretisch sollten die Host-NICs erreichbar sein, auch wenn die Cluster IP es nicht ist.
Ich überlege mir also, ob es sinnvoll ist, die Host-NICs, die für iSCSI zuständig sind, ebenfalls in der vSphere Umgebung einzurichten. Und nicht nur die virtuellen Cluster IPs. Eine Mehrwegverbindung ist für vSphere kein Problem und man kann auch priorisieren.
Sollte das nochmal passieren, wären zumindest die LUNs nicht weg, wenn ein Host auf den anderen übernommen hat und die Cluster IPs hängen wieder ...
Spräche was dagegen?
Danke fürs Lesen und Berichten, ob hier jemand ähnliches Erlebt hat.
Zuletzt bearbeitet:
