한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

云宿主机维护/热迁移 Cloud host maintenance / live migration

原因 ID nic-host-maintenance · 主责 运维团队·系统运维 · 配合研发团队·服务器开发, 外部·外部

云厂商维护物理服务器（宿主机）时，会把虚拟机迁到其他宿主机（热迁移）或暂停片刻。这期间整台服务器停住，停住时间一长，连接就会断开。

起因云厂商因宿主机维护或预测到故障，把虚拟机迁到其他宿主机，或短暂挂起 → 结果迁移期间 CPU、内存、网络变慢，最后虚拟机会短暂完全停住（视厂商和方式而定，从不到 1 秒到 30 秒左右） → 画面表现 该服务器上所有人同时卡住，随后出现快进、瞬移；停住时间超过超时设置时大量掉线

症状: 卡住, 快进, 瞬移, 掉线
因素: 停顿, 丢包
谁会遇到: 全服
何时出现: 偶尔随机
负责方: 主责 运维团队·系统运维 · 配合研发团队·服务器开发, 外部·外部
研发团队要做的事: 超时设置要能扛住几秒的停顿；停顿后追赶的 tick 数设上限；经过时间用单调时钟（monotonic clock）计算；建立收到维护通知后保存进度、把玩家转移到其他服务器的流程。
运维团队要做的事: 订阅维护通知并设告警（Google Cloud maintenance-event、AWS 计划事件和 AWS Health、Azure Scheduled Events）；收到通知后在玩家少的时段提前替换服务器；厂商允许时调整维护时间（Azure Maintenance Configuration，部分类型的 AWS 计划事件）；把维护记录与故障记录对照。
外部要做的事: 向云厂商确认维护计划和影响范围；同一实例反复停顿时向厂商报告。
数值参考: Google Compute Engine 称热迁移的停顿通常远短于 1 秒，停顿期间系统时钟最多可能向前跳 5 秒。元数据中的 maintenance-event 值会在迁移前 60 秒变化（前提是此前至少查询过一次这个值）。Azure 不需要重启的维护几乎总是停顿不到 10 秒，偶尔（通用规格每 18 个月不超过一次）停顿约 30 秒，热迁移通常不超过 5 秒。Azure Scheduled Events 至少提前 15 分钟通知这类停顿（Freeze）。不过宿主机硬件突然故障时，会不发通知直接开始恢复。
监控图上: 断流后集中到达 · 服务器收发包数、tick 间隔
查看位置: 把停住的时刻与厂商的记录对照。Google Cloud 看审计日志中的 compute.instances.migrateOnHostMaintenance，AWS 看 describe-instance-status、AWS Health 中的计划事件，Azure 看活动日志（Activity Log）中的 Microsoft.Compute/virtualMachines/liveMigration/action，以及 VM 可用性指标（VmAvailabilityMetric）降到 0 的时刻。服务器内部看停住期间指标、日志是否出现空白，紧接着时钟是否跳变（时间同步日志）
确认依据: 整台服务器停住的时刻与厂商记录的维护、迁移时刻重合，那几秒内服务器内部的指标和日志全部空白
排除依据: 厂商记录中没有，且短暂停顿频繁反复，看“CPU 窃取时间（虚拟机）”。内核日志里有网卡重置记录，看“网卡驱动/固件问题”
确认手段: 运维工具即可确认（无需游戏代码）
深入了解: AWS 通过计划事件通知。system-reboot 表示会重启并迁到新的宿主机，system-maintenance 表示可能因网络、电源维护受到短暂影响。即使只停了几秒，这期间发给服务器的数据包没收到 ACK 的客户端会把重传等待时间逐次翻倍，所以恢复之后 TCP 连接可能还要停得更久（“TCP RTO 与指数退避”）。停住后恢复时时钟会跳变，可能引发“系统时钟跳变（NTP step）”；负载均衡器健康检查也可能失败，把这台服务器暂时摘除。无法迁移的实例（如 Google Cloud 的裸金属实例）在维护时会被停止或重启。

出处

Live migration process during maintenance events Google Cloud
热迁移的停顿通常远短于 1 秒；停顿期间系统时钟最多向前跳 5 秒；迁移期间磁盘、CPU、内存、网络性能会暂时下降；不做热迁移的 VM 在维护时会被终止（裸金属实例不支持热迁移）
Query metadata server for maintenance event notices Google Cloud
maintenance-event 元数据值在热迁移前 60 秒变化（前提是配置为热迁移，且上次维护后至少查询过一次这个值）
Monitor and plan for a host maintenance event Google Cloud
维护时审计日志中会留下 compute.instances.migrateOnHostMaintenance 系统事件
Scheduled events for Amazon EC2 instances AWS
计划事件的类型（system-reboot 为重启并迁到新宿主机，system-maintenance 为网络、电源维护带来的短暂影响）；通过邮件、AWS Health 通知；用 describe-instance-status 查看；部分类型可调整时间
Maintenance and updates Microsoft Azure
不需重启的维护几乎总是停顿不到 10 秒，偶尔（通用规格每 18 个月不超过一次）约 30 秒，热迁移通常不超过 5 秒；停顿后时钟自动同步；长 TCP 连接可能断开，或对端向停住的 VM 发送的数据按指数退避重传，使恢复更慢；负载均衡器健康检查约 10 秒内判定为不正常；用活动日志中的 Microsoft.Compute/virtualMachines/liveMigration/action 和停顿期间降为 0 的 VmAvailabilityMetric 确认；用 Maintenance Configuration 选择应用时间
Scheduled Events for Linux VMs in Azure Microsoft Azure
Freeze（停顿几秒，CPU 和网络可能停住）至少提前 15 分钟通知；宿主机硬件故障时不留通知期，直接开始恢复

云宿主机维护/热迁移 Cloud host maintenance / live migration

出处

相关原因

同一层：L6 服务器网卡

其他层中同样导致“卡住”的原因