PVE Datastores mit verschiedenen knotenabhängigen ZFS-Zielen

[carsten2]

Man kann für jeden Datastore festlegen, dass er nur auf bestimmten Knoten vorhanden ist.
Ich habe aber das Problem, dass ich den Datastore zwar überall haben will, aber für jeden Knoten einen anderes ZFS-Dateisystem als Ziel brauche.
Wie kann das eingerichtet werden?

 

[Falk R.]

Wenn du ZFS Dateisysteme brauchst, kannst du dir in deinem Pool einfach welche anlegen und in der GUI nur für den jeweiligen Node hinzufügen.
Mir stellt sich nur die Frage warum du verschiedene Dateisysteme brauchst. Eventuell gibts für deinen Bedarf ja eine schönere Lösung.

 

[carsten2]

Ich will VMs zwischen den verschiedenen Nodes replizieren. Dazu müssen Sie auf einem Datastore mit demselben Namen sein, da dieser ja in in der VM configuration erwähnt ist. Die physikalischen Pools auf den einzelnen Nodes sind aber sehr unterschiedlich, so dass ich denselben logischen Datastore-Namen bei verschiedenen Nodes auf verschiedene physikalische ZFS-Dateisystem legen will bzw. muss.

Unter anderem ist ein Anwendungsfall, dass ich auf allen einen ZFS-HD-Pool habe, aber auf einzelnen einem Node einen zweiten ZFS-Pool mit schnellem NVME. Ich möchte jetzt also den zwei logische datastores haben "dataslow" und "datafast". Auf dem einen Node würde datafast auf das ZFS-Dateisystem mit dem schnellen NVME-Speicher zeigen, auf den andern beiden Nodes einfach ein Unter-ZFS-Dateisystem des einzigen (langsamen pools). Damit kann ich die Maschinen nach belieben hin- und herschieben und habe auch Ausfallsicherheitl und kann aber stark belastete VMs einfach auf den Node schieben, wo hinter datafast auch tatsächlich der schnelle NVME-Speicher ist.

Dazu müsste halt auf diesem einen Node der logische Datastore auf einen anderen ZFS-Dateisystem-Namen zeigen.

Es ist ja vorgesehen, dass Datastore logisch nur bei bestimmten Knoten vorhanden sind. Es wäre aber sinnvoll den Datastore so "mehrfach anlegen" zu können, dass er nur insoweit clusterweit eindeutig sein muss, als dass es der Namen auf jedem einzelnen Node eindeutig ist.

Ich würde also anlegen:
Node 1+2: dataslow -> myzfspool, datafast -> myzfspool/datafastfake
Node 3: dataslow -> myzfspool, datafast -> mynvmepool

Der Datastore-Name "datafast" wäre auf jedem Knoten eindeutig definiert.

 

[Falk R.]

Ich weiß gar nicht ob Replikation zwischen ZFS Dateisystemen funktioniert, habe ich einfach noch nie getestet.
ZFS Replikation machst du in de Regel zwischen den ZFS Pools, weshalb die Pools den gleichen Namen benötigen.
Ich würde einfach die Pools identisch nennen und mir dann eine Notiz machen auf welchem Host das schnelle und wo das langsame ZFS ist.

 

[carsten2]

Man kann Dateisysteme beliebig nennen und replizieren. Name ist egal.
Der eigentliche Name (also letetzte Teil des Namens) soll sich ja auch nicht ändern, sondern nur das Vaterdateisystem soll verschieden sein.

Schau dir nochmal das Beispiel mit dataslow und datafast an. Wenn man von die VM 222 von 1 nach 2 repliziert, liegt sie dann auf einem anderen Pool. In der VM steht immer datafast/disk-1 aber auf Node 1 liegt sie physikalisch auf myzfspool/datafastfake/vm-222-disk1 und auf Node 2 auf nvmepool/vm-222-disk1. Auf Node 2 gibt es AUCH den Pool langsamen myzfspool, daher kann ich nicht überall denselben Komplettpfad haben.

Würde ich auf allen Nodes einen zweiten physikalischen Pool mit Namen mynvmepool einbauen, wäre das kein Poblem, nur geht das platzmäßig nicht.

Ein etwas umständlicher Workaround wäre, den Pool mynvmepool als auf den Nodes 1+2 als Pool auf einem ZVOL oder einer Datei einzurichten, aber dann fahre ich ja ZFS auf ZFS, was auf die Performance gehen könnte.

