Budget-TrueNAS-CORE-System-Showdown

Vor ein paar Monaten haben wir mit unserem begonnen 800-Dollar-TrueNAS-Bauwettbewerb. Kurz gesagt, Brian, Ben und Kevin haben 800 US-Dollar genommen und ihr eigenes NAS-System gebaut, das TrueNAS CORE als Betriebssystem nutzt. Dank Western Digital mussten sich die Jungs keine Sorgen um den Speicher machen, WD stellte einen zur Verfügung Schar von SSD und Festplattenoptionen für die Jungs zur Auswahl. Wir wollten sehen, was unser Team beim Aufbau der einzelnen Systeme leisten kann und wie sie im Vergleich zueinander abschneiden. Sie haben das Geld ausgegeben, Unsinn geredet und ihre Systeme testen lassen. Lasst uns herausfinden, wie es ihnen ergangen ist.

Vor ein paar Monaten haben wir mit unserem begonnen 800-Dollar-TrueNAS-Bauwettbewerb. Kurz gesagt, Brian, Ben und Kevin haben 800 US-Dollar genommen und ihr eigenes NAS-System gebaut, das TrueNAS CORE als Betriebssystem nutzt. Dank Western Digital mussten sich die Jungs keine Sorgen um den Speicher machen, WD stellte einen zur Verfügung Schar von SSD und Festplattenoptionen für die Jungs zur Auswahl. Wir wollten sehen, was unser Team beim Aufbau der einzelnen Systeme leisten kann und wie sie im Vergleich zueinander abschneiden. Sie haben das Geld ausgegeben, Unsinn geredet und ihre Systeme testen lassen. Lasst uns herausfinden, wie es ihnen ergangen ist.

Als Vorbereitung für diejenigen, die noch nicht dabei sind, haben wir ein Video zu unserem kleinen Wettbewerb gemacht, das hier oder auf eingebettet zu finden ist unsere YouTube-Seite:

Budget TrueNAS CORE-Systeme

Der Körperbau von Ben dem Praktikanten war wahrscheinlich das Do-it-yourself-Projekt von allen. Er ging zur Cincinnati Computer Cooperative und zum MicroCenter, kaufte alle Teile einzeln und baute sie selbst zusammen. Zu seinen Teilen gehörten ein OCZ GSX600-Netzteil, ein ASRock B550-Motherboard, G.Skill Ripjaws V 64 GB (2 x 32 GB) DDR4-3600 RAM, ein Ryzen 5 3600, ein Chelsio 111-00603+A0 und ein Lian Li Liancool 205 PC-Gehäuse . Mit den wenigen zusätzlichen Dollars, die er übrig hatte, baute er einige LED-Streifen auf seinem Bau auf.

Wolfgang nutzte den HPE MicroServer Gen10 Plus mit seinem Xeon-Prozessor und ECC-Speicher. Kevin fügte außerdem eine 100-GbE-Mellanox-ConnectX-5-Karte hinzu, um gegenüber den anderen Builds einen Vorsprung zu haben und gleichzeitig die Netzwerkkonfiguration zu vereinfachen. Während die anderen Builds eine Dual-Port-NIC verwenden, muss Kevin nur eine 100-GbE-Schnittstelle konfigurieren.

Brians Körperbau liegt irgendwo zwischen den anderen beiden. Er begann mit dem Supermicro M11SDV-8CT-LN4F-Board, das ihm einen AMD EPYC 3201 SoC-Prozessor und vier 1-GbE-Ports bescherte, was das Budget enorm belastete. Als RAM nutzte Brain zwei SK hynix PC4-2400T-RD1-11 DDR4 ECC 8GB DRAM-Module. Außerdem installierte er ein 500-W-Netzteil von Thermaltake und eine 10-GbE-Karte. All dies wurde in einem Fractal Design Node 304-Gehäuse untergebracht. Obwohl die 10-GbE-Karte, die Brian zu einem fantastischen Preis fand, sie letztendlich nicht mit der TrueNAS-Software erkannt wurde oder mit ihr nicht funktionierte, musste er auf eine Ersatz-Labor-NIC von Emulex zurückgreifen. Auch der gebrauchte DRAM aus China war ein Problem und musste ersetzt werden.

Budget TrueNAS CORE-System – Leistung

Kommen wir zum wahren Grund, warum alle hier sind: Welcher der drei ist der Beste? Zusätzlich zu unseren drei DIY-Builds haben wir auch einen TrueNAS Mini das wir nebenbei verschenken. Der iXsystem-Build verwendet RAIDZ2, da er mit 5 Festplatten geliefert wurde. Die iXsystems TrueNAS Mini X+-Plattform bietet die beste Mischung aus Gehäusegröße und Laufwerksunterstützung. Es unterstützt fünf 3.5-Zoll-Festplatten und verfügt sogar über zwei 2.5-Zoll-Schächte für SSDs. Warum also nicht als Basis testen? Ganz einfach: Der Mini X+ ist auf maximale Datenstabilität und nicht auf Leistung ausgelegt. Die anderen drei waren darauf eingestellt, in diesem Showdown die Schnellsten zu sein, obwohl das mit einigen Risiken verbunden ist. Wenn iXsystems unsere Konkurrenten schlagen wollte, könnte es sie mit einem Build vernichten.

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 die Lagerung unterscheidet sich je nach Modell etwas. In Brians Build gab es vier 10-TB-WD-Red-Festplatten, leider funktionierte der M.2-NVMe-Port nicht ganz wie vorgesehen. Sowohl Bens als auch Kevins Builds nutzten 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 kommt die TrueNAS Mini X+ passt da rein? Für die Leistung gilt das nicht. Der besondere Build, den wir haben, dient der Datenresilienz. Allerdings verfügt das Mini X+ über einige nette Features wie 10GbE onboard. Der Mini+ bietet mit insgesamt 7 Laufwerksschächten ohne Frage auch die größte Speicherkapazitätsunterstützung 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 verschenken wir noch mehr TrueNAS Mini Einzelheiten zur Anmeldung finden Sie hier.

Holen Sie sich die Highlights in unserem Video mit den Leistungshighlights unten.

TrueNAS-Ressourcen

• TrueNAS-Backup-Ziel – Auswirkungen der Deduplizierung
• TrueNAS CORE 12 Test – HPE MicroServer
• So installieren Sie TrueNAS CORE

Beteiligen Sie sich an StorageReview

Newsletter | YouTube |  LinkedIn | Instagram | Twitter | Facebook | TikTok | RSS Feed