Systemkonsolidierung und suche nach Erfahrungen/Denkanstößen

[Cluster_]

Hallo,

Ich hab das kommende auch im TrueNAS Forum gepostet, möchte hier aber auch etwas nachgraben

momentan habe ich zwei Systeme (1xProduktiv - ESXi + div. VMs) + Backupsystem (TrueNAS Bare-Metall)
Das Backup werde ich jetzt off-site auslagern und möchte die beiden bisherigen, etwas in die Jahre gekommenen Systeme konsolidieren.
Die Festplatten werde ich in das neue System überführen und würde hier vorab schonmal nach Euren Erfahrungen bzgl. Geschwindigkeit etc. fragen. Eine 100 % Entscheidung habe ich nämlich noch nicht getroffen bzgl. der finalen Hardware.

Bestand:
4 x 8 TB WD Gold SATA an HP P420 RAID 6 (Backup)
4 x 4 TB WD RE SAS an HP P420 RAID 1+0 (Produktiv)
4 x 256 GB M.2 SATA (auf 4x M2 -> SFF-8643 PCB) an HP P420 RAID 6 (Backup)
4 x 512 GB M.2 SATA (auf 4x M2 -> SFF-8643 PCB) an HP P420 RAID 1+0 (Produktiv)

Das neue System wird wohl ein Xeon Platinum 8160 mit 6x32 GB RAM.
Der HBA wird wohl ein 9400-16i. Das Gehäuse liefert mir 2x4 Hot-Plug SAS Backplanes an SFF-8643
Ich hatte geplant nebst diesem HBA noch zwei ASUS M.2 PCIe NVME Karten einzubauen. (4x1TB (oder 2TB) als Zusatzspeicher + 4x256GB als ZFS Caching Lösung)
Der Host selber wird wieder über ESXi virtualisiert und der Storage soll über HBA Passthrough durch ein TrueNAS über iSCSI (oder NFS4) per vSwitch durchgereicht werden. Die TrueNAS VM würde von mir dann wahrscheinlich sowas um 64 GB RAM zugeteilt bekommen.

Das Speicherlayout macht mir jedoch noch Gedanken. (Die vier 4TB könnte ich noch gegen 4x8TB WD Gold tauschen)
- Raidz2 über alle 8 Platten
- 2xRaidz2 im Strip
- 2xRaid 10 im Strip
- 2xRaid 10 im Mirror
- etc.....

Mir stellt sich die Frage, welche Konfiguration ist am sinnvollsten bzgl. Ausfallsicherheit / zur Verfügung stehender Speicher / Geschwidigkeit.
Auch beim Caching bin ich mir nicht sicher, ob jetzt 256 GB NVMe nicht doch etwas über das Ziel hinausgeschossen ist (selbst mit OP).
Die M.2 SATA SSD weiß ich auch noch nicht so richtig unterzubringen. (Oder ob überhaupt)

Hat jemand hier ein paar Denkanstöße für mich. Möglicherweise sogar bereits Erfahrungen die Sie/Er hier teilen möchte?

Gruß & Dank im Voraus
Thomas

 

[Digi-Quick]

ZFS und SSD Caching geht nicht nativ!

