幾個月前，我們啟動了800美元TrueNAS搭建大賽。簡單來說，Brian、Ben和Kevin各自拿出800美元，搭建了自己的NAS系統，作業系統都是TrueNAS CORE。感謝西部數據（Western Digital），他們無需擔心儲存問題，西部數據提供了豐富的固態硬碟（SSD）和機械硬碟（HDD）供他們選擇。我們想看看團隊成員搭建不同系統後的表現，以及它們之間的表現比較。他們投入了資金，互相切磋，並完成了系統測試，讓我們來看看他們的表現如何。
為了方便那些之前沒有關注過的朋友，我們製作了一個關於我們小型比賽的視頻，可以在這裡或我們的 YouTube 頁面上找到：
預算 TrueNAS 核心系統
實習生本的裝機方案大概是所有人中最具DIY精神的了。他去了辛辛那提電腦合作社和MicroCenter，分別購買了所有零件，然後自己組裝。他的零件包括OCZ GSX600電源、華擎B550主機板、芝奇Ripjaws V 64GB (2 x 32GB) DDR4-3600記憶體、Ryzen 5 3600處理器、Chelsio 111-00603+A0散熱器，以及聯力Liancool 205 205 2053機箱。剩下的零錢，他還為電腦加裝了一些LED燈條。
Kevin利用了配備 Xeon 處理器和 ECC 記憶體的 HPE MicroServer Gen10 Plus 伺服器。他還添加了一張 100GbE Mellanox ConnectX-5 網路卡，不僅提升了效能，也簡化了網路配置。其他配置都使用雙埠網路卡，而 Kevin 只需要設定一個 100GbE 介面即可。
Brian 的配置則介於另外兩個方案之間。他首先選擇了 Supermicro M11SDV-8CT-LN4F 主機板，這塊主機板配備了 AMD EPYC 3201 SoC 處理器和四個千兆乙太網路端口，但也因此佔據了預算的很大一部分。記憶體方面，Brian 使用了兩根 SK 海力士 PC4-2400T-RD1-11 DDR4 ECC 8GB 記憶體。他還安裝了 Thermaltake 500W 電源和一張萬兆網路卡。所有這些組件都安裝在 Fractal Design Node 304 機箱內。雖然 Brian 以非常優惠的價格買到了這張萬兆網卡，但它最終無法被 TrueNAS 軟體識別或正常工作，所以他不得不換用一塊備用的 Emulex 網卡。從中國購買的二手記憶體條也存在問題，最後不得不更換。
預算 TrueNAS 核心系統 – 性能
讓我們直奔主題：這三款產品哪一款最佳？除了我們自備的三款DIY裝置方案外，我們還有一台TrueNAS Mini，順便贈送一台。 iXsystems的裝置方案由於配備了5塊硬碟，所以採用了RAIDZ2陣列。 iXsystems TrueNAS Mini X+平台在機殼尺寸和硬碟支援方面達到了最佳平衡。它支援五塊3.5吋硬碟，甚至還配備了兩個2.5吋固態硬碟位。那麼，為什麼不把它當作基準來測試呢？原因很簡單，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 機械硬碟，可惜的是，M.2 NVMe 介面並沒有完全發揮其應有的功能。 Ben 和 Kevin 的配置都使用了四台4TB 的 WD Red 固態硬碟。
重要的是要注意在性能部分，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 Mini X+在這其中扮演什麼角色？就性能而言，它並不突出。我們評測的這款 Mini X+ 主要專注於數據可靠性。不過，Mini X+ 也擁有一些不錯的特性，例如板載 10GbE 網路卡。此外，Mini X+ 無疑擁有最強大的儲存容量支援和最大的靈活性，總共配備了 7 個硬碟位元。
除了在性能方面對 DIY 系統進行排名外，本次比賽還描繪了一個人可以在 TrueNAS CORE OS 和有限預算內做什麼的清晰畫面（撇開我們從 WD 獲得的存儲作為這項工作的一部分）。 不過，對於需要供應商保證（支持）的小公司來說，獲得現成的設備始終是最安全的選擇。 顯然，我們的一些構建在走 DIY 路線時遇到了一點問題。
如果這是用於生產用例，那麼交鑰匙系統的價值怎麼強調都不為過。 iXsystems Mini+價格確實高一些，但比DIY平台多支持3塊盤，組件驅動支持沒問題。 當然，還有對硬件和軟件的企業支持，這是任何 DIY 構建都無法提供的。 最後，這僅取決於您想要什麼。 TrueNAS CORE 足夠靈活，幾乎可以處理任何硬件。
感謝 iXsystems，我們將贈送 TrueNAS Mini，更多註冊詳情請點擊此處。
在下面的性能亮點視頻中獲取亮點。
TrueNAS 資源
Amazon