> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/cn/elastic-compute/best-practice/what-happens-if-a-cloud-host-fails-instance-failover-and-recovery-explained.md).

# 云主机发生故障时会怎样？实例故障转移与恢复详解

## 简介

Zenlayer Elastic Compute 的设计目标是在底层硬件发生故障时依然保持服务连续性。本指南介绍云主机发生故障时的处理流程、实例故障转移的运作方式，以及用户应了解的恢复操作。

#### 本指南解答以下问题：

* 如果我的实例所在物理主机发生故障，会发生什么？
* 我的实例会自动重启吗？
* 硬件故障期间，我的数据会丢失吗？
* 恢复需要多长时间？
* 如何设计部署架构以实现更高可用性？

## 适用范围与运营模式

自动故障转移用于**计划外的未知故障**。对于**计划内的已知风险操作**（例如主机固件升级或核心软件升级），ZEC 会进行风险评估，直接执行热迁移，并向客户发送热迁移活动通知。

标准操作分类：

* 已知风险操作：计划内热迁移。
* 未知事件：自动故障转移。

***

## 1. 恢复时间基准

恢复流程分为三个阶段：**故障确认 + 自动故障转移 + 上线验证**。

| 阶段     | 说明                        | 典型时长（参考值）                      |
| ------ | ------------------------- | ------------------------------ |
| 故障确认   | 交叉核验多个健康信号，区分瞬时不稳定与真实主机故障 | 约 `3-5` 分钟                     |
| 自动故障转移 | 选择健康目标主机并完成实例迁移           | 通常 `2-8` 分钟；大规模影响时可达 `8-15` 分钟 |
| 上线验证   | 验证实例启动状态及服务可用性            | 约 `1-5` 分钟                     |

运营说明：

* 单主机故障、受影响实例数量有限、备用容量充足：端到端通常 `5-12` 分钟。
* `8-15` 分钟主要出现在影响规模较大、需要分批恢复的情况下。
* `15+` 分钟为非标准情形，通常与大规模/复杂故障条件或人工接管有关。

### 1.1 对比：自动故障转移 vs. 主机重启与重新启动

| 恢复路径          | 典型行为                                    | 时间特征                                                                         |
| ------------- | --------------------------------------- | ---------------------------------------------------------------------------- |
| 自动故障转移        | 工作负载迁移至健康主机并完成上线验证                      | 标准单主机场景下通常 `5-12` 分钟                                                         |
| 在同一主机上重启并重新启动 | 等待故障主机完成电源循环、硬件初始化、操作系统及服务恢复，然后重新启动工作负载 | 通常较慢且不确定性更高；在 Dell 服务器上，仅硬件启动（包括 iDRAC/硬件初始化）通常需要 `10+` 分钟，之后才能进行操作系统和工作负载恢复 |

运营含义：

* 对于未知主机事件，自动故障转移恢复服务可用性的速度通常快于等待主机重启并在原主机上重新启动。

***

## 2. 故障识别方式

ZEC 采用**持续观测 + 多信号验证 + 冷却窗口**模型：

* 持续观测：故障转移不会由单次探测失败触发。
* 多信号验证：综合评估网络可达性、控制平面可达性与主机响应能力。
* 冷却窗口：在最终确认前设置短暂稳定期，用于过滤瞬时抖动。

***

## 3. 故障决策流程

***

## 4. 恢复时间线

影响时长的主要因素：

* 受影响实例数量（单实例 vs. 批量规模）
* 实例规格组合（较大规格的 SKU 需要更严格的放置匹配）
* 实时备用容量（备用容量越充足，恢复时间通常越短）
* 故障范围（单主机故障通常比较大范围事件更快恢复）

***

## 5. 各场景恢复时间

| 场景                                    | 预期恢复时间         |
| ------------------------------------- | -------------- |
| 标准场景：单主机故障、受影响实例有限、容量充足               | 通常 `5-12` 分钟   |
| 中等规模：受影响实例较多，需分批恢复                    | 通常 `8-15` 分钟   |
| 大规模/复杂场景：批量大、大规格 SKU 占比高、容量紧张，或触发抑制机制 | `15+` 分钟，或人工接管 |

建议的沟通基准：

* 大多数单点主机故障在 `5-12` 分钟内恢复。
* `8-15` 分钟对应中等规模的分批恢复。
* `15+` 分钟视为非标准的大规模或复杂事件路径。

***

## 6. 已知风险操作的计划内热迁移

对于已知风险的主机操作，ZEC 在执行主机变更前采用直接热迁移方式。

{% stepper %}
{% step %}

#### 识别并评估风险

识别已知风险的主机操作并完成风险评估。
{% endstep %}

{% step %}

#### 验证前提条件

验证目标容量及迁移前提条件。
{% endstep %}

{% step %}

#### 通知客户

发送热迁移客户通知。
{% endstep %}

{% step %}

#### 执行迁移

在工作负载保持在线的情况下执行热迁移。
{% endstep %}

{% step %}

#### 确认清空

确认源主机已完成清空。
{% endstep %}

{% step %}

#### 执行主机操作

执行主机操作（固件/核心软件）。
{% endstep %}

{% step %}

#### 变更后验证

运行变更后健康验证，并将主机归还至服务池。
{% endstep %}
{% endstepper %}

### 简化热迁移流程

***

## 7. 块存储服务为何能实现快速故障转移

主机级快速故障转移依赖于计算与存储的解耦。采用块存储服务后：

* 虚拟机系统盘与数据盘存储于共享网络块存储卷上。
* 故障转移期间，计算节点发生变更，而磁盘状态保持可复用。
* 恢复可在健康主机上直接进行，无需从主机本地磁盘重建。

若存储为主机本地存储，存储状态将与故障节点绑定，快速故障转移的难度将大幅增加。目前，**所有 ZEC 实例均基于块存储服务**，因此该模型适用于整个平台。

***

## 8. 自动恢复操作与对外可见的结果状态

核心自动化操作：

{% stepper %}
{% step %}

#### 故障隔离

将不健康主机从调度路径中移除。
{% endstep %}

{% step %}

#### 基于优先级的恢复

优先恢复此前处于运行状态的实例。
{% endstep %}

{% step %}

#### 安全状态转换

在主机切换期间执行一致性控制。
{% endstep %}

{% step %}

#### 故障转移后验证

迁移完成后确认启动状态及上线状态。
{% endstep %}
{% endstepper %}

对外可见的结果状态：

* **完全恢复**：所有受影响实例均已恢复。
* **部分恢复**：大多数实例已恢复，少数实例进入人工处理流程。
* **人工接管中**：抑制机制或异常条件需要人工主导恢复。