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

[Johannes S]

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.

Sowas liegt so gut wie immer daran, dass jemand geglaubt hat, dass er nur mit einer Netzwerkkarte für alles auskommt. Es hat schon Gründe, warum in der Doku empfohlen wird, bitte ein eigenes Cluster-Netzwerk auf eigenen Karten zu haben und das bereits vorhande nur als Fallback zu konfigurieren:
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network

Ich glaube, das hatten wir sogar schon hier im Thread oder war das ein Anderer? Das ist natürlich bei Mini-PCs nicht so leicht machbar, aber selbst die eher frickeligen USB-Netzwerkkarten sind dann besser als gar nichts. Wenn du das nicht gewährleisten kannst, dann nimm besser pve-zsync (https://pve.proxmox.com/wiki/PVE-zsync Damit kannst du die VMs und LXCs mittels zfs auch ohne Cluster replizieren, HA geht dann aber NICHT, man muss dann ggf. die VMs/lxcs von Hand starten) und/oder den Proxmox DataCenter Manager für Migrationen zwischen den Knoten. Backup braucht es freilich trotzdem, ich würde dafür auf beiden Mini-PCs einen ProxmoxBackupServer drauf packen, der dann die VMs/Container des anderen sichert. Diese Backups dann halt noch zusätzlich auf eine USB-Platte sichern (geht als removable datastore) oder auf einen Vserver mit PBS, Cloud-PBS-Speicher oder s3 storage als offsite-Backup,

 

[TErxleben]

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.

Uff. Eine DB soll also HA herstellen, während Proxmox HA als Feature propagiert und sonst ist man doof?

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.

Gerade in der Situation sollte man keine Dinge vorspiegeln, die nicht erfüllbar sind. Egal ob eine portugiesische Apotheke so ein Risiko eingeht.
Kurz zusammengefasst: Kein zuverlässiger zentraler Speicher, keine HA.

 

[Johannes S]

Uff. Eine DB soll also HA herstellen, während Proxmox HA als Feature propagiert und sonst ist man doof?

Nein, generell sollte man die HA einer Anwendung benutzen, ich sehe die HA-Features eines Hypervisors generell nur als Notbehelf, wenn das nicht anders geht. Denn: Die Entwickler einer Anwendung können auch deren Spezialfälle berücksichtigen, was der Hypervisor nun mal nicht kann. Ich habe ja schon unsere Poststelle erwähnt, wenn deren Software nicht funktioniert ist das ziemlich doof: Die Software erkennt im Grunde um was für eine Art Schreiben es sich handelt und druckt einen speziellen Strichcode, mit dem dann eine bestimmte Maschine das passend kuvertiert. Damit wurde den Kollegen dort ein Haufen nerviger Handarbeit abgenommen. Wenn das System mal ausfällt, dann muss die Sortiererei und Kuvertiererei wieder von Hand gemacht werden, es entsteht dann ziemlich schnell ein Rückstau. Leider ist die Software propietär und läuft nur unter Windows, bei uns also in einer VM in Vmware, sie hat selbst keine HA-Funktionen. Für so einen Fall ist ein HA-Feature des Hypervisors Gold wert, eine "richtige" Hochverfügbarkeit in der Anwendung wäre mir aber trotzdem lieber, weil darüber auch Transaktionssicherheit gewährleistet werden könnte, geht in den Fall aber auch ohne. Unsere Postleute kriegen ja mit, ob ihre Ausdrucke rauskommen und sortiert werden, oder nicht Bei SQL-Datenbanken für einen Webshop will ich dagegen auf die Transaktionssicherheit nicht verzichten und die muss auf Datenbankebene garantiert werden, ergo über einen Datenbankcluster. Dass Veaam-Opfer darauf verzichten, weil diese "Enterprise"-Software application-aware Backups für MariaDB/MySQL und Postgres nicht unterstützt, spricht in meinen Augen nur gegen Veeam, nicht gegen den Datenbankcluster. Und für Webanwendungen skalieren Loadbalancer schlicht besser (nicht nur für Hochverfügbarkeit) als das HA des Hypervisors. Für den Loadbalancer selbst muss man sich natürlich fragen, ob man dessen Verfügbarkeit über den Hypervisor macht oder ob man sich mit rsync/corosync/keepalived selbst was bastelt und wie komplex es werden darf.

Gerade in der Situation sollte man keine Dinge vorspiegeln, die nicht erfüllbar sind. Egal ob eine portugiesische Apotheke so ein Risiko eingeht.
Kurz zusammengefasst: Kein zuverlässiger zentraler Speicher, keine HA.

Hast du https://www.proxmox.com/de/ueber-uns/ueber-uns/stories/story/farmacia-nova-da-maia-de überhaupt gelesen? Bei denen werden die VMs alle fünf Minuten repliziert und nach Darstellung ihres IT-Managers hat das (in Kombination mit auf mehrere Standorte verteilen PBS) ihre Infrastruktur deutlich robuster und zuverlässiger gemacht, ohne unnötiges Overengineering. Ich behaupte mal, dass der besser als du abschätzen kann, ob das für deren Usecase ok ist oder nicht, immerhin hängt da seine Arbeitsstelle dran Bei einer Bank oder Logistikunternehmen würde mich dagegen eher wundern, wenn da fünf Minuten egal wären.

Generell ist mein Problem mit deinen Beiträgen, dass du einfach sehr von deiner KMU-Blase ausgeht (wie die Story dass du Azubis mit ganzen Servern (!) für Backups durch die Republik schickst, in meinen Augen eine unfassbare Verschwendung von Personal - und sonstigen Ressourcen ), die für andere Firmen oder Umstände so nicht zutreffen müssen.

 

[waltar]

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.

1.) Normal nie, idR zieht man auf einen Datenparkplatz um, erstellt neues raidset, neues xfs und danach Daten zurück. Meistens bietet sich hier auch meistens ein mayor OS update per kompletter Neuinstallation mit an (rhel 3->4->5->6->7->8->9->10). IdR am WE oder in Sommer/Winter Urlaubszeit.
2.) Bei mdadm swraid zB:
mdadm --add /dev/mdX /dev/sdY # add 1 disk or eg for raid10 2 disks
mdadm --grow /dev/mdX --raid-devices=<new-total-count>
xfs_growfs /dev/mdX # while unmounted (or maybe mounted xfs_growfs /mountpoint)
3.) Bei HPE ssacli:
ssacli ctrl slot=0 array A modify expand ...
ssacli ctrl slot=0 ld all show # check expansion done and then:
ssacli ctrl slot=0 ld 1 modify size=max forced
xfs_growfs /dev/sdX
4.) Bei Dell:
perccli /cx/vx start migrate type=raid10 option=add drives=e:s-x
perccli /cx/eY/sZ show rebuild
xfs_growfs /dev/sdX
5.) Bei LSI chip:
storcli ... (analog perccli)

 

