Google Cloud VM 自动重启怎么配置，服务器发生故障后如何提高恢复能力

Google Cloud 的 Compute Engine VM 出现故障以后，能不能自动恢复，不能只看一个“Automatic restart”开关。自动重启解决的是单个 VM 因主机故障、Compute Engine 终止等事件失去运行状态以后重新启动的问题；它解决不了应用程序本身已经死掉、数据库损坏、整个 zone 不可用或者管理员误删资源等问题。

要设计一套可靠的云服务器恢复体系，需要把故障划分成不同层级：VM 所在宿主机发生故障，虚拟机操作系统崩溃，应用进程失效，整个 zone 出现故障，以及数据本身发生损坏。不同故障应该由不同机制处理。Compute Engine 的 Automatic Restart、Host Maintenance、Managed Instance Group Autohealing、Regional Persistent Disk、Load Balancer 和 Backup and DR 分别解决不同层次的问题，不能把它们当成同一个功能。

Compute Engine 的 Automatic Restart 并不是默认关闭

原稿中“Automatic Restart 默认关闭，需要手动开启”的说法已经不准确。

对于普通 Compute Engine 实例，automaticRestart 默认就是 true。Google 当前文档说明，标准 VM 默认配置为在 Compute Engine 因主机错误或其他符合条件的事件终止实例后自动重新启动；Spot VM 和旧的 preemptible VM 不支持这种自动重启。

因此，对于普通 VM，真正需要检查的不是“有没有开启过自动重启”，而是当前实例的 scheduling 配置是否符合预期。

使用 gcloud 可以查看和设置：

gcloud compute instances describe VM_NAME \
--zone=ZONE \
--format="yaml(scheduling)"

如果需要明确设置自动重启，可以使用：

gcloud compute instances set-scheduling VM_NAME \
--zone=ZONE \
--restart-on-failure

对应的 API 字段是：

scheduling.automaticRestart = true

Google 当前文档还提供 hostErrorTimeoutSeconds，用于控制检测到宿主机错误以后多久采取恢复动作，可设置的范围是 90 到 330 秒，以 30 秒为步长。

不过，Automatic Restart 有一个非常重要的边界：它不是“发现服务器什么都不正常就自动重启”。

Google 明确区分 Compute Engine 触发的终止与用户或 Guest OS 主动执行的关机。比如用户执行 sudo shutdown 导致的关机，不会因为开启 automaticRestart 就被当成故障重新启动；整个 zone 发生中断时，也不能依靠这个开关跨 zone 把 VM 救回来。

因此，Automatic Restart 更准确的定位是“基础设施层面的实例恢复机制”，而不是完整的故障自愈系统。

Host Maintenance 和 Automatic Restart 是两个不同问题

很多文章把 Google Cloud 的主机维护和自动重启混成一件事，这是理解 Compute Engine 恢复机制时很容易踩的坑。

标准 Compute Engine 实例默认使用 MIGRATE。发生支持 Live Migration 的宿主机维护事件时，Google Cloud 会尝试把 VM 迁移到另一台宿主机，而不是先把 VM 停下来再依靠 Automatic Restart 恢复。

如果某类实例不支持 Live Migration，或者明确把 onHostMaintenance 设置成 TERMINATE，维护事件可能表现为 VM 被停止。此时，如果 automaticRestart=true，Compute Engine 可以在符合条件的情况下重新启动 VM。

所以配置高可用 VM 时，需要同时考虑两个 scheduling 属性：

onHostMaintenance
automaticRestart

前者决定宿主机维护时 VM 怎么处理，后者决定 Compute Engine 因符合条件的事件终止 VM 后是否自动重新启动。

这两个设置不是一个“故障重启按钮”的两个名称。

自动重启无法解决应用已经死掉的问题

假设 Linux VM 仍然处于 RUNNING 状态，但 Nginx、PHP-FPM、Java 服务或者自己的 API 进程已经崩溃。

对于 Compute Engine 来说，这台 VM 可能完全正常。CPU、磁盘和虚拟网络接口都还存在，实例状态仍然是 RUNNING。

