NVMe-MI 时代的NVMe SSD监控和管理

带外管理是企业级NVMe SSD的一种管理维护方式，它独立于主机的操作系统，无需登陆甚至无需系统启动，即可实现高效的NVMe设备监控、管理、升级等操作。它涉及BMC、SMBUS、VPD、IPMI这些技术和概念，它们早已有之并且非常成熟。

说到NVMe，肯定离不开NVMe Base Spec，它定义了主机软件与NVMe SSD的通信方式。NVMe-MI（NVMe Management Interface）Spec是NVMe Spec家族中的一员，它的诞生和发展是建立在带外管理和NVMe Base Spec基础上的，算是个后来者。其使命是构建多样化的管理通道和接口，通过带外或带内的方式，对NVMe存储系统进行监控和管理，提高运维效率，并将这一过程标准化。

其中，监控部分包括盘的温度、功耗、运行状态（是否Panic等状态）等；管理则包含获取盘的基本信息（如MN、PCIe ID、厂商名、Form Factor）、升级Firmware以及对设备执行Format等操作。

由于带内管理的工作也可以在登录系统后，通过标准的NVMe指令完成，NVMe Base Spec对此也做了详细的说明，因此当我们谈及NVMe-MI，更多是对带外管理的描述。

值得一提的是，Memblaze自PBlaze5企业级NVMe SSD开始就支持NVMe-MI。目前，最新的NVMe-MI版本是1.2b，它在内容上有着诸多升级。本文将从NVMe SSD的视角，结合NVMe-MI 1.2b对带外管理的命令和下发进行详细解读。

NVMe-MI带外管理架构

上图展示了NVMe-MI协议规定的带外命令处理机制，Management Controller（通常是服务器的BMC）将NVMe-MI的命令以MCTP包的形式经过SMBUS或者PCIe VDM发给Management Endpoint（如NVMe SSD）。而这里的SMBUS和PCIe VDM就是前面提到的多样化的管理通道和接口。

上图是NVMe-MI协议中企业级NVMe SSD的典型构成，下面从右至左进行一个说明：

1. FRU Information Device，这个概念源自IPMI Platform Management FRU Information Storage Definition，其存储内容也就是我们通常说的VPD。在NVMe-MI协议规范中，对VPD的组成做了详细的说明。
2. VPD，Vital Product Data，重要产品数据。它涉及多种规范，除了上文提到的IPMI FRU information Storage Definition，Enterprise SSD Form Factor也对VPD的内容做了规定。不同规范里面信息定义的格式并不一样，但里面都是盘的主要信息，如厂商信息、SN、MN等。VPD一般存放于EEPROM中，EEPROM可以在3.3v aux供电时访问，这意味着BMC在只有辅助电源的时候也可以访问VPD。
3. SMD是NVMe-MI协议中的一个特殊情况，它允许BMC通过原生的SMBUS byte read和block read命令下发给SSD，获取设备状态、温度等信息。之所以说它特殊，是因为NVMe-MI中的其它command都是通过MCTP的包下发。
4. Management Endpoint是MCTP中的概念，在MCTP协议中，Management Controller通常指BMC，是发命令的一方，Management Endpoint则是被管理的一方，如NVMe SSD在接收命令时就是典型的Management Endpoint角色。

上图最左侧的黑箭头是指host将MI command包装成原生的NVMe命令从带内经PCIe 接口下发给SSD，这是NVMe MI协议规定的一个In-Band Tunneling Message Servicing模型，下文会对这部分In band MI命令的组成进行解释。

NVMe MI中的命令

上图是NVMe-1.2b中的命令架构，可以看到，它分为out-of band（带外）和in band（带内）两条路径，以实现NVMe Admin Command、Control Primitive、NVMe MI Command等命令的执行。这里以命令为基础对上图做一个解释：

1. 除SMD外，NVMe-MI命令的request和response都是MI Message的形式，每条MI Message由一到多个MCTP包组成；
2. 主要用到的MCTP协议包括DSP236（MCTP Base SPEC）、DSP237（SMBUS传输协议）和DSP238（PCIe VDM传输协议）三个。上图蓝色和黄色箭头标识了MCTP over SMBUS和MCTP over PCIe VDM所能执行的命令（带内的命令后面会讨论）。
3. MCTP over SMBUS是通过SMBUS/I2C发送带外命令并返回结果。SMBUS是带外管理生态中应用非常广泛且成熟的接口，如NVMe-MI最早采用的就是SMBUS接口。常见的SMBUS/I2C传输速率为100kHz和400kHz，对于一些数据量较小的命令，这个速率足够了。但对于firmware download这样的命令，Management Controller需要将一个数MB体积的image传给Management Endpoint，此时SMBUS就显得效率非常低了。
4. MCTP over PCIe VDM，其本质是通过PCIe bus传输MCTP包，由于PCIe VDM的接口速率比SMBUS/I2C有了质的提升，更有利于提高firmware download和获取大数据量log（比如telemetry log）的效率。
5. 带外的命令包含NVMe Admin Command、Control Primitive、PCIe Command（可选）以及NVMe MI Command四部分，理论上这些命令都可以从SMBUS/I2C和PCIe VDM两种接口下发给SSD处理，协议没有明确哪些命令必须使用某种接口发送。
6. NVMe Admin Command是NVMe Base Spec中的admin命令，NVMe-MI支持将这些命令放在带外执行，这极大扩充了带外的功能。一个get log和identify就可以拿到非常全面的SSD信息（如温度、上电时间、error类型以及各类ID），而format、firmware download、firmware commit等命令则可以对盘做更深入的管理。
7. Control Primitive是一组NVMe-MI规定的控制原语，可以帮助SSD在处理命令的不同阶段更好的和Management Controller交互。
8. PCIe Command主要用于处理一些PCIe的命令（比如获取一些PCIe寄存器信息），是一组可选的MI命令。
9. NVMe MI Command是NVMe-MI Spec特有的一组命令，主要获取Management Endpoint的设备信息和状态的功能。其中VPD read和VPD write提供了读取和修改VPD的命令接口。
10. 在带内路径中，NVMe-MI Spec涉及两个NVMe命令——NVMe-MI Send和NVMe-MI Receive，这两个命令允许管理员从带内发送NVMe MI Command命令。大致流程是host发送一条NVMe-MI Send或者NVMe-MI Receive命令（也就是一条Submission Queue Entry），SSD收到之后按照协议规定的对应关系将其转换为MI Command格式，并判断是否有错，没错则进行处理并返回结果。
11. 大部分时间NVMe-MI都在讲如何发送，通过什么接口、以什么样的格式发送一条命令。带外可以发NVMe admin命令，同样带内也可以通过NVMe-MI Send和NVMe-MI Receive发送带外的命令，这也是NVMe-MI工作的重点。一旦命令被SSD接收，Firmware就会交给相应的命令处理模块进行处理，所以不论是哪种接口下发命令，对于SSD，解析后的命令处理过程并没有本质的区别。

本文主要介绍了NVMe MI的命令和下发的方式，事实上，NVMe-MI Spec还对VPD的格式、设备Reset机制等等内容做了说明。除了MCTP一系列协议，NVMe-MI规范还参考了SMBUS、PCIe以及IPMI fru等规范，这些都有大量的细节需要明确，限于篇幅，本文不对这些细节做更详细的讨论。

NVMe-MI 1.2还在不断丰富，但是在命令处理机制上已经较为完善，并且NVMe-MI非常注重和NVMe Base Spec 2.0的统一，方便NVMe-MI彻底融入到NVMe的大生态中，也让带外管理可以更加的开放和标准化。

Memblaze在NVMe-MI上的调研始于NVMe-MI 1.0时代。时至今天，NVMe-MI的内容已经非常丰富，其管理和使用分离的理念也有着非常多的优点，但从实践来看，NVMe-MI的普及仍有很大空间，不论是MCTP over SMBUS还是MCTP over PCIe VDM，都需要服务器和企业级NVMe SSD双方大量的验证工作。但可以肯定，NVMe-MI以其高度标准化和开放的生态，代表了SSD带外管理的重要方向。