Proxmox Cluster Problem

[bchristopeit]

Hallo zusammen,

ich habe ein kleines Problem und weiss aktuell nicht wie ich es lösen kann. Ich habe drei physische Server und ein NAS welches mit 10GB verbunden ist zu den Servern. Ich habe einen Cluster erstellt und die VMs liegen alle auf dem NAS. Bis dahin ist alles super. Nun habe ich aber das Problem, dass nach einer undefinierten Zeit auf einmal mein Server2 nicht mehr erreichbar ist in der Übersicht. node1 und node3 sind da und node2 hat überall ein Fragezeichen. Die VM die darauf läuft ist aber erreichbar und ich komme da auch per Teamviewer drauf. SSH oder Webinterface vom Fehlerhaften Server geht nicht. Wenn ich auf Shell gehe bei Server 2 erhalte ich:

kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.1.201 port 22

und wenn ich auf Summery gehe gibt es Broken pipi (596).

Kann mir jemand helfen, wie ich das gefixt bekomme? Wenn ich nämlich die VM herunterfahre und beim Server einen Neustart mache, dann ist der Teil vom Cluster wieder ganz normal erreichbar.

Ich hoffe ich habe nichts vergessen. Aktuell läuft auf allen Proxmox 8.2.7. Bin eben noch neu in dem Proxmox Business

 

[waltar]

Einfache Clusterkonfig, wie wir es auch haben, allerdings, haben wir auf einem Node auch noch eine Kopie vom NAS, sodaß wir jenen NAS auch mal "reparieren oder so" können. Alle vm/lxc mit ha Konfig und mit maintenance mode in 1min jeder Node (je 15-25 vm wegen unterschiedliche HW) wahlweise leer.
Du kannst nun entweder das Problem suchen und beheben (mit Lerneffekt) oder du machst node2 leer, schmeißt ihn aus dem Cluster, installierst ihn neu und wieder joinen, was rund 1/2h Aufwand ist, aber dafür den Katastrophenfall Lerneffekt hat.

 

[bchristopeit]

Aber wo müsste ich ansetzen mit suchen? Die drei Server sind absolut identisch von der Hardware.

 

[fpausp]

Ich habe drei physische Server und ein NAS welches mit 10GB verbunden ist zu den Servern. Ich habe einen Cluster erstellt und die VMs liegen alle auf dem NAS.

Warum laufen die VMs (alle) auf dem NAS?

Nun habe ich aber das Problem, dass nach einer undefinierten Zeit auf einmal mein Server2 nicht mehr erreichbar ist in der Übersicht.

Ich vermute du verwendest nur ein Netz für alles oder wie sieht die Netzwerkconfig aus?

 

[bchristopeit]

Es geht darum, dass bei einem Ausfall eines Servers die VM auf den nächsten geschoben wird und von dort aus ausgeführt wird. Damit es im Betrieb keinen Ausfall gibt. Ich habe die drei Server jeweils mit 10GB Nic mit dem NAS im eigenen Netz verbunden und dann über eine weiter NIC im Firmennetz worüber die Server erreichbar sind. Beim Test (Stecker mal ziehen) hat das auch wunderbar funktioniert. Was ich mitlaufen meinte, ist, dass ich ein LUN auf dem Synology erstellt habe und die Daten der VMs dort liegen. Die drei Server sind alle so konzipiert das alle drei virtuellen Server im Notfall auf einem Server laufen könnten. Aktuell habe ich Server1 auf Node1, Server 2 auf Node2 etc. laufen. Mich wunder es einfach, dass der Server auf dem aktuell nicht erreichbaren Node noch läuft und erreichbar ist. RDP, Teamvierwer etc. und das Problem mit dem Proxmox würde ich gerne beheben können. Denn jedes mal ein Server neu installieren, scheint mir nicht die beste Lösung zu sein, auch wenn ich diese Lösung in vielen Threads finde

 

[maxim.webster]

dass nach einer undefinierten Zeit auf einmal mein Server2 nicht mehr erreichbar

Könnte eine abgelaufene Lease Time eines DHCP Services sein.

Sind alle Nodes auf feste IP eingestellt und kommt der Router damit auch klar?

 

[bchristopeit]

Ja alle nodes haben eine fixe IP.

 

[bchristopeit]

Könnte eventuell ein Update auf die neuste Version helfen?

 

[maxim.webster]

Könnte eventuell ein Update auf die neuste Version helfen?

Muss eh irgendwann kommen, also warum nicht jetzt?

Für eine tiefergehende Analyse würde ich auf Node 2 mal die Ausgaben von „dmesg -T“ (Kernelmeldungen mit Zeitstempel) durchforsten, idealerweise auch von außen ein Monitoring aufsetzen, um den Zeitpunkt des Ausfalls einzugrenzen.

 

