PVE Datastores mit verschiedenen knotenabhängigen ZFS-Zielen

[Falk R.]

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.

Wenn du eine so extrem Dynamische Umgebung hast, wundert es mich, dass du ZFS nutzt. Für große dynamische Cluster nehme ich nur Ceph, da kannst du jederzeit Platten hinzufügen oder entfernen, auch einzeln. Außerdem kann man über Crush map Regeln genau sagen wie die Daten verteilt werden sollen SSD/HDD/NVMe und auch Mirror oder Erasure Coding.
Da geht immer alles im laufenden Betrieb.

So wie du das beschreibst, wäre diese Administration ein Horror für mich.

 

[carsten2]

Wenn du eine so extrem Dynamische Umgebung hast, wundert es mich, dass du ZFS nutzt. Für große dynamische Cluster nehme ich nur Ceph, da kannst du jederzeit Platten hinzufügen oder entfernen, auch einzeln. Außerdem kann man über Crush map Regeln genau sagen wie die Daten verteilt werden sollen SSD/HDD/NVMe und auch Mirror oder Erasure Coding.
Da geht immer alles im laufenden Betrieb.

So wie du das beschreibst, wäre diese Administration ein Horror für mich.

CEPH ist eine andere Lösung und Proxmox untersützt auch ZFS als eine der Haupt-Storage-Systeme. Und es geht um die simple Sache, dass man die vorhandene Indirektionsstufe Storage-Namen->ZFS-Name flexibler als bisher benutzen kann und damit viele Scenarion sehr viel einfacher, fliexbiler und mit weniger Arbeit nutzen kann.

Und was bitte soll daran "Horror" sein, wenn die den ZFS-Namen pro Host statt global definieren kann? Derzeit muss ich es ja ohnehin schon global tun, und ein zustätzlicher abweichender Eintrag für bestimmte Hosts macht definitiv keinen "Horror". Vielmehr ist es momentan "Horror" und extrem viel Arbeit, wenn man Storage ändern oder erweitern muss, oder Notfall Scenarios, weil die extrem simple Konfigurationsmöglichkeit fehlt, die einen in der Sackgasse lässt oder immense Aufwände erzeugt. Nochmal: Es geht nicht um eine NEUE Indirektionsstufe, sondern nur darum, dass die BESTEHENDE Indirektionsstufe Storage-Name->ZFS-Name (optional) pro Host definiert werden kann und damit viel flexibler ist.

Schon jetzt kann man bei einem Storage-Pool sagen, dass er nicht auf jedem Host vorhanden ist. Es gibt also schon quasi eine Konfiguration "pro Host", nur die einzige Einstellung ist "nicht vorhanden". Das müsste nur auf einen abweichenden Namen erweitert werden.

 

[Falk R.]

Die Poolnamen sind in der VM Confg und da müsste irgend ein Prozess die Namen ständig ändern bei Migrations oder HA. Da stelle ich mir sehr Fehleranfällig vor.

 

[carsten2]

Die Poolnamen sind in der VM Confg und da müsste irgend ein Prozess die Namen ständig ändern bei Migrations oder HA. Da stelle ich mir sehr Fehleranfällig vor.

Nein gerade nicht, denn in der VM-Config steht nicht der ZFS-Pool-Name sondern der Storage-Name und diese Indirektionstufe ist auch sehr gut, denn ich kann jederzeit den Storage-Namen auf einem andern ZFS-Pool umkonfigurieren, ohne etwas an den VMs zu ändern. Auch ist der Storagename, wie schon gesagt schon jetzt ein bisschen Host-spezifisch, denn es gibt pro Host die mögliche Einstellung "existiert nicht". Die erforderliche Erweiterung ist nun, dass man pro Host nicht nur "existiert nicht" sondern einen anderen ZFS-Pool-Namen angeben kann.

Beispiel:
Es gibt zwei Storage-Namen und drei Hosts. Die logische Konfiǵuration, die schon JETZT möglich ist, sieht so aus:

vmstorage1:
host1: zfsdatabig
host2: zfsdatabig
host:3: none (d.h. existiert nicht)
vmstorage2:
host1: zfsdatafast
host2: none (d.h. existiet nicht)
host3: zfsdatafast

