Ideale Server-Konfig für externen Speicher

[Johannes S]

Udo und Falk haben zu special device, log device und SSDs versus HDDs und RAIDZ schon genug geschrieben.
Ergänzend folgender Blogpost von Jim Salter: https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/
Seine Argumentation ist, dass RAIDZ nicht nur deutlich langsamer ist, sondern auch beim Ausfall einer (der heute üblichen) Platten mit mehreren TB sehr lange zum resilvern braucht, damit man wieder die Datenintegrität und Sicherheit hat (die ja einer der Gründe sind, warum man ZFS einsetzt). Und mit Mirrorn bzw. striped mirrorn (aka RAID10) hat man ebenfalls eine sehr gute Ausfallsicherheit, aber deutlich bessere Performance und kürzere resilver-Zeiten.

Zum cache device: Der Ausfall ist zwar nicht wirklich schlimm, es wird aber erst genutzt, wenn der reguläre ARC-Cache im RAM von ZFS nichts mehr bringt. Das ist im Homelab eher selten der Fall:

• Entweder der PBS läuft eh die ganze Zeit, dann liegen die Daten im RAM-Cache und werden daraus gelesen
• Oder (wie bei mir) er wird nur für die Sicherung per wakeoverlan oder ähnliches angeschaltet, dann finden nur wenig/gar keine Zugriffe statt, die davon profitieren würden.

Dazu kommt, dass ein special device (bitte nur mit ausreichender Redundanz mirror) immer mehr bringen wird, weil damit die Zugriffe auf Metadaten (lesend wie schreibend!) deutlich schneller gehen, als wenn der Lese-/Schreibkopf der Festplatten hin- und her bewegt werden muss.

 

[S3v|\|]

Super - Danke Euch allen - der erste Fehler wäre nun schon vermieden. Gefühlsmäßig hätte ich mich für ein RAID-Z2 entschieden.

@Falk R. : Du hast mich zwar schon zu einem Hardware PBS überzeugt - aber SSD only ist aktuell einfach zu teuer.
@UdoB : Dein Setup gefällt mir recht gut. Was meinst Du mit "Immer mehrere vdevs"? Eventuell einen Pool, der aus mehreren Mirrors aufgebaut ist (vergleichbar Raid 10). Wäre das dann auch das Setup, wenn man z.B. 6 HDDs verwenden möchte? Kann man diesen Pool mit einem weiteren Mirror erweitern (im Sinne von Falk R. dass man dann in diesem Fall jeweils 2 Festplatten nachstecken kann)?

 

[UdoB]

Was meinst Du mit "Immer mehrere vdevs"? Eventuell einen Pool, der aus mehreren Mirrors aufgebaut ist (vergleichbar Raid 10).

Exakt

Wäre das dann auch das Setup, wenn man z.B. 6 HDDs verwenden möchte? Kann man diesen Pool mit einem weiteren Mirror erweitern

Ja, kann man - das ist durchaus üblich, beim "wachsen". (Wenn man das nachträglich macht, sind und bleiben die Paare allerdings zunächst unterschiedlich voll und müssen nachträglich ausgewuchtet werden ;-) )

Du bringst mich gerade etwas ins schleudern: ich weiß nicht, wie/ob das im WebGUI funktioniert.

Wenn alle sechs Platten nagelneu sind, kann man zpool create meinpool mirror /dev/disk/by-id/platte1 /dev/disk/by-id/platte2 mirror /dev/disk/by-id/platte3 /dev/disk/by-id/platte4 mirror /dev/disk/by-id/platte5 /dev/disk/by-id/platte6 machen.

man zpool-add verrät die Syntax zur nachträglichen Ergänzung für die Kommandozeile. Ich will hier jetzt keinen vollständigen ZFS-Grundlagen-Kurs abliefern, das ist vielfach dokumentiert.

Konkrete Fragen sind hier aber natürlich weiterhin willkommen

 

[news]

Du bringst mich gerade etwas ins schleudern: ich weiß nicht, wie/ob das im WebGUI funktioniert.

Hallo @UdoB gute Zusammenfassung.
Und die erweiterten ZFS Kommandos muss man immer über die Konsole absetzen.

 

[TErxleben]

Und die erweiterten ZFS Kommandos muss man immer über die Konsole absetzen.

Genau deshalb ist zfs im PVE-Umfeld nicht mein präferiertes Dateisystem, sondern eher Kategorie: kann man muss man aber nicht.

 

[Bu66as]