Das entscheindede Konzept ist eigentlich schon und und es eigentlich nur die Möglichkeit, die schon vorgesehene Indirektionsstufe Datastorename auf ZFS-Name Node-weise statt Clusterweise einrichten zu können. Evtl. geht das ja schon nur weiß ich nicht wie.

 

[Falk R.]

Du kannst dir ja Dateisysteme bauen wie du willst, aber sobald du ZFS Dateisystem benutzt, musst du wieder auf qcow2 oder andere Dateiformate zurückgreifen und hast dann immer ein Dateisystem mehr dazwischen.
Das schöne an dem Konzept, nur den Diskpool zu nutzen und da Volumes raus zu schneiden ist, dass du das erste Dateisystem in der VM anlegst.
Deshalb sind die VMs ja auch schneller im Diskzugriff als bei VMware ESXi oder HyperV, denn da hast du immer ein Dateisystem dazwischen was Overhead schafft.
Wo ist das Problem, den Pool auf allen Servern gleich zu nennen?
Du kannst auch die Pools verschieden nennen und nutzt nicht die Proxmox Replikation sondern baust dir das auf der CLI selbst .

 

[carsten2]

Nein. Die ZVOL liegen gerade nicht im Pool selbst sondern in einem ZFS-Dateisystem. Wenn du einen zpool anlegst, wird gleichzeitig ein gleichnamiges ZFS-Dateisystem angelegt. Darunter kannst du denn weiter beliebig tief weiter ZFS-Dateisysteme und darunter wiederum ZVOLs anlegen. Das Eltern-Filesystem eines ZFS-Dateisystems oder ZVOLs kannst du mit zfs rename ändern, also wie ein Verzeichnis woanderes in den Baum innerhalb desselben zpools verschieben. Allerdings geht das natürlich nicht Pool-übergreifend. Und natürlich soll ZVOL und nicht QCOW2 verwendet werden.

Wie schon oben dargestellt, habe ich auf einem Knoten zwei Pools: einen schnellen kleinen NVME- und einen langsamen großen HDD-Pool. Die müssen offensichtlich verschiedene Namen haben. Ich will auf diesem einen Knoten den logischen pve-datastore "datafast" auf den schnellen Pool legen und auf den anderen Nodes (wo kein NVME da ist) ihn zusammen auf dem großen HDD-Pool haben. Wie oben bereits erklärt.

Wenn dann eine eine kleine Menge von VMs hohe Performanceanforderungen hat, kann ich die einfach per Proxmox-UI auf diesen schnellen Konten verschieben. Wenn sich das ändert verschiebe ich sie wieder auf irgendeinen anderen Node und kann irgendeine andere in den schnellen Pool schieben. Und alles ohne, irgendwelche eigenen Skripte zu schreiben, die dann wieder mit der Proxmox-GUI ggf. inkompatibel sind.

Dazu müsste nur die schon vorhandene Indirektion datastore-Name -> ZFS-Name pro Knoten korrekt geprüft und berücksichtigt werden.

 

[fabian]

so ein "node override" fuer einzelne aspekte des storage.cfg eintrags ist derzeit nicht vorgesehen.

 

[carsten2]

so ein "node override" fuer einzelne aspekte des storage.cfg eintrags ist derzeit nicht vorgesehen.

Man müsste einfach nur zwei mit demselben Namen anlegen können, die sich aber bzgl. der zugeordneten Nodes disjunkt unterscheiden.
Irgendein anderer Anwender hatte das hier schon mal wohl so benutzt aber es ist offiziell wohl nicht unterstützt.
Wäre das nicht eine sehr einfache Verbesserung, diese Konfigurationsart zuzulassen? Dann könnte man diese Indirektionsstufe datastore -> ZFS-Name vollständig nutzen.

Oder gibt es eine andere Lösungsmöglichkeit für das Problem?

 

[fabian]

technisch liesse es sich natuerlich umsetzen, aber es verkompliziert die interfaces dafuer, dass 99% der cluster da draussen so eine verschachtelung nicht benoetigen..

 

[UdoB]

da 99% der cluster da draussen so eine verschachtelung nicht benoetigen..

Immerhin ist Carsten nicht der Erste, der sich so eine Möglichkeit für ein Homelab wünscht: https://forum.proxmox.com/threads/datastore-emulating-one-by-another.106777/

 

[fabian]

klar. das trifft auf sehr viel zu das wir nicht implementieren (wollen) in dem fall gibt es ja einen validen work-around (pve-zsync oder haendisches zfs send/recv statt PVE replication), daher steht der aufwand und die komplexitaet auf config (handling) seite nicht dafuer.

 

[carsten2]

