Kritischer Ausfall – gleichzeitiger Reboot aller Nodes nach iSCSI-Verbindungsverlust (Proxmox + HA + Softdog)

U

ugo

New Member
Nov 14, 2024
5
0
1
Hallo,


ich erlaube mir, hier zu posten, nachdem ein kritischer Vorfall in unserer Infrastruktur aufgetreten ist.


Unsere Umgebung:


  • Proxmox-Cluster 7.x mit 4 Knoten (HPE DL380 Gen10)
  • HPE MSA 2050 Storage direkt via iSCSI angebunden (kein Switch, jeder Knoten per bonding active-backup direkt an Controller A/B angeschlossen)
  • Multipath konfiguriert
  • HA aktiviert

Hintergrund des Vorfalls:


Am 2. Juli um 10:16:51 wurden auf allen 4 Knoten gleichzeitig sämtliche iSCSI-Pfade plötzlich getrennt. Dies führte sofort zu einem (nahezu) gleichzeitigen Reboot aller Nodes.


Analyse im Nachgang:


  • Kein Reboot oder Failover wurde auf der MSA festgestellt.
  • Es wurden keine physischen Verbindungen getrennt.
  • Die Logs auf der MSA zeigen FreeDDE / NewDDE unmittelbar nach dem Verbindungsverlust – dies deutet auf ein iSCSI-Reset oder Session-Verlust hin.
  • Der Software-Watchdog (softdog) hat die Nodes als "eingefroren" interpretiert und nach einem Timeout neu gestartet.

Meine Fragen:


  1. Ist es normal, dass Proxmox einen Node sofort als „offline“ betrachtet, nur weil temporär alle iSCSI-Pfade fehlen, obwohl das System weiterhin grundsätzlich reagiert?
  2. Der softdog-Watchdog scheint keinen Timeout wie PVE_HA_WATCHDOG_TIMEOUT zu berücksichtigen (zumindest nicht sichtbar im Environment von pve-ha-lrm) – ist das konfigurierbar?
  3. Wird bei dieser Architektur eher ein Software-Watchdog empfohlen oder sollte man auf einen Hardware-Watchdog (z. B. ipmi_watchdog) setzen?
  4. Gibt es eine Möglichkeit, einen sofortigen Reboot bei kurzzeitigen Storage-Ausfällen (z. B. iSCSI-Failover) zu verhindern?

Ich bin dankbar für jeden Erfahrungswert zu HA-Clustern mit iSCSI-Multipath-Storage unter Proxmox – insbesondere zu folgenden Themen:


  • Timeout-Verhalten
  • Watchdog-Empfehlungen
  • Best Practices zur Vermeidung unnötiger Neustarts

Vielen Dank im Voraus für eure Unterstützung!


Mit freundlichen Grüßen
 
Haben Sie mehrere redundante Ringe im Corosnc konfiguriert?
in /etc/corosync/corosync.conf
 
Hier ist meine Datei /etc/corosync/corosync.conf


Code: 
root@ns212577:~# cat /etc/corosync/corosync.conf
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: n1ns190103
    nodeid: 5
    quorum_votes: 1
    ring0_addr: 172.16.2.56
  }
  node {
    name: n2ns220620
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 172.16.2.60
  }
  node {
    name: n3ns220620
    nodeid: 4
    quorum_votes: 1
    ring0_addr: 172.16.2.63
  }
  node {
    name: ns170802
    nodeid: 6
    quorum_votes: 1
    ring0_addr: 172.16.2.57
  }
  node {
    name: ns181201
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 172.16.2.66
  }
  node {
    name: ns212577
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 172.16.2.55
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: DATACENTER
  config_version: 8
  interface {
    linknumber: 0
  }
  ip_version: ipv4-6
  link_mode: passive
  secauth: on
  version: 2
}
 
forum.proxmox.com/threads/adding-a-secondary-corosync-network-for-failover-setting-the-priority-when-adding-a-2nd-corosync-network-to-upgrade-to-a-redundant-ring-network.99688/
 
  • Like
Reactions: ubu and Johannes S
ugo said:
Hallo,


ich erlaube mir, hier zu posten, nachdem ein kritischer Vorfall in unserer Infrastruktur aufgetreten ist.


Unsere Umgebung:


  • Proxmox-Cluster 7.x mit 4 Knoten (HPE DL380 Gen10)
  • HPE MSA 2050 Storage direkt via iSCSI angebunden (kein Switch, jeder Knoten per bonding active-backup direkt an Controller A/B angeschlossen)
Click to expand...
Das bitte auf gar keinen Fall tun, außerdem wie soll den da Multipath noch funktionieren?
ugo said:
  • Multipath konfiguriert
  • HA aktiviert