Alle VMs benutzen nur die Namen vmstorage1 und vmstorage2. Nirgendwo wird in den VMs der physikalische ZFS-Name zfsdata/slow oder zfsdata/fast verwendet. Das ist schon mal gut. Es fehlt aber die Möglichekit das Ziel bei den Hosts verschieden festzulegen. Nehmen wir an, wir haben nun einen host4 mit einem sehr großen und schnellen ZFS-Pool. Dann möchte man folgendes einstellen können:

vmstorage1:
host1: zfsdatabig
host2: zfsdatabig
host:3: none (d.h. existiert nicht)
host4: newzfsdata/big
vmstorage2:
host1: zfsdatafast
host2: none (d.h. existiet nicht)
host3: zfsdatafast
host4: newzfsdata/fast

So könnte man ohne jegliche Änderungen alle VMs auch auf Host4 per Replikation und Live verschieben. Nach außen ändern sicht nichts, auch nicht beim Backup. Es muss nirgends etwas umkonfiguriert werden, keine Pools neu geplant, partiitioniert oder geändert werden, was extrem aufwändig wäre. Das einzige, was dafür fehlt, ist wie gesagt, die schon etwas bestehende Host-Abhängigkeit des ZFS-Ziels zu vervollständigen, so dass man statt "none" auch einen anderen Ziel-ZFS-Namen angeben kann. Derzeit kann man Namen nur gobal anlegen und pro Host abweichend dazu "none" sagen.

Anwendungen gibt es viele. ZB. ein Notfall-Standby-Host mit großen, ggf. langsamen und hochkomprimierten (ggf. sogar deduplizierten) ZFS-Pool, wohin man VMs repliziert und/oder live migriert. Im Falle eines Notfalls, könnte man Maschinen auf diesem Ersatz-Host direkt starten. Alles läuft, wenn auch langsam. Dann kann man Stück für Stück die anderen oder neuen Hosts wieder in Betrieb nehmen und die Maschinen langsam wieder umziehen. Und das geht alles LIVE und ohne aufendige Pool-Umstrukturierungen!

Auch bei Migrationsszenarien wäre das sehr hilfreich. Wichtig ist, man kann auf der physikalischen Ebene stark umkonfigurieren, ohne irgendetwas an der logischen Struktur der Storagenamen, Backups, VMS oder sonst was ändern zu müssen. Das wäre ein großer Vorteil zu jetzt.

Anmerkung: Falsches "/" im Beispiel entfernt.

 

[waltar]

Unter Linux gibt es ja auch das cmd "ln (-s)" mit dem man sowas jeweils lokal unterschiedlich erreichen kann, aber warum einfach, wenn es auch kompliziert geht ... Junge, war die Welt einfach bevor es zfs gab ... alle diese Probleme gab es vor zfs nicht, da nahm man entweder HA-NAS oder HA-SAN, das konnte man für einen DR Fall natürlich auch zu anderer Site replizieren, aber das hat einfach funktioniert, heute muß man echt schmunzeln wie sich alles zum "Besseren" gewandelt hat ...

 

[carsten2]

Unter Linux gibt es ja auch das cmd "ln (-s)" mit dem man sowas jeweils lokal unterschiedlich erreichen kann, aber warum einfach, wenn es auch kompliziert geht ... Junge, war die Welt einfach bevor es zfs gab ... alle diese Probleme gab es vor zfs nicht, da nahm man entweder HA-NAS oder HA-SAN, das konnte man für einen DR Fall natürlich auch zu anderer Site replizieren, aber das hat einfach funktioniert, heute muß man echt schmunzeln wie sich alles zum "Besseren" gewandelt hat ...

Zwar forsch vorgetragen, aber alles leider nicht richtig.
1) Symbolische Links werden von Proxmox nicht ausgewertet, ebenso nicht mount points.

2) Mit ZFS hat das nicht wirklich etwas, denn ZFS kann das ja alles geht das ja alles, nur Proxmox unterstützt das von der Oberfläche her nicht, weil es sich auf die hartkodierten und nur global festgelegten Poolnamen statt auf eine Stufe niedriger spezifierbare Ziele festlegt.

3) Mit den alten SAN-System war das kein Stück einfacher, sondern eher noch komplizierter, weil noch unflexibler. Wenn man jeden Host als ein SAN und nurmit einem ZFS-Pool betrachtet, hat man die gleiche Funktionalität wie mit SAN, wobei auch da immer zu unterscheiden ist, was die Hardware prinzipiell kann und was die Admin-Oberfläche davon zulässt. Hier hat es aber nicht mit SAN oder ZFS-Funktionalität sondern mit der fehlenden Funktionalität in der Admin-Oberfläche von Proxmox zu tun. Von Hand kann ich das gewünschte problemlos realisieren, nur funktioniert dann die Admin-Oberfläche und das Backup von Proxmox nicht mehr, weil es sich halt auf bestimmte Einschränkungen verlässt.

 

