Noch eine Anmerkung, bitte überprüfe die Speichermethode.
SMR oder CMR (das willst Du)
Planung der Einrichtung eines neuen Systems mit ZFS
- Thread starter Renegade33
- Start date
SMR oder CMR (das willst Du)
Also ich habe gelesen, dass es bei ZFS zu Problemen mit dem Caching bei Swap kommen kann und es darum auch nicht bei der Installation eingestellt ist als Standart.
Also ich fasse mal zusammen. Die Möglichkeiten sind:
1. Nur auf eine NVMe zu installieren und dazu LVM-Thin zu nutzen
+ snapshots nicht linear möglich
+ Weniger RAM Verbrauch
- Keine Redundanz bei Ausfall der Platte
- Keine Migration möglich
2. RAID1 auf Basis btrfs
+ snapshots nicht linear möglich
+ weniger RAM Verbrauch
+ Redundanz der Hardware
- Keine Migration möglich
- angeblich kein booten möglich, wenn RAID auf "degraded" steht
3. RAID1 auf Basis zfs
+ Migration möglich
+ Redundanz der Hardware
+ Booten auch bei Ausfall einer Platte möglich
- hoher RAM Bedarf
- Probleme mit einer Swap Partition
- nur lineare snapshots möglich
Du hast 6 HDD, welche in je 2 vDev Pools liegen a 3 Stück. und diese beiden Pools hast du gespiegelt oder?
Also liegen deine snapshots direkt im rpool?
Das ist irgendwie seltsam ich hab damals 6 gleiche Festplatten bestellt. Schauen auch gleich aus, sind aber anscheinend unterschiedliche Modellreihen der Serie. 4 sind CMR und 2 sind SMR.
Ja, wenn der Swap auf dem ZFS-Pool angelegt wird. Liegt daran, dass dann beim Swappen ggf. mehr Platz alloziert wird, was zur Folge haben kann, dass ZFS selbst mehr RAM anfordert - aber genau daran hat es ja bereits gemangelt und das führt dann zu einem Deadlock.
Legt man dagegen eine separate Swap-Partition an, wie ich vorschlage, ist der dafür allozierte Platz ja bereits vorab alloziert. Offenbar hat man das bei Proxmox nicht bedacht. Man sollte also nicht den gesamten Datenträger als ZFS nutzen - und falls man später das ganze System auf einen größeren Datenträger kopiert, sollte die ZFS-Partition die letzte sein, damit man sie danach vergrößern kann.
Die Frage, was passiert, wenn man tatsächlich eine Datenkorruption hat, ist nicht so super-relevant für einen Dataset, das im Wesentlichen OS-Images enthält, die man mutmaßlich sowieso täglich sichert. Es ist nämlich vergleichsweise einfach, einen Proxmox-Server wieder aufzusetzen und die VMs/LXCs wiederherzustellen, besonders, wenn man so etwas wie prox_config_backup.sh nutzt.
Ich sagte ja, für die wichtigen Daten würde ich jeden Tag ZFS nutzen. Es wäre eventuell sogar zu überlegen, Proxmox auf eine kleine ZFS-Partition zu installieren, das local-zfs zu löschen und dann den Rest später mit Swap und einem LVM-Thin (local-lvm) zu belegen. Dann wäre der eigentliche Server auf ZFS und die Images auf LVM-Thin. Es wäre wahrscheinlich sogar möglich, das auf einem ZFS Mirror zu tun und das LVM-Thin auf ein normales RAID-1 zu legen, dann hätte man die Ausfallsicherheit on top.
Ah OK, das wäre sowieso mein Plan gewesen. Über Advanced Options den ZFS Mirror verkleinern und die Swap extra legen.
Also ich stimme dir absolut zu, das "Datengrab" sollte zfs sein. Beim OS und den VMs ist mir einfach ein Raid wichtig, falls mal eine Platte abraucht. Da brauche ich jetzt keinen Bitrod Protect. ISO-Images ziehe ich eigentlich sowieso bei einer neuen Installation auch neu. Die Frage ist denke ich eher, wie man mit den Snapshots umgeht. Da kenne ich mich noch gar nicht aus. Bisher liefen bei mir Backups klassisch 3x pro Woche auf ein Veeam backup (inkrementell). Wie ich das jetzt auf snapshots umsetze ist mir noch nicht klar.
Aslo die 2 NVMe nur teilweise als rpool nutzen und den REst in eine Swap und eine normale Partition (LVM-Thin) splitten meinst du?
Ja: Ich meinte Proxmox-Installation als ZFS-System mit ZFS Mirror, aber über advanced options das meiste frei lassen, also nur ca. 100 GByte dafür und ganz wenig davon als eigentlichen VM-Pool. Danach starten, zwei gleich große Swap-Partitionen auf den beiden NVMEs plus zwei gleich große Partitionen dmraid als RAID-1 mit dem Löwenanteil der NVMEs. Auf dem raid-1 dann ein LVM-Thin händisch aufsetzen. Zum Schluss den (kleinen) local-zfs entfernen (der Platz kann danach vom ZFS Root genutzt werden). Muss man aber nicht unbedingt tun, man muss den Platz ja nicht nutzen.
Ergebnis: PVE Root als ZFS Mirror, zwei separate Swap-Partitionen (wahlweise als RAID-0), QM-Images und LXCs auf LVM-Thin local-lvm.
P.S.: Was die Datensicherheit der Images angeht: Solange ich keine ECC-Hardware habe, ist das alles sowieso relativ.
P.P.S.: Habe es gerade mal auf einer virtuellen Proxmox-Maschine ausprobiert. Geht, wie nicht anders zu erwarten. Man muss sich natürlich ein bisschen reinfräsen - wer richtet schon von Hand Swap, dmraid oder LVM-Thin ein und bindet es in einen Proxmox ein?
Last edited:
JA meine ich ja. Nur was für einen Vorteil hat es die VMs in einem local lvm und nicht in einem zfs laufen zu lassen?
Na die oben aufgeführten. Vor allem: der vermeintliche Vorteil der Online-Migration gilt nur, wenn man mehrere Nodes hat, bei mir nicht der Fall. Aber so könnte man kann ohne Probleme nicht-lineare Snapshots unter LVM machen. Dort musste ich über Spezialitäten wie EFI-Images und TPM-Disks nicht nachdenken, das funktionierte alles OOTB.
Und die Datensicherheit hat man im Root-FS per ZFS trotzdem. Beim LVM-Thin übernimmt das dann eben das dmraid.
Last edited:
Ich habe evtl. die Überlegung meinen Mini-ITX Rechner als Backup-Kiste einzusetzen, auf den ich im Bedarfsfall die VMs migrieren könnte. Oder ich nutze ihn als snapshot/backup Kiste, falls das möglich ist.
Das mit den linearen snapshots gilt aber nur für den local zfs und nicht für einen extrigen, welcher die Datenhaltung inne hat oder?
Richtig. Aber per NFS kannst Du m.W. Snapshots auch nur per QCOW2 machen und hast die ganzen Problem mit EFI- und TPM-Images sowieso.
Außerdem wäre mir das zu langsam. Für die Images nehme ich lieber eine 2 TByte NVME.
Außerdem wäre mir das zu langsam. Für die Images nehme ich lieber eine 2 TByte NVME.
Swap-Partition ist ok, nur halt nicht auf ZFS oben drauf als Zvol oder Swap-File auf dem Dataset. Problem hast du mit Swap eher mit jeder Art von Raid. Weil entscheidest du dich z.B. für einen ZFS Mirror, dann ja weil du keine Downtime haben willst und alles weiterlaufen soll, auch wenn mal eine Platte ausfällt. Ist dein Swap dann aber nicht gespiegelt, weil du nur zwei einzelne Swap-Partitionen hast, da er ja nicht auf dem ZFS Pool sein darf und fällt dir dann eine Disk aus, dann ist natürlich auch der Swap auf der Disk weg und dir stürzen deine Dienste ab, welche von dem RAM auf die Swap-Partition ausgelagert wurden...
Da würde man sich dann denken...gut, dann kommt der Swap halt auf einen mdadm raid1 array...aber das darf man auch nicht...
Habe bisher noch von nichts außer HW raid gehört, wo man den Swap wirklich redundant haben kann...und wenn man schon ZFS nutzt dannholt man sich ja normal nicht extra eine HW Raid-Karte + dedizierte SSDs rein für den Swap.
Hatten wir vorhin ja diskutiert.
Ich habe das Layout vorhin ja mal ausprobiert. Dabei habe ich den swap einfach auf den beiden Swap-Partitionen angelegt (hat auch den Vorteil, dass es doppelt so viel ist). /etc/fstab z.B.:
Ist so aber nicht redundant, korrekt.
Wenn man das redundant machen will, kann man natürlich auch den Swap auf ein dmraid1 legen, warum denn nicht? Das ist n.m.E. bei Hetzner sogar die Standardeinrichtung:
Anders als bei ZFS wird da nämlich nichts dynamisch alloziert.
Ich habe das Layout vorhin ja mal ausprobiert. Dabei habe ich den swap einfach auf den beiden Swap-Partitionen angelegt (hat auch den Vorteil, dass es doppelt so viel ist). /etc/fstab z.B.:
Code:
UUID=..... none swap sw,pri=2 0 0
UUID=..... none swap sw,pri=2 0 0Ist so aber nicht redundant, korrekt.
Wenn man das redundant machen will, kann man natürlich auch den Swap auf ein dmraid1 legen, warum denn nicht? Das ist n.m.E. bei Hetzner sogar die Standardeinrichtung:
Code:
#swapon -s
Filename Type Size Used Priority
/dev/md0 partition 33520636 667648 -2
#cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 nvme0n1p1[0] nvme1n1p1[1]
33520640 blocks super 1.2 [2/2] [UU]
md2 : active raid1 nvme0n1p3[0] nvme1n1p3[1]
465894720 blocks super 1.2 [2/2] [UU]
bitmap: 4/4 pages [16KB], 65536KB chunk
md1 : active raid1 nvme0n1p2[0] nvme1n1p2[1]
523264 blocks super 1.2 [2/2] [UU]
unused devices: <none>Anders als bei ZFS wird da nämlich nichts dynamisch alloziert.
Last edited:
Hier habe ich das so verstanden, dass dir Swap auf mdadm unter umständen das Array zerschießen kann:
Bin jetzt aber nach erneutem lesen nicht sicher, ob sich das nur auf Swap in vDisks auf einem mdadm raid bezieht oder auch bare metal mit Swap auf mdadm.
Last edited:
So wie ich das lese, ist es so, dass der Write auf den Swap für den Prozess, der inzwischen gestorben ist, noch asynchron durchgeführt wird, zur Not auch teilweise. Das kann die Daten auf den beiden Spiegelteilen unterschiedlich zurücklassen, was normalerweise nicht passieren soll. Das ganze passiert, wenn ein Userland-Prozess mit O_DIRECT geschrieben wird, was qemu auch tut, wenn der Cache für das Image aus ist.
Das spielt aber m.E. keine Rolle, weder für den Swap auf dem Wirt, noch für (ebenfalls betroffene) Dateien auf dem LVM-Thin Raid, in denen eine VM-Swap-Partition enthalten ist. Insofern wäre, wenn zuträfe, auch das LVM-Thin auf dmraid ein Problem, während der Bare Metal Swap ja gar nicht mit O_DIRECT durch userland qemu geschrieben wird (also die Beschreibung nicht greift).
Ein Beispiel: Wenn ich eine Datei alloziere und dann "sparse" schreibe, kann ich auch nicht erwarten, dass ein von mir nicht beschriebener Teil der Datei einen bestimmten Inhalt hat. Tatsächlich gab es mal einen Bug, mit dem man so den alten Inhalt eines Datenträgers lesen konnte - inzwischen wird dafür gesorgt, dass "ungeschriebene" Teile beim Lesen Nullbytes liefern.
Tatsächlich ist der Zustand des Raids an dieser Stelle eventuell nicht konsistent und wenn man ihn checken würde, würde man das feststellen. Es ist aber kein echtes Problem für die konkrete Anwendung. Beispielsweise könnte man für die Nutzung als Dateisystem sogar darauf verzichten, beim Erzeugen eines Raid-1 die beiden Datenträger vorab zu synchronisieren: Der anschließende "mkfs"-Befehl würde ja alle NOTWENDIGEN Blöcke beschreiben - der Inhalt des Rests, also die bislang unbeschriebenen Blöcke, ist egal ("Garbage on disk"). Diese Blöcke werden automatisch gleichgeschaltet, sowie sie geschrieben werden.
P.S.: Ich selbst habe meine Systemplatte gar nicht als RAID betrieben. Mir ging es primär um die Aufteilung zwischen ZFS als (kleines) PVE-Root, Swap als separate Partition und einer LVM-Thin-Partition, um lineare Snapshots zu ermöglichen, ohne Probleme durch Einschränkungen bei bestimmten Typen von VM-Disk-Abbildern zu bekommen. Wie gesagt, ich war etwas überrascht von diesen Einschränkungen bei Nutzung von ZFS im Kontext von Promox. RAID wäre insofern nur das Sahnehäubchen.
Das spielt aber m.E. keine Rolle, weder für den Swap auf dem Wirt, noch für (ebenfalls betroffene) Dateien auf dem LVM-Thin Raid, in denen eine VM-Swap-Partition enthalten ist. Insofern wäre, wenn zuträfe, auch das LVM-Thin auf dmraid ein Problem, während der Bare Metal Swap ja gar nicht mit O_DIRECT durch userland qemu geschrieben wird (also die Beschreibung nicht greift).
Ein Beispiel: Wenn ich eine Datei alloziere und dann "sparse" schreibe, kann ich auch nicht erwarten, dass ein von mir nicht beschriebener Teil der Datei einen bestimmten Inhalt hat. Tatsächlich gab es mal einen Bug, mit dem man so den alten Inhalt eines Datenträgers lesen konnte - inzwischen wird dafür gesorgt, dass "ungeschriebene" Teile beim Lesen Nullbytes liefern.
Tatsächlich ist der Zustand des Raids an dieser Stelle eventuell nicht konsistent und wenn man ihn checken würde, würde man das feststellen. Es ist aber kein echtes Problem für die konkrete Anwendung. Beispielsweise könnte man für die Nutzung als Dateisystem sogar darauf verzichten, beim Erzeugen eines Raid-1 die beiden Datenträger vorab zu synchronisieren: Der anschließende "mkfs"-Befehl würde ja alle NOTWENDIGEN Blöcke beschreiben - der Inhalt des Rests, also die bislang unbeschriebenen Blöcke, ist egal ("Garbage on disk"). Diese Blöcke werden automatisch gleichgeschaltet, sowie sie geschrieben werden.
P.S.: Ich selbst habe meine Systemplatte gar nicht als RAID betrieben. Mir ging es primär um die Aufteilung zwischen ZFS als (kleines) PVE-Root, Swap als separate Partition und einer LVM-Thin-Partition, um lineare Snapshots zu ermöglichen, ohne Probleme durch Einschränkungen bei bestimmten Typen von VM-Disk-Abbildern zu bekommen. Wie gesagt, ich war etwas überrascht von diesen Einschränkungen bei Nutzung von ZFS im Kontext von Promox. RAID wäre insofern nur das Sahnehäubchen.
Last edited: