[SOLVED] Proxmox VE ZFS Thin Provision

[atomique]

Guten Tag zusammen,

ich habe aktuell das Problem, dass das Thin Provisioning auf meinem ZFS Pool nicht zu funktionieren scheint. Eventuell habe ich irgendwo einen Konfigurationsfehler, das möchte ich nicht ausschließen, eventuell kann mir aber ein findiger User hier kurz aushelfen.

• Versucht hatte ich bereits die Tipps aus diesem Thread hier: https://forum.proxmox.com/threads/zfs-enable-thin-provisioning.41549/
• Ebenso habe ich in alter VMware Manier die Disk von einem Storage auf den anderen und wieder zurück zu migrieren, leider ohne Erfolg.

Ich danke vielmals für die Hilfe, bitte bei weiteren benötigten Infos gerne auf mich zukommen!

Gruß Atomique

 

[Dunuin]

Ich danke vielmals für die Hilfe, bitte bei weiteren benötigten Infos gerne auf mich zukommen!

zfs list -o space p01-nvme wäre hilfreich.

 

[Chris]

Eventuell muss noch der Gast ein trim ausführen, damit dieser Blöcke freigibt. Ist der QEMU Guest Agent installiert und in den VM Options aktiviert? Auch das guest trim nach storage move bzw. migration kann dort aktiviert werden.

 

[atomique]

Hi,

vielen Dank für die wirklich sehr schnelle Rückmeldung!

zfs list -o space p01-nvme wäre hilfreich.

Eventuell muss noch der Gast ein trim ausführen, damit dieser Blöcke freigibt. Ist der QEMU Guest Agent installiert und in den VM Options aktiviert? Auch das guest trim nach storage move bzw. migration kann dort aktiviert werden.

Der Gast-Agent ist enabled und aktiviert. Es läuft jedenfalls ein Service auf der Maschine. Wie aktiviert ihr den TRIM auf der Maschine? Regelmäßig via cron?

---

EDIT: Ich habe gerade auf meiner Maschine mit Ubuntu 22.04 gesehen, dass es einen fstrim.timer und fstrim.service gibt und dieser wöchentlich ausgeführt wird. Ich vermute aktuell folgendes: Die Festplatte die hier hier gezeigt habe ist ein OSD in meinem rook-ceph Cluster auf Kubernetes. Kann es sein, dass ich den Trim dann hier ausführen muss?
Ich werde auch einmal ein paar andere Platten und Beispiele checken. Eventuell funktioniert das TRIM ja und ich habe es nur mit ausgerechnet der falschen Platte getestet. Interessant wäre es auch bei einer meiner Windows Server VMs, da muss ich das dann wohl auch gesondert aktivieren.
Kann der qemu-guest-agent das nicht tun, oder warum wird explizit nochmals eine Systemd-Timer-Unit benötigt?
Ich wundere mich nur, warum das auf VMware mit ESXi nie ein Problem war, wird das hier immer über die vmware-tools realisiert? (Entschuldigt bitte die Referenz, ich komme aus diesem Umfeld und Proxmox ist noch recht neu für mich. Das hier soll keinesfalls eine Kritik am aktuellen Prozess sein, würde es nur gerne besser verstehen).

Vielen Dank!

 

[Falk R.]

Wenn die Discard Option gesetzt ist und im Windows die Virtio Tools installiert sind dann funktioniert das auch automatisch.
Ich persönlich nutze meistens Ceph oder auch mal LVM-Thin. Da passt das bei mir immer.

 

[atomique]

Wenn die Discard Option gesetzt ist und im Windows die Virtio Tools installiert sind dann funktioniert das auch automatisch.
Ich persönlich nutze meistens Ceph oder auch mal LVM-Thin. Da passt das bei mir immer.

Wie verwendest du Ceph? Direkt über Proxmox? Ich vermute aktuell, dass mein Ceph das nicht macht. Ich habe hier drei virtuelle Maschinen mit jeweils einer virtuellen scsi disk auf dem beschriebenen zfs. Wenn ich das richtig verstehe, dann müsste das TRIM vom OS kommen und auf Dateisystemebene passieren. Das tut es hier natürlich nicht, weil die Disk kein Dateisystem für mein Ubuntu haben. Deswegen tauchen die auch nicht auf, wenn ich den fstrim ausführe.
Entweder müsste also der TRIM von einem Container aus meinem K8s Cluster kommen, der ein rbd Volume aus Ceph consumed und dann quasi ein Filesystem nutzt (was ich mir nicht vorstellen kann, dass ich das hier tun muss), oder aber Ceph muss das tun auf OSD Ebene. Ich habe hier bereits zwei Parameter gefunden die ich eventuell setzen kann, die auch nicht gesetzt sind. Aktuell haperts hier noch an der Durchführung über mein Helm Chart:

bdev_enable_discard
bdev_async_discard

Beide müssen auf true gesetzt sein, was sie wohl angeblich per default nicht sind.

Sobald ich herausgefunden habe wie man das ordentlich über Helm aktiviert ohne einfach nur stupide die ConfigMap zu editieren, meld ich mich mal mit Testergebnissen zurück.

Vielen Dank für eure Rückmeldungen seither!

 

[Falk R.]

Ja, ich nutze Ceph im PVE. Und ja, das GastOS muss den Trim durchführen. Da man normalerweise Ceph auf Hardware nutzt, weiß ich nicht ob Ceph überhaupt ein Trim ausführt.

 

[Chris]

Die Festplatte die hier hier gezeigt habe ist ein OSD in meinem rook-ceph Cluster auf Kubernetes. Kann es sein, dass ich den Trim dann hier ausführen muss?