[waltar]

Ist das lustig, wollte gerade mal ein schönes Beispiel zusammenbasteln und nun ist der pool weg und läßt sich nach export mehr nicht importieren ... ist das Leben langweilig ohne zfs ... ich hau mich weg, junge junge junge, das geht jetzt wohl nicht so auf die schnelle. Zum Glück gibt's kein Backup in diesem Testcluster, insofern natürlich auch kein recover nötig da nicht möglich, haha. Aber war ja außer 2 Test vm's und irgendwelchem Testmüll auch nichts drauf, muß mich erstmal auslachen, mein Bauch tut schon weh vor lachen ... Aber macht alles nichts, genau dafür existiert ja dieser Cluster, zum Testen der Möglichkeiten und Grenzen ... top Projekt hier im Gange !!

 

[Falk R.]

Hi Carsten.
Klar kann man das wie in deinem Beispiel bauen, aber ich musste beim lesen schon aufmerksam sein und jeder fremde kommt dann mit so einem Setup nicht klar ohne Erklärung. ZFS Replikation ist ja nicht umsonst für die kleinen Cluster mit 2 Nodes gedacht und mehrfach Replikation macht das ganze schon wieder anfälliger.
Was spricht denn deiner Meinung nach gegen Ceph in deinem Setup?
Mit verschiedenen Pools (fast, slow und veryslow) kannst du das für jeden klar erkennbar definieren und du müsstest dich um nix kümmern, außer dass du aufpassen musst, dass SSDs als SSD erkannt werden und HDD als HDD. Die Verteilung auf Nodes geschieht dann vollautomatisch.

 

[waltar]

Ceph scheint mir in diesem Fall auch die stabilere Lösung zu sein, denn je komplizierter etwas aufgebaut ist, desto wahrscheinlicher fällt es eines Tages in sich zusammen und dann steht man da mit seinem Glück ...

 

[carsten2]

Hi Carsten.
Klar kann man das wie in deinem Beispiel bauen, aber ich musste beim lesen schon aufmerksam sein und jeder fremde kommt dann mit so einem Setup nicht klar ohne Erklärung. ZFS Replikation ist ja nicht umsonst für die kleinen Cluster mit 2 Nodes gedacht und mehrfach Replikation macht das ganze schon wieder anfälliger.
Was spricht denn deiner Meinung nach gegen Ceph in deinem Setup?
Mit verschiedenen Pools (fast, slow und veryslow) kannst du das für jeden klar erkennbar definieren und du müsstest dich um nix kümmern, außer dass du aufpassen musst, dass SSDs als SSD erkannt werden und HDD als HDD. Die Verteilung auf Nodes geschieht dann vollautomatisch.

Wie schon gesagt, ist da praktisch keine Extra-Komplexität, denn Proxmox hat jetzt schon eine Hostspezfische Einstellung für den Storage, nur ist der einzige Wert "none", also auf diesem Host nicht vorhanden. Die Erweiterung, hier auch einen anderen Wert als "none" einzutragen zu können, führt kein neues Konzept ein, sondern ergänzt das bestehnde nur minimal, aber mit erheblichen Vorteilen bzgl. Flexibilität. Es ist ja sogar insgesamt einfacher zu managen, als wenn man sich bei jeder Storageändernung gleich Gedanken über alle Nodes machen muss. Hier ist es einfach egal, weil man wie bei Links und Mounts besser die Logische Sicht etwas von der physikalischen trennen kann, etwas was wie schon mehrfach erwähnt Proxmox ja gerade schon hat, nur wird die halt in der Praxix durchbrochen, durch die Festlegung auf einen globel einheitlichen physikalischen Namen.

Das ganz geht übrigens bei File-System-Storage-Points schon jetzt problemlos, denn da kann man auf Hostebene mit Mounts und Links die physikalische Struktur auf jedem Node anpassen. Also da gibt es das alles schon.