r/freenas - "Tiered" Storage Capabilities? (I know ZFS doesn't natively do it)

21 votes and 16 comments so far on Reddit

www.reddit.com

Implementing tiered storage with ZFS and autotier

An uncommon — but not unheard of — use case calls for fast data ingestion, combined with relatively slow yet very big and economical data retrieval. Here is a plan to achieve that.

rudd-o.com

L2ARC ist ggü. RAM langsamer.
SLOG ist kein Schreibcache in dem üblichen Sinne.

 

[Trambahner]

- Wie alt sind die HDD, speziell die 4TB RE SAS? Die dürften schon einige Jahre am Buckel haben .
Hoffe, da sollen keine System-vDisks mehr auf den HDD-Pool. VMs gehören heutzutage IMO nur noch auf SSD-Pools.

> HDDs als 1 Raidz2-Pool für Daten, auf die langsamer Zugriff reicht und als Cold-Storage.
> SSD-Pool für VMs und Daten, die schnell zugreifbar sein sollen.

Bei den SSDs würde ich auch nicht mehr mit diesen vielen Klein-SSDs agieren, sondern dann einfach einen Mirror über zwei Datecenter NVME-SSDs (Auswahl/Spec gemäß benötigter Anforderung).

Damit braucht man eigentlich nur noch über Slog nachdenken, wenn Sync-Writes auf dem HDD-Pool notwendig wären.

Bzgl. iSCSI oder NFS: ich nutze NFSv3 (brauche hier keine Rechteverwaltung).

 

[Cluster_]

Hallo, die REs sind schon was älter - Leisten aber noch guten Dienst. Anders als die WD Gold - Hier habe ich momentan eine Platte die SMART in Ordnung ist, jedoch im Verbund mit den anderen drei Platten den Controller zum Absturz bringt - HBA habe ich bereits getauscht, Kabel auch und den Steckplatz an der Backplane. DAS treibt mich momentan wirklich in den Wahnsinn, auch weil dieses Problem ohne Vorwarnung aufgetreten ist. Für mich sieht es so aus, als ob der HDD Controller selber defekt ist - Allerdings NUR im Betrieb mit den anderen HDDs oO Sowas habe ich noch nie erlebt.

Aber: Spricht etwas dagegen einen "Raid 101" zu erstellen? Sprich mirrored Raid 10 ? Das sollte mir die Ausfallsicherheit eines Raid 6 geben mit dem (nahezu) Geschwindigkeitsvorteil von Raid 10 - Die zur Verfügung stehende Nettokapazität mal außen vor gelassen

Die kleinen SSDs hatte ich Ursprünglich mal als Cache angedacht - würden aber wahrscheinlich zu wenig Geschwindigkeit liefern. Diese werde ich wahrscheinlich mit den alten Geräten versuchen weiterzubringen.

Als Cache würde ich dann einen der ASUS M.2 PCIe Adapter nehmen und einen weiteren Adapter als NVMe Speicher im RAID 10.
-Oder Cache NVMe über SFF-8643 an den zwei noch zur Verfügung stehenden HBA Anschlüssen und die beiden ASUS M.2 Adapter ähnlich wie obige Idee als mirrored RAID10.

Gruß
Thomas

 

[Supaman]

Ich würde möglichst große Platten (16-20 TB) verwenden, und die als Raid-1 laufen lassen, wenn da mal was klemmt, kommst Du immer an die Daten. Die großen HDDs haben einen Durchsatz von 200-300 mb/sec. Wenn das an Speed nicht reicht, nehme SSDs oder m2 NVMe @PCIe Steckkarte.

 

[Digi-Quick]

Aber: Spricht etwas dagegen einen "Raid 101" zu erstellen? Sprich mirrored Raid 10 ? Das sollte mir die Ausfallsicherheit eines Raid 6 geben mit dem (nahezu) Geschwindigkeitsvorteil von Raid 10 - Die zur Verfügung stehende Nettokapazität mal außen vor gelassen

NEIN!!!!
Raid6 = es dürfen 2 beliebige HDDs ausfallen
Raid10 = es darf eine beliebige HDD ausfallen, Es darf aber je Mirror eine HDD ausfallen. Fällt die 2 HDD eines degradeten Mirrors aus, ist das Raid10 zerstört, es sei denn man betreibt ein Raid10 mir 3Way-Mirror, also 3 HDDs pro Spiegelset, dann hättest du den Redundanzlevel von Raid 6!

Die Wahrscheinlichkeit, daß dir während des Rebuilds die 2. HDD des degradeten Mirrors ausfällt dürfte deutlich höher sein, als das in der Zeit eine der HDDs des intakten Spiegels ausfällt - die sind nämlich am Rebuild nicht beteiligt!

 

[Cluster_]

Hallo,

eigentlich sollten in dieser Konstellation sogar 3 Platten gleichzeitig ausfallen dürfen.

Gruß
Thomas

 

[Digi-Quick]

Hallo,

eigentlich sollten in dieser Konstellation sogar 3 Platten gleichzeitig ausfallen dürfen.

Anhang anzeigen 763583

Gruß
Thomas

Welcher Raid Controller würde die Konfi unterstützen? (Bei Software Raids, z.B. unter Linux oder BSD durchaus vorstellbar)
Das wäre ja ein "Raid 101"
- 8 Platten
- 4 Spiegel
- Jeweils 2 Spiegel gestriped
- die beiden Stripes wiederum gespiegelt

P.S. ich hatte das "Raid101" als Schreibfehler angesehen.

 

[Cluster_]

Welcher Raid Controller würde die Konfi unterstützen? (Bei Software Raids, z.B. unter Linux oder BSD durchaus vorstellbar)

Genau um die Softwarevariante auf Basis ZFS (Entweder TrueNAS oder direkt Solaris oder Nexenta) würde es gehen.

Würde mich interessieren ob das schon mal jemand ins Auge gefasst, oder sogar ausprobiert hat.

Gruß
Thomas

 

[asche77]

1. Ich würde "oben" stripen (0) und auf der mittleren Ebene nochmal mirrorn (1)
2. Nicht sicher, ob ZFS derart geschachtelte zpools ohne weiteres unterstützt. Mit einem zpool aus Dateien auf anderen zpools müsste es grds gehen ...
3. Daher vielleicht doch lieber einfacher ein RAID 10 mit 3-way mirrors?

 

[Digi-Quick]

Vor allem widerspricht ein derartiges Konstrukt dem KISS-Prinzip (Keep It stupid Simple)!

 

[gea]

Die Frage wäre, warum man das machen sollte.

Die 8 Platten hätten als Array nur die Nutz Kapazität von 2 Platten. Es dürfen zwar viele Platten ausfallen und die Leseperformance wäre exzellent. Die Schreibperformance aber nur wie von 2 Platten. Dafür wäre das Konstrukt unglaublich kompliziert.

Im Vergleich wäre ein ZFS aus 2 x Z2 ähnlich sicher und schnell beim schreiben aber viel übersichtlicher. Raid 10 aus 6 Platten und Dreifachmirror wäre ähnlich von der Leistung und Sicherheit aber ebenfalls viel übersichtlicher. Mal davon abgesehen ginge das mit ZFS garnicht ohne darunter andere Raids zu setzen (Linux Software Raid oder Hardwareraid oder ganz exotisch ZFS Pools via iSCSI targets). Damit ginge aber nicht nur die Übersichtlichkeit komplett verloren, auch die Datensicherheit würde leiden da man dann eventuell kein sicheres ZFS CoW mehr hätte bzw keine Daten/Metadaten Prüfsummen auf den entsprechenden Sub Mirrors.

 

[besterino]

Joah, mit 8 Platten nur die Kapazität von 2 rauszuholen ist irgendwie schon sehr sportlich: Das käme ja einem ZFS-Pool mit 2x 4-way-mirror-vdevs gleich... (immerhin können da bis zu 6 Platten und im worst case 3 ohne Datenverlust ausfallen).

Da ZFS oberster (logischer) Stelle - also auf Pool-Ebene - immer von Haus aus quasi einen "Raid 0"-Ansatz fährt, kann man halt nur noch überlegen, was man "darunter" macht. Da irgendwie mit Partitionen zu tricksen macht wohl eher selten wirklich Sinn.

 

[Trambahner]

Ob man Gefrickel im Störungsfall haben will > mehhhhhh,, eher nicht. Schliesslich soll da Ausfallsicherheit da sein und entsprechend möglichst gute uptime. Da sind komplexe Setups eher hinderlich.
Und gehts um kritische Dinge, dann arbeitet man eh mit Failover-Rechnern.

Insofern "hingefrickeltes Raid 101" > meeehh.

 

[Cluster_]

Hallo,

danke für die ehrlichen Antworten. Verstehe ich das so richtig, dass ein Pool aus zwei Raid 0 automatisch ein Raid 00 werden würde?

Mir stellt sich mit der mir zur Verfügung stehenden HW von 8 x 8 TB Spindel dann die Frage was sinnvoller wäre Strip über 4xMirror, oder Strip über 3xMirror + 2 Spare.
Den Rebuild und die damit verbundene Gefahr eines weiteren HDD Schadens habe ich ja bei beiden Varianten.
Ich würde halt gerne die Sicherheit eines Raid 6 (min.) haben aber gleichzeitig so wenig Performance penalty wie möglich.
Daher hatte ich auch das SLOG ins Auge gefasst um zumindest Netzwerkseitig einen Sync zu haben ohne das die Daten bereits auf den Spindeln liegen. Hier stellt sich mir dann zwanghaft die Frage ob ein SLOG sinnvoller wäre als einfach mehr RAM in das System zu konfigurieren und dem ZFS verwaltendem System statt z.B. 64 GB einfach 128 GB RAM zur Verfügung zu stellen.

Ich komme mittlerweile nämlich recht ins Straucheln beim Rechnen bzgl. 5 sec SLOG Buffer von RAM als Kopie in SLOG FALLS mal ein Stromausfall auftreten würde, nur damit ich vorab schonmal einen Sync an das System liefern kann. Das wären ja auch nur knapp (im Idealfall bei PCIe 3 x4 NVMe) knapp 16 GByte (-20 % Controll overhead am BUS). Ganz abgesehen von der zu erreichenden Geschwindigkeit des SLOG Device selber. Wenn ich mir z.B. das Datenblatt der Kingston 240 GB DC PLP NVMe ansehe mit 280 MB/s kommt mir das sehr wenig vor.
Wird die I/O eingestellt bei SLOG wenn 5 Sekunden "voll" sind, oder erst wenn der SLOG "Buffer" oder RAM "voll" ist?
Da ich den Datenspeicher an ESXi über NFS bereitstellen will wird ja sync standardmäßig beim mount verwendet. Da ich das System per vSwitch verbinden werde bin ich hier auch "nur" durch die interne Bus-Geschwindigkeit beschränkt.

Oder wäre es nicht für den "Vorab Sync" sinnvoller aus den zusätzliche 64 GB RAM ein fuse partition zu erstellen und diese als SLOG zu verwenden (USV ist vorhanden)

Gruß & Dank
Thomas

 

[gea]

Hallo,

danke für die ehrlichen Antworten. Verstehe ich das so richtig, dass ein Pool aus zwei Raid 0 automatisch ein Raid 00 werden würde?

Ein ZFS Pool besteht zunächst aus einem oder mehreren so genannten "vdevs". Das kann eine einzelne Platte sein (basic), ein n-way Mirror oder ein Raid Z1-3. Alle vdevs werden wie ein Raid-0 gestript. Damit ist der Pool verloren, wenn ein vdev ausfällt. Jedes vdev braucht also gute Redundanz.

Dazu gibt es besondere vdevs wie L2Arc (Lesecache), Slog (Sicherung RAM-Schreibcache) oder special vdev um kleine io, dedup Daten oder einzelne Dateisysteme darauf zu zwingen.

Mir stellt sich mit der mir zur Verfügung stehenden HW von 8 x 8 TB Spindel dann die Frage was sinnvoller wäre Strip über 4xMirror, oder Strip über 3xMirror + 2 Spare.

Viele Wege führen nach Rom. Kommt immer darauf an wieviel (beliebige) Platten ohne Datenverlust ausfallen dürfen und wie man Performance vs Kapazität vs Sicherheit optimieren möchte. Bei diesen drei kann man zwei Parameter festlegen. Der dritte ist dann die Folge.

Den Rebuild und die damit verbundene Gefahr eines weiteren HDD Schadens habe ich ja bei beiden Varianten.
Ich würde halt gerne die Sicherheit eines Raid 6 (min.) haben aber gleichzeitig so wenig Performance penalty wie möglich.

Wasch mir den Pelz aber mach mich nicht nass...
Zwei beliebige Platten dürfen bei 3way Mirror und Z2 vdevs ausfallen

Daher hatte ich auch das SLOG ins Auge gefasst um zumindest Netzwerkseitig einen Sync zu haben ohne das die Daten bereits auf den Spindeln liegen. Hier stellt sich mir dann zwanghaft die Frage ob ein SLOG sinnvoller wäre als einfach mehr RAM in das System zu konfigurieren und dem ZFS verwaltendem System statt z.B. 64 GB einfach 128 GB RAM zur Verfügung zu stellen.

ZFS funktioniert so nicht. Mit aktiviertem sync wird jeder bestätigte Schreibvorgang auf den Pool oder wenn vorhanden ein Slog geschrieben und ZUSÄTZLICH im RAM Schreibcache gesammelt und nochmal geschrieben.

Mehr RAM sorgt für mehr Performance. Um die Absicherung des RAM Schreibcaches muss man sich unabhängig davon kümmern

Ich komme mittlerweile nämlich recht ins Straucheln beim Rechnen bzgl. 5 sec SLOG Buffer von RAM als Kopie in SLOG FALLS mal ein Stromausfall auftreten würde, nur damit ich vorab schonmal einen Sync an das System liefern kann. Das wären ja auch nur knapp (im Idealfall bei PCIe 3 x4 NVMe) knapp 16 GByte (-20 % Controll overhead am BUS). Ganz abgesehen von der zu erreichenden Geschwindigkeit des SLOG Device selber. Wenn ich mir z.B. das Datenblatt der Kingston 240 GB DC PLP NVMe ansehe mit 280 MB/s kommt mir das sehr wenig vor.
Wird die I/O eingestellt bei SLOG wenn 5 Sekunden "voll" sind, oder erst wenn der SLOG "Buffer" oder RAM "voll" ist?

5s Puffer gilt nur für Original ZFS und Oracle Solaris. Open-ZFS (BSD, Illumos, OSX, Linux, Windows) nutzen per default 10% RAM, max 4GB als Schreibcache. Ist der Puffer halb voll, wird er auf Platte geschrieben um Platz für weiteres Puffern zu haben.

Da ich den Datenspeicher an ESXi über NFS bereitstellen will wird ja sync standardmäßig beim mount verwendet. Da ich das System per vSwitch verbinden werde bin ich hier auch "nur" durch die interne Bus-Geschwindigkeit beschränkt.

Oder wäre es nicht für den "Vorab Sync" sinnvoller aus den zusätzliche 64 GB RAM ein fuse partition zu erstellen und diese als SLOG zu verwenden (USV ist vorhanden)

Macht keinen Sinn und ZFS arbeitet nicht so.
Dann eher sync deaktivieren (kein doppeltes Schreiben daher schneller, RAM Schreib-Cache nicht sicher, bei Crash ist ein VM Dateisystem gefährdet)

Gruß & Dank
Thomas

 

[Cluster_]

Hallo,

ok vieles geklärt - Danke
Bzgl. Fuse - Wieso arbeitet ZFS nicht so? Wenn sync=always sollte doch der RAM langsam "volllaufen" bis die HDDs den Sync approven. Wenn ich jetzt rel. langsame
Platten einem NVMe gegenüberstelle sollte doch der NVMe sync sehr viel schneller durchschlagen als der HDD sync - Oder habe ich hier einen Knoten im Kopf?

Noch eine Frage am Rande: Ich habe momentan auf einem Testsystem ein paar performance tests laufen lassen bzgl. Netzwerkgeschwindigkeit (hier allerdings nur bei physical 1 GBit).
pool async / nfs ohne option = klar, 1 GBit , also knapp 120 MB/s
pool async / nfs option sync = 75 MB/s
pool sync=always / nfs ohne option = knapp 50 MB/s
pool sync=always / nfs option sync = knapp 1-2 MB/s

Wie kommen vor allem die Unterschiede in der Übertragungsgeschwindigkeit bei letzteren beiden zu Stande? Sync sollte doch sync bleiben?

Danke
Gruß
Thomas

 

[pumuckel]

.... mir sagte mal ein Mann (Allan Jude - https://www.bsdnow.tv/ ) vor vielen Jahren, ich sollte bei ZFS immer 2 Platten im Mirror als vdev nehmen.... daran hab ich mich bisher gehalten.. Lüppt (obs ideal ist darf der Profi beurteilen, ich wende nur an)

 

[gea]

Hallo,

ok vieles geklärt - Danke
Bzgl. Fuse - Wieso arbeitet ZFS nicht so? Wenn sync=always sollte doch der RAM langsam "volllaufen" bis die HDDs den Sync approven. Wenn ich jetzt rel. langsame Platten einem NVMe gegenüberstelle sollte doch der NVMe sync sehr viel schneller durchschlagen als der HDD sync - Oder habe ich hier einen Knoten im Kopf?

- Fuse gibts nicht mehr. ZFS wird auf allen Plattforman direkt unterstützt
- ZFS sync arbeitet so: Wenn ein schreibendes Programm einen Datenblock (ZFS recsize, z.B. 128k) sync auf Platte schreiben möchte, so wird der sofort in einen schnellen Bereich des Pools (ZIL) protokolliert. Das ist dennoch ziemlich langsam bei Platten. Dieser Datenblock wird nur nach einem Crash beim nächsten Reboot gelesen und dann verzögert auf den Pool geschrieben. Slog ist daher kein Schreibcache. Wenn man ein spezielles schnelleres Slog bereitstellt, erfolgt die Protokollierung da. Unabhängig davon wird wie bei normalem async write der Datenblock im rambasierten Schreibcache gesammelt und verzögert als großes, schnelleres sequentielles Write z.B. 2M geschrieben. Diese 2M wären bei einem Crash ohne sync verloren.

Noch eine Frage am Rande: Ich habe momentan auf einem Testsystem ein paar performance tests laufen lassen bzgl. Netzwerkgeschwindigkeit (hier allerdings nur bei physical 1 GBit).
pool async / nfs ohne option = klar, 1 GBit , also knapp 120 MB/s
pool async / nfs option sync = 75 MB/s
pool sync=always / nfs ohne option = knapp 50 MB/s
pool sync=always / nfs option sync = knapp 1-2 MB/s

Wie kommen vor allem die Unterschiede in der Übertragungsgeschwindigkeit bei letzteren beiden zu Stande? Sync sollte doch sync bleiben?

Danke
Gruß
Thomas

Sync arbeitet nicht Poolweise sondern per Dateisystem wobei "Pool" selber das Parent ZFS Dateisystem ist, dessen Eigenschaften teilweise vererbt werden können. Ich vermute mal dass das hier das Problem erklärt.

Zu sync:
Ich habe mal ein paar Benchmarks mit verschiedenen Optionen gemacht,

https://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf

 

[Cluster_]

- ZFS sync arbeitet so: Wenn ein schreibendes Programm einen Datenblock (ZFS recsize, z.B. 128k) sync auf Platte schreiben möchte, so wird der sofort in einen schnellen Bereich des Pools (ZIL) protokolliert. Das ist dennoch ziemlich langsam bei Platten. Dieser Datenblock wird nur nach einem Crash beim nächsten Reboot gelesen und dann verzögert auf den Pool geschrieben. Slog ist daher kein Schreibcache. Wenn man ein spezielles schnelleres Slog bereitstellt, erfolgt die Protokollierung da. Unabhängig davon wird wie bei normalem async write der Datenblock im rambasierten Schreibcache gesammelt und verzögert als großes, schnelleres sequentielles Write z.B. 2M geschrieben. Diese 2M wären bei einem Crash ohne sync verloren.

Vielen Dank für die ausführliche Erklärung . Genau diese Zusammenhänge hatte ich so nicht auf dem Schirm - Spitze!

 

[gea]

.... mir sagte mal ein Mann (Allan Jude - https://www.bsdnow.tv/ ) vor vielen Jahren, ich sollte bei ZFS immer 2 Platten im Mirror als vdev nehmen.... daran hab ich mich bisher gehalten.. Lüppt (obs ideal ist darf der Profi beurteilen, ich wende nur an)

Mirror ist die schnellste Option insbesondere was iops und Leseperformance angeht. Mit Festplatten war es daher immer eine besonders schnelle und flexible Option auch was Pool-Erweiterungen angeht.

Heute würde man jedoch SSD/NVMe nehmen wenn man Performance braucht und Plattenpools nur noch wenn es um günstige Kapazität geht. ZFS bietet für jeden Anwendungsfall eine optimale Lösung zwischen Performance, Kapazität, Sicherheit und Preis. Mit RAM, L2Arc, Slog und special vdev gibt es darüberhinaus zusätzliche Optimierungsansätze.

Nur als Anhaltspunkt.
Ein Raid-10 aus 4 Festplatten hat vielleicht lesend 400 iops und bis 600 MB/s und schreibend die Hälfte. Eine einzelne NVMe hat eventuell 500000 iops und 3000 MB/s sequentiell. Ein Raid-Zn aus SSD/NVMe ist damit jedem Plattenpool aus egal wieviel Mirrors um Größenordnungen überlegen - sofern man nicht ganz billige Desktop SSD vergleicht.