Sinnvolle Nutzung meiner vorhandenen SSDs und HDDs für Home-NAS

[zumselziege]

Hallo zusammen,

Ich bin gerade dabei, mir ein neues NAS zu bauen. Wichtig sind mir dabei vor allem: hohe Schreibgeschwindigkeit und Sicherheit gegen ausfall von HDDs

Folgende Hardware steht zur Verfügung:

Supermicro X11SSL-F Board
Intel Xeon E3-1220 v5
16GB DDR4 ECC 2400

1x 4TB WD40EZRZ (gebraucht)
3x 4TB WD4000FYYZ (gebraucht)
Ich möchte dazu noch eine neue Seagate Ironwolf 4TB kaufen

SSDs:
4x 120GB WD Green SSD
Alte Samsung 64GB SSD
Alte Samsung 128GB SSD

Die 5x4TB möchte ich für ein RAIDZ-2 mit ZFS nutzen
Wie sollte ich die übrigen SSDs am besten Nutzen?

Ich möchte das OS gern auf SSDs haben und zusätzlich einen Schreib-Cache für das RAIDZ-2 mit SSDs einrichten.

Ich habe noch folgenden RAID-Controller (leider nur ohne Akku): 700-3405-20 Amcc 3Ware 4-Port SATA PCIe Raid Controller
-> den für die OS-Disks nehmen? Funktioniert damit überhaupt ein RAID-6 ohne Akku?) (Wozu brauchen die RAID-Controller überhaupt den Akku)

Oder lieber jeweils ein RAIDZ-1?
Wie sollte ich die SSDs am besten auf die RAIDs verteilen?

Ich bin mir noch nicht 100% sicher, welches OS ich verwenden möchten.
Da ich vielleicht auch Mal 1-2 VMs auf dem Server betreiben möchte, dachte ich an Proxmox, vielleicht sogar daran, das NAS damit zu virtualisieren (FreeNAS?), damit ich es später Mal leichter auf einen anderen Server umziehen kann.

Wie würde ihr die Platten verwenden?

 

[gea]

nur ein paar Gedanken

Mit dem System kann man prima einen kleinen ZFS Filer aufbauen. Die 5 Platten an Sata + die SSD die am wenigsten verbraucht ist als Bootlaufwerk. Den schnellsten ZFS Filer hat man mit Solaris und Original ZFS. Besonders gut ist die ZFS Integration in den Solaris Forks wie OmniOS. Da gibts neben Linux auch die neuesten ZFS Features seit über einem Jahr. Unter Free-BSD erscheinen neue Features wie Verschlüssellung, special vdevs aber auch gerade.

Für die anderen SSD sehe ich eigentlich keine Nutzung. Schreib- und Lesecache ist bei ZFS auschließlich RAM. Man könnte zwar den RAM Lesecache durch eine SSD ergänzen, mit 16 GB RAM sehe ich aber wenig nutzen. Dann eher noch etwas mehr RAM einbauen (=mehr Cache=schneller, man hat dann auch mehr Luft zum Virtualisieren)

Raid Controller brauchen einen Akku damit das Dateisystem oder das Raid bei einem Stromausfall beim Schreiben nicht kaputt geht, z.B. wenn es ein Raid Stripe für 6 Platten bereits auf 4 Platten geschafft hat und dann der Strom ausfällt. Softwareraid wie ZFS umgehen das Problem mit CopyonWrite, sync write und einem Schreibprotokoll auf einem ZIL/Slog.

Will man virtualisieren, sollte das Basissystem möglichst resourcenschonend sein. Für den Virtualisierer ist ESXi unerreicht resourcenschonend. Virtualisieren auf dem NAS sollte man vermeiden, geht aber z.B. mit LX Zonen und Bhyve auf Free-BSD und OmniOS oder mit Proxmox. Da sollte man aber mehr RAM vorsehen. (ESXi 2GB, ein 64bit OS wie Free-BSD, Linux oder Solaris auch mind 2-4 GB, eine Appliance wie Free-NAS mind. 8 GB, Windows 4GB)

