NVMe-oF：基于IP的NVMe SAN自动化发现存储网络

这几天我做事的效率可能不够高，接下来的周末都没时间写东西了，只好提前到晚上：）

今天的分享来自SNIA资料《NVMe-oF™: Discovery Automation for NVMe® IP-based SANs 》的学习笔记。

NVMe-oF的“直接发现”和“集中化发现”

图片点开后可放大，以下同

在SAN存储网络的发展来看，从SCSI到NVMe是一个趋势。已有的SCSI包括走Fibre Channel（光纤通道）网络的FCP和IP网络的iSCSI，当然后者的性能（延时）表现通常不太好，只是实现成本低。

NVMe-oF可以通过多种Fabric互连，包括NVMe/FC, NVMe/TCP, NVMe/RoCEv2, NVMe/IB和NVMe/iWARP，未来应该是以前三种为主。

我们来看一下单层网络拓扑的连接性需求。

（1）2个单独的SAN交换机，从主机（服务器）到存储之间是个冗余的后端网络，并且与前端IP LAN网络隔离。

（2）融合LAN和SAN交换机，数据网络和NVMe-TCP存储流量使用同一张IP网络。这样做性能容易无法保证，iSCSI要想达到较好的体验通常也推荐存储流量走独立网络。

（3）专用的双SAN Fabric，与上面的 1 相比SAN A/B的规模更大，应该是各自配置了FC交换机堆叠。

（4）专用的IP SAN Switch，像传统iSCSI和FC拓扑那样把存储后端网络独立出来，这对于NVMe-oF同样属于性能最佳实践。

还记得我在《NVMe-oF 1.1规范：多路径、非对称命名空间和NVMe/TCP》中提到过大约2年前的新特性：“Asynchronous discovery events inform hosts of addition or removal of target ports in a fabric-independent manner.” 下面看看NVMe工作组不断完善的路线图：

已经公布的TP-8006和8011分别解决了身份认证和加密的问题（如下图），比如NVMe over Fabric对应iSCSI CHAP和FC存储端点认证的新机制叫做DH-HMAC-CHAP，安全通道则是靠TLS 1.3。

目前已经达到Phase 3阶段的是NVMe-oF自动化发现的控制器（TP-8009）和TP-8010的CDC（集中发现控制器），这也是本文重点要讨论的。而仍在进行中的标准包括从NVMe-oF存储启动，以及吸收FC-NVMe的需求到NVM Express规范中来。

无论FC存储网络还是基于IP的NVMe SAN，自动化端到端发现的目的都差不多，也是为了规避像iSCSI那样的用户体验。iSCSI我有几年没上手玩了吧，记得之前还是在测试EQL时给交换机配VLAN。

FC网络的发现服务是供应商定义的，好在Brocade（现在是Broadcom）光纤交换机市场占主导，HBA卡也就是Emulex（也被博通收购了）和QLogic（Marvell）这2家，只要不是跨交换机品牌互连似乎还好。

在服务器和存储互相发现之前，可以有一个底层Fabric的配置服务。具体到以太网/IP Fabric的形成服务，Dell有一个SFS（Smart Fabric Storage），我理解应该是配合自家品牌交换机的自动化底层配置。

上面是基于IP的NVMe SAN中的术语。

-         端点：在主机和存储系统上，以NQN（对应iSCSI的IQN）和IP地址来识别；

-         IP网络：以太网交换机，最好是25GbE或以上；

-         子系统：指存储阵列，类似于SCSI Target；通过一个NQN可以有多个目标端口，然后每个Target再映射出若干LUN；

-         CDC：集中发现控制器实例；

-         DDC：直接发现控制器：由存储控制器自身提供的发现功能，不具备集中化管理的一些价值。

支持自动化发现的部署类型有3种：

1、物理连接：主机和存储之间通过线缆直连，没有交换机；

2、Direct Discovery：多个主机和存储子系统在一个IPFabric网络里，没有CDC控制器；

3、Centralized Discovery：在“2”基础上，加入CDC。

注：CDC支持注册和zoning（分区）。通常独立（作为一个虚拟机）运行或者嵌入到Fabric里的交换机上。

Direct Discovery的配置步骤（当前）：

（1）     主机根据管理员提供的IP地址，发送连接请求到NVMe存储阵列的Discovery Controller；

（2）     存储管理员提供Namespace（相当于存储LUN）给到主机NQN；

（3）     主机管理员使用nvme connect-all发现并连接存储阵列上的IO Controller；

（4）     在所有主机上为每一个存储子系统重复1-3步骤。

Centralized Discovery的配置步骤（新方法）：

（0）     主机和存储系统先自动发现CDC，连接到它并注册Discovery信息；

（1）     在CDC上执行Zoning（可选，这部分自动化应该需要以太网交换机的协同）；

（2）     存储管理员提供namespaces给到主机NQN，存储会发送Zoning信息给CDC；

（3）     Zoning之后，主机接收到AEN，使用get log页面，并连接到每一个（存储）的IO Controller；

（4）     针对每一台主机，为每个存储子系统重复1-2步骤。

上图是直连 vs 集中化发现在规模扩展大之后的对比。直连方式在每一次有存储添加或者移除时，都需要对每台（连接的）主机做交互操作；并且在若干存储子系统接口（网口）存在时，会导致增加发现时间。

而集中方式相当于把所有Host和存储端信息都存放在CDC上，有变更时只要在这里改，相当于新注册的主机一上来就能看到所有存储，然后选择分配即可。

当超过64台主机时，Direct发现的总配置步骤，将显著多于Centralized发现方式。

大家还记得FC存储网络的Zoning吧。NVMe IP SAN是在CDC上有一个Zoning数据库，存储着配置和激活的zones。

端到端自动化发现示例

我们来看一下NVMe IP-Based SAN集中化发现的操作流程（硬件组成包括NVMe/TCP主机端、存储子系统和以太网交换机）

（1）     自动化底层配置：基于预定义的策略进行Fabric（交换机）的自动化部署；

（2）     服务器和存储系统发现CDC；

（3）     服务器和存储系统在CDC上注册；

（4）     操作者或者orchestrator（编排器）读取CDC命名服务器数据库，并设置Server/Storage zones；

（5）     CDC提示服务器和存储关于zoning的变化；

（6）     服务器连接存储并开始传输数据。

最后再回顾一下关键要点：

-         自动化发现并不完全依赖于CDC（集中发现控制器）的存在，小规模环境可以使用mDNS来自动发现NVMeDiscovery控制器。

-         CDC和（存储）子系统将支持它们应该做的交互：

          ● 使用Port-LocalLog页面，来提供更好的UX（用户体验），并阻止不同租户之间的信息泄露；

          ● 使用（存储）子系统驱动的Zoning（SDZ）——存储管理员只需要与一个UI界面交互来分配存储；

           ● 使用终端用户易懂的扩展属性和注册符号名；

       ● 贡献给开源的NVMe-oF Discovery client（发现客户端）“nvme-stas”正在由Dell牵头。在TP-8009和8010规范被批准之后将提供review（大约在今年底）。

OMNI（OpenManage Network Integration，看上去明显是用于网络管理）集中化管理，在这里就是CDC。

大家如有兴趣，可以留意下Dell EMC的SmartFabric Storage Software，以及PowerStore OS 2.1对NVMe/TCP的支持。

参考资料

https://www.snia.org/sites/default/files/ESF/NVMe-oF-Discovery-Automation-for-NVMe-IP-based-SANs.pdf

https://www.delltechnologies.com/asset/en-ug/products/networking/technical-support/smartfabric-storage-software-spec-sheet.pdf

扩展阅读：《企业存储技术》文章分类索引（微信公众号专辑）》

注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。进一步交流可加微信：490834312。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）

尊重知识，转载时请保留全文，并包括本行及如下二维码。感谢您的阅读和支持！《企业存储技术》微信公众号：HL_Storage

长按二维码可直接识别关注

历史文章汇总：http://www.toutiao.com/c/user/5821930387/

http://www.zhihu.com/column/huangliang

点击下方“阅读原文”，查看更多历史文章↓↓↓