启动配置固化 fstab 开机自启动持久化-云服务器 ECS(ECS)-阿里云帮助中心

本文介绍如何为云服务器ECS实例配置持久化的云盘挂载和业务进程自启动，并建立配套的监控告警体系，确保实例在非预期重启后能自动恢复服务，提升系统稳定性。

业务场景

云服务器ECS实例可能因操作系统OOM（Out of Memory）、宿主机宕机等原因出现非预期重启。实例重启后，操作系统内部的临时配置，例如手动挂载的云盘、手动启动的业务进程等，并不会自动恢复。这可能导致依赖数据盘的服务无法启动，或核心业务长时间中断，影响业务的连续性和可用性。

方案架构

本方案旨在通过配置固化，将这些临时操作转变为永久配置，使实例具备在异常重启后自动恢复业务运行状态的能力。同时，通过组合使用操作系统内置功能与阿里云监控服务，构建一个具备自动恢复和监控告警能力的弹性系统。

云盘挂载固化：利用 Linux 的 /etc/fstab 文件，将云盘的挂载信息永久记录。通过使用设备的 UUID（通用唯一标识符）而非设备名（如 /dev/vdb）进行配置，避免因设备名在重启后可能发生变化而导致的挂载失败。
业务进程固化：采用 systemd 服务管理业务进程。systemd 是现代 Linux 系统的标准初始化系统，能够实现服务的开机自启动，并在服务异常退出时自动拉起，确保业务进程的持续运行。
状态监控与验证：
- 监控：配置云监控服务，对云盘挂载点、核心业务进程以及实例重启事件进行监控。当自动恢复失败或发生异常时，能够及时发送告警。
- 验证：使用云助手的故障演练插件，在非生产环境中模拟实例宕机，以端到端地验证配置固化和监控告警的有效性。

实施步骤

以下步骤将引导完成从云盘挂载、进程自启动到监控告警和最终验证的完整配置。

步骤一：配置云盘开机自动挂载

此步骤的目标是确保数据盘在实例重启后能够被自动挂载到指定目录。推荐使用 UUID 来标识云盘，因为它在实例生命周期内保持不变，比设备名（如 /dev/vdb1）更可靠。

备份 fstab 文件
在修改系统关键配置文件 /etc/fstab 之前，务必执行备份，以便在配置错误时能够快速恢复。
```
sudo cp /etc/fstab /etc/fstab.bak
```
获取云盘的 UUID
运行 blkid 命令获取目标分区的 UUID。此处以分区 /dev/vdb1 为例。
```
sudo blkid /dev/vdb1
```
命令会返回类似如下的输出，记录其中的 UUID 值。
```
/dev/vdb1: UUID="f1645951-134f-4677-b5f4-c65c71f8f86d" TYPE="ext4" PARTUUID="..."
```
将挂载信息写入 /etc/fstab
编辑 /etc/fstab 文件，在文件末尾添加新的挂载条目。
```
sudo nano /etc/fstab
```
按照以下格式添加新行，将 <Your-UUID>、<挂载点> 和 <文件系统类型> 替换为实际值。
```
# <设备>         <挂载点>    <文件系统类型>    <挂载选项>      <dump> <pass>
UUID=<Your-UUID>  /mnt        ext4        defaults,nofail   0      2
```
关于 nofail 挂载选项：
- 作用：nofail 选项确保即使该云盘因故无法挂载，实例也能正常启动，而不会卡在启动过程中等待挂载。
- 适用条件：推荐为所有非系统关键的数据盘添加此选项。
- 风险提示：使用此选项后，挂载失败时，系统不会在启动时报错。因此，请在后续步骤中对挂载点进行监控，以便及时发现并处理挂载问题。
验证自动挂载配置
在不重启实例的情况下验证 /etc/fstab 配置的正确性。
```
# 卸载当前挂载点，例如 /mnt
sudo umount /mnt

# 重新加载 /etc/fstab 中的所有条目
sudo mount -a

# 检查挂载是否成功
sudo lsblk -f
```
如果 lsblk -f 命令的输出显示目标设备已正确挂载到指定目录，则表示配置成功。如果 mount -a 命令报错，说明 /etc/fstab 文件配置存在问题。此时，可通过VNC连接实例，然后执行 sudo mv /etc/fstab.bak /etc/fstab 命令从备份中恢复，以确保实例能够正常重启。

