几个月前，我们开始了我们的 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订阅