klar. das trifft auf sehr viel zu das wir nicht implementieren (wollen) in dem fall gibt es ja einen validen work-around (pve-zsync oder haendisches zfs send/recv statt PVE replication), daher steht der aufwand und die komplexitaet auf config (handling) seite nicht dafuer.

Die Komplexität sehe ich nicht so wirklich. Wenn ein Node auf einen Datastore-Namen zugreift, muss er einfach nur den eindeutigen Namen nehmen, bei dem er auch eingetragen ist. Dieser Code muss ja ohnehin fast oder komplett schon da sein, da man ja einem Datastore Namen sagen kann, auf welchen Knoten er verfügbar ist. Und ich meine hier irgendwo gelesen zu haben, dass jemand das mit händischem Editieren sogar gemacht hat.

Von Hand geht das nicht, da man dann alles über die Oberfläche verliert: Backup, Replikation, Move usw.

Was ist denn die Alternativlösung für das obige Problem, das ja auch im Enterpriseumfeld auftaucht?

 

[Falk R.]

Die Komplexität sehe ich nicht so wirklich. Wenn ein Node auf einen Datastore-Namen zugreift, muss er einfach nur den eindeutigen Namen nehmen, bei dem er auch eingetragen ist. Dieser Code muss ja ohnehin fast oder komplett schon da sein, da man ja einem Datastore Namen sagen kann, auf welchen Knoten er verfügbar ist. Und ich meine hier irgendwo gelesen zu haben, dass jemand das mit händischem Editieren sogar gemacht hat.

Von Hand geht das nicht, da man dann alles über die Oberfläche verliert: Backup, Replikation, Move usw.

Was ist denn die Alternativlösung für das obige Problem, das ja auch im Enterpriseumfeld auftaucht?

Im Enterprise Umfeld tritt das nicht auf. Entweder hat man Homogene Cluster oder bei ganz kleinen Unternehmen, ist ein stärkerer und ein schwächerer Host, dann läuft in der Regel eh alles auf dem dicken Hobel und der „data-Pool“ ist auf dem Failovernode trotzdem gleich benannt. Das weiß man ja, dass die Platten da langsamer sind.
Und im großen Umfeld mache ich eh nur Ceph.
Das Feature ist wirklich nur für Leute im HomeLab, die sich nicht merken können wo die schnellen Platten sind.

 

[carsten2]

Das Feature ist wirklich nur für Leute im HomeLab, die sich nicht merken können wo die schnellen Platten sind.

Nein. Es geht doch nicht um das "Merken", sondern darum, dass man Hosts verschieden ausrüsten kann. Je mehr Knoten man hat (also Enterprise), desto häufiger eher hat früher oder später das Problem Es ist dauerhaft kaum durchhaltbar, eine ganze Reihe von Nodes über Jahre physikalisch identisch auszurüsten. Also hat man auf die dauer unterschiedliche Hosts mit unterschiedlichen Pools. Damit alles problemlos weiterläuft, muss man nun bei einzelnen Hosts die logischen Namen der Datastores auf andere physikalische Pools umleiten können.

 

[Falk R.]

Ich betreue auch Kunden die PVE schon seit vielen Jahren einsetzen.
Alle Cluster über 3 Knoten nutzen Ceph und die meisten sind Homogen, da wird alle 5-6 Jahre die Hardware getauscht.
Heterogene Cluster kann man auch mit unterschiedlicher Hardware, "Leistungsähnlich" halten, was bei Ceph natürlich einfacher geht.
Das Setup mit ganz vielen Hosts und ZFS Replika ist mir noch nicht unter gekommen, weil das wird wirklich ganz schnell unübersichtlich.

 

[carsten2]

Habe gerade wieder das Problem. Wegen Wartungsarbeiten an einem Hosts A muss ich die VMs mit storagename "storage-zfs2" (zeigt auf den ZFS-Pool data2/zfs2) auf einen anderen Host B migrieren. Nur geht das nicht, weil auf dem Zielhost B zwar eigentlich genügend Platz ist, aber dieser gesamte Platz dem von einem einzigen ZFS-Pool (data1/zfs1) angenommen wird, auf den der Proxmoxbox storage "storage-zfs" zeigt. Einfach wäre jetzt, wenn ich auf Host B diesen storage-zfs2 auch einrichten könnte, nur der halt auf DIESEM host einen anderes Ziel, nämlich storage-zfs2 zeigt bei dem Host auf data1/zfs2 (statt auf data2/zfs2). Dann würde alles weiterlaufen, also Replikation mit andernen Server, Backups usw. Von außen würde man praktisch gar nichts merken. Die simple einfach Unterschied ist, dass die Storage-Name bei jedem Host auf eine anderes physikaliisches Ziel zeigt.

