Ich möchte Proxmox neu aufsetzen - Was sollte ich verändern?

D.h. du würdest nur eine Marken-NVMe nehmen für OS und Anwendungen? (und nicht trennen?)
Als ob du bei den teuren "Marken"-Herstellern nicht beschissen wirst. Ich sorge iieber für adäquate Sicherung.
Was nutzt mir eine 100J-Garantie von den o.g.? Es geht um die Daten Daten Daten. Ob mir eine Platte nun ersetzt wird, oder ich eine neu kaufen muss spielt doch keine Rolle. Es gibt keinen Hersteller, der nicht sein persönliches Waterloo erlitten hat.
 
Code:
Ist sicherlich keine Doktorarbeit, aber verschafft einen Überblick. So richtig fette Schnitzer konnte ich auch nicht entdecken. Was fiel dir denn ins Auge?
Der Reihe nach ?
ext4:
"Allrounder für Web- und Datenbank-Workloads" - In zB https://www.phoronix.com/review/linux-70-filesystems/4 mit default Einstellungen auf 1 nvme ist xfs in allen DB Tests schneller als ext4.
"Die Extents-Architektur reduziert Fragmentierung und hält Zugriffe auf große Dateien effizient." - Gilt genauso für xfs und ist sofern kein ext4 Alleinstellungsmerkmal.
xfs:
"Für XFS sind su/sw (Stripe Unit/Width) beim Erzeugen wichtig, damit Allokation zu RAID passt. && Auf XFS achte ich auf Stripe-Unit/Width passend zum RAID, damit der Durchsatz stimmt." - Mehrfach verschiedene sw oder hw-raid sets mit su/sw settings getestet und immer sind jene mit solchen settings abweichend der autom. default Erstellung bei metadaten und Bandbreiten Tests paar % langsamer !!
"inode64 verhindert Hotspots in niedrigen Inode-Bereichen" - ist default, aber nicht zu verwenden, wenn man hybrid-xfs mit 2 getrennten eg. raid1/raid6 Metadaten/Daten untendrunter verwenden möchte, was ein ext4 bzgl. Millionen Files weit den Rang abläuft.
Sachen wie "echo 20 >/proc/sys/vm/vfs_cache_pressure" sind dort auch völlig unbekannt, andere wichtige Einstellungen ebenso.
"overlay2 verlangt d_type/ftype-Unterstützung; XFS muss mit ftype=1 formatiert sein, sonst brechen Hardlinks/Whiteouts in Layern." - ftype=1 ist zwangs-default in xfs v5 Format und war nur wahlweise im deprecated v4 Format vom default "abwählbar/ftype=0".
 
Last edited:
  • Like
Reactions: Johannes S
Vielen Dank für den vielen Input. btrfs nutze ich ja seit sehr vielen Jahren auf meiner Synology Diskstation und ZFS im HA-Cluster seit 2 1/2 Jahren unter Proxmox.
Auf Snapshots und die Datenintegrität möchte ich nicht mehr verzichten. Als Rentner probiere ich gerne neue Dinge aus und nicht alles funktioniert so wie gewünscht.
Da sind Snapshots sehr wichtig um schnell den alten Stand zurück zu bekommen. (ich bin kein IT-Admin)

Ob die HA Funktionen so Sinn machen, das muss ich noch rausfinden. 2 1/2 Jahre haben die super funktioniert. Je nach Wichtigkeit der VM's habe ich Replikationszeiten zwischen 15 Minuten und 24 Stunden eingestellt. Keine Hochverfügbarkeit, funktioniert aber für ein Homelab sehr gut.

Aktuell habe ich aber Probleme weil corosync beide nodes regelmäßig neu startet. Ich muss noch rausfinden, ob das am Switch oder an der NVMe liegt. Trotz inzwischen über 300 Neustarts ist das Dateisystem noch in Ordnung. Auch die NVMe zeigt keine defekten Daten an.
Ich habe alles gesichert und alls unwichtige ausgeschaltet (auch Node 2), noch bin ich in Urlaub und bereite mich nur gedanklich auf die Neu-Installation vor.
 
Last edited:
Und mit NFS kannst du bzgl. HA keinen Blumentopf gewinnen. Jedenfalls nicht, solange der NFS ein Spof ist und die gesamte Netzwerkinfrastruktur nicht ebenfalls redundant ausgelegt ist.
In unserem seit ~3 Jahren bestehendem 5-node cluster zzgl. 1 (rocky9) nfs-server sind so ziemlich alle pve's hier und da mal durchgefenct worden, den nfs-server hat's noch nie zerlegt - insofern ist in der realen Welt das cluster mit den sterbenden vm's und lxc's der spof und nicht der eine nfs-server. Das hat sich auch in den letzten 30 Jahren so bestätigt und ist nicht von diesem pve-cluster Aufbau abweichend.
 
  • Like
