Samsung：支持在线迁移的SSD

问题意识：跨DC数据迁移

实时迁移技术在数据中心和SSD存储系统中的应用动机和优势。

图右上角是全球视角下，目前正广泛建设的AI算力中心选址。

为什么迁移工作负载？

负载均衡

• • AI训练是长时间运行且无用户交互的
• • 数据中心(DC)负载可能会随当地时区而变化
• • 将AI训练迁移到因夜间而负载减少的数据中心
• • 数据中心停机时间、错误或其他访问异常

Note: 国外云计算经过近20年发展，逐渐从CSP主导，过渡到用户成熟的SuperCloud（超级云）阶段，此时跨云迁移、数据流动成为新的内生动力，对软硬件的灵活性，提出新挑战。

为什么要实时迁移？

• • 工作负载可以在不感知迁移事件的情况下继续运行
• • 最小化停机时间

为什么要在SSD层面启用实时迁移？

• • 允许移除IO队列上的软件垫片层
• • 减少主机软件负载
• • 改善存储访问延迟

实时迁移技术对现代数据中心和存储系统具有重要意义。它不仅提高了资源利用效率和系统可靠性，还通过优化存储访问路径，显著提升了整体性能。这种技术使得数据中心能够更灵活地应对负载变化和潜在故障，同时为高性能计算任务（如AI训练）提供更好的支持。

迁移工作流

介绍实时迁移过程的各个阶段和关键组件。

关键组件：

• • 迁移管理主机 - MMH
• • 迁移管理控制器 - MMC
• • 可迁移控制器 - MC

实时迁移过程，如图右所示，

主机IO是连续的

• • 预复制阶段
  • • NS的初始复制
  • • 主机更改的NS数据的迭代复制
• • 暂停和复制阶段
  • • 暂停MC-S
  • • 主机更改的NS数据的最终复制
• • 后复制阶段
  • • 移动主机并复制MC状态
  • • 恢复

实时迁移系统的具体设置，重点关注虚拟化环境和SSD存储。

关键技术特性：

1. 1. 虚拟化架构：使用VM和VMM
2. 2. 集中化迁移管理：通过VMM控制
3. 3. 透明迁移：VM不感知迁移过程
4. 4. SR-IOV技术应用于SSD
5. 5. 灵活的目标设置：允许预先操作

Note：要实现主机VM无感知的数据自动迁移，需要在虚拟化层实现，同时为提高迁移效率，需要SSD支持 SR-IOV 直通。虚拟化层（VMM）中需要实现：迁移队列管理（Admin Q）和迁移队列（MQ）。

各家云平台虚拟化管理层不一样，如何在VMM中实现统一的队列管理？软件层的工作可能还是类似VAST/WEKA这样的数据公司来做更合适，SSD厂商需要满足场景迁移的需求，但软件层的事可能还做不了。

预复制阶段

预复制阶段：开始日志记录（源端）

VM继续与SSD上的次级Ctlr交互（读/写）

• • 竞争条件是一个关注点
• • 通过对"开始日志记录"、"日志记录已开始"和"初始NS迁移"的排序来解决

"开始日志记录"命令流程

• • VMM发送"Track Send"和"记录用户数据变更"选项，同时IO继续
• • 主Ctlr开始追踪VM的Ctlr（次级Ctlr）中发生的所有请求MQ事件
• • 主Ctlr完成"开始日志记录"命令
• • SSD承诺：所有可能需要记录的命令现在都将被记录

VMM已成功在MQ中开始日志记录

• • 日志开始和某些命令之间的关系未知
• • 不确定日志开始相对于"开始日志记录"命令完成的具体时间点
• • "日志记录已开始"确保 - 所有正在进行的先前命令已完成
• • 所有未来正在进行的命令将被记录

Note： 鹏弟对这部分不了解，故直译供参考。

预复制阶段：目标端准备

目标端预条件

• • 可用的次级控制器
• • 可用的主机端VM资源

用于初始化目标SSD的标准NVMe命令

• • 初始化所需的任何队列和IO命令结构
• • 创建NS

上图说明了一种可能的流程，但存在其他选项

• • 例如：由VMM在Ctlr G上创建共享NS

预复制阶段：初始NS迁移（两种实现方式）

选项1：

• • VMM复制整个VM NS
• • 对于稀疏写入的数据不是最优选择（图右所示）

选项2：VMM向主控制器发送：获取LBA状态

• • 粒度：由SSD设置（按实际场景选择）

主控制器

• • 返回结果，带有粒度限制
• • 任何非解除分配的数据状态都作为已映射返回

VMM - 对于每个已映射的LBA状态 - 作为次级控制器NS的读取提交

预复制阶段：向目标端进行初始NS迁移

• • VM的NS映射
• • 返回每个粒度的LBA状态
• • VMM为每个连续的已映射LBA范围向次级Ctlr的NS提交读取请求
• • 新NS的填充不依赖于源SSD的粒度

预复制阶段：增量数据复制

持续进行

• • VM继续对源NS进行读/写操作
• • 源主控制器X继续向VMM记录所有写入操作
• • 从源SSD到目标SSD的复制需要时间

源驱动器视角

• • 经历了从源NS到目标NS的初始复制读取
• • 继续经历来自VMM解析已发布MQE的额外读取
• • VMM正在继续跟上VM的活动
• • 数据被写入目标次级控制器NS

注意：未讨论内存跟踪

• • NVMe-oF聚焦的功能
• • 企业处理器在其IOMMU中具有此能力
• • 建议对缺乏此功能的系统进行完整的内存复制

暂停和复制阶段：暂停

VMM决定完成/执行迁移

• • VMM向主控制器发出暂停命令

暂停命令流程

• • 次级控制器停止获取新命令
• • 次级控制器完成所有正在执行的命令
• • 成功或错误都可接受 - 所有CQE正确返回给VM
• • 包括任何用于日志记录的MQE
• • 主控制器向VMM完成暂停命令
• • 在MQ中记录此成功暂停

暂停状态摘要

• • VM的SQE/CQE可能在SQ/CQ中

源SSD

• • 必须准备好潜在的恢复命令
• • 可能由于系统错误
• • 概念上，恢复/启动在源和目标上的行为应该相同
• • 例外：源SSD将继续日志记录
• • 如果不恢复，预期次级控制器将被重置

VMM负责：

• • 解析所有剩余MQE
• • 将任何剩余数据复制到目标次级控制器NS

后复制阶段

复制最终数据和迁移控制器状态

MQ解析中的最终数据复制迭代

获取/设置控制器状态

• • 将控制器Y的状态读出到VMM
• • VMM将控制器H的状态写入目标SSD

VMM将迁移VM

从SSD角度看恢复操作

• • 相同行为：
• • 向控制器X发送恢复控制器Y命令
• • 向控制器G发送恢复控制器H命令
• • 一个差异：控制器G不太可能在控制器H上启用了日志记录

标准NVMe流程

• • 源VMM将清理并重置控制器Y和NS

总结

文章梳理跨数据中心，Data 动态迁移过程，区分：预复制、暂停/复制和后复制三个阶段，过程中各组件工作流。

AI训练场景的数据访问，一直是数据平台和软件定义存储厂商关注的热点。应用侧倾向于移动计算（如VAST的容器计算方案），将计算引擎分发到指定数据中心，避免数据规模复制（计算完的过程数据仍需远程复制）；或基于全局文件系统，构建满足一致性要求的高效元数据服务。

上述场景都免不了跨地域数据复制问题，区别在于量的多少，SSD主控层面的在线迁移增强，能一定程度优化数据传输效率，减少计算资源消耗。

只有真正理解海外云厂商商业模式和挑战（倾听客户声音），才能理解SSD在线迁移其实是个真实、具体的问题。