步骤二：配置业务进程开机自启动与服务保活

此步骤的目标是使用 systemd 将业务进程注册为系统服务，实现开机自启动和异常退出后自动重启。

方法一：systemd（推荐）：提供更强大、透明和可定制的服务管理能力，是生产环境的最佳实践。配置虽稍显复杂，但提供了对服务依赖、运行用户、环境变量等方面的精细控制。
方法二：使用云助手插件进行服务保活：云助手的 ecs-tool-servicekeepalive 插件能自动生成 systemd 配置，操作简单。适用于对服务管理细节要求不高的简单场景。

本教程采用 systemd 手动配置方式。

（可选，推荐）为应用创建专用用户
为了遵循最小权限原则，避免使用 root 用户运行业务进程。
```
sudo groupadd myapp
sudo useradd -r -s /bin/false -g myapp myapp
```

创建 systemd 服务配置文件

在 /etc/systemd/system/ 目录下创建一个以 .service 结尾的服务文件，例如 myapp.service。

sudo nano /etc/systemd/system/myapp.service

将以下模板内容粘贴到文件中，并根据实际情况修改。

[Unit]
Description=My Application Service
# 定义服务在网络和远程文件系统挂载就绪后启动
After=network-online.target remote-fs.target
Wants=network-online.target
# 如果服务依赖于步骤一中挂载的云盘（例如 /mnt），请取消下一行注释
# RequiresMountsFor=/mnt

[Service]
# --- 安全配置 ---
# 使用专用用户和组运行
User=myapp
Group=myapp

# --- 运行配置 ---
# 进程的工作目录
WorkingDirectory=/opt/myapp
# 启动命令的绝对路径及参数
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.json

# --- 自动重启策略 ---
# 仅在服务非正常退出（例如崩溃）时重启
Restart=on-failure
# 两次重启之间的间隔时间
RestartSec=5s

[Install]
# 定义服务所属的 target，multi-user.target 表示在多用户模式下启用
WantedBy=multi-user.target

启用并启动服务

执行以下命令使 systemd 重新加载配置、启用服务的开机自启动，并立即启动该服务。

# 重新加载 systemd 配置
sudo systemctl daemon-reload
# 启用开机自启动
sudo systemctl enable myapp.service
# 立即启动服务
sudo systemctl start myapp.service

验证服务状态
检查服务的运行状态，确保其已成功启动并已启用开机自启动。
```
sudo systemctl status myapp.service
```
如果输出中的 Active 字段显示为 active (running)，且 Loaded 行包含 enabled，则表示配置成功。

步骤三：配置监控与告警

配置固化后，建议建立配套的监控体系，以便在自动恢复机制失效时第一时间收到告警并介入处理。

挂载点可用性监控
- 目的：确保数据盘挂载点（如 /mnt）始终可用。
- 实现：使用脚本（df -h）定期检查关键挂载点是否正常，发现挂载丢失及时告警。
关键进程存活监控
- 目的：确保核心业务进程（如 myapp）运行。
- 实现：使用云监控的进程监控功能。
实例异常重启监控
- 目的：感知系统事件。
- 实现：使用云监控的系统事件报警功能。

更多监控配置信息，请参见云监控。

步骤四：验证配置固化效果（宕机演练）

完成所有配置后，必须通过模拟故障来验证整个自愈和告警体系是否按预期工作。

重要

故障演练会导致实例重启和业务中断，请务必在非生产环境或可接受的维护窗口内执行。

执行故障注入
使用云助手插件 ecs-fault-oscrash 模拟内核 Panic，触发实例的非预期重启。
```
sudo acs-plugin-manager --exec --plugin ecs-fault-oscrash --params inject
```
等待实例重启
命令执行后，实例将立即崩溃并重启。等待约3-5分钟后，重新连接实例。
端到端验证
- 检查云盘挂载：执行 lsblk -f，确认数据盘已自动挂载。
- 检查业务进程：执行 systemctl status myapp.service，确认业务服务已自动启动并处于 active (running) 状态。
- 检查监控告警：登录云监控控制台，检查是否收到事件告警。