中国内核开发者大会:云平台热迁移技术优化与实践

云平台热迁移技术优化与实践

中国内核开发者大会云和服务器分论坛回放：https://live.csdn.net/room/Hansen666666/OzVSYgu0

能力价值

基本逻辑：

• 虚拟机在业务不断的前提下，实现计算/存储/网络迁移到新的虚拟机。
• 基本流程分为 建立跟踪/迭代拷贝/停机迁移 三步。

应用场景

• 固件更新
• 硬件维护
• 机房规整
• 资源调度规整
• 节能环保

业务要求

• 迁移成功率
• 迁移感知度 – （迭代拷贝/建立跟踪）持续影响
• 迁移感知度 – （停机迁移）停机影响

行业痛点

痛点	解法
迁移前：虚拟机带宽能力大，迁移成功率低	脏页、负载、带宽预估模型
迁移迭代时：热迁移能力能覆盖的规格与负载范围窄	大带宽支持能力
迁移迭代时：热迁移建立跟踪时业务感知大	TDP预构建能力
迁移完成时：热迁移停机时间	停机阶段设备处理优化

解决方案

脏页、负载、带宽评估

内存脏页评估：

• 内存带宽：始终大于等于真实值，采集无额外开销，会增加单核IPI中断/s。
• page sampling：数值精确，采集存在低开销，且guest tdp页大小受限制。

磁盘脏页评估：

• 流量统计：始终大于等于真实值，采集无额外开销。

迁移带宽：

• min{cpu_to_bandwidth(空闲负载), 源端空闲带宽, 目的端空闲带宽}
• 理论迁移时间 = (内存总量 + 磁盘总量) / (迁移带宽 – 内存脏页速率 – 磁盘脏页速率)

迁移时机：

• 服务器业务具备周期性原则，通过2周内数据来预估当日低负载。

迁移时评估：

• 实时带宽流量反馈机制

大带宽能力支持

大带宽多流multifd全平台支持 - multifd

• 内存迭代仍由热迁移线程主导
• 协议协商由主线程进行主导
• 发送线程作为网络资源池供主线程进行调用。
• 100G更高网络环境可基于DPDK实现发送线程。
• 提升特定cpu利用率下发送数据量，从而提升效率。
• 宿主机数据发送offload实现

大带宽多流multifd全平台支持 – 迭代保序

问题:热迁移数据流始终需要保证新一轮的迭代不能覆盖旧一轮的数据，因此实际应用中需要有机制去保证顺序。

方案：使用MULTIFD_FLAG_SYNC / RAM_SAVE_FLAG_EOS机制保序。

对比：

• 激活multifd后，内存不再需要额外拷贝。
• 基于DPDK实现multifd后，4C即可达到带宽极限。
• 协议层面差异

停机阶段设备处理优化

原生qemu热迁移完成后满足 pending_size < s->threshold_size && can_switchover后会直接触发停机，并且进入savevm_state逻辑。

问题1：Onflight io下刷时间不确定，受限于块设备能力。

问题2：网络切换有损，与外部路由无协同方案。

解决方案：存储：停机前设定半停机状态，此刻只停io，待pending io下刷完毕后一次性停机切换。网络：网络为实现无损耗切换，采用中继方案继续保持通信。

TDP 预构建能力

实际情况：

• 虚拟机为追求性能最大化，会采用最高级别TDP页表
• 进行脏页跟踪时，只能采用最低级别的TDP页表，追求细粒度。
• 热迁移阶段，存在重构TDP页表代价

挑战：内核kvm->mmu_lock属于mmu的一把关键spinlock，针对mmu的任何操作都会涉及到这把锁，热迁移的时候，会产生大量vcpu排队。

解决方案：异步线程，针对kvm->memslot/hpa_root，进行异步拆解，构建完整4K页表后统一通知vcpu替换TDP页表。

最终效果：除了KVM_REQ_MMU_RELOAD，源端不会产生额外退出。目的端在迁移激活后，不会产生额外退出。

脏页track过程中 – intel:PML，AMD:仍涉及退出

落地效果

实际落地的迁移数据