[bchristopeit]

Muss eh irgendwann kommen, also warum nicht jetzt?

Für eine tiefergehende Analyse würde ich auf Node 2 mal die Ausgaben von „dmesg -T“ (Kernelmeldungen mit Zeitstempel) durchforsten, idealerweise auch von außen ein Monitoring aufsetzen, um den Zeitpunkt des Ausfalls einzugrenzen.

Ich kann Morgen vor Ort sein und schaue das dann an. Ich sehe unter "HA" pve2 (old timestamp - dead?, Thu Dec 26 00:03:32 2024). Ich denke das wäre schon mal ein Anhaltspunkt.

 

[waltar]

Warum laufen die VMs (alle) auf dem NAS?

Weil man so völlige Flexibilität bzgl. Updates, HW Ausfall oder Austausch hat. Die pve's kümmern sich um's virtualisieren und die Storages um das Serven der Images, und von pve losgelösten snapshots und backup. Ebenso kann man so in sekunden- bis minutenschnelle einen Haufen vm's automatisch generieren und für einen Applikationsfall laufen lassen. Zudem ist ein Zurückspringen aus einen Sanpshot nur Sekundensache, ein restore von anderem Host läuft mit unserer alten HW mit 900MB/s. Einfacher und unkomplizierter geht es nicht

 

[bchristopeit]

Vielen lieben Dank euch allen für so schnelle Hilfe. Werde mich morgen dann wieder melden, wenn ich auch auf die Maschine komme.

 

[pvps1]

probiere mehrfach hintereinander dich per ssh auf node2 einzuloggen. die broken pipe würde ich als Überlastung deuten (evtl oom killer). Wenn wieder erreichbar, zb nach reboot schaue dir die Auslastung dieses Hosts an (oder im Monitoring wenn vorhanden)

 

[pvps1]

probiere mehrfach hintereinander dich per ssh auf node2 einzuloggen. die broken pipe würde ich als Überlastung deuten (evtl oom killer). Wenn wieder erreichbar, zb nach reboot schaue dir die Auslastung dieses Hosts an (oder im Monitoring wenn vorhanden)

Nachtrag: lauter Fragezeichen aber vms laufen noch, heisst nichts anderes als dass der cluster aka corosync probleme hat, restarte das mal am node2

 

[bchristopeit]

Hallo zusammen und erst einmal ein frohes neues Jahr. Ich war vor Ort und die VM lief ja noch. Da ich nun auch nen Monitor hatte, hatte ich auf dem node2 folgende Meldung (siehe Bild). Der Smart Status nach einem Neustart ist aber in Ordnung und auch auf dem Controller sagte er es sei okay. Nun habe ich jede Menge im Netz gefunden und ich bin wohl nicht der einzige Mensch. Hatte jemand schon mal das Problem und kann mir eventuell helfen? Ich habe aktuell auch keine VM auf dem node laufen.


@pvps1 ich komme leider in dem Zustand (bevor ich neu gestartet habe) nicht per Web und auch nicht per SSH auf die Kiste.

 

[waltar]

Ext4 filesystem error on dm-1 and set by kernel to read-only mode. You need a new os disk and new pve inst.

 

[mr44er]

Von ext4 habe ich keine Ahnung, aber wenn das eine/die interne Bootplatte ist, sieht mir das nach kaputt aus.

Der Smart Status nach einem Neustart ist aber in Ordnung und auch auf dem Controller sagte er es sei okay.

Das muss nichts heißen, SMART ist zu unzuverlässig.
Ich weiß, dass SSDs ab einem bestimmten Prozentsatz Endurance den Schreibzugriff blocken. Das ist nicht immer vorher bekannt oder wird mitgeteilt.
Gesehen habe ich auch schon, dass SSDs auf 70% Endurance wirklich spinnen und sonst kein Fehler erahnbar wären.

 

[bchristopeit]

Okay. Dann muss ich schauen, denn die Server und nvme sind frisch ausgepackt.

 

[maxim.webster]

„smart“ prüft das Medium und den Controller, weiß aber nichts vom Filesystem.

Das FS kann einen Hau mitbekommen habe durch Stromausfall oder ähnliches. Wobei Journaling Filesystems wie ext4 das selber wieder hinbekommen.

 

[bchristopeit]

„smart“ prüft das Medium und den Controller, weiß aber nichts vom Filesystem.

Das FS kann einen Hau mitbekommen habe durch Stromausfall oder ähnliches. Wobei Journaling Filesystems wie ext4 das selber wieder hinbekommen.

Aber vorher irgendwie prüfen geht das?