Automatic Restart 在这里没有理由介入。

这就是应用层健康检查的重要性。

如果 Web 服务部署在 Managed Instance Group 中，可以配置 application-based health check。当健康检查确认某个 VM 上的应用没有按照预期响应时，MIG 可以把该实例标记为 unhealthy，并按照 autohealing 策略修复实例。Google 对 MIG Autohealing 的定义就是通过应用层健康检查判断 VM 是否正常，然后自动修复不健康实例。

这与 Load Balancer 的流量健康检查也不能简单混为一谈。

Load Balancer 的健康检查主要决定哪些后端可以继续接收流量；MIG Autohealing 则可以进一步把持续不健康的 VM 进行 repair。一个负责流量层面的后端选择，一个负责实例生命周期层面的修复。

真正需要自动恢复的 Web 服务器通常不应该只有一台 VM

如果业务非常重要，单台 VM 即使配置 Automatic Restart，也仍然存在明显的可用性窗口。

例如 VM 所在 zone 出现问题时，这台 VM 可能无法继续提供服务。此时你需要的不是“把同一台 VM 再启动一次”，而是让业务本身拥有多个实例。

Managed Instance Group 就是这种架构的基础组件之一。

MIG 根据 Instance Template 创建和管理一组 VM，并维护期望的实例数量。如果组内某个实例失败，MIG 可以重新创建实例；如果配置了 application-based autohealing，还可以根据应用健康状态判断实例是否应该被修复。Regional MIG 则可以把实例分布到同一 region 的多个 zone，从而减少单一 zone 故障对业务造成的影响。

典型 Web 服务架构应该考虑：

Global/Regional Load Balancer
|
Managed Instance Group
|
多个 VM 实例
|
Persistent storage / Database

这里每一层承担的职责不同。Load Balancer 负责流量，MIG 负责实例数量和实例生命周期，健康检查负责判断后端是否正常，数据库和持久化存储负责数据。

真正的高可用不是把一个 VM 的“自动重启”开关打开以后就结束。

Persistent Disk 不是 RAID 1，Regional Persistent Disk 才是跨 zone 的复制方案之一

原稿中“Persistent Disk 配置 RAID 1，通过 Disk Type 设置”是不正确的。

Google Cloud 的 Persistent Disk 是网络连接的持久化块存储，并不是传统物理服务器里由操作系统自己配置的 RAID 1。Google 当前文档提供的 Regional Persistent Disk 是一种跨两个 zone 同步复制的存储方案，可以针对单个 zone 故障提供磁盘数据层面的高可用能力。

Regional Persistent Disk 的复制是 Google Cloud 存储服务提供的能力，而不是用户在 Linux 中运行 mdadm 配置 RAID 1。

Hyperdisk Balanced High Availability 也提供跨两个 zone 的同步复制能力。具体选择哪一种，需要结合实例类型、性能需求、共享访问方式和应用架构判断。

另外，“Replica Count”也不能被理解成普通 Persistent Disk 的通用配置项。Google Cloud 的不同存储产品拥有不同的复制和高可用模型，不能用传统本地服务器 RAID 的概念直接套到所有 Cloud Disk 上。

Local SSD 恰恰不应该作为持久化恢复方案

原稿把 Local SSD 放在服务器容灾和数据持久化建议中，这一点需要特别修正。

Local SSD 的定位是高性能、低延迟的临时本地存储，而不是普通 Persistent Disk 的替代品。需要持久化的数据不应该因为“Local SSD 很快”就直接放在那里作为唯一副本。

Local SSD 可以非常适合：

临时计算数据、缓存、scratch space、部分数据库临时文件、AI 数据预处理以及可以重新生成的数据。

但如果 VM 因故障被替换，Local SSD 上的数据生命周期和 Persistent Disk 完全不同。因此，系统设计应该先判断数据是不是可以丢失，再决定是否使用 Local SSD。

对于需要跨 VM、重建后仍然存在的数据，应该优先考虑 Persistent Disk、Hyperdisk、Cloud Storage 或数据库自身的持久化机制。