Der Raid Controller taugt nicht für ZFS, daher alles an Sata anschließen. Reichen die 6 Ports nicht, dann einen LSI HBA mit 2008, 2308 oder 3008 Chipsatz kaufen (gebraucht ab ca 50 Euro). Will man Performance, dann NVMe z.B. für VMs benutzen (PCI-e Karten).

 

[zumselziege]

Moin,

für das OS dachte ich dann vielleicht doch eher an Hardware RAID mit den 4x120 GB SSDs

Das Problem ist, dass ich mit ZFS keine Erfahrung habe. Ich habe keinen blassen Schimmer, wie man bei Betriebssysteminstallation die OS-Disks als RAID-Z konfiguriert bzw. auch wie man das repariert wenn wirklich eine der SSDs abraucht.

VM Performance ist mir nicht so wichtig. Stabilität ist auf jeden Fall wichtiger

 

[gea]

Als Bootdisk nimmt man eine einfache Platte. Bei kommerziellen Einsatz kann man einen Mirror überlegen damit man keine Ausfallzeit hat wenn die ausfällt. Raid-Z für die Bootdisk (sollte 30-100 GB haben) ist schlicht nicht sinnvoll und macht in der Tat alles nur kompliziert. Bootlaufwerk und Datenpool sollte man eh trennen.

Wenn man sich an die Regel hält, dass ein Virtualisierer und das Storage keine Komplexität haben soll, dann ist ein Raid auf dem Bootlaufwerk auch überflüssig. Gute SSD fallen sehr selten aus. Ist darauf ESXi gespeichert, so bedeutet Disaster Recovery einfach ESXi neu aufspielen und die VMs importieren.

Fällt das Storage OS aus, dann einfach neu installieren und den Datenpool importieren. Schlimmstenfalls muss man die User neu anlegen damit die Rechte wieder stimmen. Mehr macht man nicht auf Storage wenn das einfach laufen und nicht ständig zicken soll.

Nur bei sehr komplexen Installationen muss man sich Gedanken über Disaster Recovery machen. Bei Solarish kann man dazu einfach die aktuelle Bootumgebung im laufenden Betrieb auf den Datenpool replizieren. Das kann man automatisiert täglich laufen lassen. Disaster Recovery bedeutet dann ein Minimal-OS neu installieren, die Bootumgebung wiederherstellen und in diese booten.

 

[Trambahner]

@TE:
Ich seh das etwas skeptischer.
Wie alt sind die Platten? Über 5 Jahre > weiß ich nicht, ob das eine gute Idee ist die in einem NAS einzusetzen. Da Platten für ein gewisses Alter entwickelt sind, werden sie oft im Alter unzuverlässiger und fehlerträchtiger.
Die WD Greens ist eine ganz schlechte Idee; das sind Einfachst-SSD ohne Dram-Cache und nur 2 Kanälen für die Flashspeicher. Die werden nicht viel reissen und dürften in einem Raidpool noch schlechter performen. Nochdazu fällt in Hardwareraids oft "Trim" aus und der Controller des AMCC ist recht betagt und nicht gerade schnell.

Kurzum, für ein neues Nas, was jahrelang sicher und performant laufen soll, sehe ich die Hardware meiner Meinung nach, sagen wir mal diplomatisch, suboptimal.

Btw, für ZFS gibt es keinen "Schreibcache" auf SSD. Dafür dient ausschliesslich das Ram. Du kannst bei bestimmten ZFS-Versionen eine SSD als sog. "special Device" anfügen für die Metadaten und kleinen Datenblöcke.

 

[tolga9009]

Dein Board hat 6x SATA - auch noch die guten direkt vom Intel Chipsatz. Nimm die 5 HDDs im RAID-Z2 und 1 SSD als Boot und spar dir die HBA. Wenn du willst, spiegelst du die SSD regelmäßig auf eine externe SSD und kannst im Ernstfall einfach die SSDs austauschen, mit sehr kurzen Ausfallzeiten.

