⅓ des HA-Clusters ausgefallen, /etc/pve unvollständig

[rmoriz]

Hallo,

mein 3-Node Promox VE9-HA-Setup (zfs lokal, ohne shared storage) ist degraded, da mir ein Node mit zfs-Fehlern ausgestiegen ist (obwohl SMART sauber und keine I/O-Fehler auf kernel level).

Soweit so gut, da ich Backup-Images der VMs und LXCs habe.

Allerdings fehlt die Konfigurationen aus dem fuse unter /etc/pve/qemu-server und /etc/pve/openvz des ausgefallenen Nodes auch im Rest des cluster. Es ist ziemlich mühsam herauszufinden, welche VM nun zum Ausfall auf dem Node lief und in welcher Konfiguration.

Ist das so by design? Habe ich etwas falsch gemacht?

Viele Grüße
Roland

 

[narrateourale]

/etc/pve/qemu-server und /etc/pve/lxc (OpenVZ ist noch da, aber wohl schon lange nicht mehr verwendet) zeigt immer die lokale node. Aber unter /etc/pve/nodes/NODE/... sollte die Ordnerstruktur für alle Nodes da sein.

In der GUI sollte aber auch noch ersichtlich sein, welche Gäste auf der ausgefallenen Node waren oder?

 

[UdoB]

In der GUI sollte aber auch noch ersichtlich sein, welche Gäste auf der ausgefallenen Node waren oder?

Da sieht man dann aber leider nur die VM-IDs, nicht die sprechenden Namen...

 

[waltar]

Im täglichen Backup sollten auch alle configfiles liegen, aus denen man widerum alles entnehmen kann. Wer sowas nicht mitsichert, erschwert sich unnötig ein mögliches Desaster.

 

[rmoriz]

Ja das Problem ist, dass HA-VMs natürlich dynamisch verschoben werden können und immer ein drift zwischen Realität und Backup existierten kann.

Hier z.B. die View eines grauen PVE-Nodes. Da ist man erst mal aufgeschmissen.

 

[TErxleben]

Darum prüfe, bevor man sich ein Cluster ans Bein bindet!
By design hat man einen ganzen Sack von fetten zusätzlichen Fehlerquellen an Bord.

 

[Johannes S]

Darum prüfe, bevor man sich ein Cluster ans Bein bindet!
By design hat man einen ganzen Sack von fetten zusätzlichen Fehlerquellen an Bord.

Das ist zwar grundsätzlich korrekt, aber auch bei einen single-node könnte einen die Konfiguration der VMs und Container flöten gehen, dagegen helfen halt nur Backups.

Soweit so gut, da ich Backup-Images der VMs und LXCs habe.

Warum hast du Backup-Images der VMs und LXCs aber nicht von deren Konfiguration? Die in PVE enthaltenen Backupoptionen sichern ja entweder auf einen ProxmoxBackupServer oder als vma.zst ) auch immer die Konfiguration der VMs und LXCs mit.

 

[TErxleben]

Warum hast du Backup-Images der VMs und LXCs aber nicht von deren Konfiguration? Die in PVE enthaltenen Backupoptionen sichern ja entweder auf einen ProxmoxBackupServer oder als vma.zst ) auch immer die Konfiguration der VMs und LXCs mit.

Verstehe ich auch überhaupt nicht, macht mir aber Angst.

 

[rmoriz]

Das ist zwar grundsätzlich korrekt, aber auch bei einen single-node könnte einen die Konfiguration der VMs und Container flöten gehen, dagegen helfen halt nur Backups.

Warum hast du Backup-Images der VMs und LXCs aber nicht von deren Konfiguration? Die in PVE enthaltenen Backupoptionen sichern ja entweder auf einen ProxmoxBackupServer oder als vma.zst ) auch immer die Konfiguration der VMs und LXCs mit.

Weil ich Replication aktiviert habe und da nur die vm-disks kopiert werden, nicht aber die Konfiguration. Laut https://pve.proxmox.com/pve-docs/chapter-pvesr.html#_migrating_a_guest_in_case_of_error sollte da eigentlich unter /etc/pve die Konfiguration noch vorhanden sein, das war sie bei mir aber nicht

 

[narrateourale]

Hast du mal nachgeschaut, auf einer Node die noch läuft? In /etc/pve/nodes/pve3/qemu-server, bzw lxc sollten die configs liegen. Wenn kein HA aktiviert ist, was die Gäste automatisch recovered, musst du das von hand machen. Z.B. mit