Reactions: Johannes S and UdoB
weitegeführt auf Basis des letzten Replikationsstandes.
Niedlich. In meinem DB-Server fehlen als nur 2min Daten und mögliche Inkonsistenten erbe ich noch als Leckerli obendrauf?
HA ist ein feststehender Begriff, der nicht so fahrlässig genutzt werden sollte.
Und mit NFS kannst du bzgl. HA keinen Blumentopf gewinnen. Jedenfalls nicht, solange der NFS ein Spof ist und die gesamte Netzwerkinfrastruktur nicht ebenfalls redundant ausgelegt ist.

Jedes Konstrukt, welches im Homelab realistisch installierbar ist, hat sowohl Vor- als auch Nachteile!
Ich habe noch nie NFS als akzeptables Speicherziel tituliert. Sich immer auf Homelab zurückzuziehen, ist auch nicht valide.
Wenn ich HA herstellen will, dann geht das nur mit zentralem, redundanten Storage! Früher (TM) hieß die Mindestanforderung für zentralen Speicher noch RAID.
 
Last edited:
Ob die HA Funktionen so Sinn machen, das muss ich noch rausfinden. 2 1/2 Jahre haben die super funktioniert. Je nach Wichtigkeit der VM's habe ich Replikationszeiten zwischen 15 Minuten und 6 24 Stunden eingestellt. Keine Hochverfügbarkeit, funktioniert aber für ein Homelab sehr gut.
Dann spare dir die Fehlerquellen eines "HA"-Clusters. Nimm zwei EinzelPVEs und justiere die Backupfrequenz jeder VM. Am besten mit einem PBS oder auf externen Disks per vzdump.
KISS-Prinzip also.
 
Last edited:
Und mit NFS kannst du bzgl. HA keinen Blumentopf gewinnen.

Das kam jetzt offenbar etwas unpassend 'rüber, sorry. Mein obiger Blumentopf war nur als Spitze gegen den nicht zitierten Teil:

"Ohne schnellen und zuverlässigem shared storage, kannst du bzgl. HA keinen Blumentopf gewinnen. Hier wird es aber fälschlich gerne so dargestellt, da es ja Zauber-ZFS gibt."

...in #18 gedacht. Ich habe nix gegen NFS :-)
 
  • Like
Reactions: Johannes S
In unserem seit ~3 Jahren bestehendem 5-node cluster zzgl. 1 (rocky9) nfs-server sind so ziemlich alle pve's hier und da mal durchgefenct worden, den nfs-server hat's noch nie zerlegt - insofern ist in der realen Welt das cluster mit den sterbenden vm's und lxc's der spof und nicht der eine nfs-server. Das hat sich auch in den letzten 30 Jahren so bestätigt und ist nicht von diesem pve-cluster Aufbau abweichend.
Ich kenne keine wirklich zuverlässige Zusammenarbeit zwischen NFS-Server und NFS-client.
P.S.:
Ich habe auch nichts gegen NFS. Kenne aber genügend Nickligkeiten, die mich davon abhalten VMs dort zu lagern und starten.
 
Last edited:
Zudem sollte man bei xfs immer vorm 1. mount an quotas aktivieren. Je mehr Platten (hdd/ssd/nvme) desto größer und schneller ist ein xfs.
Wenn man unlimitierte Quotaprojekte anlegt ist die Größenabfrage der Ordner instant da und ersetzt ein zähes "du" dafür.
Wenn man dagegen den nfs/smb clients nur begrenzte Bereiche anbieten möchte, sehen sie quotiert auch nur deren Größe vom Kuchen.
:)
 
  • Like
Reactions: Johannes S
Ich kenne keine wirklich zuverlässige Zusammenarbeit zwischen NFS-Server und NFS-client.
Da stellt sich die Frage was du falsch machst. Auch die rocky updates auf unserem (15J altem Lenovo) nfs-server.zzgl. reboot tun keinem pve noch deren vm's und lxc's weh, alles hängt sich autom. wieder ein nachdem er wieder oben ist.
Machst du udp anstatt tcp mit seinen acknowledged Paketen, die beim client neu angefordert/gesendet werden, falls (wegen reboot) nicht angekommen ??
 
Last edited:
  • Like
