PVE auf ZFS-Root-Pool

[waldwuffel]

Hallo noch einmal!

Mein PVE-Server steht nun fast - es fehlen nur noch die Festplatten. Auf jeden Fall sind geplant: 4 x 10TB Seagate Exos für die Container und VMs als RAID 10. Unsicher bin ich mir nur noch etwas darüber, ob ich für PVE selbst eine separate SSD verwenden sollte oder nicht. Eigentlich tendiere ich dazu, das System auch auf den ZFS-Pool zu installieren - so hätte ich da auch die Redundanz und ich schätze, eine besonders hohe Geschwindigkeit ist hier nicht nötig. Irritiert hat mich nur folgendes:

"Now replace the physical disk (if it's hot-swappable, otherwise you'll have to reboot which could be interesting if it's /dev/sda that's failing)."
https://pve.proxmox.com/wiki/ZFS:_Tips_and_Tricks#Replacing_a_failed_disk_in_the_root_pool

Das liest sich für mich so, als könnte es evtl. Probleme geben, wenn eine Festplatte auszutauschen ist, die Teil des Root-Pools ist. (Tatsächlich werden meine HDDs hot-pluggable sein, aber man weiß ja nie...)

Von daher meine Frage: spricht etwas dagegen, Proxmox VE auf einen ZFS-Pool zu installieren? Und wenn ja, welche SSD wäre empfehlenswert? Auch hier konnte ich zwar viel im Allgemeinen finden (hoher TBW-Wert etc.), aber so richtig fündig geworden bin ich nicht bei der Suche (die Werte sind, entsprechend der Speicherkapazität, sehr ähnlich bzw. es sticht eigentlich nichts heraus).

Ich hoffe jetzt nicht auf eine komplett ausbuchstabierte Lösung - nur ein kleiner Schubs in die richtige Richtung wäre schön.

 

[waldwuffel]

Sorry, falsche Kategorie... bitte verschieben

 

[LnxBil]

Das liest sich für mich so, als könnte es evtl. Probleme geben, wenn eine Festplatte auszutauschen ist, die Teil des Root-Pools ist. (Tatsächlich werden meine HDDs hot-pluggable sein, aber man weiß ja nie...)

Das ist ein generelles Problem, dass darin besteht, dass wenn deine erste Platte kaputt geht, also die, von der du bootest, dann ist das schon schlimmer als wenn egal welche kaputt geht. Wenn du jetzt den Rechner ausschalten würdest um die Platte zu tauschen würde er beim nächsten Boot von der nun neu eingesetzten Platte booten wollen, da ist aber noch nix drauf und dann wars das mit deinem System. Falls aber alles Hot-pluggable ist kann das System die Platte komplett reparieren und bei bei einem Neustart (nach der Reparatur) würde alles wie erwartet funktionieren.

 

[waldwuffel]

Vielen Dank für die Antwort. Okay, wenn dieses Problem bzw. die Möglichkeit allgemein besteht, bin ich nun doch schon am Überlegen, ob ich die Konfiguration nicht etwas ändern sollte (man weiß ja nie, ob letzten Endes doch etwas nicht funktioniert mit dem Hot-Plug...). Leider hat mein Server nur 4 SATA-Anschlüsse, d.h. es blieben nur ein M.2- oder PCIe-Slot übrig. Evtl. baue ich mir da eine Intel Optane DC P4801X mit 100 GB ein, um PVE darauf zu installieren. Die Ausfallsicherheit ist damit zwar nicht mehr so gegeben bzw. wenn die SSD kaputt geht, ist das System erstmal down, aber ich wäre auf der sicheren Seite, wenn ich es richtig verstehe.

 

[LnxBil]

aber ich wäre auf der sicheren Seite, wenn ich es richtig verstehe.

Ne, leider nicht. Wenn in einem ZFS-Mirror die erste Platte kaputt geht, kannst du davon nicht mehr booten, was aber kein Problem ist. Du startest den Rechner, drückst F11 (oder was dein Mainboard dir sagt was du drücken musst für das Bootmenü) und wählst die zweite Disk aus, bootest und alles klappt weiter - es geht nur nicht automatisch, wie es bei einem Hardware-RAID der Fall wäre. Dann kannst du in Ruhe die kaputte Platte ausbauen und entsprechend den Anleitungen im Wiki deinen ZFS-Pool wieder reparieren.

