Nova Suspend/Rescue 操做详解 - 天天5分钟玩转 OpenStack（35）

本节咱们讨论 Suspend/Resume 和 Rescue/Unrescue 这两组操做。

Suspend/Resume

有时须要长时间暂停 instance，能够经过 Suspend 操做将 instance 的状态保存到宿主机的磁盘上。当须要恢复的时候，执行 Resume 操做，从磁盘读回 instance 的状态，使之继续运行。

这里须要对 Suspend 和 Pause 操做作个比较：

相同点
二者都是暂停 instance 的运行，并保存当前状态，以后能够经过 Resume 操做恢复

不一样点
1. Suspend 将 instance 的状态保存在磁盘上；Pause 是保存在内存中，因此 Resume 被 Pause 的 instance 要比 Suspend 快。 2. Suspend 以后的 instance，其状态是 Shut Down；而被 Pause 的 instance 状态是Paused。 3. 虽然都是经过 Resume 操做恢复，Pause 对应的 Resume 在 OpenStack 内部被叫做 “Unpause”；Suspend 对应的 Resume 才是真正的 “Resume”。这个在日志中能体现出来。

Suspend/Resume 的日志分析留给你们作练习。

Rescue/Unrescue

从这节开始，咱们将讨论几种 instance 故障恢复的方法，不一样方法适用于不一样的场景。 首先咱们考虑操做系统故障。

有时候因为误操做或者忽然断电，操做系统重启后却起不来了。 为了最大限度挽救数据，咱们一般会使用一张系统盘将系统引导起来，而后在尝试恢复。 问题若是不太严重，彻底能够经过这种方式让系统从新正常工做。 好比某个系统文件意外删除， root 密码遗忘等

Nova 也提供了这种故障恢复机制，叫作 Rescue。 咱们来看看 rescue 的说明：

Rescue 用指定的 image 做为启动盘引导 instance，将 instance 自己的系统盘做为第二个磁盘挂载到操做系统上。

下面是 rescue instance 的流程图

1. 向 nova-api 发送请求

2. nova-api 发送消息

3. nova-compute 执行操做

下面咱们详细讨论每个步骤。

向 nova-api 发送请求

目前 Rescue 操做只能经过 CLI 执行

这里咱们没有指明用哪一个 image 做为引导盘，nova 将使用 instance 部署时使用的 image

查看日志 /opt/stack/logs/n-api.log

nova-api 发送消息

nova-api 向 Messaging（RabbitMQ）发送了一条消息：“Rescue 这个 Instance” 源代码在 /opt/stack/nova/nova/compute/api.py，方法是 rescue。

nova-compute执行操做

查看日志 /opt/stack/logs/n-cpu.log

关闭 instance

经过 image 建立新的引导盘，命名为 disk.rescue

启动 instance

Rescue 执行成功后，能够经过 virsh edit <instance_name> 查看 instance 的 XML 定义，disk.rescue 做为启动盘 vda，真正的启动盘 disk 做为第二个磁盘 vdb。

登陆 instance，经过 fdisk 也可确认。

此时，instance 处于 Rescue 状态

Rescue 操做让咱们有机会修复损坏的操做系统。 修好以后，使用 Unrescue 操做从原启动盘从新引导 instance。

Unrescue 的日志分析留给你们练习。