Een paar maanden geleden zijn we begonnen met onze $ 800 TrueNAS bouwwedstrijd. Kortom, Brian, Ben en Kevin namen $ 800 en bouwden hun eigen NAS-systeem met TrueNAS CORE als besturingssysteem. Dankzij Western Digital hoefden de jongens zich geen zorgen te maken over opslag, WD zorgde voor een overvloed aan SSD en HDD-opties voor de jongens om uit te kiezen. We wilden zien wat ons team zou kunnen doen om elk afzonderlijk systeem te bouwen en hoe ze zich tot elkaar verhouden. Ze gaven het geld uit, praatten onzin en lieten hun systemen testen, laten we eens kijken hoe ze het deden.
Een paar maanden geleden zijn we begonnen met onze $ 800 TrueNAS bouwwedstrijd. Kortom, Brian, Ben en Kevin namen $ 800 en bouwden hun eigen NAS-systeem met TrueNAS CORE als besturingssysteem. Dankzij Western Digital hoefden de jongens zich geen zorgen te maken over opslag, WD zorgde voor een overvloed aan SSD en HDD-opties voor de jongens om uit te kiezen. We wilden zien wat ons team zou kunnen doen om elk afzonderlijk systeem te bouwen en hoe ze zich tot elkaar verhouden. Ze gaven het geld uit, praatten onzin en lieten hun systemen testen, laten we eens kijken hoe ze het deden.
Als opzet voor degenen die ons nog niet hebben gevolgd, hebben we een video gemaakt over onze kleine wedstrijd die je hier kunt vinden of op onze YouTube-pagina:
Budget TrueNAS CORE-systemen
Ben de stagiaire gebouwd was waarschijnlijk de meest doe-het-zelver van het stel. Hij ging naar de Cincinnati Computer Cooperative en MicroCenter en kocht alle onderdelen apart en monteerde ze zelf. Zijn onderdelen omvatten een OCZ GSX600 PSU, een ASRock B550-moederbord, G.Skill Ripjaws V 64GB (2 x 32GB) DDR4-3600 RAM, een Ryzen 5 3600, een Chelsio 111-00603+A0 en een Lian Li Liancool 205 pc-behuizing . Met de paar extra dollars die hij over had, gooide hij wat LED-strips op zijn build.
Kevin maakte gebruik van de HPE MicroServer Gen10 Plus met zijn Xeon-processor en ECC-geheugen. Kevin voegde ook een 100GbE Mellanox ConnectX-5-kaart toe om een voorsprong te krijgen op de andere builds, terwijl het ook gemakkelijker werd om netwerken te configureren. Terwijl de andere builds een dual-port NIC gebruiken, hoeft Kevin slechts één 100GbE-interface te configureren.
Brians bouw zit ergens tussen de andere twee in. Hij begon met het Supermicro M11SDV-8CT-LN4F-bord, waardoor hij een AMD EPYC 3201 SoC-processor en vier 1GbE-poorten kreeg, wat een enorme hap uit het budget nam. Voor RAM gebruikte Brain twee SK hynix PC4-2400T-RD1-11 DDR4 ECC 8GB DRAM-modules. Hij installeerde ook een Thermaltake 500W PSU en 10GbE-kaart. Dit alles werd in een Fractal Design Node 304-behuizing geplaatst. Hoewel de 10GbE-kaart die Brian vond voor een fantastische prijs, zou deze uiteindelijk de TrueNAS-software niet herkennen of ermee werken, dus moest hij terugvallen op een reserve lab Emulex NIC. De gebruikte DRAM uit China was ook een probleem en moest worden vervangen.
Budget TrueNAS CORE-systeem - Prestaties
Laten we eens kijken naar de echte reden waarom iedereen hier is: welke van de drie is het beste? Naast onze drie DIY-builds hebben we ook een TrueNAS mini die we overigens weggeven. De iXsystem-build gebruikt RAIDZ2 omdat deze werd geleverd met 5 HDD's. Het iXsystems TrueNAS Mini X+-platform biedt de beste combinatie van chassisgrootte en schijfondersteuning. Het ondersteunt vijf 3.5″ HDD's en heeft zelfs twee 2.5″ bays voor SSD's. Dus waarom zou u het niet testen als basislijn? Eenvoudig, de Mini X+ is afgestemd op maximale gegevensveerkracht, niet op prestaties. De andere drie waren afgesteld om de snelste te zijn in deze krachtmeting, maar dat brengt een handvol risico's met zich mee. Als iXsystems onze concurrenten zou willen verslaan, zou het ze met een build kunnen verpletteren.
Een kort woordje over RAID-configuraties: TrueNAS ondersteunt er verschillende, afhankelijk van de build. Omdat we radicaal verschillende builds hebben gebruikt, zullen er verschillende RAID-configuraties zijn. De builds van Ben en Kevin gebruiken RAIDZ over vier SSD's en de build van Brian gebruikt Mirror over vier HDD's.
We hebben voor deze confrontatie alleen gekeken naar het SMB-fileshare-protocol. Een interessant element om te vermelden is hoeveel belang er wordt gehecht aan de moederbord- en chassisconfiguratie. Ben's desktopplatform dat er aantoonbaar het coolst uitziet, heeft slechts twee 3.5″ drive bays en is ook verreweg de grootste behuizing.
Brian's behuizing ondersteunt tot zes 3.5″ schijfposities met aandacht voor koeling, maar zijn moederbord heeft slechts vier on-board SATA-poorten. Kevin's HPE Microserver gebouwd als standaard build heeft vier bays en vier poorten, maar dat is precies hoe het platform is ontworpen.
Opslag is ook een beetje anders in verschillende modellen. In de build van Brian waren er vier WD Red HDD's van 10 TB, helaas werkte de M.2 NVMe-poort niet precies zoals bedoeld. De builds van zowel Ben als Kevin maakten gebruik van vier WD Red SSD's van 4 TB.
Het is belangrijk om in het prestatiegedeelte op te merken dat RAID-configuratie een grote rol speelt bij de manier waarop prestaties worden gemeten, naast alleen de schijfselectie zelf. RAIDZ heeft minder overhead dan RAIDZ2 en Mirror heeft nog minder overhead dan RAIDZ. Dat gezegd hebbende, moet de RAID-opstelling rekening houden met wat de uiteindelijke eindtoepassing is, hoeveel capaciteit u nodig heeft en hoe storingsbestendig u wilt bouwen. Uiteindelijk zijn deze resultaten niet bedoeld om te laten zien welke NAS sneller is, maar in plaats daarvan hoe TrueNAS-configuraties presteren in vergelijkbare builds, sommige met dezelfde schijven, in verschillende RAID-configuraties.
Enterprise synthetische werklastanalyse
Ons enterprise shared storage en harde schijf benchmarkproces preconditioneert elke schijf in een stabiele toestand met dezelfde werklast waarmee het apparaat zal worden getest onder een zware belasting van 16 threads met een uitstekende wachtrij van 16 per thread, en vervolgens getest met vaste intervallen in meerdere thread/wachtrij diepteprofielen om de prestaties bij licht en zwaar gebruik te tonen. Aangezien NAS-oplossingen zeer snel hun nominale prestatieniveau bereiken, zetten we alleen de belangrijkste onderdelen van elke test in een grafiek.
Voorconditionering en primaire steady-state tests:
- Doorvoer (lezen+schrijven IOPS aggregaat)
- Gemiddelde latentie (lees- en schrijflatentie samen gemiddeld)
- Maximale latentie (piek lees- of schrijflatentie)
- Latentie Standaarddeviatie (Lezen + Schrijven Standaarddeviatie samen gemiddeld)
Onze Enterprise Synthetic Workload Analysis omvat vier profielen op basis van taken uit de echte wereld. Deze profielen zijn ontwikkeld om het gemakkelijker te maken om te vergelijken met onze eerdere benchmarks en met algemeen gepubliceerde waarden zoals max. 4k lees- en schrijfsnelheid en 8k 70/30, wat vaak wordt gebruikt voor zakelijke schijven.
- 4K
-
- 100% lezen of 100% schrijven
- 100% 4K
- 8K 70/30
- 70% lezen, 30% schrijven
- 100% 8K
- 8K (opeenvolgend)
- 100% lezen of 100% schrijven
- 100% 8K
- 128K (opeenvolgend)
- 100% lezen of 100% schrijven
- 100% 128K
Als eerste is er onze 4K lees-/schrijfdoorvoertest. Om te lezen, de best presterende was die van Ben met 14,865 IOPS. Kevin werd tweede met 11,476. Brian werd derde met 595 IOPS. Voor schrijven nam Kevin de eerste plaats in met 3,868 IOPS. Ben werd tweede met 2,517 IOPS. Brian bleef derde met 923 IOPS.
Veel hiervan komt neer op het gebruikte RAID-type, hoewel, met Kevin's Microserver versus Ben's DIY-build, het IOPS-verschil een rol speelt in de snelheid van de CPU in elke build.
Het volgende is 4K gemiddelde latentie. Hier zien we dezelfde plaatsing als hierboven. In read wint Ben met 17.2 ms, Kevin wordt tweede met 22.31 ms en Brian blijft ver achter met 429.2 ms. Kevin schakelde over op schrijven en pakte de eerste plaats met 66.21 ms, Ben werd tweede met 101.66 ms en Brian was iets dichterbij met 276.89 ms als derde.
4K max latentie zorgde voor een beetje opschudding bij het plaatsen. Om te lezen nam Ben de eerste plaats in met 263.96 ms, Kevin volgde hem met 273.44 ms en Brian werd derde met 1,091.3 ms. Voor schrijven pakte Kevin de eerste plaats met 1,195 ms, Brian werd voor de verandering tweede met 2,092.5 ms en Ben zakte terug naar de derde plaats met 2,431.7 ms.
Onze laatste 4K-test is standaarddeviatie. Voor lees, Ben pakte de eerste plaats met 5.94 ms, Kevin zat vlak achter met 7.11 ms en Brian lag ver achter Kevin met 171.75 ms. Met schrijft had Kevin de eerste plaats met 117.02, Ben lag niet ver achter met 201.58 ms en Brian zat daar niet ver achter met 271.13 ms.
Onze volgende benchmark meet 100% 8K sequentiële doorvoer met een 16T16Q-belasting in 100% lees- en 100% schrijfbewerkingen. Ben's build nam de leiding met 47,699 IOPP, Kevin volgde met 44,848 IOPS en Brian had 29,767 IOPS. Voor schrijven nam Ben opnieuw de eerste plaats in met 83,866 IOPS, Kevin bleef tweede met 51,020 IOPS en Brian behield de derde plaats met 33,448 IOPS.
Vergeleken met de vaste werklast van 16 threads en max. 16 wachtrijen die we hebben uitgevoerd in de 100% 4K-schrijftest, schalen onze gemengde werklastprofielen de prestaties over een breed scala aan thread/wachtrij-combinaties. In deze tests variëren we de werklastintensiteit van 2 threads/2 wachtrijen tot 16 threads/16 wachtrijen. Schijftype en RAID-configuratie spelen hier een grote rol. Toegevoegde pariteit ter ondersteuning van schijfstoringen heeft een impact op de prestaties. Met doorvoer begon Ben als hoogste en behaalde hij de hoogste piek met 17,317 IOPS, hoewel zijn build tegen het einde wat afnam. Hoewel Brian's build hoger begon dan die van Kevin, wist Kevin hem voor de tweede plaats te overtreffen.
Met een gemiddelde latentie begonnen alle drie de StorageReview-builds met een latentie van minder dan een milliseconde. Terwijl ze redelijk dichtbij renden, kun je zien dat Ben's postuur geleidelijk voor die van Kevin uittrekt en dat ze allebei wegtrekken van Brain's postuur. Ben's eindigde met 15.8 ms, Kevin met 18.3 ms en Brian met 31.2 ms.
Voor maximale latentie begon Kevin als beste en hij en Ben wisselden de eerste plaats heen en weer. Uiteindelijk had de build van Kevin 221 ms en die van Ben 285 ms. Brian lag de hele tijd ver achter op de derde plaats.
De standaarddeviatie liet duidelijk zien dat Ben de hele tijd vooruit bouwde. Kevin had ongeveer 3 keer de latentie en Brian had ongeveer 4 keer.
De laatste Enterprise Synthetic Workload-benchmark is onze 128K-test, een sequentiële test met grote blokken die de hoogste sequentiële overdrachtssnelheid voor een apparaat laat zien. In read nam Kevin de eerste plaats in met 2.32 GB/s, Ben zat vlak achter hem met 1.81 GB/s en Brian's build moet het startschot gemist hebben met 734 MB/s. Op het schrijven nam Kevin opnieuw de eerste plaats in met 2.77 GB/s, Ben en Brian waren bijna gelijk met respectievelijk 1.42 GB/s en 1.41 GB/s.
De juiste configuratie kiezen voor uw behoeften...
Dus wie heeft er gewonnen? Het hangt echt af van waar u de meeste waarde aan hecht voor uw implementatie. De snelste build met betrekking tot I/O-prestaties had slechts twee schijfposities en een consumenten-CPU/RAM. Met ZFS wil je echt dat enterprise-componenten zoals ECC-geheugen gebruik maken van de geavanceerde data-integriteitsstack, dus het wordt vrijwel gediskwalificeerd voor alle implementaties behalve niet-productie-implementaties.
Vervolgens kijken we naar Brian's build die veel dichter in de buurt komt van wat je nodig hebt op het gebied van hardware en meer schijfposities op het chassis, maar het moederbord ondersteunt slechts vier harde schijven. Het was ook tot de rand gevuld met overtollige kabels van de voeding. Het bleek dat de oproep om naar eBay te gaan voor gebruikte NIC en DRAM een slechte was en de algehele systeemstabiliteit was duidelijk anderhalve stap in de categorieën "shifty" en / of "janky".
Voor de doe-het-zelf-menigte kwam het er echt op neer dat Kevin bouwde met een kant-en-klare microserver. De Microserver heeft een kleinere voetafdruk en een lagere instapprijs. Er zijn ook alle enterprise-componenten en zaken als iLo voor out-of-band beheer. Het systeem beperkt echter wel de opslag, met slechts 4 sleuven en ze zijn allemaal SATA, dus geen high-speed goodies. Toch biedt het de weg van de minste weerstand als het gaat om het rollen van een TrueNAS CORE-systeem met een doe-het-zelf budget.
Misschien een TrueNAS Mini?
Waar komt de TrueNAS Mini X+ hierin passen? Voor prestaties doet het dat niet. De specifieke build die we hebben is voor gegevensveerkracht. Wel heeft de Mini X+ een aantal leuke features zoals 10GbE aan boord. De Mini+ heeft ook zonder twijfel de meeste opslagcapaciteit, ondersteuning en flexibiliteit, met in totaal 7 drivebays.
Afgezien van het rangschikken van de doe-het-zelfsystemen in termen van prestaties, schetst deze wedstrijd ook een goed beeld van wat men kan doen binnen het TrueNAS CORE OS en een beperkt budget (afgezien van het feit dat we opslag van WD hebben gekregen als onderdeel van dit werk). Een kant-en-klare eenheid kopen is echter altijd de veiligste gok voor kleine bedrijven die geruststelling (ondersteuning) van leveranciers nodig hebben. Het is duidelijk dat sommige van onze builds een beetje hebben geleden bij het volgen van de doe-het-zelf-route.
De waarde van een kant-en-klaar systeem kan niet genoeg worden benadrukt als dit voor een productiegebruiksscenario is. De iXsystems Mini+ heeft weliswaar een hogere prijs, maar ondersteunt 3 extra schijven dan de doe-het-zelf-platforms en had geen sprake van ondersteuning van componentdrivers. Natuurlijk is er ook bedrijfsondersteuning voor de hardware en software, iets wat geen van de doe-het-zelf-builds zou kunnen bieden. Uiteindelijk hangt het er maar vanaf wat je wilt. TrueNAS CORE is flexibel genoeg om vrijwel elke hardware aan te kunnen.
Dankzij iXsystems geven we de TrueNAS Mini weg, meer details over hoe u zich hier kunt registreren.
Bekijk de hoogtepunten in onze prestatie-hoogtepuntenvideo hieronder.
TrueNAS-bronnen
- TrueNAS-back-updoel – Deduplicatie-impact
- TrueNAS CORE 12 recensie – HPE MicroServer
- TrueNAS CORE installeren
Neem contact op met StorageReview
Nieuwsbrief | YouTube | LinkedIn | Instagram | Twitter | Facebook | TikTok | RSS Feed