Reactions: Johannes S
Code:
Ist sicherlich keine Doktorarbeit, aber verschafft einen Überblick. So richtig fette Schnitzer konnte ich auch nicht entdecken. Was fiel dir denn ins Auge?
Der Reihe nach ?
ext4:
"Allrounder für Web- und Datenbank-Workloads" - In zB https://www.phoronix.com/review/linux-70-filesystems/4 mit default Einstellungen auf 1 nvme ist xfs in allen DB Tests schneller als ext4.
"Die Extents-Architektur reduziert Fragmentierung und hält Zugriffe auf große Dateien effizient." - Gilt genauso für xfs und ist sofern kein ext4 Alleinstellungsmerkmal.
xfs:
"Für XFS sind su/sw (Stripe Unit/Width) beim Erzeugen wichtig, damit Allokation zu RAID passt. && Auf XFS achte ich auf Stripe-Unit/Width passend zum RAID, damit der Durchsatz stimmt." - Mehrfach verschiedene sw oder hw-raid sets mit su/sw settings getestet und immer sind jene mit solchen settings abweichend der autom. default Erstellung bei metadaten und Bandbreiten Tests paar % langsamer !!
"inode64 verhindert Hotspots in niedrigen Inode-Bereichen" - ist default, aber nicht zu verwenden, wenn man hybrid-xfs mit 2 getrennten eg. raid1/raid6 Metadaten/Daten untendrunter verwenden möchte, was ein ext4 bzgl. Millionen Files weit den Rang abläuft.
Sachen wie "echo 20 >/proc/sys/vm/vfs_cache_pressure" sind dort auch völlig unbekannt, andere wichtige Einstellungen ebenso.
"overlay2 verlangt d_type/ftype-Unterstützung; XFS muss mit ftype=1 formatiert sein, sonst brechen Hardlinks/Whiteouts in Layern." - ftype=1 ist zwangs-default in xfs v5 Format und war nur wahlweise im deprecated v4 Format vom default "abwählbar/ftype=0".
Fette Schnitzer gehen anders. Du bemängelst zurecht Dinge, die ich nicht im Auge hatte. Es lässt sich für einen groben Überblick doch schnell lesen.
 
Da stellt sich die Frage was du falsch machst. Auch die rocky updates auf unserem (15J altem Lenovo) nfs-server.zzgl. reboot tun keinem pve noch deren vm's und lxc's weh, alles hängt sich autom. wieder ein nachdem er wieder oben ist.
Machst du udp anstatt tcp mit seinen acknowledged Paketen, die beim client neu angefordert/gesendet werden, falls (wegen reboot) nicht angekommen ??
Da wir bei PVE sind. Exporte eines USB-devices auf einem PVE und einbinden als Backupziel in einem anderen PVE erzeugt das putzigste Verhalten. Trotz ordentlichem umount vor Plattenwechsel, hilft eigentlich nur der regelmässige Neustart des NFS-Servers.
 
Puuh, haha, USB-Speicher gehört sich sowieso verboten, wenn es sich nicht um Sticks handelt.
Zudem läßt sich der nfs-server restart wahrscheinlich verhindern, wenn du erst den entsprechenden export davon wegnimmst, dann erst den USB umount machst und zuletzt USB device abziehen, geht auch mit Miniscript oder alias als nur ein cmd.
 
Last edited:
  • Like
Reactions: Johannes S
Puuh, haha, USB-Speicher gehört sich sowieso verboten, wenn es sich nicht um Sticks handelt.
Zudem läßt sich der nfs-server restart wahrscheinlich verhindern, wenn du erst den entsprechenden export davon wegnimmst, dann erst den USB umount machst und zuletzt USB device abziehen, geht auch mit Miniscript oder alias als nur ein cmd.
Klingt extrem elegant;)
Warum gehören denn 8TB externe Platten an seit jahrzehnten verfügbaren Schnittstellen als Wechselmedien verboten? Weil man das schon immer per Autoloader erldigt hat? Könnte es nicht an SW liegen, die irgendwie um die Jahrtausendwende stehen geblieben ist?

Noch ein Nachschlag:
Warum kann ein PVE/PBS keine USB-Devices ootB automatisch einbinden? Stattdessen kann ich Opa-Band-Technik in einem PBS "anlernen".
Suuper Sache, man kann es ja sonst mit scripten hindengeln.
 
Last edited:
Tja, kann ich dir nicht sagen, die einen HW Entwickler denken so und die anderen SW Entweckler ggf. in die andere Richtung, aber wie so oft gilt doch immer wieder: Wer nicht mit der Zeit geht, geht mit der Zeit ... :)
 