Oh, da ist also noch ein storage layer dazwischen... Na ja, es ist Aufgabe des Gast Betriebssystems ungenutzte Blöcke mittels trim freizugeben, in deinem Fall also der Gast der auf deine Ceph block devices zugreift (verwendest du rados block devices oder cephfs?). Laut Ceph docs sollten RBD dies nach Aktivierung unterstützen, (allerdings betrifft es hier einen QEMU Gast, in deinem Fall mit Kubernetes pods ist das vermutlich nochmals etwas anders) https://docs.ceph.com/en/latest/rbd/qemu-rbd/#enabling-discard-trim. Eventuell hilft auch dieser blogpost weiter https://ceph.io/en/news/blog/2014/use-discard-with-krbd-client-since-kernel-3-18/

Kann der qemu-guest-agent das nicht tun, oder warum wird explizit nochmals eine Systemd-Timer-Unit benötigt?

Wenn der guest agent installiert und aktiviert ist, kann dieser mittels guest-fstrim das trim im Gast anstoßen, siehe https://www.qemu.org/docs/master/interop/qemu-ga-ref.html#qapidoc-100. Das systemd service und timer ist da weil das bei vielen Installationen default so konfiguriert wird, damit periodisch ein trim gemacht wird.

Ich wundere mich nur, warum das auf VMware mit ESXi nie ein Problem war, wird das hier immer über die vmware-tools realisiert?

Wie das dort gelöst ist, kann dir wohl nur der Hersteller selbst sagen.

Eine Frage Abseits: Was ist der Anwendungsfall für dieses Setup? Kann mir nicht vorstellen, dass dies sonderlich performant sein wird. Ich vermute mal der darunterliegende Storage wird sehr bald nicht mehr mithalten können, sobald Ceph anfängt Daten hin und her zu schieben.

 

[atomique]

Hi zusammen,

als allererstes vielen Dank nochmal für eure Hilfe. Ich konnte mich in letzter Zeit nicht darum kümmern, habe jetzt aber einen anderen Lösungsansatz gewählt. Man kann wie oben erwähnt im Ceph dafür sorgen, dass dort ein TRIM durchgeführt wird. Mein Ansatz ist nun aber folgendermaßen: Ich habe nun die virtuellen Festplatten (OSDs) gegen iSCSI Devices von meinem TrueNAS ausgetauscht. Somit liegen diese nicht mehr auf dem entsprechenden Pool der sowieso Platzprobleme hat. Die Geschwindigkeit des anderen Pools reicht mir für diesen Zweck locker aus.
Der NVMe Pool bleibt nun also für meine VMs vorbehalten und der Ceph Storage liegt quasi "nahezu" direkt auf dem Storage ohne einen virtuellen Zwischenlayer.
Meine ursprüngliche Vorgehensweise hatte mit vmware und TrueNAS nur nie solche Performance-Probleme und ich musste hier einige Anpassungen an meiner Storage-Situation vornehmen um diese (annehmbar) performant umzusetzen.

Der trim vom OS selbst hatte im übrigen hervorragend funktioniert.

Ich schließe hier einmal das Thema, wollte nur kurz erklären - dass ich das inzwischen einfach etwas anders gelöst habe, da mir dieser Lösungsansatz zu viele Rattenschwänze nach sich zog.

Grüße Atomique

 

[Falk R.]

Ich hoffe du hast dich nur etwas missverständlich ausgedrückt und nicht iscsi Devices als OSDs genutzt.
Wenn du einigermaßen vernünftige Performance möchtest, dann nutze lieber NFS von deinem NAS statt iSCSI. Damit sparst du schon viel Overhead beim NAS und je nach Einrichtung auch auf PVE Seite.

 

[atomique]

Und dann quasi die OSDs auf das NFS? Dann hab ich doch noch den Oberhead eines Dateisystems.
Ich möchte gerne den Storage via Rook in K8s provisionieren. Ich nutze hier kein Ceph auf Proxmox. Ich weiß, dass ich diesen auch im K8s direkt nutzen kann (NFS), möchte aber Ceph nutzen und dieses Ceph Cluster kann ich aus Homelab Gründen nicht auf extra Hardware laufen lassen.
Insofern ja, ich habe iSCSI Devices direkt auf den entsprechenden K8s Nodes eingebunden und konsumiere dann diese als Ceph OSD.

Ich verstehe aber auch ehrlich gesagt nicht, warum das bei Proxmox so ein Thema mit der schlechten Performance bei iSCSI ist. Bei vmware kann man iSCSI direkt nutzen, dann mit VMFS betanken und als VM Storage performant vom Storage nutzen. Warum macht das bei Proxmox so viel Ärger? (Hatte ich hier auch versucht, war von der Performance gesehen eine Vollkatastrophe, obwohl die Hardware die gleiche war)

 

[Falk R.]

Du kannst iSCSI high Performance in Proxmox mit LVM nutzen.
Alles andere sind vollkommen andere Storagekonzepte.

 

[atomique]

Also auch einbinden auf dem Node und dann ein LVM thin drauf oder Ähnliches? Auch eine Idee

 

[Falk R.]

Wenn man iSCSI nutzt, dann in der Regel als shared Storage im Cluster und dann geht kein Thin sondern nur normal LVM.
Ich weiß nicht wie groß dein PVE Cluster ist und wie groß du deinen K8S Cluster baust.
Für K8S wäre zu Ceph auch OpenEBS eine Option. Falls du zum rumspielen nur einen Nide hast, kannst du das ganze sparen und direkt eine Disk für die persistenten Daten nutzen.