磁盘性能也不能简单理解成 SSD 一定比 HDD 快

Google Cloud 当前推荐在支持的情况下优先考虑 Hyperdisk；Persistent Disk 仍然是广泛使用的持久化块存储。Hyperdisk 和 Persistent Disk 都属于网络连接的块存储，并不是直接焊在 VM CPU 上的本地物理磁盘。

存储选型应该根据 IOPS、吞吐量、访问模式、容量、延迟、可用性以及 VM 本身能够提供的存储性能上限来决定。

因此，“数据库使用 NVMe SSD，普通服务器使用 HDD”这种分类过于粗糙。现代 Google Cloud 存储体系中，Hyperdisk、Persistent Disk、Local SSD 的性能模型和生命周期都不同，不能只用 SSD/HDD 两个标签判断。

Backup 和高可用解决的是完全不同的问题

这是云架构里非常重要的一条原则。

高可用解决的是：

“机器坏了以后，服务能不能继续运行？”

备份解决的是：

“数据坏了以后，能不能恢复到过去某个正确状态？”

假设数据库中的一批记录被错误删除，或者攻击者把文件全部加密。

MIG 可以重新创建 VM。

Load Balancer 可以把流量转给另一台 VM。

Automatic Restart 可以重新启动 VM。

但这些机制都不会自动把错误删除的数据恢复回来。

这就是为什么必须单独建立 Backup and Disaster Recovery 体系。

Google 当前的 Backup and DR 可以通过 Backup Plan 和 Backup Vault 为 Compute Engine 实例或磁盘配置定期备份。Backup Vault 提供隔离、不可变和不可删除的备份存储能力，并支持按照备份计划设置频率和保留周期。

因此，与其在文章里写“Cloud Backup API 实现分钟级数据保护”，不如根据实际业务定义 RPO。例如业务要求最多丢失 15 分钟数据，那么备份策略就应该围绕 15 分钟的 RPO 设计，而不是先假定一个所谓“分钟级”能力。

同样，RTO 也应该明确：发生故障以后，希望多长时间恢复服务。

Cloud Scheduler 不是天然的故障恢复控制器

原稿提出“监控发现故障后触发 Cloud Scheduler，再执行恢复脚本”，这种设计并不是不能做，但不能作为 Google Cloud VM 自动恢复的默认架构。

Scheduler 更适合按照时间触发任务。

如果需要根据事件触发自动化动作，更合理的设计通常会使用事件驱动架构。例如 Cloud Monitoring 产生告警后，可以进入通知或自动化处理链，再根据故障类型调用相应 API。

更重要的是，自动化脚本本身不能成为新的单点故障。

如果一个脚本判断“VM ping 不通，所以立即删除并重建”，很容易把暂时性的网络故障、应用启动慢、健康检查误判和真正的实例故障混为一谈。

生产系统的自动修复应该具有：

故障检测、故障确认、恢复动作、恢复验证、重试限制和审计记录。

否则自动化可能把一个小问题变成更大的事故。

Cloud Build 也不是 VM 故障以后自动重建服务器的必选组件

如果 VM 使用 MIG，实例模板已经定义了机器配置，MIG 本身就能够根据期望容量和实例生命周期管理 VM。发生实例故障时，不需要先让 Cloud Build 编译一个新服务器镜像，再重新部署一次。

如果企业采用 Infrastructure as Code，例如 Terraform、Deployment Manager 的替代方案或其他自动化部署体系，CI/CD 工具可以参与基础设施发布，但它与运行时故障自愈是两个不同层次的问题。

把 Cloud Build 放在每一次 VM 故障恢复路径中，反而可能增加恢复链路复杂度。

数据库更不能用“重新启动 VM”解决

如果应用依赖 Cloud SQL，数据库的高可用和备份应该交给 Cloud SQL 自己的架构和数据保护机制处理。

数据库发生故障时，需要考虑实例高可用、自动备份、时间点恢复、复制、事务日志、RPO 和 RTO，而不是简单执行一次 VM restart。