Und: welche "alten" Samsung SSDs hast du? Alles ab 830 aufwärts geht klar.

 

[oNyX`]

Ich wuerde bei 4 HDDs auch kein raid z2 fahren, lieber striped mirror, mehr iops, mehr readspeed, weniger cpu overhead. Bei 4 HDDs RaidZ1 oder Mirror.

ZFS Raidz Performance, Capacity and Integrity Comparison @ Calomel.org

 

[zumselziege]

Dein Board hat 6x SATA - auch noch die guten direkt vom Intel Chipsatz. Nimm die 5 HDDs im RAID-Z2 und 1 SSD als Boot und spar dir die HBA. Wenn du willst, spiegelst du die SSD regelmäßig auf eine externe SSD und kannst im Ernstfall einfach die SSDs austauschen, mit sehr kurzen Ausfallzeiten.

Und: welche "alten" Samsung SSDs hast du? Alles ab 830 aufwärts geht klar.

Ich möchte eigentlich dass das System sich selbst repariert.
In meiner naiven Vorstellung: 1 SSD Kaputt, eine neue rein, RAID-Controller baut RAID selbstständig neu, ohne dass ich regelmäßig die Disk clonen muss

 

[tolga9009]

Dann nimmst du wie @oNyX` vorgeschlagen hat 4x 4TB im RAIDZ1 (ebenfalls 12TB nutzbarer Speicher, wie bei 5x 4TB RAIDZ2) und 2x SSD im Mirror.

 

[Gen8 Runner]

Nur zur Klarstellung:
1. Der RAID-Controller MUSS im IT-Mode arbeiten und auch geflasht sein (!!!!!!!!!!!!!!!!). BLOß NICHT IM URSPRÜNGLICHEN Zustand laufen lassen, kein RAID im Controller-Menü konfigurieren. NADA. Der reicht prinzipiell nur stupide die Festplatten oder SSD an dein ZFS OS durch, welches den Rebuild übernehmen würde. Quais RAID auf Softwarebasis. Der RAID Controller an sich baut hier NICHTS neu auf.
2. Bei einer fehlerhaften Festplatte muss natürlich wenigstens händisch die Platte ausgebaut und gegen eine funktionelle ersetzt werden -> Anschließend muss der Rebuild auf der Oberfläche vom ZFS OS angestoßen werden. Der Rest ist dann prinzipiell tatsächlich ein ziemlicher Selbstläufer (außer bei Besonderheiten, wie Verschlüsselung)
3. "Selbstläufer" wäre es, wenn du eine Platte dauerhaft als Hot-Spare laufen lassen würdest. D.h. die ist angeschlossen, wird im OS als Hot-Spare vorgehalten und springt -beim Ausfall einer der Platten deines Pools- von alleine ein und wird direkt für den Rebuild genutzt. Ist aber natürlich -bis zu diesem Szenario- "totes Kapital", da nicht in irgendeiner Weise nutzbar

Aber prinzipiell funktioniert das schon so, wie du es dir vorstellst.
Wenn du Zeit hast (und die würde ich mir nehmen):
- Server mit OS aufsetzen
- ZFS Pool aufbauen und nach deinen Wünschen konfigurieren
- Eine Platte rausschmeißen
- Rebuild anstoßen und komplett die Schritte durchlaufen

Quasi: Dry-Humping eines Platten-Ausfalls. Den hätte ich mir bei meinen ersten Schritten mit verschlüsseltem ZFS Pool auch gönnen sollen. Denn der erste Rebuild, der damals leider kam, ging fast in die Hose. Nur mit Ach und Krach bekam ich all meine Daten wieder -> Lag aber nicht an ZFS, sondern -wie so oft- am Anwender 1m vor dem Bildschirm, da nicht die Anleitung gelesen.

Sobald du das allerdings durchlaufen hast, gute Wahl. ZFS ist einfach genial und läuft super stabil, wenn man weiß, was man tut.