云主机迁移产品实践II

背景

本次介绍关于云迁移产品、以及核心部分设计逻辑，主要技术原理以Linux场景为主。

在产品设计阶段，参考过华为Rainbow、 万博智科Hypermotion 、英方、数腾等厂商工具。

产品设计

如下，主机迁移服务工作原理如下图，主要步骤如下所述：

1. 用户在源端服务器上安装迁移 Agent。
2. 源端服务器上的迁移 Agent 向主机迁移服务注册自身连接状态并将源端服务器信息上报到主机迁移服务，完成迁移可行性检查。
3. 用户在主机迁移服务控制台设置目的端，创建或指定规格一致的目标端
4. 迁移 Agent 向云迁移网关获取并执行主机迁移服务发送的迁移指令。
5. 全量迁移源端服务器系统盘和数据盘。
6. 动态增量同步源端服务器系统盘和数据盘。
7. 重配置并启动目的端，迁移完成。

块级同步

在底层数据同步方案选择上，建议以块级别同步技术为主。和文件级别相比，块级别同步有如下优点：

• 性能更好。要保证数十万、甚至百万的小文件的稳定同步相对较为耗时。
• 块级别同步相当于源盘的克隆，兼容性更好。无论是Linux还是Windows场景下， 部分用户文件，系统文件，隐藏文件等特殊文件会在同步后可能出现异常

全量同步

对于源端主机的全量迁移，就是将该主机的系统盘和数据盘的扇区数据传输到目标端。以 2MB/4MB/8MB 的分片进行传送。这样做的目的，不仅可以监控发送进度，而且不过多占用源端主机硬件资源，实现基于去重，压缩方式的可控发送。

需要说明的是，进行全量数据拷贝前，会开启对所有源端磁盘的写 IO 事件监控。这部分属于 Agent 拿到全量迁移指令后，自动开启的动作，用户无需操作。

增量同步

基本原理

对于Linux 磁盘IO流程，所有的块IO都需要经过通用块层（Block Layer）处理，这一层主要实现BIO调度逻辑，比如将一个大BIO请求拆分为多个小的BIO请求，将相邻的BIO请求合并，实现各种BIO调度等。增量的数据同步不，需要动态监测落盘完成的增量BIO，并将增量同步到目标端磁盘。

同步流程

全量迁移开始前，就会利用启动Agent的BIO监控服务对源端主机磁盘的写事件BIO监控。如下简要介绍的同步流程：

1. 在块层追踪物理磁盘上的 Write-BIO 成功的事件并记录 BIO 的 LBA 地址和偏移长度。
2. 以 2MiB/4MiB/8MiB 的粒度进行自定义磁盘 Bitmap 的刷新并记录
3. 每隔 10s/20s，读取 Bitmap 数据，进行检测，压缩，校验，传输。
4. 用户业务停止后，强制 SYNC 对源端进行缓存脏数据落盘，进行数据扫尾。
5. 等待一段时间无 Dirty Bitmap 生成时，目标端做最后驱动修复，重启目标端，迁移完成。

自定义 Bitmap 是记录磁盘数据变化的位图信息，如下图所示，2 号和 6 号分片数据发生变化，那么此时磁盘的 Bitmap 可以示意为 010001

BIO监测工具

• iosnoop
• blktrace
• bpftrace

简单对比几种工具的优缺点，可根据情况选择使用

名称	原理	依赖	说明、兼容性
iosnoop	基于ftrace的内核追踪框架	单个sh脚本	从内核2.6.27后，ftrace成为内核原生的调试工具兼容性较好，功能较为简单
blktrace	基于跟踪点（tracepoints）机制监测工具	二进制可执行文件	兼容性好，针对块设备 I/O 专用工具，能提供更详细的上下文（如进程、时间戳、I/O 大小等。功能较多，开销较大
bpftrace	基于ebpf扩展出来的trace工具	bcc	要求内核4.18以上，使用简单，功能全面，开销较小

结束END

先写这么多吧，下一章说说云主机迁移中，任务与指令的设计和流程。