Wenn du das mit der Optane (oder sonst einem Single-Laufwerk) machst und die geht kaputt hast du nix mehr und musst neu installieren.

 

[waldwuffel]

Dass das bei einem einfachen Mirror so geht, klingt einleuchtend. Der ZFS-Pool soll allerdings als "RAID 10" betrieben werden (mit 4 SATA-HDDs). Wäre in dem Fall eine solche Situation riskanter, was die Möglichkeit angeht, den Pool überhaupt wieder zu reparieren, wenn (warum auch immer) ein Neustart nötig sein sollte, bevor er wiederhergestellt worden ist?

 

[waldwuffel]

Ginge es ansonsten vielleicht so: auf Grundlage der 4 vorhandenen HDDs bei der Installation einen kleineren Pool (Mirror, ggf. halt viermal gespiegelt) für das System erstellen und dann mit dem restlichen freien Speicherplatz der Platten für die Container, VMs und Daten den RAID-10-Pool. Nach dem, was ich bisher gelesen habe, kann man mit ZFS ja ziemlich frei umgehen, was die Aufteilung des verfügbaren Speicherplatzes usw. angeht. Erfahrung habe ich damit bisher allerdings noch gar keine, daher bin ich mir etwas unsicher, wie ich das am besten umsetzen sollte bzw. was überhaupt (sicher) möglich ist.

 

[typewriter]

Hier kam gerade Optane als Systemplatte zur Sprache. Ich meine hier im Forum mehrfach gelesen zu haben, dass Proxmox SSDs schnell "kaputtschreibt" und man wenn überhaupt Enterprise SSDs nutzen soll. Was wäre dann ein ideales Systemlaufwerk? Ich klinke mich hier einmal ein, weil ich gerade vor einem ähnlichen Problem stehe wie der OP - eine sinnvolle Festplatten-Kombination auszuwählen.

 

[waldwuffel]

Ich meine hier im Forum mehrfach gelesen zu haben, dass Proxmox SSDs schnell "kaputtschreibt" und man wenn überhaupt Enterprise SSDs nutzen soll.

Ja, das ist auch der Grund, warum ich, wenn, dann eine solche nehmen wollte. Hatte auch danach gesucht, welche SSD eine relativ lange Lebensdauer hat, und bin auf die genannten Optane-SSDs gestoßen. Eine Konfiguration nur mit (redundanten) Festplatten wäre mir allerdings lieber, zumal die Geschwindigkeit des Systemlaufwerks ja nicht so relevant ist.

 

[LnxBil]

Dass das bei einem einfachen Mirror so geht, klingt einleuchtend. Der ZFS-Pool soll allerdings als "RAID 10" betrieben werden (mit 4 SATA-HDDs). Wäre in dem Fall eine solche Situation riskanter, was die Möglichkeit angeht, den Pool überhaupt wieder zu reparieren, wenn (warum auch immer) ein Neustart nötig sein sollte, bevor er wiederhergestellt worden ist?

Bei RAID10 (also zwei mirrored vdevs) wird die Boot-Partition auf die ersten zwei Disks gelegt. Wenn du online alles tauschen kannst hast du eh kein Problem, sonst das von mir beschriebene wenn eine der ersten beiden Platten kaputtgeht.

Ginge es ansonsten vielleicht so: auf Grundlage der 4 vorhandenen HDDs bei der Installation einen kleineren Pool (Mirror, ggf. halt viermal gespiegelt) für das System erstellen und dann mit dem restlichen freien Speicherplatz der Platten für die Container, VMs und Daten den RAID-10-Pool. Nach dem, was ich bisher gelesen habe, kann man mit ZFS ja ziemlich frei umgehen, was die Aufteilung des verfügbaren Speicherplatzes usw. angeht. Erfahrung habe ich damit bisher allerdings noch gar keine, daher bin ich mir etwas unsicher, wie ich das am besten umsetzen sollte bzw. was überhaupt (sicher) möglich ist.

Kann man alles machen, aber das löst doch dein Problem nicht. Problem ist nach wie vor wenn die erste Platte freckt und du einen Neustart machst kann es sein, dass du manuell von der 2. Booten musst (je nachdem wie kaputt deine 1. Platte ist).