mv /etc/pve/nodes/pve3/qemu-server/103.conf /etc/pve/nodes/ANDERE_NODE/qemu-server

 

[Falk R.]

Weil ich Replication aktiviert habe und da nur die vm-disks kopiert werden, nicht aber die Konfiguration. Laut https://pve.proxmox.com/pve-docs/chapter-pvesr.html#_migrating_a_guest_in_case_of_error sollte da eigentlich unter /etc/pve die Konfiguration noch vorhanden sein, das war sie bei mir aber nicht

Replikation ist aber kein Backup.
Move doch einfach die VM Konfigurationen aus /etc/pve/nodes/<ausgefallernerNode>/... nach /etc/pve/nodes/<funktionierenderNode>/...

 

[rmoriz]

Replikation ist aber kein Backup.
Move doch einfach die VM Konfigurationen aus /etc/pve/nodes/<ausgefallernerNode>/... nach /etc/pve/nodes/<funktionierenderNode>/...

die waren dort auf keinem verbleibenden Node mehr vorhanden.

 

[Falk R.]

die waren dort auf keinem verbleibenden Node mehr vorhanden.

Dann muss der Cluster schon früher auseinander gebrochen sein.
Ich habe schon ganz viele Cluster in der Hand gehabt und keine Möglichkeit wie die Konfigurationen einfach verloren gehen, ohne das jemand von Hand etwas gemacht hat.

Verrate uns was du alles gemacht hast, dann können wir dir Sagen ob man da helfen kann.

Backup hast du ja keins und irgendwie die Clusterkonfiguration kaputt gespielt, nur da fehlt mir die Idee, was du da genau gemacht hast.

 

[rmoriz]

Dann muss der Cluster schon früher auseinander gebrochen sein.
Ich habe schon ganz viele Cluster in der Hand gehabt und keine Möglichkeit wie die Konfigurationen einfach verloren gehen, ohne das jemand von Hand etwas gemacht hat.

Verrate uns was du alles gemacht hast, dann können wir dir Sagen ob man da helfen kann.

Backup hast du ja keins und irgendwie die Clusterkonfiguration kaputt gespielt, nur da fehlt mir die Idee, was du da genau gemacht hast.

ich hab mir die Daten aus den Images extrahiert und restored.
Geholfen hat mir die Tatsache, dass ich alle VMs mit terraform anlege, so musst ich dann "nur" noch die Nutzdaten einspielen.
War natürlich eine miese Arbeit, da ich neue VM immer auf einem Node anlege und dann von Hand verteile, von Hand backups/replication anlege usw. usf.

Mittlerweile habe ich auch das zfs von der ursprünglichen NVMe importiert bekommen, wobei 3 VMs kaputt sind und auch im root etwas kaputt war. Es hat Tage gedauert. Sowohl ein memtest wie auch badblocks waren ebenso unauffällig wie SMART. Also nach dem Restore-Problem bin ich jetzt ratlos, was die Ursache gewesen sein könnte.

 

[news]

Guten Morgen, ich lese hier nvme und ZFS ist ja schon mal eine tolle Sache, aber nur mit einem Datenträger? Gibt's doch kaum eine Möglichkeiten, wenn bit-rod stattfindet oder Flash-Zellen kaputt gehen, diese Daten wieder repariert zu bekommen. Dafür ist doch ZFS bekannt es braucht Redundanz um Selbstheilung durchzuführen. Kann es sein dass hier ein Designfehler vorliegt? Darf man erfahren welche nvme das ist? Eventuell ist es auch so, dass sie gar nicht für ZFS geeignet ist und so vorzeitig stirbt.

 

[rmoriz]

Guten Morgen, ich lese hier nvme und ZFS ist ja schon mal eine tolle Sache, aber nur mit einem Datenträger? Gibt's doch kaum eine Möglichkeiten, wenn bit-rod stattfindet oder Flash-Zellen kaputt gehen, diese Daten wieder repariert zu bekommen. Dafür ist doch ZFS bekannt es braucht Redundanz um Selbstheilung durchzuführen. Kann es sein dass hier ein Designfehler vorliegt? Darf man erfahren welche nvme das ist? Eventuell ist es auch so, dass sie gar nicht für ZFS geeignet ist und so vorzeitig stirbt.