Die Posts (#38–#40) beantworten S3v's RaidZ- und Dedup-Frage, aber #36 wegen SLOG vs. Cache device beim PBS ist offen. Dazu kann ich noch konkret was sagen.

---

Zu deiner Frage, welches der drei Devices beim PBS was bringt, special device war ja schon Thema:

SLOG kannst du dir beim PBS sparen. Das greift nur bei synchronen Writes, und die Backup-Streams schreibt der PBS async. Bringt dir also nichts.

Cache device (L2ARC) ist beim PBS auch meist rausgeschmissenes Geld. Deine Reads bei GC und Verify sind quasi random über den kompletten Datastore, da ist die Hit-Rate mies. Und L2ARC frisst zusätzlich ARC-RAM für die Header, kann dir also sogar schaden. Steck den Euro lieber in mehr RAM oder ein ordentliches special device.

Von den dreien bringt nur das special device was beim HDD-PBS. SLOG und L2ARC lass weg. Dedup-Device wie UdoB schon meinte sowieso nicht, der PBS dedupliziert eh selbst.

 

[Johannes S]

Ergänzung: Seit zfs 2.4 ( PBS 4.2, PVE 9.2 ) wird das Special device als slog device genutzt, wenn es kein eigenes gibt:
https://github.com/openzfs/zfs/pull/17505


Für asynchrone Writes bringt das immer noch nichts, aber man kann sich dann das Einrichten sparen, sofern man keinen spezifischen Usecase hat, der ein dezidiertes slog-device rechtfertigen würde.

 

[S3v|\|]

Vielen Dank Euch allen - Vor allem auch für die Erläuterungen, was die einzelnen Cache-SSDs für Vorteile haben (oder auch nicht )

Steck den Euro lieber in mehr RAM oder ein ordentliches special device.

Also RAM wird aufgerüstet, sobald er wieder bezahlbar ist - aber bei aktuell 3 bis 5 Euro pro GB für Gebrauchten macht es leider kein Sinn.
Wie sieht es mit Optane für special device aus? Die sind aktuell gebraucht preislich in Ordnung. Ok - man kann nicht sagen wieviel TB-Written da schon verbraucht sind - oder sollte man da lieber sicher gehen und neue SATA SSDs nehmen?

Zu den Festplatten: wie sieht es mit einem RAID 50 aus (also ein ein Stripe über zwei RAID-Z1) - dann hätte ich abgesehen von dem langsamen Resilver-Prozess die Vorteile von beiden?
z.B. bei 6 Platten
RAID50: Schreibrate von 2 Platten und 66% Ausnutzung
RAID10: Schreibrate von 3 Platten und 50 % Ausnutzung
z.B. bei 8 Platten
RAID50: Schreibrate von 2 Platten und 75% Ausnutzung
RAID10: Schreibrate von 4 Platten und 50 % Ausnutzung

Die Leserate müsste ungefähr bei beiden gleich sein, da ja von allen gleichzeitig gelesen werden kann.
Ausfallsicherheit ist bei RAID10 theoretisch auch höher, da bei jedem Mirror jeweils eine ausfallen kann.

Oder hab ich hier auch schon wieder ein Denkfehler?

 

[Johannes S]

Das wird halt trotzdem langsamer als mirror oder striped mirror sein. Octane für special device ist OK, sollten halt min. 2 im mirror sein

 

[waltar]

z.B. bei 6 Platten
RAID50: Schreibrate von 2 Platten und 66% Ausnutzung
RAID10: Schreibrate von 3 Platten und 50 % Ausnutzung
z.B. bei 8 Platten
RAID50: Schreibrate von 2 Platten und 75% Ausnutzung
RAID10: Schreibrate von 4 Platten und 50 % Ausnutzung

Haha, mit echtem raid5
aus 6 disks: Schreibrate von 5 Platten und 83% Ausnutzung bzw.
aus 8 disks: Schreibrate von 7 Platten und 87% Ausnutzung
und nicht zu vergessen, daß bei ext4/xfs die Schreibperformance bis 100% nahezu im unmeßbaren Bereich liegt wärend sich bei zfs bei 80-90% voll die ganze Tragweite der Trägheit in's Unerträgliche breit macht, inwieweit die rechnerischen Auslastungsraten bei zfs nur theoretisch gelten, was aber meist wiederum durch Kompression ausgeglichen werden kann.
PS: Hatten mal 4x hw-raid6 a 44 hdd's an 2 HP dl380 gen7: machten jeweils Schreibrate von 42 Platten und 95% Ausnutzung ... - liefen super!

 

[TErxleben]

Vielen Dank Euch allen - Vor allem auch für die Erläuterungen, was die einzelnen Cache-SSDs für Vorteile haben (oder auch nicht )

Also RAM wird aufgerüstet, sobald er wieder bezahlbar ist - aber bei aktuell 3 bis 5 Euro pro GB für Gebrauchten macht es leider kein Sinn.
Wie sieht es mit Optane für special device aus? Die sind aktuell gebraucht preislich in Ordnung. Ok - man kann nicht sagen wieviel TB-Written da schon verbraucht sind - oder sollte man da lieber sicher gehen und neue SATA SSDs nehmen?

Zu den Festplatten: wie sieht es mit einem RAID 50 aus (also ein ein Stripe über zwei RAID-Z1) - dann hätte ich abgesehen von dem langsamen Resilver-Prozess die Vorteile von beiden?
z.B. bei 6 Platten
RAID50: Schreibrate von 2 Platten und 66% Ausnutzung
RAID10: Schreibrate von 3 Platten und 50 % Ausnutzung
z.B. bei 8 Platten
RAID50: Schreibrate von 2 Platten und 75% Ausnutzung
RAID10: Schreibrate von 4 Platten und 50 % Ausnutzung

Die Leserate müsste ungefähr bei beiden gleich sein, da ja von allen gleichzeitig gelesen werden kann.
Ausfallsicherheit ist bei RAID10 theoretisch auch höher, da bei jedem Mirror jeweils eine ausfallen kann.

Oder hab ich hier auch schon wieder ein Denkfehler?

Jede Redundanz bringt einen Overhead mit, egal ob beim Lesen oder Schreiben. Die Performance-Verluste sind nur hin- und herschiebbar. RAID ist in meinen Augen im 08/15-Betrieb eigentlich komplett raus. Schon (tm) damals wollte keiner auf das resilvern von gigantischen 4TB-Platten warten. Über 50TB-Einheiten möchte ich gar nicht erst nachdenken. Jedenfalls keinesfalls im Umfeld von 95% der Umgebungen. In großen Umgebungen weht natürlich ein ganz anderer Wind.

 

[waltar]

HW-raid mit cache rebuilded raid6 idR mit eh normal weitergehender workload mit "TB*1.6", also zB bei 18TB hdd ist rebuild in 29h durch, egal ob das raidset voll oder leer ist und ebenso egal ob da nun 4 oder 30 hdd im raid6 sind. Ebenso verwendet man im prod Betrieb immer hotspares, insofern man den rebuild idR auch nicht mitbekommt, außer der configurierten Mail, die autom. versendet wird, damit man die Defekte einfach online auch austauscht.

 

[UdoB]

aus 6 disks: Schreibrate von 5 Platten

Du meinst Leserate, oder?

Vielleicht auch sequentielles Schreiben großer Dateien.

Die (sync-) IOPS sind und bleiben (höchstens, "write penalty") die einer Platte. (Oder die des per Batterie gesicherten Caches, sofern vorhanden. Das hat dann aber rein gar nix mehr mit den Datenträgern zu tun.)

 

[TErxleben]

HW-raid mit cache rebuilded raid6 idR mit eh normal weitergehender workload mit "TB*1.6", also zB bei 18TB hdd ist rebuild in 29h durch, egal ob das raidset voll oder leer ist und ebenso egal ob da nun 4 oder 30 hdd im raid6 sind. Ebenso verwendet man im prod Betrieb immer hotspares, insofern man den rebuild idR auch nicht mitbekommt, außer der configurierten Mail, die autom. versendet wird, damit man die Defekte einfach online auch austauscht.

29h-rebuild bei 18TB Einheiten ist ja auch schon ein Wort. Egal ob Hotspare oder nicht. Ich kenne bis Heute kein RAID-System, welches ohne spürbare Leistungsverluste einen Plattenausfall mal eben wegbügelt.

 

[waltar]

Du meinst Leserate, oder?

Vielleicht auch sequentielles Schreiben großer Dateien.

Die (sync-) IOPS sind und bleiben (höchstens, "write penalty") die einer Platte. (Oder die des per Batterie gesicherten Caches, sofern vorhanden. Das hat dann aber rein gar nix mehr mit den Datenträgern zu tun.)

Das Textwort stammt nicht von mir, zudem betrifft es bei raid5/6 neben Schreib- auch der Leserate.
Die sync IOPS sind NICHT die einer Platte, weil wie in diesem man ja vom Storage viler VM's/LXC's redet und diese wegen der eben parallel laufenden Maschinen jene auch parallel I/O machen und deswegen auch parallel am Storage ankommen und dort auch parallel verarbeitet werden, weil sie eben auch die verschiedenen Images bearbeiten - ist real halt doch noch was anderes, als wenn man nur von 1 VM benchmarked.

 

[waltar]

Ich kenne bis Heute kein RAID-System, welches ohne spürbare Leistungsverluste einen Plattenausfall mal eben wegbügelt.

Ein raid system muß man immer tunen und nicht default betreiben !
Habe auch mal bei einem Fileserver raid6 rebuild und hinterher ein multijob Benchmark mit 100% device load (iostat) gemacht, 12-15% Leistungsverlust lokal auf Fileserver, das merkt kein AW an irgendeinem nfs bzw. smb client. Keine Ahnung was du für Controller benutzt und wie du die wie auch das FS configurierst, daß du noch normale Workload Auf und Ab's von laufender Rebuild Belastung auf Clientseite unterscheiden kannst.

 

[UdoB]

Die sync IOPS sind NICHT die einer Platte

Okay. Ich sehe da durchaus Fragezeichen, will das hier aber eigentlich nicht vertiefen...

 

[TErxleben]

Ein raid system muß man immer tunen und nicht default betreiben !
Habe auch mal bei einem Fileserver raid6 rebuild und hinterher ein multijob Benchmark mit 100% device load (iostat) gemacht, 12-15% Leistungsverlust lokal auf Fileserver, das merkt kein AW an irgendeinem nfs bzw. smb client. Keine Ahnung was du für Controller benutzt und wie du die wie auch das FS configurierst, daß du noch normale Workload Auf und Ab's von laufender Rebuild Belastung auf Clientseite unterscheiden kannst.

Ich bin gespannt, wie ich ein Raid wieder in einen normalen Betriebszustand zurückführen kann, ohne 2 Tage eingeschränkte Leistung.. Da freut mich jeder Tuning-Tipp.

 

[Bu66as]

Verschleiß bei gebrauchten Optane kannst du auslesen, nvme smart-log /dev/nvme0 zeigt dir Percentage Used und Data Units Written. Bei den Dingern steht das fast immer noch bei 0-1%, die Endurance ist so hoch dass du sie als Special Device praktisch nicht totschreibst. Und fürs SD sind sie ohnehin das Beste was du kriegen kannst, kleine random Metadaten-Writes bei QD1 sind genau ihre Stärke, da können normale SATA-SSDs nicht mithalten.

Worauf ich mehr achten würde ist die Kapazität. Bei deiner Datenmenge wird das SD schnell größer als die üblichen 0,3%-Faustregeln vermuten lassen, der PBS legt ja Millionen winziger Chunk-Dateien an und das sind alles Metadaten. Die 16/32GB-M10-Optane kannst du direkt vergessen, und bei zig TB Pool würde ich auch bei 100GB nicht ruhig schlafen. Lieber eine Nummer größer, denn wenn das SD volläuft wandern die neuen Metadaten wieder auf die HDDs und du merkst das erst daran, dass die GC plötzlich wieder kriecht. Nachträglich vergrößern geht nur über Platten tauschen und resilvern.

 

[waltar]

Ich bin gespannt, wie ich ein Raid wieder in einen normalen Betriebszustand zurückführen kann, ohne 2 Tage eingeschränkte Leistung.. Da freut mich jeder Tuning-Tipp.

zB ein DDN sfa raid scrub'ed 365x24h jedes raidset alle parallel, beim rebuild pause'd der scrub - da merkst und mißt du nix.
Ist EC raid mit modis 1+1, 4+1, 8+1, 4+2 oder 8+2, jedes raidset glaube 8GB groß, stripesize ändert glaube ich die Größe nicht oder doch, weiß nicht, jedenfalls hat man dann Milionen raidsets die ein Volume definieren mit Größe der Anzahl der disks dafür. Ist so'n bißchen wie ein draid, hat jedoch virtuelle dedicated und reale globale hotspare disks (ww. auch unassigned spares). Erfolgt also immer erst fast rebuild auf spare capacity (alle raidset disks schreiben auf alle verbliebenen disks des Volumes) und danach auf spare disk, damit die spare capacity wieder frei wird.