Hier kam gerade Optane als Systemplatte zur Sprache. Ich meine hier im Forum mehrfach gelesen zu haben, dass Proxmox SSDs schnell "kaputtschreibt" und man wenn überhaupt Enterprise SSDs nutzen soll. Was wäre dann ein ideales Systemlaufwerk? Ich klinke mich hier einmal ein, weil ich gerade vor einem ähnlichen Problem stehe wie der OP - eine sinnvolle Festplatten-Kombination auszuwählen.

Proxmox VE ist ein Enterprise Virtualisierungsprodukt und billig-SSDs passen da nicht so dazu. Wobei billig ist nicht das richtige Wort, denn eine 16 GB Optane kostet auch keine 40 Euro. Es geht einfach um die Schreibfähigkeit. Viele haben es schon ausprobiert und sind auf die Nase gefallen mit Consumer bis zu Prosumer SSDs (mich eingeschlossen), nur die Enterprise SSDs sind für die Schreibvorgänge ausgelegt und das sehr, sehr gut (mich auch hier eingeschlossen).

Eine Optane ist super, ich hab selbst eine, aber die haben einen ganz speziellen Einsatzbereich, nämlich z.B. als Journaling-Gerät bei CEPH oder auch bei ZFS, wo synchron schnell geschrieben werden muss. Klar kann man die auch für vieles andere einsetzen, u.A. auch als Systemplatte, jedoch dann bitte nur gespiegelt.

Generell kann ich mit ZFS zu einem gemischten System raten, d.h. z.B. zwei kleine Enterprise SSDs (auch gerne gebraucht) als special devices in ZFS und sonst alles auf gespiegelte VDEVs legen. So hat man die optimale Geschwindigkeits fürs Geld. Dazu kann man noch eine Optane (oder besser zwei) als ZIL hängen und ihr habt ein echt flottes System, wenn ihr die Platten schon habt. Kosten unter 100 Euro für 2 gebrauchte, kleine Enterprise SSDs und eine Optane. Eine Liste der "guten" SSDs findet sich an dieser hier ständig zitierten Seite.

 

[waldwuffel]

Bei RAID10 (also zwei mirrored vdevs) wird die Boot-Partition auf die ersten zwei Disks gelegt. Wenn du online alles tauschen kannst hast du eh kein Problem, sonst das von mir beschriebene wenn eine der ersten beiden Platten kaputtgeht.

Okay, wenn so oder so im schlimmsten Fall lediglich das Boot-Laufwerk nach dem Neustart manuell angegeben werden muss, bin ich beruhigt (zumal das ja eigentlich nicht einmal nötig sein sollte). Ich hatte es nur zunächst so verstanden, als gäbe es da Konfigurationen, bei denen man in einer solchen Situation gar nicht mehr (ohne weiteres) zu dem Punkt kommen könnte, den Pool zu reparieren. An der Stelle nochmal vielen Dank für die Antworten!

 

[typewriter]

Generell kann ich mit ZFS zu einem gemischten System raten, d.h. z.B. zwei kleine Enterprise SSDs (auch gerne gebraucht) als special devices in ZFS und sonst alles auf gespiegelte VDEVs legen. So hat man die optimale Geschwindigkeits fürs Geld. Dazu kann man noch eine Optane (oder besser zwei) als ZIL hängen und ihr habt ein echt flottes System, wenn ihr die Platten schon habt. Kosten unter 100 Euro für 2 gebrauchte, kleine Enterprise SSDs und eine Optane. Eine Liste der "guten" SSDs findet sich an dieser hier ständig zitierten Seite.

Wie würde dann konkret eine sinnvolle Kombination aussehen?

Ich will v.a. meine Desktop-Systeme (OSX, Windows 10) als VMs virtualisieren, um Snapshots etc. nutzen zu können. Von den VMs erzeugte Daten landen alle über ein 10GB Netzwerk auf einem externen Server, wo dann für die Daten Redundanz besteht und dann gibt es noch einen zweiten Server für Backup der Server-Daten.

Ich dachte im einfachsten Fall an eine EXOS Festplatte für PVE und an eine SSD (oder mehrere) als Storage für die VMs. Wenn ich Dich richtig verstehe, dann käme für die VMs auch eine Kombination aus gespiegelten VDEVs mit SSDs als special devices in Frage. Macht da ein VDEV aus zwei gespiegelten Platten und zwei SSDs als special devices schon Sinn? Ich schätze, Du dachtest an deutlich mehr VDEVs.

 

[LnxBil]

[...]bei denen man in einer solchen Situation gar nicht mehr (ohne weiteres) zu dem Punkt kommen könnte, den Pool zu reparieren.[...]

