Cluster-Reinstallation mit ZFS

[AF360]

Guten Abend zusammen,

leider habe ich mich erst eine Weile nach Inbetriebnahme des ersten Proxmox Mini-PCs für einen zusätzlichen zweiten Mini-PC entschieden, weshalb ich die Nodes leider ohne ZFS installiert habe und nun im Clusterbetrieb keine Replikation zwischen den Nodes möglich ist.
Die TLDNR-Freunde können gern direkt runter zu meiner Frage springen

Noch etwas Background zum Einsatzszenario:
Das Setting ist mein Homelab (bestehend u.a. Home Assistant, Paperless NGX, Pi-Hole, AdGuard Home, UniFi etc., teilw. KWM, teilw. LXC)
Hardware: 2x lüfterlose Homelab-Mini-PC intel N100, 32GB RAM, 1TB M.2-NVMe-SSD, 2TB SATA-SSD, 4x 2.5 Gbps NIC
Praktisch sind hier auch die 4x 2.5gbps NICs je PC, so ist gut die physikalische Trennung von Anwendungs-, Management-, Corosync- und Migration-Traffic möglich, aber das ist ein anderes Thema.
Für ZFS wäre die Hardware eigentlich auch unterdimensioniert, aber ich würde gern die Möglichkeit der Replikation zwischen den Nodes nutzen, für die meisten der VMs/LXC wird eine Replikation alle 24 Stunden genügen.
Aktuell laufen beide Nodes in einem Proxmox-Cluster (v8.3, ein Raspberry übernimmt das QDevice fürs Quorum.

Frage:
Bei der Installation des Proxmox-Nodes habe ich den Default-Vorschlag übernommen und nun die gesamte NVME (1 TB) für den LVM bzw. die Volume-Group PVE verwendet.

Besteht die Möglichkeit, diese Volume-Group minimal zu verkleinern, um anschließend die Partition 3 ebenso zu verkleinern, dann eine zusätzliche Partition (850-900GB) für ZFS anlegen und einen ZFS-Pool darauf anlegen, das Ganze ohne Neuinstallation/Datenverlust? Die VMs und Container könnte man solange auf den zweiten Node migrieren.
Oder macht ZFS mit der Hardware keinen Sinn?
Falls Ihr habt, gern auch eine alternative Vorgehensweise. Alles willkommen.
Das Ziel sollte sein, die replizierten VMs/Container bei Ausfall eines Nodes auf dem anderen Node hochfahren zu können.
Und kann jemand von Euch abschätzen, wie sich in diesem Setup die Performance mit ZFS vs Ext4 negativ bemerkbar machen würde?

Unten zum Ausklappen die Ausgabe der Befehle pvdisplay, vgdisplay sowie fdisk,

Viele Grüße und Danke für Eure Antworten.

Spoiler: Ausgabe von pvdisplay, vgdisplay und fdisk

--- Physical volume ---
PV Name /dev/nvme0n1p3
VG Name pve
PV Size 930.51 GiB / not usable 4.69 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 238210
Free PE 4096
Allocated PE 234114
PV UUID sbfdzz-bcdfj-yvxF-Z22B-8yR3-zEdL-G253Rs

root@pve1:~# vgdisplay
--- Volume group ---
VG Name pve
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 338
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 19
Open LV 12
Max PV 0
Cur PV 1
Act PV 1
VG Size <930.51 GiB
PE Size 4.00 MiB
Total PE 238210
Alloc PE / Size 234114 / <914.51 GiB
Free PE / Size 4096 / 16.00 GiB
VG UUID JFrrcO-1ISC-2Msdf-6sH-Zdfm-pCdf9-fkMM3

Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0E13CBEF-8778-4DA4-8C13-2141B

Device Start End Sectors Size Type
/dev/nvme0n1p1 34 2047 2014 1007K BIOS boot
/dev/nvme0n1p2 2048 2099199 2097152 1G EFI System
/dev/nvme0n1p3 2099200 1953525134 1951425935 930.5G Linux LVM

 

[news]

Also ZFS ohne Mirror - Raid1 ist ohne Sinn.
Ein Backup aller vm und lxc machen und extern zwischen speichern. Und anschließend alles neu auf 2 Datenträger installieren.

 

[Falk R.]

Ich würde wie News vorschlägt, alle VMs sichern und dann mit ZFS neu installieren. Aber vorsicht mit den günstigen Consumer SSDs, die werden oft schnell kaputt geschrieben von ZFS.

 

[AF360]

Danke für Eure Antworten.

Mirror ist leider keine wirkliche Option, da die Mini PCs nur je einen M.2 2280 NVME Slot haben.
Es gibt auch noch einen SATA-Anschluss, damit könnte man zwar spiegeln, würde aber die gute NVME-Performance vernichten.
Ich werd's mal überdenken.

Neuinstallieren wollte ich ja vermeiden, aber scheint vermutlich der sinnvollste Weg.

Ich wollte es ja unbedingt klein und lüfterlos haben, muss aber jetzt halt damit leben, dass das Setup keine großen Redundanzen bietet. Daher ja die Idee mit dem zweiten Node und Replikation…

 

[AF360]

Guten Abend zusammen,

ich habe heute den Node2 aus dem Cluster entfernt, neu VE 8.3.1 aufgesetzt und nun einen Raid1-ZFS Spiegel auf der NVME und der SATA-SSD. Nachdem alles wieder konfiguriert war, habe ich den Node2 wieder in den Cluster aufgenommen. Soweit alles gut.

Nun dachte ich ganz naiv, dass ich die VMs und LXCs auf dem Node1 (noch lvm/ext4) herunterzufahren, sie im offline Modus auf Node2 zu migrieren und sie dort zu starten. Dann Node1 aus dem Cluster nehme und das gleiche Spiel wiederhole mit Neuinstallation und Spiegelung und Rejoin.

Aber leider lassen sich die Maschinen nicht von Node1 auf Node2 migrieren, Fehlermeldung:

2025-01-17 23:24:05 ERROR: migration aborted (duration 00:00:00): storage 'local-lvm' is not available on node 'pve2'
TASK ERROR: migration aborted

Auf Node2 (pve2) gibt's natürlich auch kein local-lvm, sondern nur ein volume „local“ für dumps, container images sowie ISOs und ein volume "local-pve2" für die VMs und LXCs. Das local-lvm gibt‘s auf Node1 (pve1)

Viele Grüße

 

[AF360]

Ich habe noch weiter recherchiert. Offenbar unterstützt das GUI die Migration nur dann, wenn auf beiden Nodes der Speicher gleich benannt ist. Da das nicht der Fall ist, und das GUI keine Option für einen abweichenden Storage-Namen auf der Target-Seite hat, sollte es eigentlich mit dem CLI-Befehl funktionieren, für LXC:
pct <CTID> <TargetNode> --target-storage <StorageID>

root@pve1:~# pct migrate 104 pve2 --target-storage local-zfs
2025-01-18 12:13:16 use dedicated network address for sending migration traffic (192.168.50.43)
2025-01-18 12:13:16 starting migration of CT 104 to node 'pve2' (192.168.50.43)
2025-01-18 12:13:16 found local volume 'local-lvm:vm-104-disk-0' (in current VM config)
2025-01-18 12:13:16 ERROR: storage migration for 'local-lvm:vm-104-disk-0' to storage 'local-zfs' failed - cannot migrate from storage type 'lvmthin' to 'zfspool'

Also bleibt wirklich nur der Umweg über Backup/Restore.
Ich hätte allerdings erwartet, dass Proxmox bei der Migration zwischen unterschiedlichen Speichertypen konvertieren kann.