幾個月前，我們開始了我們的 800 美元的 TrueNAS 構建競賽. 簡而言之，Brian、Ben、Kevin 花了 800 美元並利用 TrueNAS CORE 作為操作系統構建了他們自己的 NAS 系統。 感謝 Western Digital，這些人不必擔心存儲問題，WD 提供了 一堆SSD 硬盤選項 供小伙伴們選擇。 我們想看看我們的團隊可以做些什麼來構建每個不同的系統，以及它們之間的比較。 他們花了錢，說了廢話，測試了他們的系統，讓我們看看他們是怎麼做到的。
幾個月前，我們開始了我們的 800 美元的 TrueNAS 構建競賽. 簡而言之，Brian、Ben、Kevin 花了 800 美元並利用 TrueNAS CORE 作為操作系統構建了他們自己的 NAS 系統。 感謝 Western Digital，這些人不必擔心存儲問題，WD 提供了 一堆SSD 硬盤選項 供小伙伴們選擇。 我們想看看我們的團隊可以做些什麼來構建每個不同的系統，以及它們之間的比較。 他們花了錢，說了廢話，測試了他們的系統，讓我們看看他們是怎麼做到的。
作為對那些沒有關注的人的設置，我們製作了一個關於我們的小型比賽的視頻，可以在此處或 我們的 YouTube 頁面:
預算 TrueNAS 核心系統
實習生 Ben 的體型 可能是最DIY的。 他去了 Cincinnati Computer Cooperative and MicroCenter，分別購買了所有零件，然後自己組裝。 他的零件包括 OCZ GSX600 PSU、ASRock B550 主板、G.Skill Ripjaws V 64GB (2 x 32GB) DDR4-3600 RAM、Ryzen 5 3600、Chelsio 111-00603+A0 和 Lian Li Liancool 205 PC 機箱. 他用剩下的幾美元，在他的建築上扔了一些 LED 燈條。
凱文 利用 HPE MicroServer Gen10 Plus 及其至強處理器和 ECC 內存。 Kevin 還添加了一個 100GbE Mellanox ConnectX-5 卡，以在其他構建上佔據一席之地，同時還可以更輕鬆地配置網絡。 雖然其他構建使用雙端口 NIC，但 Kevin 只需要配置一個 100GbE 接口。
布萊恩的身材 介於其他兩者之間。 他從 Supermicro M11SDV-8CT-LN4F 主板開始，為他提供了 AMD EPYC 3201 SoC 處理器和四個 1GbE 端口，這大大節省了預算。 對於 RAM，Brain 使用了兩個 SK hynix PC4-2400T-RD1-11 DDR4 ECC 8GB DRAM 模塊。 他還安裝了 Thermaltake 500W PSU 和 10GbE 卡。 所有這些都放在 Fractal Design Node 304 外殼內。 雖然 Brian 發現 10GbE 卡的價格非常優惠，但它最終無法識別 TrueNAS 軟件或無法與 TrueNAS 軟件一起使用，因此他不得不轉而使用備用的實驗室 Emulex NIC。 來自中國的用過的 DRAM 也是一個問題，必須更換。
預算 TrueNAS 核心系統 – 性能
讓我們來看看每個人都在這裡的真正原因：這三個中哪個最好？ 除了我們的三個 DIY 構建之外，我們還有一個 TrueNAS 迷你版 我們順便放棄了。 iXsystem 構建使用 RAIDZ2，因為它隨附 5 個 HDD。 iXsystems TrueNAS Mini X+ 平台提供機箱尺寸和驅動器支持的最佳結合。 它支持五個 3.5" HDD，甚至還有兩個 2.5" SSD 托架。 那麼為什麼不將其作為基線進行測試呢？ 很簡單，Mini X+ 已針對最大數據彈性而非性能進行了調整。 其他三個被調整為這場攤牌中最快的，儘管這會帶來一些風險。 如果 iXsystems 想要打敗我們的競爭對手，它可以用一個構建來粉碎他們。
關於 RAID 配置的簡要說明：TrueNAS 支持多種配置，具體取決於構建。 由於我們使用了完全不同的構建，因此會有不同的 RAID 配置。 Ben 和 Kevin 的構建在四個 SSD 上使用 RAIDZ，而 Brian 的構建在四個 HDD 上使用 Mirror。
我們只查看了此攤牌的 SMB 文件共享協議。 值得一提的一個有趣因素是主板和機箱配置的重要性。 Ben 的桌面平台可以說是最酷的，只有兩個 3.5 英寸驅動器托架，也是迄今為止最大的機箱。
Brian 的機箱最多支持六個 3.5 英寸驅動器托架，並註意冷卻，但他的主板只有四個板載 SATA 端口。 Kevin 的 HPE 微服務器構建作為庫存構建有四個托架和四個端口，但這正是平台的設計方式。
不同型號的存儲也略有不同。 在 Brian 的構建中，有四個 10TB WD Red HDD，遺憾的是 M.2 NVMe 端口沒有完全按預期工作。 Ben 和 Kevin 的構建都利用了四個 4TB WD 紅色固態硬盤.
重要的是要注意在性能部分，RAID 配置在如何衡量性能方面發揮著巨大作用，而不僅僅是驅動器選擇本身。 RAIDZ 的開銷會比 RAIDZ2 少，而 Mirror 的開銷會比 RAIDZ 更少。 話雖如此，RAID 設置必須考慮最終的最終應用程序是什麼、您需要多少容量以及您希望構建的抗故障能力如何。 最後，這些結果並不是為了顯示哪個 NAS 更快，而是為了顯示 TrueNAS 配置如何在類似的構建中執行，一些使用相同的驅動器，在不同的 RAID 配置中。
企業綜合工作負載分析
我們的企業共享存儲和硬盤驅動器基準測試流程將每個驅動器以相同的工作負載預先設定為穩定狀態，設備將在 16 個線程的重負載下進行測試，每個線程有 16 個未完成隊列，然後在設定的間隔內多次測試線程/隊列深度配置文件以顯示輕度和重度使用情況下的性能。 由於 NAS 解決方案很快就能達到其額定性能水平，因此我們只繪製出每個測試的主要部分。
預處理和初級穩態測試：
- 吞吐量（讀+寫 IOPS 聚合）
- 平均延遲（讀+寫延遲一起平均）
- 最大延遲（峰值讀取或寫入延遲）
- 延遲標準偏差（讀+寫標準偏差一起平均）
我們的企業綜合工作負載分析包括四個基於實際任務的配置文件。 開發這些配置文件是為了更容易與我們過去的基準測試以及廣泛發布的值（例如最大 4k 讀寫速度和 8k 70/30，通常用於企業驅動器）進行比較。
- 4K
-
- 100% 讀取或 100% 寫入
- 100% 4K
- 8K 70/30
- 70% 讀取，30% 寫入
- 100% 8K
- 8K（連續）
- 100% 讀取或 100% 寫入
- 100% 8K
- 128K（連續）
- 100% 讀取或 100% 寫入
- 100% 128K
首先是我們的 4K 讀/寫吞吐量測試。 對於讀取，表現最好的是 Ben 的 14,865 IOPS。 凱文以 11,476 分排名第二。 Brian 以 595 IOPS 獲得第三名。 對於寫入，Kevin 以 3,868 IOPS 位居榜首。 Ben 以 2,517 IOPS 位居第二。 Brian 以 923 IOPS 位居第三。
這在很大程度上歸結為部署的 RAID 類型，不過，對於 Kevin 的 Microserver 與 Ben 的 DIY 構建，IOPS 差異會影響每個構建中的 CPU 速度。
接下來是 4K 平均延遲。 在這裡我們看到與上面相同的位置。 在讀取中，Ben 以 17.2ms 獲勝，Kevin 以 22.31ms 位居第二，Brian 以 429.2ms 遠遠落後。 轉向寫作，Kevin 以 66.21ms 位居榜首，Ben 以 101.66ms 位居第二，Brian 以 276.89ms 位居第三。
4K 最大延遲在放置方面發生了一些變化。 在閱讀方面，Ben 以 263.96 毫秒位居榜首，Kevin 以 273.44 毫秒緊隨其後，Brian 以 1,091.3 毫秒位居第三。 對於寫入，Kevin 以 1,195 毫秒獲得第一，Brian 以 2,092.5 毫秒獲得第二名，Ben 以 2,431.7 毫秒下滑至第三。
我們最後的 4K 測試是標準偏差。 對於讀取，Ben 以 5.94 毫秒獲得第一，Kevin 以 7.11 毫秒緊隨其後，Brian 以 171.75 毫秒遠遠落後於 Kevin。 Kevin 以 117.02 毫秒位居榜首，Ben 以 201.58 毫秒緊隨其後，而 Brian 以 271.13 毫秒緊隨其後。
我們的下一個基準測試在 100% 讀取和 8% 寫入操作中使用 16T16Q 負載測量 100% 100K 順序吞吐量。 Ben 的構建以 47,699 IOPP 領先，Kevin 以 44,848 IOPS 緊隨其後，Brian 的 IOPS 為 29,767。 在寫入方面，Ben 以 83,866 IOPS 再次奪冠，Kevin 以 51,020 IOPS 位居第二，Brian 以 33,448 IOPS 保持第三。
與我們在 16% 16K 寫入測試中執行的固定 100 線程、4 隊列最大工作負載相比，我們的混合工作負載配置文件可在各種線程/隊列組合中擴展性能。 在這些測試中，我們將工作負載強度從 2 個線程/2 個隊列擴展到 16 個線程/16 個隊列。 驅動器類型和 RAID 配置在這裡起著巨大的作用。 添加奇偶校驗以支持驅動器故障會影響性能。 在吞吐量方面，Ben 從最高開始並以 17,317 IOPS 的最高峰值完成，儘管他的構建在接近尾聲時有所下降。 雖然 Brian 的體型起步高於 Kevin，但 Kevin 超越了他獲得第二名。
對於平均延遲，所有三個 StorageReview 構建都以亞毫秒級延遲開始。 當他們跑得相當近時，您可以看到 Ben 的體型逐漸領先於 Kevin 的體型，而他們兩人的體型都遠離 Brain 的體型。 Ben 以 15.8ms 結束，Kevin 以 18.3ms 結束，Brian 以 31.2ms 結束。
對於最大延遲，Kevin 的起步最好，他和 Ben 來回交換第一名。 最後，Kevin 的構建時間為 221 毫秒，而 Ben 的構建時間為 285 毫秒。 布賴恩始終落後於第三名。
標準差清楚地顯示了 Ben 始終領先。 Kevin 的延遲大約是 3 倍，而 Brian 的延遲大約是 4 倍。
最後一個企業綜合工作負載基準是我們的 128K 測試，這是一個大塊順序測試，顯示了設備的最高順序傳輸速度。 在閱讀中，Kevin 以 2.32GB/s 位居榜首，Ben 以 1.81GB/s 緊隨其後，而 Brian 的版本肯定以 734MB/s 錯過了首發手槍。 在寫入方面，Kevin 以 2.77GB/s 再次奪冠，Ben 和 Brian 分別以 1.42GB/s 和 1.41GB/s 幾乎並列。
根據您的需要選擇正確的配置……
那麼誰贏了？ 這實際上取決於您對部署的最大價值。 就 I/O 性能而言最快的構建只有兩個驅動器托架和一個消費類 CPU/RAM。 使用 ZFS，您確實希望 ECC 內存等企業組件使用高級數據完整性堆棧，因此除了非生產部署外，它幾乎不符合所有部署的資格。
接下來，我們看看 Brian 的構建，它從硬件方面更接近您的需求，並增加了機箱上的驅動器托架，但主板僅支持四個硬盤驅動器。 它也充滿了來自電源的多餘電纜。 事實證明，去 eBay 購買使用過的 NIC 和 DRAM 的電話是一個糟糕的電話，整體系統穩定性顯然在“不穩定”和/或“janky”類別中邁出了一步半。
對於 DIY 人群，這實際上歸結為 Kevin 使用現成的微服務器構建。 微服務器佔用空間更小，入門價格更低。 還有用於帶外管理的所有企業組件和諸如 iLo 之類的東西。 不過，該系統確實在存儲上達到了上限，只有 4 個托架，而且它們都是 SATA，所以沒有高速的東西。 即便如此，在推出 DIY 預算 TrueNAS CORE 系統時，它提供了阻力最小的途徑。
也許是 TrueNAS Mini？
在哪裡 TrueNAS 迷你 X+ 適合這個？ 對於性能，它沒有。 我們擁有的特定構建是為了數據彈性。 然而，Mini X+ 有幾個不錯的功能，例如板載 10GbE。 毫無疑問，Mini+ 還具有最多的存儲容量支持和靈活性，共有 7 個驅動器托架。
除了在性能方面對 DIY 系統進行排名外，本次比賽還描繪了一個人可以在 TrueNAS CORE OS 和有限預算內做什麼的清晰畫面（撇開我們從 WD 獲得的存儲作為這項工作的一部分）。 不過，對於需要供應商保證（支持）的小公司來說，獲得現成的設備始終是最安全的選擇。 顯然，我們的一些構建在走 DIY 路線時遇到了一點問題。
如果這是用於生產用例，那麼交鑰匙系統的價值怎麼強調都不為過。 iXsystems Mini+價格確實高一些，但比DIY平台多支持3塊盤，組件驅動支持沒問題。 當然，還有對硬件和軟件的企業支持，這是任何 DIY 構建都無法提供的。 最後，這僅取決於您想要什麼。 TrueNAS CORE 足夠靈活，幾乎可以處理任何硬件。
感謝 iXsystems，我們贈送了 TrueNAS Mini，還有更多 有關如何在此處註冊的詳細信息.
在下面的性能亮點視頻中獲取亮點。
TrueNAS 資源
參與 StorageReview
電子通訊 | YouTube | LinkedIn | Instagram | Twitter | Facebook | 的TikTok | RSS訂閱