Samsung 990 Pro 4TB.

Szenario: Homelab, dass mittlerweile auch „etwas produktives“ hosted (aber nichts wo Geld oder Leben daran hängt) und per Tunnel und BGP ein öffentliches IPv4-Netz bekommt. Hardware: 2x Thinkcentre m715q Tiny Gen 2 und ein m720q(?). Leider nur ein ein PCIe M.2 Steckplatz bei den 715q. Ca 13-15 Watt pro System.

2.5G am Wifi-M.2 für Corosync und Migration, 1G intern für die VMs.

2x32GB SO-DIMM von Crucial. ZFS kam nur wegen der Livemigrationsfähigkeit zum Einsatz, als Single Disk natürlich nicht das richtige. Ich hätte gerne ext4 und LVM2-Snapshotting gehabt, das kann/konnte Proxmox 8 Ende 2024 nicht. Ka ob das mit der 9 jetzt geht.

 

[UdoB]

2.5G am Wifi-M.2 für Corosync und Migration,

Das ist ein Kupfer-Adapter im M.2 Steckplatz, richtig?

Migration belegt gerne so viel Bandbreite wie möglich --> "Sättigung". Das ist aber genau das, was man auf der Verbindung für Corosync auf gar keinen Fall haben will. Entschärfung: man kann die genutzte Bandbreite für die Migration explizit begrenzen.

Corosync hat einen "ring" auf beiden Schnittstellen, ja?

 

[Johannes S]

Weil ich Replication aktiviert habe und da nur die vm-disks kopiert werden, nicht aber die Konfiguration.

Klar, für die Konfigs ist ja auch der Cluster zuständig, solange der denn funktioniert. Aber ( wie du gerade gemerkt hast): Das ist kein Backup ( Cluster kann Probleme haben, wie jede Software), sondern um nach Ausfall eines Knotens die VMs und lxcs auf einen anderen Kmoten fortsetzen zu können. Was du machen könntest: Die VMs und lxcs mit anderer ID neu erstellen und dann Kopien ( wichtig um nichts zu überschreiben, wenn du einem Fehler machst ) der Images anhängen. Generell wäre nun ein guter Zeitpunkt diese Images an einen Ort außerhalb des Clusters zu sichern.

Nun kann die Replikation von zfs natürlich Basis für ein Backup sein, sofern man die Konfigs auf anderem Weg sichert. Oder wenn man die VMs/lxcs auch auf einen Notfall-Server für den Weiterbetrieb hätte, dafür gibt es pve-zsync:

https://pve.proxmox.com/wiki/PVE-zsync


Damit kann man auch ohne cluster Images und configs zwischen single-nodes realisieren, aber auch das ersetzt kein Backup, kann aber Teil einer Notfallstrategie sein.

 

[Johannes S]

Corosync hat einen "ring" auf beiden Schnittstellen, ja?

Ergänzung zur Doku: https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_redundancy

Es wäre definitiv sinnvoll, auf einen der beiden Links nur den Corosync-Verkehr laufen zu haben und den anderen Link zusätzlich als redundanten Link (im Falle eines Ausfalls/Überlastung des ersten) für corosync.
Ich würde es dann wohl so machen, den corosync auf die 1GB zu legen und den VM-Verkehr plus Migration und corosync-Redundanz auf die 2.5 GB (schnellere Migrationen )

 

[news]

Samsung 990 Pro 4TB.

Szenario: Homelab, dass mittlerweile auch „etwas produktives“ hosted (aber nichts wo Geld oder Leben daran hängt) und per Tunnel und BGP ein öffentliches IPv4-Netz bekommt. Hardware: 2x Thinkcentre m715q Tiny Gen 2 und ein m720q(?). Leider nur ein ein PCIe M.2 Steckplatz bei den 715q. Ca 13-15 Watt pro System.

2.5G am Wifi-M.2 für Corosync und Migration, 1G intern für die VMs.

2x32GB SO-DIMM von Crucial. ZFS kam nur wegen der Livemigrationsfähigkeit zum Einsatz, als Single Disk natürlich nicht das richtige. Ich hätte gerne ext4 und LVM2-Snapshotting gehabt, das kann/konnte Proxmox 8 Ende 2024 nicht. Ka ob das mit der 9 jetzt geht.
View attachment 90147

@rmoriz danke für die Bilder.