Jetzt habe ich zwar viel Speicher frei, aber halt dem "falschen" Pool-Namen zugeornet und ich komme aus dieser Sackgasse nicht heraus.
Momenten geht das nur, wenn man die Platten auf Host B zu umpartitioniert, dass man auf einer zweiten Partition den einen weiteren Pool data2/zfs2 halten könnte. Aber dafür muss man halt den gesamten Pool neu einrichten, was praktisch unmöglich ist, da man doppelt so viel Speicher braucht und das Tage dauert. Außerdem sehr unschön.

Dabei wäre die Lösung sehr einfach: Proxmox benutzt für VMs ohnehin schon virtuelle Storage-Namen, die dann von physikalischen Namen abstrahieren auf einen konkreten loklen, ZFS-Pool zeigen und daher eine Indirektionstufe. Das einzige, was fehlt, ist, dass man den Storage-Namen pro Host statt pro Cluster konfigurieren kann.

Das würde sehr viel Flexibilität bringen, speziell in Migrations-oder Notfall-Scenarios.

 

[Falk R.]

Ich würde sagen, diese extra Abstraktionsschicht bringt eher mehr Arbeit mit sich.
Wenn man sein Storage von vornherein gut plant, dann hat man ja kein Problem.
Ich würde die kleineren VMs auf einen anderen Node migrieren (Mit Storage kopieren) und dann auf dem leer gewordenen Host den Pool neu anlegen. Dann Replika einrichten und fertig.

 

[carsten2]

Es gibt keine Planung, die ewig hält. Man muss migieren, erweitern, neue Hosts einrichten, alte außer Betrieb nehmen, Speicherplatz erweitertn, Platten tauschen und erweitern usw.

Ich kann aber nicht hingehen und einfach einem Multi-Host-System alle Platten aller Hosts gleichzeitig autauschen und gleich einrichten, schon allein, weil man man das erhebliche Ausfallzeiten bedeuten würde. Also muss man temporär VMs möglichst Live und ohne Ausfall irgendwo hinschieben können.

Ich habe z.B. einen Host, normalerweise nur für Backup mit sehr großem und vergleichsweise langsamen Speicher (alles in einem Pool). Jetzt will ich für die Migrationsszenatio die VMs andere Hosts dort hinschieben können, wo sie laufen (wenn auch langsamer) oder für ein Notfall-Szenario bestimmte die VMs immer dort hinreplizieren, damit ich im Notfall diese VMS direkt auf dem Backup-Host direkt starten kann.

Proxmox kann das alles, das einzige was fehlt, ist dass man den Storage Namen pro Host konfigurieren kann. Auch ist es extrem unpraktisch, wenn man große Pools aufteilen müsste, nur weil es Hosts mit anderen Poolnamen gibt (die auch ihren Sinn haben).

Damit hätte man mit Abstand am wenigsten Arbeit, weil man halt den virtuellen Storagenamen von Proxmox beliebt auf phasikalische Resourcen mappen kann. Das würde auch der Logik entsprechen, virutellen Storagename sind grundsätzlich global, aber die physische Ressourcen sind naturgemäß lokal, so dass es auch sinn macht, das Mapping globaler-Storage name auf physikalischen Storage-Namen lokal (also pro Host zu definieren).

Aktuell verliert der virtuellen Storage-Name viel Wert, da die fehlende Zuordnungsmöglichkeit gleiche physikalische Namen auf allen Hosts erzwingt. Woraum dann überhaupt so eine Indirektionsstufe? Man könnte quasi gleich den physikalischen Storagenamen verwenden. Die Idee mit der Indirektionsstufe ist sehr gut, nur halt kurz vor dem Ziel nicht ganz zu Ende gedacht, nämlich dass die Zordnung Virtuell->Physisch pro physischem Host (statt global) passieren muss.

Und das ist nicht mehr Arbeit, sondern in sehr vielen Fällen DRASTISCH WENIGER Arbeit, als was bisher geht.

 

[UdoB]

Der Vollständigkeit halber: manuell geht Migration inklusive Storagewechsel ("Target storage:") mittlerweile sowohl per GUI (anscheinend nur für Live-Migration) als auch auf der Kommandozeile per "qm remote-migrate". (Nicht getestet.)

Tricks um die ZFS-Replikation per GUI zu nutzen kenne ich aber leider nicht...