Ne ne. ZFS ist Enterprise Storage und es ist wirklich sehr gut durchdacht.

Ich dachte im einfachsten Fall an eine EXOS Festplatte für PVE und an eine SSD (oder mehrere) als Storage für die VMs. Wenn ich Dich richtig verstehe, dann käme für die VMs auch eine Kombination aus gespiegelten VDEVs mit SSDs als special devices in Frage. Macht da ein VDEV aus zwei gespiegelten Platten und zwei SSDs als special devices schon Sinn? Ich schätze, Du dachtest an deutlich mehr VDEVs.

Ich würde nur auf die special allocation class mit SSD setzen, wenn dein primärer Speicher Festplatten sind. Je nach SSD würde ich erstmal im Internet recherchieren, wie gut oder schlecht diese mit ZFS arbeiten. Con- und Prosumer SSDs haben oft kein ZFS als Einsatzgebiet, was dann in der Verwendung zu einer enorm hohen Wearout-Rate führt. Bei Enterprise SSDs ist diese nicht vorhanden.

Generell würde ich aber immer versuchen die Daten redundant zu halten, also keine extra PVE Platte, die nicht gespiegelt ist. Eigentlich steht und fällt es mit Enterprise SSDs. Hier im Forum gibt es viele Berichte über langsames SSD ZFS, was mit Con-/Prosumer SSDs gemacht wurde. Ich selbst hab auf einem Desktop auf einer 750 EVO ein ZFS laufen (ohne PVE), was gut klappt, aber ich auch wirklich keine Ansprüche an die Maschine hab', da ich alles auf unserem PVE-Cluster mache. Früher hatte ich die 750 EVO mal mit PVE und ZFS betrieben und nach 1,5 Monaten war schon gut ein Drittel des Wearouts verflogen, da so viel geschrieben wird. Das Problem besteht intern in der SSD: Wenn man z.B. einen 4K Block schreiben möchte, dann ist es abhängig wie die SSD intern gebaut ist und ob auch wirklich nur ein 4K-Block geschrieben wird oder gleich ein viel größerer Block wie z.B. 1 MB, da dies die kleineste zu speichernde Einheit in der SSD sein könnte. So hat man dann mit 1024x 4K Schreibvorgängen gleich 1 GB an geschriebene Daten auf der SSD verursacht. Daher immer den Wearout im Auge behalten, denn es bringt nix, wenn die SSD nach einem Jahr bereits ihre komplette Garantie aufgebraucht hat. Das ist der entscheidende Punkt, an dem sich Enterprise SSDs hervorheben, denn dort wird z.B. 4K oder 8K Blöcke intern verwendet.

Zu Waldwuffels Ansatz mit 4 Festplatten kann man durchaus zwei kleine Enterprise SSD dazu packen, die als special allocation class dienen und zum einen die kompletten Metadaten des Pools als auch z.B. das ROOT-Dataset enthalten. Zum Beschleunigen kann ich hier noch eine kleine Optane (z..B 16 GB, denn für ZIL benötigt man nicht viel Speicher. Oft wird immer 5 GB angegeben) angehängt werden, die die SYNC Schreibvorgänge beschleunigt. Dann hat man ein recht performantes ZFS, man kann es aber auch gleich "nur" bei den Festplatten belassen, je nach Geldbeutel. Eine einzelne SSD nur für PVE macht keinen Sinn, lieber auf die Platten mit drauf.

Bei Typerwriters Ansatz mit nur einer Platte und einer SSD kann man das nicht gescheit kombinieren, denn man hat weder Redundanz noch Vorteile die beiden Speichermedien zu kombinieren. Hier also am Besten zwei Pools erstellen und ständig Backups machen. Bei der Redundanz sind die Backups weniger wichtig, wenn man mit ZFS-Mitteln snapshots macht und diese auf ein nicht-lokales Medium sendet. Das ist wesentlich Speicherplatzsparender als Backups, da ja nur die Änderungen übertragen werden.

Generell gilt wie immer: selbst ausprobieren und sehen ob es für einen passt. Ich betreibe kleinere Installationen mit 10-20 Containern auf zwei Laptop Festplatten (in einem Laptop) als RAID1 (gespiegeltes vdev) ohne Probleme seit Jahren. Im Privatbereit setze ich auch seit mindestens 10 Jahren nur noch RAID (außer 0 natürlich ) ein und empfehle dies auch jedem.

 

