Windows 在很多方面都很棒，它成为世界第一的操作系统是有原因的。 也就是说，它并不完美，尤其是在采用新的存储标准时。 因此，有进取心的公司有巨大的机会为 Windows 商店开发解决方案。 随着 NVMe SSD 继续在企业中占据主导地位，成为 SSD 服务器存储的标准，能够共享该存储的需求也在增加。 可悲的是，在 Windows 中，这是一个问题，直到最近。 今年早些时候，StarWind 将适用于 Windows 的 NVMe-oF Initiator 商业化。
Windows 在很多方面都很棒，它成为世界第一的操作系统是有原因的。 也就是说，它并不完美，尤其是在采用新的存储标准时。 因此，有进取心的公司有巨大的机会为 Windows 商店开发解决方案。 随着 NVMe SSD 继续在企业中占据主导地位，成为 SSD 服务器存储的标准，能够共享该存储的需求也在增加。 可悲的是，在 Windows 中，这是一个问题，直到最近。 今年早些时候，StarWind 将适用于 Windows 的 NVMe-oF Initiator 商业化。
在商业化之前，StarWind 一直在提供适用于 Windows 的 NVMe-oF Initiator 作为开发和 PoC 用例的免费工具。 他们仍然 提供免费版本 对于那些想玩的人，但我们今天要看的是 GA 发布版本。 事实上，如果您正在查看适用于 Windows 的任何 NVMe-oF Initiator，您可能正在使用 StarWind IP。 他们为需要扩展其产品的各种合作伙伴提供 OEM 解决方案。
适用于 Windows 配置的 NVMe-oF 启动器
适用于 Windows 的 StarWind NVMe-oF Initiator 可以在任何 Windows 主机上轻松安装。 不需要专门的硬件或额外的 Windows 组件。 该软件已通过 Windows 认证（Server 2019 和 Windows 10），并通过了与主要 NVMe-oF 存储供应商的兼容性测试。 在我们的场景中，我们有一个非常简单的配置，即一个存储主机和四个客户端。
四个客户中的每一个都是 戴尔PowerEdge R740 服务器。 他们每个人都运行两个 6130GHz 的 Intel Xeon Gold 2.1 CPU 和 256GB 的 DRAM。 对于连接，我们使用 NVIDIA ConnectX-5 EN 100GbE NIC (MCX516A-CCAT)。 服务器安装了 Windows Server 2019 Standard Edition，利用 StarWind NVMe-oF Initiator for Windows 1.9.0.455 版。 对于 Linux 测试，我们使用了 CentOS 8.4.2105（内核 – 4.18.0-305.10.2）和 nvme-cli 1.12。 服务器直接连接到存储主机。
存储主机是一台 Intel OEM 服务器 (M50CYP2SB2U)，配备两个 8380 GHz 的 Intel Xeon 2.3 CPU 和 512GB DRAM。 我们再次使用了 NVIDIA ConnectX-5 EN 100GbE NIC (MCX516A-CDAT)，这次我们在主机中使用了四个。 在这种情况下，我们使用 CentOS 8.4.2105（内核 – 5.13.7-1.el8.elrepo）和 SPDK v21.07。
在主机中，我们使用八个 英特尔 P5510 第 4 代 NVMe 固态硬盘。 SSD 分为两批，每批四块，以便与 CPU 进行 NUMA 对齐。 它们在 RAID0 中配置以获得最佳性能。
用于 Windows 性能的 NVMe-oF 启动器
对于此测试，我们利用 Linux 和 Windows 启动器通过 FIO 运行了以下基准测试。
- 随机读取 4K – 16 个线程，32 个队列深度
- 随机写入 4K – 8 个线程，4 个队列深度
- 随机读取 64K – 4 个线程，32 个队列深度
- 随机写入 64K – 4 个线程，1 个队列深度
- 顺序读取 1M – 2 个线程，8 个队列深度
- 顺序写入 1M – 1 个线程，8 个队列深度
单次测试持续时间为 3600 秒（1 小时）。 在对写入操作进行基准测试之前，存储已先预热 3600 秒（1 小时）。 所有测试均进行了三次，取平均值作为最终结果。
在我们研究 4 个客户端的 Linux NVMeoF 启动器性能的第一组中，我们在 5.54K 随机读取中以 21.6 毫秒的延迟在 0.369GB/s 的带宽下测量了 4M IOPS。 4K 随机写入性能在 1.58GB/s 的带宽下测得 6.2M IOPS，延迟为 0.08ms。
转向大块传输，我们测量了 64K 随机，最后是 1M 顺序测试，重点关注整个结构的带宽。 在 64K 随机读取中，我们在 46.6 毫秒的延迟下测得 0.69GB/s，在 7.2ms 的写入延迟下测得 0.14GB/s。 1M 顺序读取速度为 42.9GB/s，延迟为 1.48ms，写入速度为 25.4GB/s，延迟为 1.26ms。
接下来，我们切换到 Windows，我们在相同的四个客户端上利用了 StarWind NVMeoF 发起程序。 在这里，我们在 4.17K 随机读取时测得 4 万次 IOPS，或在 16.3 毫秒延迟时测得 0.35GB/秒。 4K 随机写入速度为 1.54M IOPS 或 6GB/s，延迟为 0.07ms。
然后，我们转移到具有相同随机访问配置文件的更大的 64K 传输大小。 在这里，我们在 46.6 毫秒的延迟下测量了 0.68GB/s 的读取速度，在 7.2ms 的延迟下测量了 0.13GB/s 的写入速度。 切换到我们上一个具有顺序访问模式的 1M 传输大小的工作负载配置文件，我们测量到 42.9GB/s 的读取速度为 1.38ms 延迟，25.2GB/s 的写入速度为 1.14ms 延迟。
比较这些数字，除了 4K 随机读取外，Windows 和 Linux 的性能非常接近。 在所有其他测试中，性能差距小于 3%。 主要区别实际上归结为流经 Windows 存储堆栈时增加的 CPU 开销。 这产生了 2.7 到 3.7 倍的差异，其中增加的 I/O 本身对 CPU 使用率的影响最大。
从 Linux 中的 16% CPU 利用率上升到 Windows 中的 44% 是一个相当大的跳跃，但从 3.5% 上升到 9% 的感觉不会达到相同的程度。 对于需要在 Windows 中运行的应用程序或通常更关注 Windows 的 IT 商店，StarWind 的主要目标是带来他们显然能够实现的 NVMeoF 功能和性能。
总结
此分析的目的不是确定推出您自己的 NVMe-oF 解决方案的最佳方式或最快方式。 大多数存储部署跟随应用程序，而不是应用程序跟随存储。 也就是说，组织可能想要使用 Windows 的原因有很多。 可能是特定应用程序、现有基础设施、成本原因或任何其他问题使 Windows 成为首选平台。 至少现在，借助 StarWind 的 NVMe-oF Initiator for Windows，我们可以选择共享 NVMe SSD 并让它们尽可能靠近应用程序系统。
暂时忽略客户端操作系统，我们测试中的主要限制实际上归结为系统之间的网络链接。 在我们的案例中，利用 100Gb NIC，我们使网络饱和，并在 Linux 和 Windows 环境中达到 46.6GB/s 的最高速度。 即使是 Windows 中的峰值 4K 随机读取测试也达到了 16.3GB/s，这可以计算出超过六个 25GbE 链接的随机 I/O。 网络最终在 NVMe-oF 中扮演更重要的角色，因为 NVMe 性能以任何方式切片都会吸收大量流量。
但归根结底，我们的目标是评估 StarWind 启动器的工作情况。 它真的很好用。 考虑替代方案是“没有适合您的 NVMe-oF！” 在 Windows 中，我们很高兴有任何选择。 是的，该特权会影响 CPU，但即使从 Linux 到 Windows 的百分比增量很可怕，但在 4K 随机读取之外，感知到的影响是最小的。 如果您不确定这是否合适，StarWind 可让您免费试用。 安装如此简单，有充分的理由试一试，看看 NVMe-oF 在 Windows 中对您的应用程序的工作效果如何。
参与 StorageReview
电子报 | YouTube | 播客 iTunes/Spotify | Instagram | Twitter | Facebook | RSS订阅