[Bu66as]

Der reihenweise Reboot beider Nodes ist so gut wie sicher kein NVMe-Problem, sondern Corosync das sein Token verliert und die HA dann fenced. Über 300 mal beide zusammen neu gestartet passt genau dazu. Bei nur einer NIC für alles ist der Klassiker: deine ZFS-Replikation ballert den Link voll, Corosync kommt nicht mehr durch, Quorum weg, Node fenced sich raus. Schau mal mit journalctl -u corosync auf beiden, kurz bevor es knallt steht da sowas wie "token has not been received" bzw. retransmit.

Bevor du alles neu aufsetzt würd ich das erst fixen, sonst hast du's nachher wieder. Auf den Minis ist ein zweiter Ring das einfachste: billige USB-NIC in beide, direkt per Kabel zwischen die zwei Kisten, als link1 für Corosync mit rein. Dann killt dir die Replikation den Cluster nicht mehr. Und den Pfad zum QDevice-Pi im Auge behalten, wenn der zickt flappt's genauso.

Split macht Sinn. Der ganze Kleinkram-Schreib (pmxcfs, Corosync, Logs) landet auf der OS-Disk, drum die billigere SATA-SSD fürs OS und die NVMe für die VMs, dann schonst du die teurere Platte. TLC-Consumer reicht im Homelab locker solang du den Wearout beobachtest. PBS als VM auf die SATA ist ok, nur nicht als einzige Kopie, liegt ja auf derselben Kiste. Gegenseitig auf den anderen Node bzw. aufs Synology sichern, dann passt's.

 

[Johannes S]

Mit den split hat er dann aber nicht mehr die Redundanz eines Mirrors. Natürlich muss jeder selbst wissen, wie er Vor- und Nachteile gewichtet. Aber ich persönlich habe auf meinen Mini-PCs eine Consumer-NVME und eine gebrauchte Enterprise-SSD im Mirror, damit beim Ausfall einer der beiden Laufwerke (realistisch das NVME) das System noch weiter läuft. Ob man bereit ist, den dann nötigen Austausch der defekten Disk einzupreisen, muss aber natürlich jeder selbst wissen.

 

[Bu66as]

Stimmt schon, ist halt Abwägung. Bei ihm liegt die Redundanz aber eh auf dem zweiten Node, ZFS-Replikation plus Backup fängt einen Plattentod ab, halt mit Restore-Aufwand statt weiterlaufen. Ob einem das die zweite Platte wert ist, muss er selbst wissen.

Das löst ein Mirror aber nicht: sein Ausgangsproblem war ja TBW. Im Mirror schreibt ZFS jeden Block auf beide Platten, der ganze pmxcfs/Corosync-Kleinkram inklusive. Die Consumer-NVMe kriegt also weiter dieselbe Schreiblast wie vorher ab, nur dass sie diesmal nicht alleine stirbt. Beim Split landet der Dauergeschreibsel-Anteil auf der billigen SATA und die NVMe sieht nur noch VM-IO. Deshalb würd ich in dem Fall zum Split tendieren, aber das ist wirklich Geschmackssache.