Downsizing meines Setups (NFS als HA?)

[ramba.zamba]

Hallo. Ich betreibe aktuell einen 4-Knoten-Cluster mit Ceph auf einem dedizierten 25G Netzwerk. Das läuft alles geschmeidig, aber ich muss aus Kostengründen deutlich reduzieren Ich überlege daher, einen 2-Knoten-Cluster mit Quorum daraus zu machen und Ceph zurückzubauen.

Die Herausforderung: Ich brauche trotzdem ein in verschiedenen VMs mountbares Dateisystem (quasi der Ersatz für CephFS) und das mit möglichst hoher Verfügbarkeit (Ausfall/Blockierung der VMs nur für wenige Sekunden). Eine einfache NFS-Server-VM mit ZFS-Snapshots und per PVE-HA hin- und herzuschieben bringt mir noch zu viel Unterbrechungszeit mit sich. Alles andere ist bereits redundant ausgelegt - OPNsense, Reverse Proxy, Webserver, Datenbank...)

Gibt es also praktikable (und noch vernünftig administrierbare) Lösung, um ein Blockstorage zwischen zwei PVE-Knoten möglichst hochverfügbar aufzusetzen? Ich habe da (irgendwo) etwas von Linstor gelesen und das mit einem Master-Slave-NFS-Server (per Keepalived) einzubinden. Ist das Best Practise? Hat jemand einen Tipp?

(BTW: Es geht um mind. 4 Mio. kleine Dateien, meist PDFs zwischen 40-300 kB)

 

[Bu66as]

Für zwei Nodes ist DRBD bzw. Linstor der übliche Weg. Die Idee wäre eine DRBD-Resource, die synchron zwischen beiden Nodes gespiegelt wird (Protocol C). Darauf kommt ein Dateisystem, und davor läuft ein Active/Passive-NFS-Server. Das Umschalten - DRBD promoten, mounten, Floating IP setzen, nfsd starten - muss in der richtigen Reihenfolge passieren. Dafür gibts Pacemaker oder schlanker den drbd-reactor mit dem Promoter-Plugin von LINBIT, die haben dazu auch eine fertige HA-NFS-Anleitung. Mit einer selbstgebastelten Keepalived-Lösung baust du dir sonst schnell einen Split-Brain.

Zum Quorum: DRBD braucht genauso einen Tiebreaker wie Corosync. Mit DRBD 9 kann ein dritter Host als diskless Node mitmachen. Wie willst du das Quorum für den 2-Knoten-Cluster lösen, per QDevice? Dann bietet sich derselbe Host dafür an. Ohne den würde ich das nicht produktiv fahren.

Bei den "wenigen Sekunden" musst du aufpassen. Der Failover selbst geht recht schnell, aber NFSv4 hat nach einem Serverwechsel eine Grace Period, per Default 90s, in der die Clients blockieren. Die kannst du in der /etc/nfs.conf mit grace-time/lease-time runtersetzen, ganz auf ein paar Sekunden kommst du aber realistisch nicht. Den NFS-State musst du außerdem mit auf das DRBD-Device legen, sonst klappt das Reclaim der Locks nicht.

Noch eine Frage: Was liegt da eigentlich drauf, und muss das wirklich ein POSIX-Dateisystem sein, oder schreibt das deine Anwendung selbst? Wenn die auch S3 kann, wäre ein repliziertes Object Storage (z.B. Garage) in den VMs oft entspannter als HA-NFS.

 

[ramba.zamba]

Hey. Danke erstmal. Ja, es würde ein QDevice zum Einsatz kommen. Wenn der Tiebreaker aber synchron laufen sollte (ähnlich wie beim Galera Cluster der garbd Arbitrator), dann hätte ich aber doch Sorge, das einfach auf einer Cloud-VM zu betreiben. Hm. Aber deine Erläuterung bestätigen das, was ich grob vorhin schon gelesen hatte (NFS-State mit sharen, Grace-Time etc.).

Wie gesagt, momentan ca. 4 Mio PDF-Dateien im Bereich 40-300kB. Ja, SeaweedFS oder etwas in der Richtung wäre wirklich besser, aber es gibt einige legacy Anwendungen, die sich den Share teilen müssen, also es muss wohl wirklich etwas POSIX-kompatibles sein.

 

[Bu66as]

Der Tiebreaker ist bei DRBD nicht synchron wie garbd bei Galera. Der garbd hängt voll in der Replikation mit drin. Der diskless Node bei DRBD kriegt AFAIK keine Writes ab, die laufen nur zwischen den beiden Nodes mit Disk und bremsen durch deren Latenz. Der dritte hält nur die Verbindung und gibt seine Stimme ab, wenn einer der beiden wegfällt. Ein paar ms mehr zur Cloud-VM tun also nicht weh. Wichtig ist, dass die Verbindung stabil ist, sonst ist bei jedem Wackler der Zeuge weg. Beim QDevice ist das ähnlich, qnetd ist extra dafür gebaut, woanders zu laufen. DRBD-Traffic ist unverschlüsselt, den würd ich zur Cloud-VM nur durch WireGuard schicken.

Wegen der Legacy-Apps würd ich die Shares in den VMs mit hard mounten (ist eh Default). Dann hängen die Apps während dem Failover kurz, kriegen aber keine I/O-Errors, die sie vermutlich nicht sauber abfangen. Arbeiten die Apps eigentlich mit File-Locks auf dem Share? Dann unbedingt mal einen Failover unter Last testen, bevor du das produktiv nimmst.