Naja, das stimmt so pauschal nun auch nicht. Ich habe auf meinen beiden PVE-Hosts auch mit ZFS formatierte SSDs für die VMs, bislang hält sich die Abnutzung in Grenzen (< 5%), aber es ist eben ein Glücksspiel. Gibt hier genug Threads, wo Leute sich sehr schnell ihre Consumer-SSDs kaputt gemacht haben.
Was allerdings generell stimmt: Consumer-SSDs als /boot-Medium sind problematisch, da ständig Logging- und Metrikdaten durch das Betriebssystem und die PVE-Dienste auf die Festplatte geschrieben werden und ZFS macht es nicht besser (da ZFS von sich aus schon mehr schreibt für seine automatische Erkennung von Datenfehlern und andere Features). Das kann man nun auf verschiedene Weise lösen:
- HDD statt SSD nehmen, HDDs sind da robuster und nur auf den Betriebssystem tut die schlechtere Performance der HDDs nicht so weh.
- Gebrauchte Enterprise-SSD mit powerloss-protection als Medium fürs Betriebssystem kaufen. Das ist die mit Abstand sinnvollste beste Option, setzt halt voraus dass die als Server verwendete Hardware einen oder mehrere (falls man SW-RAID machen will) SATA-Anschlüsse hat.
- Damit leben, dass man halt öfter neue SSDs kaufen muss und entsprechend planen.
- LVM + ext4 oder LVM+XFS als Dateisystem für die /boot-Partition und ggf. auch die VMs nehmen. Kann man im Homelab machen, wenn man eh keinen Cluster einsetzt. Will man aber z.B. Storage-Replikation nutzen, dann braucht es ZFS, da das für LVM und co nicht unterstützt wird. Ein Kompromiss könnte sein, dass man nur die /boot-Partitition mit LVM einrichtet und die SSD für die VMs/Container mit ZFS. So mache ich es aktuell, bin damit aber nicht zufrieden: Mein aktuelles Setup hat keine Redundanz, damit greift die Autoheilung von ZFS nicht. Daher erscheint mir mittlerweile ein ZFS-Mirror über /boot, Betriebssystem und die VM/lxcs als kleineres Übel. Dass ich dann envtl. öfter die M2-SSD (da es die leider so gut wie nie mit PLP gibt) austauschen muss, ist dann halt so. Aktuell warte ich noch auf ein gutes Angebot für eine gebrauchte Enterprise-SSD mit ausreichender Größe.
- Eher experimentell und nur wenn man keinen Cluster am Laufen hat: Mit Verlagern der Loggingverzeichnisse in den Arbeitsspeicher (mit log2ram o.ä.) und Abschalten der Clusterdienste die Schreiblast reduzieren. Das bringt aber eigene Probleme mit sich, da es damit im Falle eines Stromausfalls zu Datenverlusten und Inkonsistenzen führen kann, deshalb ist das besonders bei Clustern ein No-Go für mich.
SSDs sind auf eine bestimmte Anzahl Schreibvorgänge ausgelegt, die bei den typischen Consumer-Drives deutlich schneller erreicht werden. Da sie außerdem keine Powerloss-Protection haben, gibt es auch keinen Bufferspeicher, sondern alle Daten müssen immer direkt auf die SSD geschrieben werden (statt erst zu größeren Blöcken zusammengefasst und dann in einen Rutsch geschrieben), das reduziert die Lebensdauer auch noch mal:
Ich habe mich früher schon gefragt, warum man eigentlich eine Batterie für einen Raidcontroller Cache braucht, wenn man denn 2 Netzteile und 'ne USV hat. Das man also ohne BBU den Cache nicht verwenden kann, fand ich damals schon dämlich.
Hier im Forum wird immer wieder betont, wie wichtig PLP bei SSDs ist, weil man dadurch deutlich mehr Performance bekommt. Ich habe mich damals schon gefragt, was PLP denn mit Performance zu tun hat. Da ich mich aber nicht auskenne, habe ich die Aussage einfach übernommen. Jetzt bin durch die horrenten Preise zu PLP SSDs wieder über die Frage...
