NVMe 连接器修复代理¶
https://blueprints.launchpad.net/cinder/+spec/nvmeof-client-raid-healing-agent
一个守护进程，用于监控 NVMe 连接和 NVMe 连接器创建的 MDRAID 阵列，识别故障的卷副本，请求新的副本，并用新的副本替换故障的副本。
注意
此规范已被 NVMeoF 连接代理 取代。
问题描述¶
当 NVMe 连接器连接一个复制的卷时，OpenStack 会将其视为一个卷，无法监控、管理和修复这些 MDRAID 阵列中的副本。此代理将负责处理这些问题。
它将监控 MDRAID 阵列的状态，并将它们在主机上的物理状态与卷配置器期望的状态进行协调，替换损坏的腿。
对于后端卷副本，存储阵列负责监控和替换不健康的副本。
NVMe MDRAID 将数据复制的责任从后端转移到消费者。
目前没有机制来监控和修复这些复制的卷。
我们无法在 Cinder 端执行此操作，因为即使 Cinder 驱动程序检测到问题并创建了替换卷，我们也没有机制将替换卷的连接信息报告给消费者。
因此，监控和修复需要在卷消费者端进行。
此代理对于某些已连接复制卷的副本发生故障的情况也大有裨益，通过向卷配置器通知故障设备，可以将其标记为故障，以避免在重新连接时使用旧数据，并完全替换它们。
用例¶
在使用连接到实例很长时间的复制 NVMe 卷时，其中一个副本可能会发生故障。此代理将检测到它并尝试替换它（自我修复 MDRAID，无需分离和重新连接卷）。
提议的变更¶
添加一个“NVMe 代理”类，该类将在主机上卷连接期间由 NVMe 连接器初始化。
初始化此代理将启动一个监控任务，该任务将定期重复。如果可能，我们建议使用原生线程，但如果需要，可以使用独立的进程。
最初的提议是使用 python 事件调度器 sched.scheduler，但也可以选择其他替代方案，例如通过套接字通信的独立进程。需要解决的关键问题是计算服务停止，而虚拟机继续运行（及其卷保持连接）的情况 - 我们不想在这种情况下丢失此代理。
初始化时，代理将从预先确定的配置文件位置读取访问卷配置器的信息，格式为供应商特定的格式，系统操作员应在那里提供内容。
该任务将监控 NVMe 设备和基于它们的 MDRAID 阵列。
它将根据来自卷配置器（后端）的元数据来确定要监控哪些 NVMe 设备和 MDRAID 阵列 - 它将具有自定义接口与之交互。
如果需要，它将通知卷配置器有关故障设备的信息。
它将尝试连接到新的 NVMe 设备/副本，并在 MDRAID 中替换它们。
典型的自我修复流程
卷副本发生故障
代理注意到故障副本，报告给配置器
配置器将副本标记为坏的（因此除非同步，否则以后不会使用它）
代理持续从配置器拉取卷信息
经过一定的宽限期后，代理没有看到配置器对故障副本的状态更改，因此它发送明确的请求来替换副本
配置器替换副本并更新卷信息
代理拉取卷副本信息，注意到一个副本已更改
代理执行副本替换
备选方案¶
操作员可以使用自己的脚本来监控连接并手动修复它们
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
将调用 NVMe 连接器方法，这些方法将在 os-brick 中生成的新的代理任务中执行对 nvme 和 mdadm 的 sudo 执行。
Active/Active HA 影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
为了允许多个供应商实现，特定的方法/逻辑用于
探测卷配置器
从配置器拉取/解析卷元数据
向配置器报告卷状态更改
请求配置器替换副本
需要基于每个供应商实现。
架构是代理将是一个提供接口的通用类，而 kioxia 实现将是供应商特定实现的第一个示例。
实现¶
负责人¶
- Zohar Mamedov
zoharm
工作项¶
NVMe 连接器将在连接卷时（如果未运行）启动监控任务。
任务监控连接器创建的 NVMe 设备和 MDRAID 阵列。
当副本发生故障（以及其他事件，例如断开连接）时，调用用于通知卷配置器的接口方法。
当卷配置器更改复制的卷设备时，协调主机上 NVMe 设备和 MDRAID 阵列的物理状态。
依赖项¶
无
测试¶
我们应该只用单元测试就能接受这个。
文档影响¶
记录使用 NVMe 连接器和复制卷将可选地启动此代理。
参考资料¶
架构图 https://wiki.openstack.org/wiki/File:Nvme-of-add-client-raid1-detail.png
