几个月前，我们启动了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机箱。剩下的零钱，他还给电脑加装了一些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