Nova Suspend/Rescue 操作详解

sunsir

　　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 的流程图

• 向 nova-api 发送请求
  
• nova-api 发送消息
  
• 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 的日志分析留给大家练习。