了解 Zenlayer Elastic Compute 如何通过自动实例故障转移与恢复机制应对云主机故障。掌握停机时间预期、数据安全保障及高可用最佳实践。
Zenlayer Elastic Compute 的设计目标是在底层硬件发生故障时依然保持服务连续性。本指南介绍云主机发生故障时的处理流程、实例故障转移的运作方式，以及用户应了解的恢复操作。
如果我的实例所在物理主机发生故障，会发生什么？
我的实例会自动重启吗？
硬件故障期间，我的数据会丢失吗？
恢复需要多长时间？
如何设计部署架构以实现更高可用性？
自动故障转移用于计划外的未知故障。对于计划内的已知风险操作（例如主机固件升级或核心软件升级），ZEC 会进行风险评估，直接执行热迁移，并向客户发送热迁移活动通知。
标准操作分类：
已知风险操作：计划内热迁移。
未知事件：自动故障转移。
恢复流程分为三个阶段：故障确认 + 自动故障转移 + 上线验证。
故障确认
交叉核验多个健康信号，区分瞬时不稳定与真实主机故障
约 3-5 分钟
自动故障转移
选择健康目标主机并完成实例迁移
通常 2-8 分钟；大规模影响时可达 8-15 分钟
上线验证
验证实例启动状态及服务可用性
约 1-5 分钟
运营说明：
单主机故障、受影响实例数量有限、备用容量充足：端到端通常 5-12 分钟。
8-15 分钟主要出现在影响规模较大、需要分批恢复的情况下。
15+ 分钟为非标准情形，通常与大规模/复杂故障条件或人工接管有关。
自动故障转移
工作负载迁移至健康主机并完成上线验证
标准单主机场景下通常 5-12 分钟
在同一主机上重启并重新启动
等待故障主机完成电源循环、硬件初始化、操作系统及服务恢复，然后重新启动工作负载
通常较慢且不确定性更高；在 Dell 服务器上，仅硬件启动（包括 iDRAC/硬件初始化）通常需要 10+ 分钟，之后才能进行操作系统和工作负载恢复
运营含义：
对于未知主机事件，自动故障转移恢复服务可用性的速度通常快于等待主机重启并在原主机上重新启动。
ZEC 采用持续观测 + 多信号验证 + 冷却窗口模型：
持续观测：故障转移不会由单次探测失败触发。
多信号验证：综合评估网络可达性、控制平面可达性与主机响应能力。
冷却窗口：在最终确认前设置短暂稳定期，用于过滤瞬时抖动。
影响时长的主要因素：
受影响实例数量（单实例 vs. 批量规模）
实例规格组合（较大规格的 SKU 需要更严格的放置匹配）
实时备用容量（备用容量越充足，恢复时间通常越短）
故障范围（单主机故障通常比较大范围事件更快恢复）
标准场景：单主机故障、受影响实例有限、容量充足
通常 5-12 分钟
中等规模：受影响实例较多，需分批恢复
通常 8-15 分钟
大规模/复杂场景：批量大、大规格 SKU 占比高、容量紧张，或触发抑制机制
15+ 分钟，或人工接管
建议的沟通基准：
大多数单点主机故障在 5-12 分钟内恢复。
8-15 分钟对应中等规模的分批恢复。
15+ 分钟视为非标准的大规模或复杂事件路径。
对于已知风险的主机操作，ZEC 在执行主机变更前采用直接热迁移方式。
主机级快速故障转移依赖于计算与存储的解耦。采用块存储服务后：
虚拟机系统盘与数据盘存储于共享网络块存储卷上。
故障转移期间，计算节点发生变更，而磁盘状态保持可复用。
恢复可在健康主机上直接进行，无需从主机本地磁盘重建。
若存储为主机本地存储，存储状态将与故障节点绑定，快速故障转移的难度将大幅增加。目前，所有 ZEC 实例均基于块存储服务，因此该模型适用于整个平台。
核心自动化操作：
对外可见的结果状态：
完全恢复：所有受影响实例均已恢复。
部分恢复：大多数实例已恢复，少数实例进入人工处理流程。
人工接管中：抑制机制或异常条件需要人工主导恢复。
最后更新于
