Wer kennt das nicht, da hat man ein kleines NAS und das ist mal wieder bis oben voll. Meist sind die Dinger auch nicht erweiterbar und relativ langsam sowieso.
Lösung: ein Eigenbau muss her, quasi ein eigener Storage-Server.
Aber was soll der können?

• SMB-Shares (für Windows-Clients)
• NFS-Shares (für Linux und andere *nixoide)
• iSCSI
• mGig oder 10Gbit/s Anbindung (SFP+)
• Fehlertoleranter erweiterbarer Storage
• Hot Swap
• SSD-Cache (wirklich notwendig?)
• Verwendung von vorhandenem Equipment, sofern möglich

Soweit schon mal der Rahmen. Als NAS-OS hatte ich vorab Unraid oder FreeNAS ausgesucht. Letztlich habe ich mich aber auf FreeNAS festgelegt, da es ein übersichtliches und funktionales UI bietet, es eine große Community gibt, es kostenfrei ist, ich aber im Fall der Fälle jederzeit Support kaufen könnte.

Los geht’s!
Vorhanden sind ein älteres Motherboard (Asus Z-97P), ein i5 4690K mit 4x 3,5GHz, 16GB RAM, Netzteil, eine 10Gtek BCM57810S Netzwerkkarte mit 2x SFP+, mit passendem DAC-Kabel und eine 96GB M.2 2280 SATA-SSD.
Nachgeordert habe ich das Gehäuse (Intertech 4U-4408) mit 4 Höheneinheiten und 8 Hotswap-Cages, verteilt auf 2 SAS Backplanes und passende Rack-Schienen.
Dazu einen 10Gtek LSI 9211-8i SAS Host-Adapter mit 2 SFF-8087 auf SFF-8087 Kabeln um Controller und Gehäuse-Backplane verbinden zu können.
Der Plattenverbund besteht aus 5x WD Red 4TB (WD40EFRX) und 3x Seagate IronWolf 4TB, also insgesamt 32TB Speicherplatz, die ich als RAIDZ2 konfigurieren werde. Insgesamt also 20TB Speicherplatz.
Der SAS-Controller hat ein PCIe 2.0 X8 Interface, ist also bei 8Gbit, bzw 1Gbyte/s ausgereizt. Das FreeNAS-System ist auf zwei gespiegelten 16Gbyte Sandisk USB-Sticks (USB 3.0) installiert.
Die geschätzte maximale (Dauer-) Transferleistung des NAS habe ich grob auf Basis der Daten der WD Red überschlagen. Jede Platte ist mit 150MB/s angegeben. In meiner Konfiguration würden Zugriffe auf 6Platten verteilt, plus Redundanz. Grob ergäben sich damit 900MB/s, bzw. 7,2GBit/s. Davon geht noch Leistung für die redundante Speicherung und Protokoll-Overhead  ab. Wenn das System später eine Transferleistung in der Nähe von 6Gbit/s  (750MByte/s) erreicht, sollte das Maximum ausgeschöpft sein.

Systemkonfiguration
Nach Aufbau und Funktionscheck der Hardware kann das aktuelle FreeNAS-Release heruntergeladen werden. Die Installationsdatei kann dann mittels z.B. Balena Etcher auf einen USB-Stick geschrieben werden.
Die Installation ist im Video auf FreeNAS.org  (erscheint direkt nach dem Download) sehr gut beschrieben.
Aus den 8 NAS-HDD habe ich einen RAIDZ2 Datenpool erstellt, die 96GB M.2SSD ist als Cache zugewiesen. In diesem Pool habe ich die einzelnen Datasets erstellt, die unter Sharing propagiert werden.
Wichtig war mir dabei, dass dem Datapool möglichst viele Drives  zugewiesen sind, um die Last gleichmäßig verteilen zu können.
Ein wichtigeer Performance-Aspekt betrifft eine Einstellung unter Network/Interfaces. Beim aktiven Netzwerk-Interface sollte die MTU auf z.B. 9000 gesetzt werden, um Jumbo-Frames zuzulassen.

Das muss dann allerdings netzwerkweit eingestellt werden.
Neben den eingangs erwähnten Shares soll zusätzlich für die Messungen FTP aktiviert werden. Dieser Dienst kann unter Services aktviert werden. Bei den Einstellungen werden lokale User zugelassen. FTP ist ein altes Datenübertragungsprotokoll mit sehr geringem Overhead. So ist es für effiziente Massendatentransfers im LAN, aber auch für soche Messungen optimal geeignet.
Damit ist das NAS vorbereitet und es kann gemessen werden.

Lasset die Spiele beginnen!
Gemessen werden FTP-Transfers zwischen NAS und Admin-Rechner. Als Messdaten dienen 4 VM-Images mit insgesamt 232GB Größe. Die Images werden einzeln übertragen und die Messungen gemittelt. Es wird nie ein Image direkt mehrfach hintereinander übertragen um Caching-Effekte auszuschliessen. Der Admin-Rechner verfügt neben einer NVMe-SSD auch über eine 10G Netzwerkkarte, so dass ein Flaschenhals auf der Seite ausgeschlossen werden kann.
Bei der ersten Messreihen befinden sich NAS und Client im gleichen VLAN, im gleichen IP-Netz (switched, non-routed).

Schreiben (Client -> NAS): 668,2MB/s bzw. 5,35Gbit/s
Lesen (NAS -> Client): 895,86MB/s, bzw. 7,16Gbit/s
SFTP lesend: 212,5MB/s bzw. 1,7Gbit/s

Folgemessreihe – Client und NAS befinden Sich in unterschiedlichen VLANs/IP-Netzen. Hier wird der Einfluss des Netzwerks ermittelt.

Schreiben (Client -> NAS): 436,75MB/s, bzw. 3,49Gbit/s
Lesen (NAS -> Client): 643,6MB/s, bzw. 5,15Gbit/s

Auf der Firewall ist während der Transfers kein Engpass feststellbar, lediglich die CPU geht von 4% auf 14%.

Random-Zugriffe wurden nicht getestet. Ebenfalls bleiben die Einflüsse anderer Protokolle (z.B. SMB) unberücksichtigt.
SFTP ist auf Sicherheit ausgelegt und hat einen entsprechenden Overhead, wie der Transfer zeigt.

Fazit
Die Leistung des NAS ist m.E. äusserst gut, speziell mit den Datenraten beim Lesen habe ich so nie gerechnet. Bei gerouteten Verbindungen ‘verliert’ man schon bei nur einem Hop ca. 1/3 der möglichen Bandbreite.
Geht es schneller? Nur mit deutlich größerem Aufwand. Eine Möglichkeit wäre ein SSD-Cache mit NVMe-SSDs, eine weitere noch mehr und/oder schnellere HDDs. Also nur mit mehr Kosten und mehr Energieverbrauch.
Der Aufwand die Leistung hier noch höher zu schrauben ist somit  nicht vertretbar.

nas_start