Ohne schnellen und zuverlässigem shared storage, kannst du bzgl. HA keinen Blumentopf gewinnen. Hier wird es aber fälschlich gerne so dargestellt, da es ja Zauber-ZFS gibt.
Ja, das Shared Storage HA im Homelab kenne ich auch (nicht von mir). In der Regel besteht es aus einem TrueNAS und drei PVE Mini-PCs. Wenn das TrueNAS ausfällt, ist es mit HA vorbei.

Leute, wenn ihr zwei Kisten im Homelab habt, nutzt eine davon als Backup-Target. Und ja, nur auf einer separaten Kiste sind Backups auch wirklich Backups (okay, eine separate HDD/SSD vielleicht auch noch knapp). Wenn ihr drei Kisten habt, benutzt die zweite für mehr VMs und Container und vielleicht, so wie es der OP machen will, als HA „light”, also ZFS-Replikation für eure wichtigsten VMs und Container. Also diejenigen, wo euch eure Frau die Hölle heiß macht, wenn sie einen Tag lang nicht läuft. (Wobei, braucht ihr hier da wirklich Automation? Ich meine, eine 10 GB große Rezepte-VM ist in zwei Minuten aus dem Backup wiederhergestellt, wenn der falsche Node ausfallen sollte. ;)

Noch einmal: Backups sind das Wichtigste in der Home Production. HA ist ein Gimmick und ihr kriegt es niemals richtig hin mit Laptops, Raspberry Pi, gebrauchten MiniPCs, denn es wird genau das schieflaufen, was ihr übersehen habt. Am Ende ist es wahrscheinlich das "Desktop-NIC", welches mit dem ganzen Corosync-Traffic und den 30 VLANs überfordert ist. ;)

Falls es sich um geschäftskritische Anwendungen handelt, verlasst bitte diesen Thread und lasst euch anständig beraten. :cool:
 
Last edited:
Tja, kann ich dir nicht sagen, die einen HW Entwickler denken so und die anderen SW Entweckler ggf. in die andere Richtung, aber wie so oft gilt doch immer wieder: Wer nicht mit der Zeit geht, geht mit der Zeit ... :)
Die HW-Abteilung liefert inzwischen 20-40GBit/s und hat ihre Hausaufgaben gemacht. Die SW-Ecke befindet sich im Tiefschlaf und freut sich, wenn eine Maus kabellos funktioniert.
 
Last edited:
  • Like
Reactions: waltar
Niedlich. In meinem DB-Server fehlen als nur 2min Daten und mögliche Inkonsistenten erbe ich noch als Leckerli obendrauf?
Naja, HA auf Ebene des Hypervisors sollte man eh nur dann machen (imho), wenn die Anwendungen das nicht nativ können. Und so ziemlich jede ernsthafte SQL-Datenbank hat selbst Clusteringmöglichkeiten. Wer die dann nicht einsetzt (etwa weil man unbedingt meint Veeam benutzen zu müssen, was bei MySQL/MariaDB und Postgres keine Backups von Clustern unterstützt) ist dann, sorry, not, sorry selbst schuld. Und der kleinste mögliche Intervall ist eine Minute, das ist nicht für alle Sachen akzeptabel, aber für z.B. einen Loadbalancer oder Software zur Steuerung von Posteingängen und Ausgängen (da kriegt man ja mit, wenn was fehlt) reicht das ja. Das ist eben mein Punkt: Ob das ok ist oder nicht, hängt vom Usecase ab.

HA ist ein feststehender Begriff, der nicht so fahrlässig genutzt werden sollte.

Ich habe noch nie NFS als akzeptables Speicherziel tituliert. Sich immer auf Homelab zurückzuziehen, ist auch nicht valide.

In diesen Thread schreibt aber halt jemand, der sich seinen Heimserver neu aufsetzt. Und die portugiesische Apotheke oder die öfter erwähnten Mittelständler würde ich jetzt nicht als Homelab betrachten.
 
Zudem sollte man bei xfs immer vorm 1. mount an quotas aktivieren. Je mehr Platten (hdd/ssd/nvme) desto größer und schneller ist ein xfs.

Wie machst du das mit den mehr Platten bei xfs? Über HW-Raid oder lvm/mdadm? Ich bin immer davon ausgegangen, dass xfs immer ein konkretes Device braucht, weil da eben (anders als bei zfs oder btrfs) kein eigener Volumemanager und SW-RAID-Stack mit bei ist.