Kernelmodul kvdo fehlt - GlusterFS + Deduplizierung

[floh8]

Hallo,

wollte heute mal lvmvdo testen. lvmvdo ist im aktuellen lvm2 aktiv, aber wenn ich es nutzen möchte, meckert er das kernelmodul zu vdo "kvdo" an.

# lvcreate --type vdo -l 98%FREE --name LV-VDO-SAS-KD --config 'allocation/vdo_slab_size_mb=32768' vg1
modprobe: FATAL: Module kvdo not found in directory /lib/modules/5.11.22-1-pve /sbin/modprobe failed: 1

Kernel: SMP PVE 5.11.22-1
Könntet ihr den VDO Support vollständig mit integrieren, damit man dies nicht kompilieren muss?
Gibt es in den Enterprise-Repos das Kernel-Header-File für den eingesetzten PVE-Kernel?

gruß

 

[dcsapak]

ich glaube das ist nicht im upstream kernel (oder ubuntu) kernel enthalten. zumindest finde ich keine referenz dazu im aktuellen 5.15er
aber wahrscheinlich ist es möglich als dkms modul zu bauen...
https://github.com/dm-vdo/kvdo

edit:

Gibt es in den Enterprise-Repos das Kernel-Header-File für den eingesetzten PVE-Kernel?

ja klar, das paket heißt 'pve-headers'

 

[floh8]

alles klar, muss man also selber integrieren.
ich hatte bereits diesen link dazu gefunden: https://unix.stackexchange.com/questions/518549/compiling-vdo-for-use-on-debian
interessant für alle, die Deduplizierung einsetzen wollen.

 

[floh8]

Kompilierung mit obigen Link funktioniert nicht mit Debian 10. Die 11 würde ich nochmal testen.

 

[floh8]

tja, schlimme Zeiten für VDO. Debian 11 bietet auch keinen support zum _Nachinstallieren. Es kommt noch schlimmer. Selbst xcp-ng bietet zwar das Paket, aber nicht die passenden Abhängigkeiten. Damit bleibt leider nur die Möglichkeit kein HCI zu bauen, sondern den Storage mit VDO+GlusterFS als separate Server zu implementieren. Als OS würde sich dann RockyLinux anbieten, da es stabiler als centOS ist. Wer dies nicht möchte, muss für Proxmox als HCI dann Ceph nehmen, was ja Proxmox auch empfiehlt und supportet.
Alternativen siehe weiter unten!

 

[floh8]

Neulich habe ich über eine günstige HCI Variante für Vmware nachgedacht und dabei ist mir aufgefallen, dass man die gleiche Lösung ja für alle Hypervisor Lösungen einsetzen kann.
Wer also GlusterFS mit Deduplizierung in Proxmox haben möchte, der kann natürlich - so wie es viele kommerzielle Storagelösungen anbieten - einfach eine VM mit durchgereichtem HBA auf den lokalen Storage jedes Knotens eines 3er Clusters installieren. Das Storage Netz verbindest du halt mit dieser VM. Damit du VDO nutzen kannst, solltest du wie oben geschrieben Rocky Linux nehmen.
Allerdings bin ich mir nicht so sicher, ob GlusterFS die Perfomance bringt. Laut diesem Test ist die IOPS ziemlich gering im Vergleich zu Ceph. Das könnte man natürlich mit SSDs kompensieren.
Wer die Inline-Dedplication als Bottleneck sieht, kann natürlich Offline-Deduplication von XFS nutzen. So übernimmt VDO die Komprimierung und XFS die Deduplizierung.

Nachteil einer Storage VM:
Man hat natürlich einen Overhead durch die zusätzliche OS Umgebung, aber das wäre es mir wert.

Ergänzung: Wer GlusterFS etwas tunen möchte, kann einen R/W-Cache mit bcache oder LVM hinzufügen.

Variante ohne VM: In den letzten Jahren hat BTRFS in Sachen Performance sehr gut aufgeholt und kann teilweise in manchen Szenarien die Platzhirsche wie ext4 und xfs übertrumpfen. Ich habe mal meine Testumgebung geupdatet und bin jetzt auf PVE 7.3-6. Diese bringt einen Kernel 5.15.85 mit. Ist natürlich nicht gerade sehr aktuell, aber das ist ja Debian-Philosophie. Kurzum: Die nächsten Kernelaktualisierung bringen nochmal einige Performanceboosts für BTRFS.
Da GlusterFS nur einen Mountpoint benötigt, um zu replizieren, kann man quasi darunter jedes Filesystem einsetzen. Im Netz findet man somit Lösungen, wo GlusterFS auf zfs aufsetzt. Als HCI - Lösung ist das natürlich eine RAM-Katastrophe. BTRFS hingegen ist weit weniger RAM-lastig und bietet wie zfs und VDO Komprimierung und Deduplizierung und diese sogar offline. Ein alternatives Szenario für Deduplikationsfans wie mich ist also auf den Gluster-Nodes MDADM+BTRFS Mountpoints als Brick anzubieten. Da BTRFS Subvolumes unterstützt, kann ich sogar große Raidgruppen einrichten und diese mit BTRFS auf verschieden Bricks aufteilen. Jetzt kommt aber das Beste: Da ich nicht auf VDO angewiesen bin, benötige ich keine VM, sondern kann die Konfiguration direkt auf dem Proxmox-Host tätigen.
Ich habe mal ein kleines Testszenario aufgebaut und es lief ohne Probleme.

 

[Falk R.]

Was ist es dir denn wert? Was gewinnst du wofür du so viel Overhead auf dich nehmen willst?

 

[floh8]

Ich habe ja bereits in anderen Threads meine vorschnelle Enttäuschung über die Unmöglichkeit des Baus eines 3 Node GlusterFS Cluster direkt auf dem Proxmox Host als HCI zum Ausdruck gebracht. Ceph kann nun mal keine Deduplizierung. Der Overhead ist minimal für das, was man gewinnt.

 

[Falk R.]

Ich habe mich schon eine Menge mit Closed Source Systemen und inline Dedup auseinander gesetzt.
Die einzigen Systeme auf denen richtig gute Dedupwerte erreichen, arbeiten mit 4K Blöcken. Das erfordert gute CPUs und RAM.
Bei dedizierten Storages kann man sowas sinnvoll sizen. Bei HCI belastet das die Nodes zu sehr und die VMs leiden.
Was du an CPU und RAM mehr kaufen musst, dafür bekommst du auch einige NVMe‘s.
Ich mag dann lieber volle Performance und deutlich weniger Komplexität.
Wieviele TB Daten hast du denn das sich sowas lohnt? Ab einem halben PB lohnen sich auch dicke CPUs und viel RAM, aber vermutlich bewegst du dich woanders.

 

[floh8]

Offline-Dedup würde ich nur für das Volume machen, wo ich die Betriebssysteme ablege, da es dort am meisten bringt. Für SQL und Apps würde ich kein Dedup aktiveren. Für Fileserver würde ich eine Offline-Dedup in der VM wählen.

 

[Falk R.]

Gerade bei SQL kann man viel sparen. Ich empfehle aber lieber Compression, da sparst du bis zu 80% und hast viel weniger Overhead. Teilweise werden die DBs dadurch sogar schneller.