[waldwuffel]

@LnxBil: Danke für die ausführliche Erklärung. Das hat einiges an weiterem Verständnis gebracht. Tatsächlich werde ich es jetzt erstmal bei den 4 HDDs belassen, aber ich kann mir schon vorstellen, die Konfiguration später noch zu erweitern (was ja offenbar problemlos möglich ist). Leider ist mein Server (basiert auf einem Supermicro X11SCL-IF), was die installierbaren Komponenten angeht, etwas eingeschränkt. Zusätzlich können jetzt noch ein M.2- und ein PCIe-Laufwerk eingebaut werden. Ich werde mich mal informieren, was da evtl. in Frage kommen könnte.

 

[Klaus Urban]

Ich würde auf jeden Fall den PVE-Server auf einer SSD/HDD installieren. Das ZFS dann später auf weiteren SSD/HDD einrichten.
Bei eine Neuinstallation wird sonst der ZFS-Speicher gelöscht. Das Installieren eines PVE-Servers ist ja schnell gemacht und die Konfiguration ist ja auch einfach zurückzusichern. (Natürlich sollte die vorher gesichert werden) ;-)
Der zpool kann dann mit "zpool import POOLNAME -r" eingebunden werden.
Wer den POOLNamen nicht mehr kennt, mit "zpool import" wird er angezeigt.

 

[LnxBil]

Danke für die ausführliche Erklärung.

Kein Problem, war ja leider doch wieder etwas ausufernd.

die Konfiguration später noch zu erweitern (was ja offenbar problemlos möglich ist)

Ja, das ist kein Problem, so lange du an den vorhandenen vdevs nicht ändern willst. Wenn du dich z.B. Jetzt für ein RAID5 entscheidest ist das final, das kann man nicht mehr online und ohne neuen Pool anzulegen z.B. in RAID10 ändern. Hinzufügen von special devices, slog/zil etc. ist jedoch online möglich.

Leider ist mein Server (basiert auf einem Supermicro X11SCL-IF), was die installierbaren Komponenten angeht, etwas eingeschränkt.

SAS HBA rein und gut is :-D
Ich hab meine Enterprise SSDs (special allocation class) da auch dranhängen und ich hab noch kein Gehäuse gesehen, was die 255 adressierbaren SAS-Geräte ausnutzen würde.

Bei eine Neuinstallation wird sonst der ZFS-Speicher gelöscht.

Fraglich warum das überhaupt notwendig sein würde. Wir brauchen uns nicht über Redundanz, Optimierung und Performance zu unterhalten, wenn grundlegende 0815-Administrationskenntnisse fehlen ein System nochmal zum laufen zu bringen. Deiner Logik folgend: nur weil der Admin keine Ahnung hat auf 50% der Performance und des Platzes zu verzichten finde ich schon etwas überzogen und definitiv nicht geeignet für ein Produktivserver, Testsystem ist was anderes, aber darüber reden wir hier ja nicht. Wer vor einem Upgrade keinen Snapshot des ROOT/pve-1 datasets anlegt (oder einen automatisch angelegten nutzen kann) ist selbst schuld.

 

[Klaus Urban]

Fraglich warum das überhaupt notwendig sein würde. Wir brauchen uns nicht über Redundanz, Optimierung und Performance zu unterhalten, wenn grundlegende 0815-Administrationskenntnisse fehlen ein System nochmal zum laufen zu bringen. Deiner Logik folgend: nur weil der Admin keine Ahnung hat auf 50% der Performance und des Platzes zu verzichten finde ich schon etwas überzogen und definitiv nicht geeignet für ein Produktivserver, Testsystem ist was anderes, aber darüber reden wir hier ja nicht. Wer vor einem Upgrade keinen Snapshot des ROOT/pve-1 datasets anlegt (oder einen automatisch angelegten nutzen kann) ist selbst schuld.

Manchmal ist es einfach schneller neu zu installieren, als den Fehler zu beheben. Ich gehe immer vom Worst-Case aus.
Ich bin seit 1985 als Admin tätig. (Novell-Netware, Windows-Server, Linux, VMWare usw.)
Nur bei PoxMox bin ich noch Anfänger.

BTW. Mehrfache Datensicherungen auf verschiedenen Medien ist natürlich Pflicht. Man sollte aber den Ausfall so kurz wie möglich halten.
Warum zurücksichern, wenn die Daten noch da sind.