Nur geht das bei ZFS nicht, da Proxmox das derzeit nicht zulässe. Theoretisch könnte man meinen Vorschlag auch so umsetzen, dass Proxmox Mount-Ponts auf jedem Host berücksichtigt. Dann kann man sich ähnlich wie bei Filesystem-Storages, auf einem Host per ZFS-Mount-Points das Dateisytem so bauen, dass es zum global eindeutigen Namen pass.t. Proxmox verwendet aber Es ist die subtile Unterscheidung zwischen dem ZFS-Namen und dem Filesystem-Namen (Poolname zfsdata/big vs Filesystem-Mount-Point /zfsdata/big). Proxmox wertet aber direkt den ZFS-Namen aus. Würde es den Filesystem-Namen nehmen und darüber dann erst den ZFS-Namen bestimmen, könnte mal wie bei File-System-Storage-Namen alles auf ZFS-Filesystem-Ebene des lokalen Hosts umkonfigurieren.

Beispiel von
Bei ZFS-Storage-Namen geht Proxmox auf den ZFS-Namen, würde es auf den Filesystem-Namen gehen und daraus erst den ZFS-Namen bestimmen, könnte man das Problem auf zwei Arten lösen:
1) Bei Host 4 einen ZFS-Mountpoint /zfsdata anlegen und die beiden ZFS-Dateisysteme newzfsdata/big und newzfsdata(fast einfach als /zfsdata/big und /zfsdata/fast per ZFS-Mount-Point einhängen
ODER
2) Bei Host4 den ZFS-Poolnamen zfsdata nennen (gemounted auf den Default-Mount-Moint /zfsdata), der einfach zwei Unter-Dateisystem zfsdata/fast (Default mount-Point /zfsdata/fast) und zfsdata/big (Default-Mountpoint /zfsdata/big) hat. Bei den anderen Host legt man dann umgekehrt beiden Pools zfsdatabig und zfsdatafast unter als /zfsdata/big und /zfsdata/fast ein.

Und Ceph ist eine andere Lösung mit seinen eigenen Vor- und Nachteilen. ZFS ist ebenso untersützt und die marinale Erweiterung des schon bestehenden Konzepts erzeugt keine wirkliche Zusatzkomplexität. Es bringt die ZFS-Funktionalität nur auf das gleiche Niveau, wie das bei File-System-Storage-Namen schon immer geht und allgemein akzeptiert wird.

PS: Im Beispiel oben im anderen Artikel ist leider ein Schreibfehler, da sind auf host1 und host2 vershentlich auch "/" zuviel Richtig müsste das so heißen.
vmstorage1:
host1: zfsdatabig
host2: zfsdatabig
host:3: none (d.h. existiert nicht)
host4: newzfsdata/big
vmstorage2:
host1: zfsdatafast
host2: none (d.h. existiet nicht)
host3: zfsdatafast
host4: newzfsdata/fast

 

[Falk R.]

Ich glaube hier ist auch das Problem. Bei ZFS nutzt PVE ja kein Dateisystem sondern nur das ZFS Pooling. Wenn du Datasets anlegst und ein Dateisystem erzeugst, kannst du viele andere schöne Sachen machen, aber mi8t großem Overhead und ohne Replikation.

 

[carsten2]

Ich glaube hier ist auch das Problem. Bei ZFS nutzt PVE ja kein Dateisystem sondern nur das ZFS Pooling. Wenn du Datasets anlegst und ein Dateisystem erzeugst, kannst du viele andere schöne Sachen machen, aber mi8t großem Overhead und ohne Replikation.

Nein, nicht ganz. Zunächst repliziert Proxmox keine ZFS-Pools (geht auch gar nicht) sondern immer nur die darunterliegen ZFS-Volumes oder ZFS-Filesystems. Diese aber können bei ZFS beliebt in einen anderen ZFS-Pool und dort unterhalb eines beliebigen anderes ZFS-Dateisystems repliziert werden. Zudem kann man Mountpoint beliebigt ändern. Das Problem ist nur, dass Proxmox die Oberfläche das nicht zulässt, weil es hardkodiert den Poolnamen für alle gleich haben will, der Teil des Pfades ist. Man braucht hier auch nicht die totale Flexiblität, sondern im Grunde die Einfachere Erweiterung, dass man Pro Host angeben kann, wo das Root-Filesystem für den logischen Storage liegt. Wie schon mehrfach erwähnt gibt es ja jetz schon eine Host-Spezifische Einstellung für den ZFS-Storage, nämlich "none". Die müsste man zusätzlich nur auf einen anderen Namen festlegen können.

 

