Die Frage des Filesystems für VMs

[Shihatsu]

Ayo, folgende situation:
workstation auf Linuxbasis, 2 NVMe Sticks, eine Sata-SSD. eine Sata-HDD.
NVMe1: BTRFS, Betriebssystem und games - keine weiteren Fragen
NVMe2: VM-Träger für diversteste Test/Rumspiel/Wasauchimmer VM - bisher war das ext4, da die Platte aber gerade ausgetauscht wird und ich bei NVMe1 gerade von ext4 auf BTRFS gewechselt bin hier auch die Frage: Gibts was besseres als ext4 für VMs?
Sata-SSD: Bisher ext4, wird aber wohl ZFS um einfacher Backups machen zu können.
Sata-HDD: same
Wie würdet ihr eure DAteisysteme, besonders für NVMe2 wählen?

 

[asche77]

Wenn Du schon BTRFS und einzelne disks verwendest, warum dann nicht überall BTRFS? "Besser" als ext4 sollte das allemal sein (vielleicht nicht ganz so schnell, dafür aber sichererer).

Auch BTRFS kann snapshots und die an extern übertragen (https://schwender-beyer.de/artikel.php?k=3&a=3), da sehe ich die Notwendigkeit für ZFS nicht (einzelne Platte, BTRFS wird ohnehin schon genutzt).

 

[gea]

Jedes Dateisystem hat seine Besonderheiten, Stärken und Schwächen. Da btrfs und ZFS in nahezu allen Punkten ext4 überlegen sind und beide wegen Copy on Write und Prüfsummen ähnlich sicher sind, würde ich darauf gehen. ZFS punktet eventuell mit sync write (Sicheres Schreiben trotz Nutzung eines rambasierten Schreibcaches für bessere Performance bei VM Storage) und special vdev (Tiering eines Teils der Daten auf einen schnelleren NVMe Bereich des Pools aus langsameren Platten aufgrund der Datenstruktur).

Am Wichtigsten ist aber "keep it simple", daher überall das gleiche damit man sich auskennt wenn es Probleme gibt.

 

[Shihatsu]

ZFS wäre meine rste Wahl für alles, aber nicht im Kernel ist halt ein Killer - BTRFS ist da fast genausogut.
Die ext4 Platten werden atm via rsync auf mein NAS gebackupped, das läuft mit ZFS - daher hat ZFS hier einen emanenten Vorteil gegenüber BTRFS, der aber nichts mit der Workstation selber zusammenhängt.
Daher war die Frage nur für das filesystem mit den VMs - ich hab irgendwo mal aufgeschnappt das CoW nicht gut ist wenn darauf VMs liegen - BTRFS behandelt solche Subdirectories ja auch anders. Müsste ich da also irgend etwas besonderes beachten? Wenn nicht nehm ich einfach ZFS...

 

[sch4kal]

ZFS wäre meine rste Wahl für alles, aber nicht im Kernel ist halt ein Killer - BTRFS ist da fast genausogut.
Die ext4 Platten werden atm via rsync auf mein NAS gebackupped, das läuft mit ZFS - daher hat ZFS hier einen emanenten Vorteil gegenüber BTRFS, der aber nichts mit der Workstation selber zusammenhängt.
Daher war die Frage nur für das filesystem mit den VMs - ich hab irgendwo mal aufgeschnappt das CoW nicht gut ist wenn darauf VMs liegen - BTRFS behandelt solche Subdirectories ja auch anders. Müsste ich da also irgend etwas besonderes beachten? Wenn nicht nehm ich einfach ZFS...

ZoL nutz ich jetzt schon seit ein paar Jahren im Notebook ohne Probleme, mW. auch als Kernelmodul. Es kommt zwar nicht OotB mit dem Kernel mit, aber ein Kernelmodul lässt sich doch bauen ?!

 

[asche77]

ich hab irgendwo mal aufgeschnappt das CoW nicht gut ist wenn darauf VMs liegen -

Verwechselst Du das evtl mit der Frage, welches Filesystem man IN der VM verwenden sollte? Aus dem Bauch raus würde ich in der VM ext4, aber auf dem VM storage ZFS (oder ein anderes CoW fs) verwenden ...

 

[Shihatsu]

ZoL nutz ich jetzt schon seit ein paar Jahren im Notebook ohne Probleme, mW. auch als Kernelmodul. Es kommt zwar nicht OotB mit dem Kernel mit, aber ein Kernelmodul lässt sich doch bauen ?!

Joa, Kernelmodul lässt sich bauen - aber das mach ich nicht auf einem Arch System. Zumindest nicht auf dem das nicht öfters mal zuckeln soll.

Verwechselst Du das evtl mit der Frage, welches Filesystem man IN der VM verwenden sollte? Aus dem Bauch raus würde ich in der VM ext4, aber auf dem VM storage ZFS (oder ein anderes CoW fs) verwenden ...

Unter Umständen tue ich das, ist durchaus möglich. Es spricht also nichts gegen ein CoW basiertes FS für VMs?

 

[asche77]

Unter Umständen tue ich das, ist durchaus möglich. Es spricht also nichts gegen ein CoW basiertes FS für VMs?

Glaube nicht, aber Fachfrauen/-männer wissen da evtl mehr.

(Edit: ich meinte: keine besonderen Nachteile im Vergleich zu nicht-VM-storage; gea benennt unten ja die allgemeinen Nachteile)

 

[gea]

Prinzipiell hat Copy on Write folgende Nachteile egal ob auf dem Host oder der VM

- das Ändern von "Haus" in "Maus" bedeutet dass man statt ein Byte zu ändern bis zu 1M je nach recsize Einstellung und Dateimenge schreiben muss. Es fällt also erheblich mehr io an, daher die Empfehlung bei VM Storage auf 16-64 k recsize zu gehen. 4-8k sind nicht empfehlenswert da dann ZFS ineffektiv arbeitet (langsame small io, Prüfsummen, Compress, Verschlüssellung etc)

- Fragmentierung bei Platten nimmt zu vor allem wenn der Pool voller wird, bei NVMe/SSD ist das egal

- Resourcenbedarf und Datenmenge steigen nicht zuletzt auch wegen der zusätzlichen Prüfsummen.
Das wird durch besonders aufwendige rambasierte Schreib/Lesecaches (über)kompensiert. Daher ist ausreichend RAM für die Performance wichtig egal ob auf dem Host oder in der VM vor allem bei langsamen Platten.

- Pools sind darauf optimiert, unabhängig von der Größe oder dem Layout konstante Multiuser Performance zu gewährleisten,
Für Single User Videocut eher nicht so optimal was Performance angeht.

In der VM wären neue Dateisysteme auch sicherer als ältere. Hat man meist aber keine Wahl. Wenn da z.B. Windows läuft ist ntfs die erste Wahl. Man hat dann aber dank ZFS darunter dennoch Prüfsummenkontrolle und höhere Datensicherheit. Lediglich ein Absturz bei Schreiben kann für die VM übel enden da Copy on Write nur dafür sorgt dass atomare Schreibvorgänge von btrfs oder ZFS sicher auf Platte sind, nicht aber die von Gast VMs egal mit welchem Dateisystem die arbeiten (daher die Notwendigkeit von sync write bei VMs)

 

[Shihatsu]

Vielen Dank euch beiden, eine Nachfrage noch: Du meinst bei Absturz aber schon Absturz des Host Systems, right? Weil: Das passiert eigentlich nicht. Kann mich nicht erinnern das mein Rechner wirklich abgestürzt ist seit ich auf Linux umgestiegen bin. zumindest nicht wenn ich nicht daddele, und dann laufen keine VMs...

 

[asche77]

Nein er meint Absturz der VM.

 

[Trambahner]

Wobei man in Bezug auf Abstürze/plötzliche Stromausfälle daran denken sollte, was evtl. noch im Ram-Writecache ist. Hat gea ja drüber schon geschrieben.
Daher SSDs mit Powerloss-Protection, Sync-Writes bei VMs oder zumindest ne USV, um Stromausfälle bei z.B. SMB-Shares (sind per default ja non-syncwrites) abzusichern.

 

[Shihatsu]

Nee, nicht bei Spiele-VMs. VMs mit relevanten Services oder relevanten Daten laufem aufm Proxmox, der ist dafür aufgestellt. Das Zeugs das ich lokal benutze ist schneller wieder hochgezogen als ich ein Backup einspiele (ansible/packer/k8s/...). Es geht hier nicht um irgendwelche produktiv Daten oder Services, sondern ausprobieren, testen, deployen etc pp. - aber abstürzen tun die wirklich an und an mal, weil ich sie absichtlich gegen die Wand fahre (cluster unterm Arsch wegreißen z.B.). Ich glaub dann setze ich dafür einfach weiterhin auf ext4.

 

[gea]

Nein er meint Absturz der VM.

Ich meinte Absturz des VM Servers (ESXi, ProxMox etc) beim Schreiben, egal ob durch Stromausfall, Hardware oder Softwareproblem. Auch eine UPS kann das nicht ausschließen. Trotz ZFS und CoW Dateisystem kann der VM Server ohne sync write (oder Hardwareraid Adapter + BBU) nicht verhindern dass Gastdateisysteme dabei hopps gehen weil man alles verliert was im RAM-Schreibcache ist. Ohne den sind Systeme langsam.

Stürzt eine VM ab, ist es deren Sache ob es Dateisystemprobleme oder Datenbankprobleme gibt. Mit CoW Dateisystem in der VM sehr unwahrscheinlich sonst möglich.

 

[gea]

Daher SSDs mit Powerloss-Protection, Sync-Writes bei VMs oder zumindest ne USV, um Stromausfälle bei z.B. SMB-Shares (sind per default ja non-syncwrites) abzusichern.

Nur als Ergänzung.
Wenn ZFS mit einem SMB Share beim Schreiben abstürzt, ist das ZFS Dateisystem wegen CoW zu 99,999% sicher (Totale Sicherheit gibts nicht. Es gibt immer ein minimales Zeitfenster in dem ein Absturz auch mit CoW Probleme macht). Da passiert ZFS nichts auch wenn man kein sync write nutzt. Lediglich die Datei die gerade geschrieben wird ist defekt. Da kann nur das schreibende Programm mit tmp Files helfen. Lediglich in dem Sonderfall in dem eine kleine Datei beim Schreiben bereits vollständig im RAM Schreibcache liegt aber noch nicht ganz auf Platte geschrieben werden konnte, bringt sync write eine Verbesserung bei einem SMB Filer. Da landet die Datei beim nächsten Reboot vollständig auf dem Pool. Bei langsameren SMB filern oder mit Verschlüssellung deaktiviert man daher meist sync write.

Lediglich bei VM Storage mit Dateisystemen oder transaktionalen Datenbanken ist sync write absolut notwendig. PLP braucht man damit ein Absturz während die Firmware der SSD im Hintergrund Garbage Collection macht oder ein Write bereits wegen besserer Performance bestätigt hat ohne das es tatsächlich sicher auf SSD ist nicht zu Datenverlust/ Korruption führt.

 

[Shihatsu]

Nochmals: Es ist kein Server über den wir hier reden, das ist meine workstation - ich zieh da halt immer mal wieder verschiedenste VMs hoch (kvm/qemu, vbox, vmware, ...), via verschiedenster Mittel (von Hand, packer, kubernetes, ...) und fragte mich halt ob EXT4 hier das Mittel der Wahl wäre... Ich glaub ich bleib bei EXT4, die VMs kommen eh in mannigfaltigen Dateisystemen die ich nicht ausscuhen oder ändern kann....

 

[gea]

Eine Workstation auf der VMs laufen ist ein Server. Das sicherste Dateisystem darauf ist ZFS. Um die Gastdateisysteme trotz schnelleren Schreiben über den RAM Schreibcache sicher zu halten aktiviert man sync bei ZFS. Mit ext4 erhält man schlicht nicht diese Sicherheit oder Performance. Selbst mit einem Raid Controller + BBU nicht mit dem man früher mit ext4 oder ntfs die Performance eines Schreibcaches mit Sicherheit kombinierte.

 

[Trambahner]

Addon schätze ich auch, dass ich einfach mit LZ4 VMs (je nach Inhalt natürlich) auch stark, völlig transparent und trotzdem performant komprimiert bekomme.

Nur schade, dass Windows bzw. der ISCSI Targetserver wohl kein Trim/Discard bei ISCSI-Shares an das Zvol schickt, so dass nicht mehr benutzte Blöcke mit Daten drin nicht wieder für ZFS leer erscheinen :-(.
Zumindest bei Proxmox mit "tgt".

 

[gea]

Nur schade, dass Windows bzw. der ISCSI Targetserver wohl kein Trim/Discard bei ISCSI-Shares an das Zvol schickt, so dass nicht mehr benutzte Blöcke mit Daten drin nicht wieder für ZFS leer erscheinen :-(.
Zumindest bei Proxmox mit "tgt".

Trim ist eine Funktion des Betriebssystems um SSDs zu optimieren. Was sich hinter einem iSCSI Target versteckt (Plattenart, Raid) ist für den Initiator nicht ersichtlich. Daher ist da kein Trim möglich - ist aber auch gar nicht nötig. Trim macht man direkt unter ZFS und alles was dann ZFS nutzt (Dateisysteme oder Zvols) profitiert dann davon.

 

[Trambahner]

Klar, woher sollte der Initiator das auch wissen. Letztlich ist es ein "Heimuser nutzt Datacenter-Technik" Thema für Scratch-Volumes, da im DC Bereich ja sowas eh unvorteilhaft ist, Trim und beständiges massives Freigeben von Blöcken würde da ja nur die Latenzen erhöhen.

Ich nulle halt bei solchen Shares einfach bei Bedarf innerhalb der VMs die entprechenden freien Bereiche von Volumes, das bringt auch Speicherplatz von den Pools (sind bei mir LZ4-komprimiert) zurück.
Z.B. unter Windows mit "sdelete".

 

[gea]

ZFS Trim kann man dauerhaft oder on Demand z.B. nachts einsetzen. Da macht ein Trim Performanceverlust nichts aus und die SSD ist nachher wieder schneller beim Schreiben und die SSD interne Garbage Collection arbeitet effektiver.

Das "Wiederherstellen freien Platzes" liegt wohl daran dass das Zvol thin provisioned angelegt wurde und hat eigentlich nichts mit Trim zu tun. Schreiben von Nullen eventuell zusammen mit Compress ist wohl ein Workaround wenn keine andere Shrink Option zur Verfügung steht. NFS statt iSCSI hätte das alles nicht und ist im Handling viel einfacher zumal man dann parallel per SMB und Windows inkl ZFS Snaps=previous versions an die VMs kommt. Das ist aber eine andere Baustelle.