PVE Datastores mit verschiedenen knotenabhängigen ZFS-Zielen

[Falk R.]

Dataset ist meiner Ansicht nach eigentlich der Oberbegriff für ZFS-Volume und ZFS-filesystem, wird aber manchmal nicht einheitlich verwendet. letzlich liegen Volumes und Filesystems unter einem anderen anderen Filesystem (ggf. dem Root-Filesystem des ZFS-Pools). Der Trick wäre jetzt, dass das Root-Filesystem für den ZFS-Storage optional nicht anhand des Namens sondern nach seinem Mointpint bestimmen kann (also eine einfache Namensauflösung).

Sämtliche ZFS-Kommandos müssen natürlich immer den offiziellen Dataset-Namen (ohne /) verwenden.

Genau das ist das Problem. Unter Storages kannst du ja deine Mountpoints hinzufügen, aber da die ZFS Kommandos im Hintergrund mit dem richtigen ZFS-Pool Namen arbeiten müssen, ist dieser Name hinterlegt, damit die Replikation auch funktioniert.
Man müsste eine extra integration schreiben, wo man in der GUI einen Anzeigenamen hat und dann pro Host einen Pool angeben kann. Dann brauchen wir einen Übersetzer, der für die ZFS Kommandos den richtigen Pool auf dem jeweilgen Host anspricht.

Die Erweiterung wäre jetzt nur, dass dieser Dataset-Name nicht direkt im Storage drinsteht, sondern optional sein Mountpoint, so dass ich den auf ZFS-Ebene verändern kann. Proxmox müsste jetzt nur den echten Dataset-Namen des Storages über den Mountpint bestimmen und dann geht alles wie bisher. Das wäre dann auch recht ähnlich zu Proxmox-File-Storages, wo man (natürlicherweise) ja auch den Mountpoint und nicht den physischen Filesystem-Namen referenziert.

 

[carsten2]

Mit meinem zweiten Vorschlag, die ZFS-Mountpoints auszuwerten, ist doch gerade keine GUI-Änderung erforderlich (außer ggf. am Anfang des Zielnamens ein "/" zuzulassen). Wo ist denn jetzt das große Problem? Proxmox müsste nur statt das Storage-Ziel als ZFS-Name zu nehmen, auf dem jeweiligen Host nachschauen und über den Mountpoint den ZFS-Namen bestimmen.

Ähnlich machen das z.B. uach Urbackup und zwar sowohl auf Server und Client. Man gibt für die Client dort einen zu sichernden Pfad an, und dann sucht Urbackup über die Mountspoints das übergeordnete ZFS-Dateisystem, macht einen Snapshot für Konsistenz darauf, und sichert dann den angegebenen Pfad. Der Zielpfad auf dem Server ist ebenfalls nur ein normaler Pfad. Urbackup schaut dann, ob der zu einem ZFS-Dateisystem gehört, sucht den entsprechenden übergeordneten ZFS-Namen heraus und arbeitet dann mit diesen Namen für alle ZFS-Operationen.

 

[Falk R.]

Aber dazu muss eine extra routine eingebaut werden, weil sich das dann von allen anderen Shared Storages unterscheidet.
Ich verstehe auch nicht das Problem einen Fast-Pool auf jedem Host Fast-Pool zu nennen und mit Slow das gleiche.
Dann ist das übersichtlich für jeden. Ich glaube wir drehen uns im Kreis. Du kannst ja mal einen Bugzilla Request aufmachen mit deiner Idee, mal sehen was das Team dazu sagt.

 

[carsten2]

Aber dazu muss eine extra routine eingebaut werden, weil sich das dann von allen anderen Shared Storages unterscheidet.
Ich verstehe auch nicht das Problem einen Fast-Pool auf jedem Host Fast-Pool zu nennen und mit Slow das gleiche.
Dann ist das übersichtlich für jeden. Ich glaube wir drehen uns im Kreis. Du kannst ja mal einen Bugzilla Request aufmachen mit deiner Idee, mal sehen was das Team dazu sagt.

Also dass es eine Änderung / Verbesserung ist, habe ich ja gesagt. Also ist klar, dass man dafür Code ändern muss.

Und es unterscheidet sich auch nicht so wirklich, denn es gibt ja kein generisches Shared-Storage sondern explizit ein ZFS-Modul, dass speziell auf ZFS abgestimmt ist. Dort soll halt nur die Art und Weise der ZFS-Namenbestimmung erweitert werden.

Das ursprüngliche Problem ist, dass große Pools sich nicht so einfach umpartitionieren lassen und man würde mit der Änderung erhebliche Flexibilität bekommen, den die Speichersicht neu zu konfigurieren. Wenn ich also z.B. eine Backup-Server mit einem einen einzigen großen Pool habe, kann ich jetzt nicht alle Maschinen, die auf anderen Hosts auf verschiedenen Pools liegen dort hinreplizieren, weil der ZFS-Name überall gleich sein muss. Ich müsste also auf dem Backup-Server auf den Platten für jeden Pool eigene Partitionen anlegen und dann mehrere Pools auf denselben Platten laufen lassen (unschön, langsam und Speicherplatzverschwendung) oder noch viel mehr Platten einbauen (teuer, unflexibel bzw. Gehäuse-Beschränkungen). Das ist alles sehr unprakisch. Mit meinem Voschlag kann man den Speicher auf jedem Host so umkonfigurieren, dass die logische Sicht passt.

 

[waltar]

Ist echt ein Spezial-Problem, daß nur auftritt, wenn man zfs benutzt ...
Aber die Idee mit dem bugzilla Request ist doch garnicht so verkehrt - noch nicht abgeschickt ?!?
Btw. hätte ja auch noch gerne einen Button oder pulldown Menü für Node Maintenance Mode im Web-UI ...

 

[Falk R.]

Btw. hätte ja auch noch gerne einen Button oder pulldown Menü für Node Maintenance Mode im Web-UI ...

Da gibt es glaube ich auch schon einen Request für, einfach mal mit anhängen und Druck machen.