Hintergrund des Vorfalls:


Am 2. Juli um 10:16:51 wurden auf allen 4 Knoten gleichzeitig sämtliche iSCSI-Pfade plötzlich getrennt. Dies führte sofort zu einem (nahezu) gleichzeitigen Reboot aller Nodes.
Click to expand...
Wenn du ein Active-Backup Bonding bei direkt gesteckten Links hast, reicht ein Fehler oder Rebopot eines Controllers, dass alle Verbindungen verloren gehen.
ugo said:
Analyse im Nachgang:
  • Kein Reboot oder Failover wurde auf der MSA festgestellt.
Click to expand...
Fehler auf der MSA finden ist schwer. Viele kleine Probleme sieht man in der GUI gar nicht und außer den logs im Supportbundle hast du keine Möglichkeiten da vernünftig was zu analysieren
ugo said:
  • Es wurden keine physischen Verbindungen getrennt.
  • Die Logs auf der MSA zeigen FreeDDE / NewDDE unmittelbar nach dem Verbindungsverlust – dies deutet auf ein iSCSI-Reset oder Session-Verlust hin.
  • Der Software-Watchdog (softdog) hat die Nodes als "eingefroren" interpretiert und nach einem Timeout neu gestartet.

Meine Fragen:

  1. Ist es normal, dass Proxmox einen Node sofort als „offline“ betrachtet, nur weil temporär alle iSCSI-Pfade fehlen, obwohl das System weiterhin grundsätzlich reagiert?
  2. Der softdog-Watchdog scheint keinen Timeout wie PVE_HA_WATCHDOG_TIMEOUT zu berücksichtigen (zumindest nicht sichtbar im Environment von pve-ha-lrm) – ist das konfigurierbar?
  3. Wird bei dieser Architektur eher ein Software-Watchdog empfohlen oder sollte man auf einen Hardware-Watchdog (z. B. ipmi_watchdog) setzen?
  4. Gibt es eine Möglichkeit, einen sofortigen Reboot bei kurzzeitigen Storage-Ausfällen (z. B. iSCSI-Failover) zu verhindern?

Ich bin dankbar für jeden Erfahrungswert zu HA-Clustern mit iSCSI-Multipath-Storage unter Proxmox – insbesondere zu folgenden Themen:

  • Timeout-Verhalten
  • Watchdog-Empfehlungen
  • Best Practices zur Vermeidung unnötiger Neustarts
Click to expand...
Die MSA ist recht einfach und läuft ganz gut im Switchsetup. Direkt gesteckt verhalten die sich manchmal zickig. VMware tolleriert das etwas besser, aber die halten sich oft auch nicht 100% an die iSCSI Spezifikationen. Bei Linux Servern, so auch Proxmox merkt man das dann öfter und man muss da etwas mehr aufpassen.
MSA laufen bei mir direkt verkabelt nur stabil, wenn jeder Node eigene IP Kreise bekommt und man die nicht erreichbaren Target IPs nach dem Discover manuell wieder entfernt.
Dann natürlich Multipath sauber konfigurieren. Damit habe ich auch Cluster bei Kunden stabil am laufen.

Alles andere, wie redundante Corosync Netzwerkverbindungen und so weiter, setze ich mal voraus.
 
  • Like
Reactions: Johannes S
Guten Tag,


vielen Dank für Ihre Rückmeldung – sie bestätigt einige der Punkte, die wir bereits in Betracht gezogen hatten.


Unsere aktuelle Konfiguration basiert tatsächlich auf einer direkten Verkabelung (ohne iSCSI-Switches). Jeder Knoten ist direkt mit beiden Controllern des MSA über Bonding im Active-Backup-Modus verbunden, wobei jeder iSCSI-Pfad über eigene IP-Adressen verfügt.
Multipath ist ebenfalls korrekt eingerichtet und funktioniert im Normalbetrieb zuverlässig (Pfad-Erkennung, Failover getestet und stabil).


Der Vorfall am 2. Juli bleibt dennoch überraschend: Alle Pfade sind auf allen vier Knoten gleichzeitig ausgefallen – ohne physikalisches Problem oder Reboot auf der Speicherseite.
Dies führte zu einem automatischen Reboot der Knoten durch den HA-Watchdog. Wie Sie bereits angemerkt haben, scheint dieses Verhalten typisch für direkte iSCSI-Verbindungen mit dem MSA zu sein.


Sie erwähnten, dass Sie empfehlen, nicht erreichbare Zieladressen manuell zu entfernen, nachdem die Discovery erfolgt ist. Könnten Sie bitte konkretisieren, was Sie dabei genau empfehlen? Meinen Sie die Entfernung über iscsiadm oder eine gezielte Einschränkung der erreichbaren Targets pro Knoten?