[Falk R.]

Wo finde ich denn diese Hostspezifische Einstellung "none"?

 

[carsten2]

Wo finde ich denn diese Hostspezifische Einstellung "none"?

In den Eigenschaften des Storagenames gibt es oben rechts eine Liste, wo man sagen kann, auf welchem Host Storage nicht vorhanden ist (default ist alle). Im Prinzip ist das eine Host-spezifische Einstellung mit einzig möglichem Wert "none". Stattdessen müsste man dort nun auch einen abweichenden Namen angeben können (oder halt Proxmox berücksichtigt die lokalen ZFS-Mount-Points).

 

[Falk R.]

Ich verstehe nicht wie eine Auswahl welche Hosts Zugriff auf ein Storage haben, bei deinem Problem helfen soll. Diese Auswahl ist ja nicht ZFS Spezifisch, sondern für alle Storages.
Klar kannst du ein Storage anlegen und keinen Host zugreifen lassen, aber mir fehlt da der rote Faden wie es dort weiter gehen soll.

 

[carsten2]

Ich verstehe nicht wie eine Auswahl welche Hosts Zugriff auf ein Storage haben, bei deinem Problem helfen soll. Diese Auswahl ist ja nicht ZFS Spezifisch, sondern für alle Storages.
Klar kannst du ein Storage anlegen und keinen Host zugreifen lassen, aber mir fehlt da der rote Faden wie es dort weiter gehen soll.

Wie schon mehrfach oben geschrieben, braucht man eine ERWEITERUNG, dass man pro Host nicht nur sagen kann "gibt es nicht" sondern "liegt abweichend unter einem anderen Namen".

Alternativ, wie ebenfalls schon dargelegt, wäre, dass Proxmox den Namen nicht als dataset-Namen sondern als Filesystem-Pfad interpretiet, die lokalen ZFS-Mountpoints berücksichtigt und daraus den Dataset-Namen bestimmt. Dann könnte man alles auf dem Host mit ZFS-Mitteln machen und der globale Name bliebe gleich. Letzteres wäre ggf. sogar zu bevorzugen, da dann die globale Sicht einheitlich bleibt und nur auf dem Host etwas umgebogen werden könnte.

Genau das geht ja schon mit Filesystem-Storage-Namen, nur geht es halt nicht mit ZFS-Storage-Namen.

 

[Falk R.]

Wie schon mehrfach oben geschrieben, braucht man eine ERWEITERUNG, dass man pro Host nicht nur sagen kann "gibt es nicht" sondern "liegt abweichend unter einem anderen Namen".

Aber die Stelle, welche du beschreibst, ist dafür völlig ungeeignet. Da stellt man bei Shared Storages ein, welcher Host dies benutzen darf. ZFS ist mit der Replika ein Sonderfall, der einfachheithalber mit da rein genommen wurde.

Alternativ, wie ebenfalls schon dargelegt, wäre, dass Proxmox den Namen nicht als dataset-Namen sondern als Filesystem-Pfad interpretiet, die lokalen ZFS-Mountpoints berücksichtigt und daraus den Dataset-Namen bestimmt. Dann könnte man alles auf dem Host mit ZFS-Mitteln machen und der globale Name bliebe gleich. Letzteres wäre ggf. sogar zu bevorzugen, da dann die globale Sicht einheitlich bleibt und nur auf dem Host etwas umgebogen werden könnte.

Genau das geht ja schon mit Filesystem-Storage-Namen, nur geht es halt nicht mit ZFS-Storage-Namen.

Genau, weil es Dateisysteme sind, die klassich gemountet werden. Für das was du dir wünschst, müsste man eine eigene Integration bauen. Auch wenn du und ein paar wenige Leute davon echten Nutzen hätten, würde der Aufwand viele Ressourcen binden.
Falls du eine gute Idee hast wie man diese Integration bauen könnte und wo man die unterbringen könnte, kannst du das ja mal in den Bugzilla reinstellen.

 

[carsten2]

Meiner Ansicht nach ist der Aufwand nicht besonders groß. Ich bevorzuge inzwischen auch die Erweiterung auf ZFS-Ebene auf dem Host, die recht einfacher zu implementieren ist, denn Proxmox muss dann nur den Datasetnamen über den Pfad bestimmen:

Momentan gibt man beim einen ZFS-Storage den ZFS-Dateien-Namen an, also z.B. mypool/myzfs (ohne "/" am Anfang). Die Erweiterung wäre dann, dass man stattdessen auch einen absoluten Dateisystempfad angeben kann also /mypool/myzfs. Standardmäßig wird ja mypool/myzfs auf /mypool/myzfs gemounted, so dass dann "mypool/myzfs" und "/mypool/myzfs" identisch wären, aber das kann man ja unter ZFS den Mountpoint ändern. Promox müsste also jetzt, wenn ein ZFS-Storage mit "/" beginnt, einfach das tatsächliche ZFS-Dataset über den Mountpoint bestimmen (z.B. mit "zfs get mountpoint"). Das wäre meiner Ansicht nach eine sehr einfache Anpassung und rückwärtskompatibel.

 

[Falk R.]

Meiner Ansicht nach ist der Aufwand nicht besonders groß. Ich bevorzuge inzwischen auch die Erweiterung auf ZFS-Ebene auf dem Host, die recht einfacher zu implementieren ist, denn Proxmox muss dann nur den Datasetnamen über den Pfad bestimmen:

Momentan gibt man beim einen ZFS-Storage den ZFS-Dateien-Namen an, also z.B. mypool/myzfs (ohne "/" am Anfang). Die Erweiterung wäre dann, dass man stattdessen auch einen absoluten Dateisystempfad angeben kann also /mypool/myzfs. Standardmäßig wird ja mypool/myzfs auf /mypool/myzfs gemounted, so dass dann "mypool/myzfs" und "/mypool/myzfs" identisch wären, aber das kann man ja unter ZFS den Mountpoint ändern. Promox müsste also jetzt, wenn ein ZFS-Storage mit "/" beginnt, einfach das tatsächliche ZFS-Dataset über den Mountpoint bestimmen (z.B. mit "zfs get mountpoint"). Das wäre meiner Ansicht nach eine sehr einfache Anpassung und rückwärtskompatibel.

Aber wenn wir VMs im ZFS Pool ablegen, gibt es kein Dataset. Es wird ja immer nur auf den ZFS-Pool gezeigt. Du kannst auch jetzt jederzeit /ZFS-Pool hinzufügen als Mountpoint, aber dann funktioniert keine Replika. Ich stecke nicht so tief drin, aber vermutlich wird für die Replika der Poolname und nicht ein Pfad benötigt.

 

[carsten2]

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. 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.

Beispiel:
Ich lege meine VMs als Volumes unter zfsdata/vms ab. Dieses zfsdata/vms ist tatsächlich aber auch ein Filesystem, dass (in der Regel) keine Dateien sondern nur Volumes hält und defaultmäßig unter /zfsdata/vms gemounted wird.

Wenn ich also einen neuen Pool zfsdata2 mit Unterfilesystem vms habe, also zfsdata2/vms, und möchte den aber als Proxmox-Storage zfsdata/zfs auf diesen einen Host ansprechen dann kann ich jetzt einfach den Mountpoint von zfsdata2/vms auf zfsdata/vms ändern (und natürlich vorher den alten zfsdata/vms auf zfsdata/old ändern) und schon ist auf diesem einen Host der logische Name zfsdata/vms tatsächlich auf einem anderen Pooi.

Ebenso kann ich, im ursprüglichen Beispeil oben, nun Proxmox-Storage-Roots aus verschiedenen Pools in einen einzigen Pool mappen. Ich gabe also diesen Promox-Storage mit "/" an und erhalte (wegen ZFS-Default-Mounts) auf Host 1:
storage1: /datapool1/vms (äquivalent zu datapool1/vms, da ZFS-Default)
storage2: /datapool2/vms (äquivalent zu datapool2/vms, da ZFS-Default)

Auf einem Host 2 mit ZFS-Pool monsterpool richte ich nun einfach ein:
monsterpool/datapool1/vms mit mit mountpoint /datapool1/vms
monsterpool/datapool2/vms mit mit mountpoint /datapool2/vms

Wenn Proxmox /datapool1/vms sieht, muss er (je nach Host) über diesen Mountpoint den echten Datasetnamen bestimmen.
Auf Host1:
storage1: /datapool1/vms -> datapool1/vms
storage2: /datapool2/vms -> datapool2/vms
Auf Host2:
storage1: /datapool1/vms -> monsterpool/datapool1/vms
storage2: /datapool2/vms -> monsterpool/datapool2/vms