Vor einigen Monaten starteten wir unseren TrueNAS-Bauwettbewerb für 800 Dollar . Kurz gesagt: Brian, Ben und Kevin nahmen sich 800 Dollar und bauten sich ihr eigenes NAS-System mit TrueNAS Core als Betriebssystem. Dank Western Digital mussten sie sich keine Gedanken um den Speicherplatz machen, denn WD stellte eine große Auswahl an SSDs und HDDs zur Verfügung . Wir wollten sehen, was unser Team mit den verschiedenen Systemen leisten konnte und wie sie sich im Vergleich schlugen. Sie investierten das Geld, lieferten sich Wortgefechte und ließen ihre Systeme testen – schauen wir uns an, wie sie abgeschnitten haben.
Für alle, die es noch nicht mitverfolgt haben: Wir haben ein Video zu unserem kleinen Wettbewerb gemacht, das hier eingebettet oder auf unserem YouTube-Kanal zu finden ist :
Budget TrueNAS CORE-Systeme
Bens PC-Bau war wohl der selbstgebautste von allen. Er ging zum Computerladen Cincinnati Computer Cooperative und zum MicroCenter, kaufte alle Teile einzeln und baute sie selbst zusammen. Seine Komponenten umfassten ein OCZ GSX600 Netzteil, ein ASRock B550 Mainboard, 64 GB G.Skill Ripjaws V DDR4-3600 RAM (2 x 32 GB), einen Ryzen 5 3600 Prozessor, ein Chelsio 111-00603+A0 Gehäuse und ein Lian Li Liancool 205 Gehäuse. Mit dem wenigen übriggebliebenen Geld verpasste er seinem PC noch ein paar LED-Streifen.
Kevin nutzte den HPE MicroServer Gen10 Plus mit seinem Xeon-Prozessor und ECC-Speicher. Zusätzlich installierte er eine 100GbE Mellanox ConnectX-5-Karte, um sich einen Wettbewerbsvorteil zu verschaffen und die Netzwerkkonfiguration zu vereinfachen. Während die anderen Systeme eine Dual-Port-Netzwerkkarte verwenden, benötigt Kevin nur eine einzige 100GbE-Schnittstelle.
Brians System liegt irgendwo zwischen den beiden anderen. Er begann mit dem Supermicro M11SDV-8CT-LN4F-Mainboard, das ihm einen AMD EPYC 3201 SoC-Prozessor und vier 1-GbE-Ports bot, was sein Budget stark belastete. Für den Arbeitsspeicher verwendete Brian zwei SK hynix PC4-2400T-RD1-11 DDR4 ECC 8GB-DRAM-Module. Außerdem installierte er ein Thermaltake 500W-Netzteil und eine 10-GbE-Karte. Das Ganze wurde in ein Fractal Design Node 304-Gehäuse eingebaut. Obwohl Brian die 10-GbE-Karte zu einem fantastischen Preis gefunden hatte, wurde sie von der TrueNAS-Software nicht erkannt und funktionierte nicht mit ihr, sodass er auf eine gebrauchte Emulex-Netzwerkkarte aus seinem Labor zurückgreifen musste. Auch der gebrauchte Arbeitsspeicher aus China bereitete Probleme und musste ersetzt werden.
Budget TrueNAS CORE-System – Leistung
Kommen wir nun zum eigentlichen Grund, warum alle hier sind: Welches der drei Systeme ist das beste? Zusätzlich zu unseren drei Eigenbau-Systemen verlosen wir auch ein TrueNAS Mini . Das iXsystems-System nutzt RAIDZ2, da es mit fünf Festplatten geliefert wurde. Die iXsystems TrueNAS Mini X+ Plattform bietet die beste Kombination aus Gehäusegröße und Laufwerksunterstützung. Sie unterstützt fünf 3.5-Zoll-Festplatten und verfügt sogar über zwei 2.5-Zoll-Einschübe für SSDs. Warum also nicht dieses System als Vergleichsbasis testen? Ganz einfach: Das Mini X+ ist auf maximale Datensicherheit und nicht auf Höchstleistung optimiert. Die anderen drei Systeme wurden auf maximale Geschwindigkeit in diesem Vergleich optimiert, was allerdings mit einigen Risiken verbunden ist. Wenn iXsystems die Konkurrenz schlagen wollte, könnte das Unternehmen sie mit einem solchen System regelrecht überflügeln.
Ein kurzes Wort zu RAID-Konfigurationen: TrueNAS unterstützt je nach Build mehrere. Da wir völlig unterschiedliche Builds verwendet haben, wird es unterschiedliche RAID-Konfigurationen geben. Die Builds von Ben und Kevin verwenden RAIDZ auf vier SSDs und Brians Build verwendet Mirror auf vier Festplatten.
Wir haben uns für diesen Showdown nur das SMB-Fileshare-Protokoll angesehen. Ein interessanter Aspekt ist, wie wichtig die Motherboard- und Gehäusekonfiguration ist. Bens Desktop-Plattform, die wohl am coolsten aussieht, verfügt nur über zwei 3.5-Zoll-Laufwerksschächte und ist zudem mit Abstand das größte Gehäuse.
Brians Gehäuse unterstützt bis zu sechs 3.5-Zoll-Laufwerksschächte, wobei auf die Kühlung geachtet wird, aber sein Motherboard verfügt nur über vier integrierte SATA-Anschlüsse. Kevins HPE Microserver-Build als Standard-Build verfügt über vier Einschübe und vier Ports, aber genau so ist die Plattform konzipiert.
Auch der Speicher variiert je nach Modell. In Brians System waren vier 10-TB-WD-Red-HDDs verbaut, der M.2-NVMe-Anschluss funktionierte jedoch leider nicht wie gewünscht. Ben und Kevin nutzten hingegen jeweils vier 4-TB-WD-Red-SSDs.
Im Abschnitt „Leistung“ ist es wichtig zu beachten, dass die RAID-Konfiguration eine große Rolle bei der Leistungsmessung spielt, die über die reine Laufwerksauswahl hinausgeht. RAIDZ wird weniger Overhead haben als RAIDZ2 und Mirror wird sogar noch weniger Overhead haben als RAIDZ. Vor diesem Hintergrund muss beim RAID-Setup berücksichtigt werden, was die endgültige Endanwendung ist, wie viel Kapazität Sie benötigen und wie ausfallsicher Ihr Aufbau sein soll. Letztlich sollen diese Ergebnisse nicht zeigen, welches NAS schneller ist, sondern vielmehr die Leistung von TrueNAS-Konfigurationen in ähnlichen Builds, von denen einige dieselben Laufwerke verwenden, in unterschiedlichen RAID-Konfigurationen.
Synthetische Workload-Analyse für Unternehmen
Unser Enterprise-Shared-Storage- und Festplatten-Benchmark-Prozess versetzt jedes Laufwerk in einen stabilen Zustand mit der gleichen Arbeitslast, mit der das Gerät getestet wird, unter einer hohen Last von 16 Threads mit einer ausstehenden Warteschlange von 16 pro Thread und wird dann in festgelegten Intervallen mehrfach getestet Thread-/Warteschlangentiefenprofile, um die Leistung bei leichter und starker Beanspruchung anzuzeigen. Da NAS-Lösungen sehr schnell ihr Nennleistungsniveau erreichen, stellen wir bei jedem Test nur die Hauptabschnitte grafisch dar.
Vorkonditionierung und primäre stationäre Tests:
- Durchsatz (Lese- und Schreib-IOPS-Aggregat)
- Durchschnittliche Latenz (Lese- und Schreiblatenz insgesamt gemittelt)
- Maximale Latenz (Spitzen-Lese- oder Schreiblatenz)
- Latenz-Standardabweichung (Lese- und Schreib-Standardabweichung insgesamt gemittelt)
Unsere Enterprise Synthetic Workload Analysis umfasst vier Profile, die auf realen Aufgaben basieren. Diese Profile wurden entwickelt, um den Vergleich mit unseren früheren Benchmarks sowie weit verbreiteten Werten wie maximaler Lese- und Schreibgeschwindigkeit von 4K und 8K 70/30, die häufig für Unternehmenslaufwerke verwendet wird, zu erleichtern.
- 4K
-
- 100 % Lesen oder 100 % Schreiben
- 100 % 4K
- 8K 70/30
- 70 % lesen, 30 % schreiben
- 100 % 8K
- 8K (sequentiell)
- 100 % Lesen oder 100 % Schreiben
- 100 % 8K
- 128K (sequentiell)
- 100 % Lesen oder 100 % Schreiben
- 100 % 128K
Als Erstes folgt unser 4K-Lese-/Schreibdurchsatztest. Der Top-Performer war übrigens Ben's mit 14,865 IOPS. Kevin wurde mit 11,476 Punkten Zweiter. Brian erreichte mit 595 IOPS den dritten Platz. Beim Schreiben belegte Kevin mit 3,868 IOPS den Spitzenplatz. Ben landete mit 2,517 IOPS auf dem zweiten Platz. Brian blieb mit 923 IOPS auf dem dritten Platz.
Vieles davon hängt vom eingesetzten RAID-Typ ab, obwohl sich der IOPS-Unterschied zwischen Kevins Microserver und Bens DIY-Build auf die Geschwindigkeit der CPU in jedem Build auswirkt.
Als nächstes kommt die durchschnittliche Latenz von 4K. Hier sehen wir die gleiche Platzierung wie oben. Beim Lesen gewinnt Ben mit 17.2 ms, Kevin wird mit 22.31 ms Zweiter und Brian liegt mit 429.2 ms deutlich dahinter. Als er zum Schreiben wechselte, sicherte sich Kevin mit 66.21 ms den ersten Platz, Ben wurde mit 101.66 ms Zweiter und Brian war mit 276.89 ms als Dritter etwas näher dran.
Bei der maximalen 4K-Latenz gab es bei der Platzierung ein wenig Durcheinander. Ben belegte mit 263.96 ms den Spitzenplatz, Kevin lag mit 273.44 ms direkt hinter ihm und Brian mit 1,091.3 ms auf dem dritten Platz. Beim Schreiben belegte Kevin mit 1,195 ms den ersten Platz, Brian wurde mit 2,092.5 ms ausnahmsweise Zweiter und Ben rutschte mit 2,431.7 ms auf den dritten Platz ab.
Unser letzter 4K-Test ist Standardabweichung. Ben belegte mit 5.94 ms den ersten Platz, Kevin lag mit 7.11 ms dicht dahinter und Brian lag mit 171.75 ms weit hinter Kevin. Beim Schreiben lag Kevin mit 117.02 ms an der Spitze, Ben lag mit 201.58 ms nicht allzu weit dahinter und Brian mit 271.13 ms nicht allzu weit dahinter.
Unser nächster Benchmark misst 100 % sequenziellen 8K-Durchsatz mit einer 16T16Q-Last bei 100 % Lese- und 100 % Schreibvorgängen. Bens Build übernahm beim Lesen mit 47,699 IOPS die Führung, Kevin lag mit 44,848 IOPS knapp dahinter und Brian hatte 29,767 IOPS. Beim Schreiben belegte Ben mit 83,866 IOPS erneut den Spitzenplatz, Kevin blieb mit 51,020 IOPS auf dem zweiten Platz und Brian blieb mit 33,448 IOPS Dritter.
Im Vergleich zur festen maximalen Arbeitslast von 16 Threads und 16 Warteschlangen, die wir im 100 % 4K-Schreibtest durchgeführt haben, skalieren unsere gemischten Arbeitslastprofile die Leistung über eine Vielzahl von Thread-/Warteschlangenkombinationen. In diesen Tests decken wir die Arbeitslastintensität von 2 Threads/2 Warteschlangen bis zu 16 Threads/16 Warteschlangen ab. Dabei spielen Laufwerkstyp und RAID-Konfiguration eine große Rolle. Die zusätzliche Parität zur Unterstützung von Laufwerksausfällen wirkt sich negativ auf die Leistung aus. Beim Durchsatz startete Ben am höchsten und erreichte mit 17,317 IOPS durchgehend den höchsten Spitzenwert, obwohl sein Build gegen Ende etwas abfiel. Während Brians Statur anfangs höher war als die von Kevin, konnte Kevin ihn auf dem zweiten Platz überholen.
Bei durchschnittlicher Latenz starteten alle drei StorageReview-Builds mit einer Latenz von weniger als einer Millisekunde. Während sie ziemlich nah rannten, kann man sehen, wie Bens Körperbau Kevins Körperbau allmählich überholte und sich beide von Brains Körperbau ablösten. Ben beendete das Rennen mit 15.8 ms, Kevin mit 18.3 ms und Brian mit 31.2 ms.
Für maximale Latenz hatte Kevin den besten Start und er und Ben tauschten den ersten Platz hin und her. Am Ende hatte Kevins Build 221 ms und Bens 285 ms. Brian lag die ganze Zeit über auf dem dritten Platz weit zurück.
Die Standardabweichung zeigte deutlich, dass Bens Körperbau die ganze Zeit voraus war. Bei Kevin war die Latenz etwa dreimal so hoch und bei Brian etwa viermal.
Der letzte Enterprise Synthetic Workload-Benchmark ist unser 128K-Test, ein sequenzieller Test mit großen Blöcken, der die höchste sequenzielle Übertragungsgeschwindigkeit für ein Gerät zeigt. Beim Lesen belegte Kevin mit 2.32 GB/s den Spitzenplatz, Ben lag mit 1.81 GB/s direkt hinter ihm und Brians Build muss mit 734 MB/s den Startschuss verfehlt haben. Beim Schreiben belegte Kevin mit 2.77 GB/s erneut den Spitzenplatz, Ben und Brian lagen mit 1.42 GB/s bzw. 1.41 GB/s fast gleichauf.
Wählen Sie die richtige Konfiguration für Ihre Anforderungen …
Wer hat also gewonnen? Es hängt wirklich davon ab, worauf Sie bei Ihrer Bereitstellung den größten Wert legen. Der hinsichtlich der E/A-Leistung schnellste Build hatte nur zwei Laufwerksschächte und eine Consumer-CPU/RAM. Mit ZFS möchten Sie wirklich, dass Unternehmenskomponenten wie ECC-Speicher den erweiterten Datenintegritätsstapel nutzen, daher ist es für alle Bereitstellungen außer Nicht-Produktionsbereitstellungen praktisch ausgeschlossen.
Als Nächstes werfen wir einen Blick auf Brians Konstruktion, die in puncto Hardware viel näher an Ihre Anforderungen herankommt und über mehr Laufwerksschächte im Gehäuse verfügt, das Motherboard jedoch nur vier Festplatten unterstützt. Außerdem war es bis zum Rand mit überschüssigen Kabeln der Stromversorgung gefüllt. Wie sich herausstellte, war der Aufruf, bei eBay nach gebrauchten NICs und DRAMs zu suchen, eine schlechte Entscheidung, und die allgemeine Systemstabilität lag eindeutig anderthalb Schritte in den Kategorien „unbeständig“ und/oder „ruckelig“.
Für die Heimwerker war es vor allem wichtig, dass Kevin einen handelsüblichen Microserver baute. Der Microserver hat eine geringere Stellfläche und einen niedrigeren Einstiegspreis. Außerdem sind alle Enterprise-Komponenten und Dinge wie iLo für die Out-of-Band-Verwaltung vorhanden. Allerdings ist der Speicherplatz des Systems mit nur 4 Schächten begrenzt, und alle sind SATA, also keine Hochgeschwindigkeits-Extras. Dennoch bietet es den Weg des geringsten Widerstands, wenn es darum geht, ein preisgünstiges TrueNAS CORE-System zum Selbermachen einzusetzen.
Vielleicht ein TrueNAS Mini?
Wo positioniert sich das TrueNAS Mini X+ in diesem Vergleich? In puncto Leistung nicht. Unser Testgerät ist auf Datensicherheit ausgelegt. Das Mini X+ bietet jedoch einige nützliche Funktionen, wie beispielsweise integriertes 10GbE. Außerdem bietet es mit insgesamt sieben Laufwerksschächten zweifellos die größte Speicherkapazität und Flexibilität.
Abgesehen von der Bewertung der DIY-Systeme hinsichtlich der Leistung zeichnet dieser Wettbewerb auch ein gutes Bild davon, was man mit dem TrueNAS CORE-Betriebssystem und einem begrenzten Budget tun kann (abgesehen davon, dass wir im Rahmen dieser Arbeit Speicher von WD erhalten haben). Für kleine Unternehmen, die Zusicherungen (Unterstützung) von Anbietern benötigen, ist der Kauf eines handelsüblichen Geräts jedoch immer die sicherste Wahl. Offensichtlich haben einige unserer Builds etwas gelitten, als wir uns für den DIY-Weg entschieden haben.
Der Wert eines schlüsselfertigen Systems kann nicht genug betont werden, wenn es sich um einen Produktionsanwendungsfall handelt. Der iXsystems Mini + hat zwar einen höheren Preis, unterstützt aber drei zusätzliche Festplatten als die DIY-Plattformen und bietet keine Unterstützung für Komponententreiber. Natürlich gibt es auch Enterprise-Support für die Hardware und Software, den keines der DIY-Builds bieten kann. Am Ende kommt es einfach darauf an, was Sie wollen. TrueNAS CORE ist flexibel genug, um nahezu jede Hardware zu verarbeiten.
Dank iXsystems verlosen wir das TrueNAS Mini. Weitere Informationen zur Registrierung finden Sie hier.
Holen Sie sich die Highlights in unserem Video mit den Leistungshighlights unten.
TrueNAS-Ressourcen
Amazon