NVMe/TCP：性能、部署和自动化
Source: Erik Smith, Christine McMonigal, NVMe/TCP: Performance, Deployment and Automation, July 19, 2023
摘要
在性能方面，NVMe/TCP与我现有的块存储协议相比如何？ 在部署NVMe/TCP时，我应该使用专用的存储网络，还是可以使用融合网络？ 如何实现与基于IP-SAN的自动化交互？
问题解答
问：集中式发现控制器（CDC，Centralized Discovery Controller）层是否还提供驱动器访问控制，还是仅用于发现网络上可见的驱动器？
答：根据TP8010的定义，CDC仅提供传输层发现功能。换句话说，CDC将允许主机发现与其通信的子系统端口（在阵列上）的传输层信息（IP、端口、NQN），这些是已被授权的。将存储卷分配给特定主机是可以添加到CDC实现中的附加功能。例如，Dell推出了一个我们称之为智能布局存储软件（SmartFabric Storage Software，SFSS）的CDC实现。
问：您能提供一些提供CDC和驱动器访问控制功能的公司示例吗？
答：据我所知，目前唯一可用的CDC实现是Dell的SFSS。
问：您解决了安全性方面的身份验证问题，但是其它方面的加密呢？是否有可用或正在开发的加密解决方案？
答：我时间不多，所以在那部分内容上匆忙过去了。根据规范，可以使用身份验证（DH-HMAC-CHAP）和安全通道（TLS 1.3）。Dell目前还不支持这两者，但我们正在努力。
问：我认为NVMe/Fibre Channel也得到了广泛部署。这是真的吗？
答：根据我所看到的情况，情况并非如此。NVMe/FC已经存在一段时间了，它的性能很好，Dell也支持它。然而，采用速度相对较慢。再次根据我所看到的情况，NVMe/TCP似乎正在获得更多的关注。
问：nvme-stas是“in-box”解决方案、EPEL解决方案还是原型解决方案？
答：目前取决于发行版。
SLES 15 SP4和SP5 - 内置
RHEL 9.X - 内置（技术预览）[RHEL 8.X：不可用]
Ubuntu 22.04 - Universe（社区支持）
问：关于比较iSCSI、NVMe-oF、FC速度的幻灯片，这些数字与以太网或Infiniband上的RDMA传输（iSCSI对RDMA的扩展（iSER）或NMVe-oF RDMA）相比如何？接近FC NVMe-oF的数字吗？您是否考虑过NVMe-oF RoCE，或者当前或未来的采用率不够？作为后续问题，您是否看到与FCoE一样的连接/跳数问题？
答：我们在开始研究NVMe over Fabrics时，花费了大量时间来研究RoCE、iWARP、NVMe/TCP和NVMe/FC。其中一些测试结果在之前的网络研讨会“NVMe-oF: Looking Beyond Performance Hero Numbers”（https://www.snia.org/educational-library/nvme-looking-beyond-performance-hero-numbers-2021）中进行了演示。特别是在100GbE下，RoCE的性能表现实际上非常惊人，比我们研究的其他任何内容都要好，除了在使用硬件卸载的情况下的NVMe/TCP。上述研讨会详细描述了RoCE的不足之处。但简而言之，在我上次使用它时，配置和故障排除都比较困难。我知道NVIDIA最近在这方面做了很多工作来改进，但我认为大多数终端用户最终会选择在通用IP SAN连接外部存储时使用NVMe/TCP。
问：您是否可以拥有多个CDC，就像在分隔的子网区域中可能有一个CDC，但将由CDC的管理者报告或管理，以便您可以在可被隔离的服务器访问的不同存储网络中每个都提供或具有物理存在的区域内集中式“CDC”？
答：理论上是可以的。我们已经解决了协议细节，以提供此功能。然而，目前我们可以通过为单个CDC实例提供多个网络接口来提供此功能。然后，我们可以将每个接口连接到不同的子网。配置可能需要一些工作，但这样您就不需要维护多个CDC实例了。
问：NVMe/TCP提供块级别还是文件级别的存储访问？
答：块级别。更多信息可以在名为《Storage Protocol Stacks for NVMe》（https://brasstacksblog.typepad.com/brass-tacks/2017/11/storage-protocol-stacks-for-nvme.html）的博文中找到。
问：在40G上使用NVMe/TCP还是在32G上使用NVMe/FC，哪个会提供更好的性能？
答：不知道具体实现情况的情况下是无法确定的。我也没有看到关于在40GbE上测试NVMe/TCP性能的结果。
问：好吧，但是为SAN A和SAN B创建两个以太网fabric违反了古老的单一fabric网络部署标准... 此外：这个步骤是否需要彻底取消光纤通道并用以太网替换它？
答：我同意。使用以太网对隔离的SAN A和SAN B进行空隔离并不会得到IP网络团队的认可。一种妥协的方式是让网络团队分配两个VLAN（一个用于SAN A，另一个用于SAN B）。这在很大程度上规避了我所担心的问题。关于取消FC并用以太网替换它，我认为绝对没有人会用基于以太网的SAN替换现有的FC SAN。从经济角度来看，这是没有意义的。然而，我认为随着最终用户计划部署新应用程序或环境，使用以太网作为FC的替代方案是有意义的。这主要是因为我们为NVMe/TCP定义的配置过程是基于FC配置过程的，这是为了使传统的FC客户在需要从FC迁移到以太网时尽可能轻松地进行迁移。
问：您可以再次分享您用于连接的脚本吗？
答：请参考第47张幻灯片。脚本可以在这里找到：https://github.com/dell/SANdbox/tree/main/Toolkit
问：Microsoft是否有计划开发适用于Windows的NVMe/TCP驱动程序？
答：我不能对另一家公司的产品路线表达评论。我强烈建议您直接与Microsoft联系。
问：该幻灯片中有一个拼写错误，不是10.10.23.2，应该是10.10.3.2
答：10.10.23.2是该图中CDC的IP地址。"mDNS响应" 表示主机在10.10.23.2处有一个CDC可用。
问：-1500和-9000之间有什么区别？
答：这是最大传输单元（MTU）大小。
问：TP-8010将何时获得认可？
答：它已于2022年2月获得认可。
问：CDC是位于末端存储（端点）还是位于fabric中？
答：理论上，CDC可以位于任何地方。Dell的CDC实现（SFSS）目前可以部署为虚拟机（或在AWS中的EC2实例上）。从长远来看，您可以期望在交换机上运行SFSS。
问：在FC-NVMe中使用的是32Gb适配器。用于以太网/NVMe over TCP的测试使用了什么？
答：我们使用了设置为25GbE的Intel E810适配器。
问：对于NVMe over TCP，更高速的以太网适配器会带来更好的结果，因为100Gb以太网适配器更广泛可用，而128Gb FC仍未获得认可？
答：更高速的以太网适配器将为NVMe/TCP提供更好的结果。通常/现代的主机应该能够使用NVMe/TCP IO将一对100GbE适配器驱动到接近线速率。问题在于，尝试这样做将消耗大量CPU，并且可能会对应用程序/虚拟机留下的CPU量产生负面影响，除非利用网卡中的卸载来抵消利用率。此外，128GFC标准今年早些时候获得认可。
问：CDC将成为一个单独的设备吗？一个设备？
答：CDC目前在服务器上作为虚拟机运行。我们还期望在交换机上部署CDC。
问：在这个测试中使用了哪个存储系统？
答：结果是针对Dell PowerStore的。测试结果将根据所使用的存储平台而异。
问：第20至40张幻灯片：您希望谁来进行这个配置工作，是服务器团队、网络团队还是存储团队？
答：这些幻灯片旨在展示需要完成的工作，而不是哪个团队需要执行。也就是说，完全自动化的解决方案可以由存储管理员驱动，网络和服务器团队的参与仅需最少量。
问：CPU利用率的结果是针对主机还是阵列？
答：是主机。
问：测试时使用的HBA卡和以太网NIC是什么？
答：HBA = QLE2272。NIC = Intel E810。
问：FC HBA和NIC的速度是多少？
答：HBA以32GFC运行。以太网以25GbE运行。
问：您是如何处理多站点冗余或单站点冗余的？
答：通过部署多个CDC实例并设置类似于SAN A / SAN B的配置，可以实现单站点冗余。多站点冗余取决于管理员域的范围。如果管理员域跨越两个站点，则单个CDC实例可能为两个站点提供发现服务。如果管理员域限制为每个站点/管理员域，则目前需要每个站点/管理员域一个CDC实例。
问：当主机管理员决定使用“直接连接”发现方法而不是“集中式发现”时，会失去哪些功能？
答：这种配置在一定程度上运行良好（数十个端点），但会导致全网格发现，这可能会导致在主机和存储上浪费资源。
问：是否还有使用更大/更常规块大小的测试结果？
答：是的。请参阅《Transport Performance Comparison White paper》（https://www.delltechnologies.com/asset/en-us/products/storage/industry-market/h18892-nvme-transport-performance-comparison.pdf）。
问：例如VMware ESXi内是否本机支持自动发现？
答：是的。在ESXi 8.0u1中，动态发现得到了完全支持。
问：所以NVMe/TCP支持LAG，而iSCSI不支持？
答：LAG可以支持NVMe/TCP和iSCSI。在ESXi中存在一些限制，这些限制在SFSS部署指南中有描述。
问：所以NVMe/TCP支持路由？
答：是的。我展示的是如何自动配置路由信息，通常需要在主机上完成，以支持L3上的NVMe/TCP。
问：您提到了Dell开源主机软件；其它厂商是否也有相同的多路径/存储路径处理概念？
答：我不认为现在有其它可用的发现客户端。Dell为确保发现客户端可以被任何供应商使用，付出了很大的努力。
问：FC已经转向64G作为新标准。此解决方案是否适用于大多数环境中常见的混合终端设备速度，还是测试时所有设备都运行相同的网卡、存储速度？
答：我们进行了混合速度的测试，并没有遇到任何问题。尽管如此，与同质速度配置相比，混合速度配置的测试远没有那么多。
问：较低的MTU为什么会比NVMe TCP上的巨帧MTU产生更好的性能结果？这似乎违反了在涉及SAN时启用9K MTU的常规思维。
答：这是一个很好的问题，我迄今为止还无法回答。我们也发现它违背了直觉。
问：CDC是厂商的事情还是协议的事情？
答：CDC是一个NVMe标准。CDC在NVMe标准中定义。有关更多信息，请参见TP8010。
问：您是否认为在NVMe-oF背后的虚拟块存储中存在问题？具体而言，在我的情况下是zfs zvol与原始NVMe磁盘相比。已经在iSCSI中做过了？
答：只要应用程序不使用SCSI命令（例如，供应商专有的用于阵列管理目的的SCSI命令）执行专门的任务，它就不会知道底层存储卷是基于NVMe还是SCSI的。
问：在您的IOPS比较中，是否存在针对NVMe/TCP的硬件卸载，还是只是一般的IP/TCP卸载？
答：NVMe/TCP测试中没有使用硬件卸载。都是基于软件的。
问：NVMe/TCP是否支持IPv6？如果支持，响应时间是否有所改善（在相同的子网上）？
答：是的，支持IPv6，不会影响性能。
问：在Link Aggregation和Multipath之间存在一个悬而未决的问题，只有后者才能以可靠的方式汇总任意两个设备之间的有效带宽...
答：我不确定我是否会走得那么远，但我确实认为它们都很重要，如果网络和存储团队都希望确保覆盖这两种情况，它们可以组合在一起。就个人而言，我更倾向于使用多路径，因为我更关心意外导致数据不可用（DU）事件，而不是确保我获得最佳性能。
问：有效性能很可能也仅限于单个链接的带宽...多路径是正确的方法。
答：我认为这在很大程度上取决于工作负载，但我同意，如果必须选择一种，多路径是最好的选择。
问：为了使接口路由以这种方式工作，您需要ProxyARP，对吗？
答：是的！谢谢您提到这一点。在L3 IP SAN中，您需要在交换机上启用代理ARP，以绕过路由表问题。
问：测试是否使用1500字节帧？我们能够使用巨帧吗？
答：测试结果包括1500和9000字节的MTU。
问：发现的配置步骤似乎很多。与Fibre Channel相比，配置的复杂性如何？
答：当我们首次开始为NVMe/TCP开发发现自动化时，我们做出了明智的决定，确保通过NVMe/TCP将存储配置给主机的用户体验尽可能接近通过FC SAN将存储配置给主机的过程。我们包含了像名称服务器和区域设置这样的概念，以尽可能简化传统FC客户与NVMe/TCP一起工作的过程。我认为我们成功实现了目标。
演讲内容
演讲PPT：https://www.snia.org/sites/default/files/ESF/NVMeTCP-Performance-Deployment-and-Automation.pdf
如需了解该协议详细信息，可参考下列资源：
《What NVMe/TCP Means for Networked Storage》- 发布于4年前，仍然100%准确。由Sagi Grimberg和J Metz呈现的这段视频是全面了解NVMe/TCP协议的最佳途径。https://www.youtube.com/watch?v=uA1kO91yTzQ
《SNIA NSF – Discovery Automation for NVMe IP-Based SANs》- 对自从首次推出以来为NVMe/TCP添加的与发现自动化相关的增强功能的高级概述。https://www.youtube.com/watch?v=uzeK_g-1Pxw
《SNIA SDC – Discovery Protocol deep dive》- 对发现自动化协议的更详细研究。https://www.youtube.com/watch?v=Oqb3s0llNxw
《Security of Data on NVMe over Fabrics, The Armored Truck Way》- 对NVMe/TCP安全考虑的详细概述。https://www.snia.org/sites/default/files/ESF/Security-of-Data-on-NVMe-over-Fabrics-Final.pdf
---【本文完】---
近期受欢迎的文章：
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解