因为数据库的核心问题不是“服务器有没有开机”，而是“数据状态是否正确”。

这也是为什么 Web 层和数据库层应该分开设计。Web VM 可以通过 MIG 快速替换，而数据库则必须关注状态、事务、一致性和持久化。

监控指标不能用几个固定百分比解决

原稿中的“CPU 超过 80% 五分钟”“内存超过 90% 三分钟”“磁盘 I/O 超过 100ms 两分钟”等数字可以作为某些业务的示例，但不能写成通用 Google Cloud 故障标准。

CPU 90% 对一个 CPU 密集型批处理服务器可能完全正常。

CPU 30% 对一个延迟敏感的 API 服务也可能已经出现严重问题。

同样，磁盘延迟是否异常，需要结合磁盘类型、I/O 模式、队列深度和应用的延迟目标判断。

专业监控应该同时看基础设施和业务指标。例如 VM 层可以观察 CPU、内存、磁盘 I/O、网络吞吐；应用层则观察请求延迟、5xx 比例、连接池耗尽、线程池状态、队列长度、进程状态以及关键业务操作成功率。

对于 Web 服务，HTTP 500/502/503、P95/P99 延迟和有效请求率，往往比单独一个 CPU 百分比更接近用户实际感受到的故障。

如何判断一次 VM 重启到底发生了什么

Google Cloud 本身会记录系统事件。

当前 Compute Engine 文档中，compute.instances.automaticRestart 表示自动重启事件；如果是宿主机问题，日志中可能先出现 hostError，如果是维护导致的终止，则可能出现 terminateOnHostMaintenance。Guest OS 自己执行关机，则属于 guestTerminate。

因此，当服务器突然重启以后，第一步不应该只是登录 Linux 查看 uptime。

应该同时检查：

Compute Engine system events、实例 operations、Cloud Logging、Linux kernel log、systemd journal，以及应用自身日志。

Linux 中可以进一步检查：

journalctl -b -1

以及：

journalctl -k -b -1

查看上一次启动周期的系统和 kernel 日志。

如果涉及 Linux kernel panic、OOM Killer、文件系统错误、磁盘 I/O error 或应用崩溃，这些信息可能直接决定下一步应该修复 VM、调整应用，还是改变架构。

真正的高可用应该分层设计

如果只是个人网站或者内部工具，一台普通 Compute Engine VM 配合 Automatic Restart、持久化磁盘和可靠备份，已经可能足够。

如果是生产 Web 服务，则可以进一步采用 Load Balancer、MIG、application health check 和 autohealing，让单个 VM 故障不再直接等于服务中断。

如果业务不能承受单一 zone 故障，则应该考虑 Regional MIG、跨 zone 的持久化存储以及数据库层面的高可用。

如果业务不能承受数据误删除、勒索软件或应用逻辑错误，则必须加入独立的备份和恢复体系。

如果业务需要跨 region 灾难恢复，则需要进一步设计跨区域数据复制、备份存储、基础设施重建以及 DNS 或流量切换策略。

这几层分别解决的是不同问题：实例恢复、应用恢复、zone 级容灾、数据恢复和 region 级灾难恢复。

把它们全部压缩成“开启 Automatic Restart”是不够的。

Google Cloud VM 的自动重启功能本身并不复杂，真正困难的是判断什么故障应该重启、什么故障应该重建、什么故障应该切换流量、什么故障应该恢复数据，以及什么时候不应该让自动化继续执行。一个成熟的云平台不会试图用一个开关解决所有故障，而是让 Compute Engine 负责基础设施生命周期，让 MIG 负责实例组的容量和自愈，让 Load Balancer 负责流量切换，让持久化存储负责数据保存，让数据库负责一致性和恢复，让 Backup and DR 负责历史数据保护。只有这些机制按照故障边界组合起来，自动恢复才不会变成“服务器自己不断重启”，而会真正成为一套能够缩短故障时间、降低人工介入成本并控制数据损失范围的生产级恢复体系。