Zur Information: Das Corosync-Netzwerk ist redundant aufgebaut, mit zwei physisch getrennten Interfaces.


Vielen Dank nochmals für Ihre Einschätzung.


Mit freundlichen Grüßen,
 
ugo said:
Guten Tag,


vielen Dank für Ihre Rückmeldung – sie bestätigt einige der Punkte, die wir bereits in Betracht gezogen hatten.


Unsere aktuelle Konfiguration basiert tatsächlich auf einer direkten Verkabelung (ohne iSCSI-Switches). Jeder Knoten ist direkt mit beiden Controllern des MSA über Bonding im Active-Backup-Modus verbunden, wobei jeder iSCSI-Pfad über eigene IP-Adressen verfügt.
Multipath ist ebenfalls korrekt eingerichtet und funktioniert im Normalbetrieb zuverlässig (Pfad-Erkennung, Failover getestet und stabil).


Der Vorfall am 2. Juli bleibt dennoch überraschend: Alle Pfade sind auf allen vier Knoten gleichzeitig ausgefallen – ohne physikalisches Problem oder Reboot auf der Speicherseite.
Dies führte zu einem automatischen Reboot der Knoten durch den HA-Watchdog. Wie Sie bereits angemerkt haben, scheint dieses Verhalten typisch für direkte iSCSI-Verbindungen mit dem MSA zu sein.


Sie erwähnten, dass Sie empfehlen, nicht erreichbare Zieladressen manuell zu entfernen, nachdem die Discovery erfolgt ist. Könnten Sie bitte konkretisieren, was Sie dabei genau empfehlen? Meinen Sie die Entfernung über iscsiadm oder eine gezielte Einschränkung der erreichbaren Targets pro Knoten?


Zur Information: Das Corosync-Netzwerk ist redundant aufgebaut, mit zwei physisch getrennten Interfaces.


Vielen Dank nochmals für Ihre Einschätzung.


Mit freundlichen Grüßen,
Click to expand...
Mit Bonding kann Multipath nicht sauber funktionieren. Eventuell gut genug um bestimmte Tests zu bestehen aber niemals so wie es in den Spezifikationen angedacht ist.
 
  • Like
Reactions: Johannes S
ugo said:
Sie erwähnten, dass Sie empfehlen, nicht erreichbare Zieladressen manuell zu entfernen, nachdem die Discovery erfolgt ist. Könnten Sie bitte konkretisieren, was Sie dabei genau empfehlen? Meinen Sie die Entfernung über iscsiadm oder eine gezielte Einschränkung der erreichbaren Targets pro Knoten?
Click to expand...
Wenn man bei einer MSA ein Target discovert, bekommt man alle Target IPs zurück geliefert. Natürlich auch dier anderen Ports, wo die anderen Server dran hängen und von dem Server nicht erreichbar sind..

Man kann das natürlich aufwändig per iscsiadm wieder entfernen oder einfach in den Ordner: /etc/iscsi/nodes/<iqndesStorages>
gehen und da die Ordner mit den IPs der Targets, von den anderen Nodes löschen.
 
  • Like
Reactions: Johannes S
bitte die logs ca. 15minuten vor dem ausfall bis zum ausfall posten (journalctl --since ... --until ...). es klingt fuer mich eher danach, als haetten sich alle nodes aufgrund eines netzwerk problems gleichzeitig gefenced, und der reset der iSCSI session war ein symptom/eine folge des fencings, nicht umgekehrt. PVE ist die iSCSI verbindung in bezug auf HA und fencing naemlich vollkommen egal, es kommt ausschliesslich auf die corosync verbindung an. du schreibst die waere redundant, aber in der corosync.conf ist nur ein link konfiguriert - heisst dass ihr fahrt hier auch mit bond unter corosync?

uebrigens:

  • Proxmox-Cluster 7.x mit 4 Knoten (HPE DL380 Gen10)
Click to expand...

PVE 7 ist schon laenger EOL..
 
  • Like
Reactions: Johannes S
Wenn du dein Cluster Netzwerk auf Vordermann bringst, am besten auch gleich das iSCSI auch mal korrekt konfigurieren.
Generell wäre es eine gute Idee zwei gar nicht so teure Switches zu kaufen, das iSCSI nach HPE Anleitung korrekt einzurichten und die beiden iSCSI Netze am besten auch als weitere Corosync Rings einzurichten. Denn wenn beide iSCSI Netze weg sind, ist Corosync dann auch egal.
 
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom