我第一次真正感受到“跨机房 GPU 弹性调度”的复杂性，是在香港科学园 5 楼冷气机房里蹲了整整一晚。凌晨两点，风扇的嗡鸣和 IB 光模块的绿灯让我清醒得不能再清醒——我们要把香港的 GPU 集群，通过 RDMA，和深圳的数据中心做实时容灾和弹性调度，而且是零中断。

我们现有的 GPU 训练与推理集群是基于 KVM + SR-IOV + NVIDIA A100 搭建的多租户环境，香港主机房和深圳 DR（灾备）机房之间的光纤专线实际 RTT 在 0.7~0.8ms 左右。目标是：

• 训练任务在香港运行时，深圳机房能随时接管；
• 推理服务具备实时弹性扩容能力，实现跨机房秒级调度；
• GPU 的热迁移尽可能零中断，或者延迟低于 200ms。

接下来的内容，是我在这次跨机房 GPU 容灾与弹性调度项目中的实战记录，包含真实的技术坑点与解决方案。

1. 跨机房网络与 RDMA 链路部署

1.1 网络物理架构

香港机房使用 Mellanox ConnectX-6 100Gb IB 网卡，深圳机房同配置，通过两对光纤专线做 L2 EVPN 扩展，最终实现 RoCEv2 的跨机房 RDMA。

香港 ↔ 深圳 双线路：主链路 RTT ~0.78ms，备用链路 RTT ~1.2ms

RDMA MTU：9000（必须配合大帧以降低 CPU 开销）

PFC（Priority Flow Control）：开启

ECN：实验后关闭，因为低 RTT 场景下反而导致丢包恢复慢

实战坑点：

机房温湿度对光模块性能影响明显

我在夜里巡检时发现香港机房某一条链路丢包率奇高，后来发现是光模块温度在 60℃ 以上，重新调整了机架散热才恢复稳定。

RDMA 跨城必须做流量隔离

我们专门在 Spine 交换机上给 RoCE 流量打了 DSCP=4 的 QoS，避免和普通 iSCSI 流量抢带宽。

2. GPU 热迁移策略与调度实现

2.1 KVM + SR-IOV 多租户 GPU 设计

GPU 虚拟化方案：

• GPU：NVIDIA A100 80G
• 驱动：R470 + vGPU Manager
• Hypervisor：KVM + QEMU 6.2
• GPU 直通：VFIO 直通 + SR-IOV vGPU

为了支持跨机房热迁移，我们采用了 vGPU 的保存/恢复机制，并结合 RDMA 进行状态镜像。

# 热迁移准备
virsh save --bypass-cache --verbose gpu-vm /mnt/rdma/gpu-vm-state
# RDMA 实时同步到深圳
rdma-copy /mnt/rdma/gpu-vm-state 10.0.0.2:/mnt/rdma/
# 在深圳恢复
virsh restore /mnt/rdma/gpu-vm-state

实测单卡迁移镜像约 6GB，通过 100Gb RDMA 链路大约 700ms 传完。

2.2 热迁移过程中的关键问题

GPU 显存镜像一致性

问题：跨机房热迁移时，显存更新频繁，如果没有页级追踪，容易出现推理错误或训练崩溃。

解决方案：开启 QEMU Dirty Page Tracking + vGPU Checkpoint，并在最终切换前做一次短暂的 IO 冻结（约 80ms）。

跨机房调度延迟

原因：RDMA 的镜像传输和调度器状态同步存在约 1ms 延迟。

解决方案：采用 主机 + 容器两级调度，在迁移前先在深圳预热容器环境，减少冷启动时间。

3. 弹性调度与自动容灾

调度框架采用自研的 Kubernetes + Volcano Scheduler 改造版，关键逻辑：

• 通过 Prometheus 实时采集 GPU 使用率；
• 当香港机房负载 >80% 或 RDMA 链路质量下降时，触发迁移；
• 深圳机房预热 Pod，拉取数据并建立 vGPU 镜像；
• 完成 GPU 热迁移或容器级冷迁移。

核心经验：

迁移前 5 秒，我们会通过 RDMA 做一次大规模状态同步，迁移成功率 >98%；

如果链路抖动 >2ms，则回退到冷迁移策略，保证任务不中断。

4. 跨机房 GPU 容灾实战总结

光纤和机房温控是底线，RDMA 稳定性依赖物理环境；

GPU 热迁移必须结合 显存页追踪 与 状态镜像，否则数据不一致；

跨机房弹性调度要有双模策略：

• 优先热迁移
• 链路异常时自动切换冷迁移

在这次项目完成后，我们实现了：

• 香港主训练，深圳秒级接管；
• 推理业务零中断迁移成功率 95%+；
• 跨机房 GPU 利用率提升 35%。

这是真正落地的跨城 GPU 容灾与弹性调度，不是 PPT 上的概念。