devstackd 计算Nova的虚机生命周期场景查看

短命女 2022-04-08 11:25 310阅读 0赞

### 一. shut off instance ###

**shut off 的流程为**  
1. 向nova-api 发送请求  
2. nova-api 发送消息  
3. nova-compute执行操作

第一步：向nova-api发送请求

*  从openstack界面关闭一个实例，查看nova-api的log文件，可以看到：  
    ![在这里插入图片描述][20181213155045485.png]  
    instance后面有实例ID。

第二步：nova-api 发送消息

*  nova-api 向 Messaging（RabbitMQ）发送了一条消息：“关闭这个 Instance” nova-api 没有将发送消息的操作记录到日志中，不过我们可以通过查看源代码来验证。 一提到源代码，大家可能以为要大海捞针了。其实很简单，上面日志已经清楚地告诉我们需要查看的源代码在 /opt/stack/nova/nova/compute/api.py 中，方法是 force\_stop。  
    ![在这里插入图片描述][20181213160143737.png]
 *  force\_stop 方法最后调用的是对象 self.compute\_rpcapi 的 stop\_instance 方法。 在 OpenStack 源码中，**以 xxx\_rpcapi 命名的对象，表示的就是 xxx 的消息队列。 xxx\_rpcapi.yyy() 方法则表示向 xxx 的消息队列发送 yyy 操作的消息。**

第三步：nova-compute执行操作

*  根据操作日志中的req-ID来查看n-cpu的log，可以看到nova-compute关闭instance的日志条目。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70]

### 二、开启一个instance ###

**start instance的流程**

1.  向nova-api发送请求
2.  nova-api 发送消息
3.  nova-compute 执行操作

第一步：向nova-api发送请求

*  从openstack界面进行启动实例的按钮点击，可以根据req-ID进行日志查看。![在这里插入图片描述][20181213155438754.png]

第二步：nova-api 发送消息

*  nova-api向message发送了一条消息：“启动这个 Instance”  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 1]
 *  self.compute\_rpcapi.start\_instance() 的作用就是向 RabbitMQ 上 nova-compute 的消息队列里发送一条 start instance 的消息。

第三步：nova-compute执行操作

*  根据req-ID查看n-cpu的log文件
 *  首先开始启动![在这里插入图片描述][2018121316263586.png]
 *  然后准备虚拟网卡
 *  准备instance的XML文件
 *  准备instance镜像文件
 *  成功启动  
    ![在这里插入图片描述][20181213163035955.png]

### 三、Soft/Hard Reboot ###

**区别：**

1.  soft reboot 只是重启操作系统，整个过程中，instance 依然处于运行状态。相当于在 linux 中执行 reboot 命令。
2.  hard reboot 是重启 instance，相当于关机之后再开机

**提示：**

1.  soft/hard reboot 在 nova-api 的日志里找不到，这是因为 /opt/stack/nova/nova/compute/api.py 的 reboot 方法中没有输出 log。  
    可以通过关键字 “nova.api.openstack.wsgi” 或者 “reboot” 搜索。
2.  在 nova-compute 的日志中可以看到 “soft reboot” 和 “hard reboot” 二者有明显的区别。

### 四、Lock /Unlock ###

*  为了避免误操作，比如意外重启或删除 instance，可以将 instance 加锁。
 *  对被加锁（Lock）的 instance 执行重启等改变状态的操作会提示操作不允许。
 *  执行解锁（Unlock）操作后恢复正常。  
    查看日志：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 2]

### 五、terminate (删除instance) ###

**删除instance的流程**

1.  向 nova-api 发送请求
2.  nova-api 发送消息
3.  nova-compute 执行操作  
    (1）关闭instance  
    (2) 删除instance的镜像文件  
    (3) 释放虚拟网络等其他资源

### 六、Pause/Resume（暂停instance/恢复) ###

**暂停instance流程**

*  向 nova-api 发送请求
 *  nova-api 发送消息
 *  nova-compute 执行操作
 *  有时需要短时间暂停 instance，可以通过 Pause 操作将 instance 的状态保存到宿主机的内存中。当需要恢复的时候，执行 Resume 操作，从内存中读回 instance 的状态，然后继续运行 instance。

### 七、 Suspend/Resume ###

*  有时需要长时间暂停 instance，可以通过 Suspend 操作将 instance 的状态保存到宿主机的磁盘上。当需要恢复的时候，执行 Resume 操作，从磁盘读回 instance 的状态，使之继续运行。  
    **相同点**
 *  两者都是暂停 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”。这个在日志中能体现出来。

### 八、Rescue/Unrescue ###

**instance故障**

*  操作系统故障：误操作或者突然断电，操作系统重启后却起不来了；或者系统文件意外删除、root密码遗忘等  
    –解决：为了最大限度挽救数据，我们通常会使用一张系统盘将系统引导起来，然后在尝试恢复。
 *  nova也提供了这种故障恢复机制——Rescue
 *  Rescue 用指定的 image 作为启动盘引导 instance，将 instance 本身的系统盘作为第二个磁盘挂载到操作系统上。

**rescue instance流程**

1.  向 nova-api 发送请求

*  目前 Rescue 操作只能通过 CLI 执行

1.  nova-api 发送消息

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

1.  nova-compute 执行操作

*  关闭instance
 *  通过image创建新的引导盘，命名为disk.rescue
 *  启动instance

### 九、snapshot ###

*  有时候操作系统损坏得很严重，通过 Rescue 操作无法修复，那么我们就得考虑通过备份恢复了。当然前提是我们之前对instance做过备份。
 *  Nova 备份操作为Snapshot，其工作原理是对 instance 的镜像文件（系统盘）进行全量备份，生成一个类型为 snapshot 的 image，然后将其保存到 Glance 上。
 *  从备份恢复的操作为Rebuild。

**snapshot操作流程**

1.  向nova-api发送请求
2.  nova-api发送消息
3.  nova-compute执行操作

第一步：向nova-api发送请求

*  可以通过界面进行操作，做个快照。  
    ![在这里插入图片描述][20181213180351410.png]

第二步：nova-api发送消息  
![在这里插入图片描述][20181213180736542.png]

第三步：nova-compute执行操作

1.  暂停instance
2.  对instance的镜像文件做快照
3.  恢复instance
4.  将快照上传到Glance
5.  snapshot 成功保存在Glance中

### 十、Rebuild ###

*  如果 instance 损坏了，可以通过 snapshot 恢复，这个恢复的操作就是 Rebuild。
 *  Rebuild 会用 snapshot 替换 instance 当前的镜像文件，同时保持 instance 的其他诸如网络，资源分配属性不变。

**rebuild instance操作流程**

1.  向nova-api 发送请求
2.  nova-api发送消息
3.  nova-compute执行操作  
    （1）关闭instance  
    （2）下载新的image，并准备instance的镜像文件  
    （3) 启动instance  
    （4) Rebuild后，GUI显示instance已经使用新的image

### 十一、Shelve(废弃实例） ###

*  Instance 被 Suspend 后虽然处于 Shut Down 状态，但 Hypervisor 依然在宿主机上为其预留了资源，以便在以后能够成功 Resume。
 *  如果希望释放这些预留资源，可以使用 Shelve 操作。
 *  Shelve 会将 instance 作为 image 保存到 Glance 中，然后在宿主机上删除该 instance。  
    **shelve流程**

1.  向 nova-api 发送请求
2.  nova-api 发送消息
3.  nova-compute 执行操作  
    （1）首先，关闭instance  
    （2）然后对instance执行snapshot操作  
    （3）成功后。snapshot生成的image会保存在Glance上，命名为 -shelved  
    （4）最后删除instance在宿主机上的资源  
    暂停操作成功执行后，instance 的状态变为 Shelved Offloaded，电源状态是 Shut Down

### 十二、Unshelve Instance （恢复instance) ###

*  通过 unshelve 操作恢复该 instance.
 *  因为 Glance 中保存了 instance 的 image，unshelve 的过程其实就是通过该 image launch 一个新的 instance，nova-scheduler 也会调度合适的计算节点来创建该 instance。
 *  instance unshelve 后可能运行在与 shelve 之前不同的计算节点上，但 instance 的其他属性（比如 flavor，IP 等）不会改变。

**Unshelve的流程**

1.  向 nova-api 发送请求
2.  nova-api 发送消息
3.  nova-scheduler 执行调度 --在 devstack@n-sch.service 中看log
4.  nova-scheduler 发送消息 --告诉被选中的计算节点可以launch instance了
5.  nova-compute 执行操作  
    (1) 为instance准备CPU 、内存和磁盘资源  
    (2) 创建instance镜像文件  
    (3) 创建instance的XML定义文件  
    (4) 创建虚拟网络并启动instance

### 十三、Migrate (迁移实例） ###

*  Migrate 操作的作用是将 instance 从当前的计算节点迁移到其他节点上。
 *  Migrate 不要求源和目标节点必须共享存储，当然共享存储也是可以的。
 *  Migrate 前必须满足一个条件：计算节点间需要配置 nova 用户无密码访问。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 3]

**迁移实例流程**

1.  向 nova-api 发送请求  
    客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我迁移这个 Instance” ，Migrate 操作是特权操作，只能在 Admin 的 instance 菜单中执行
2.  nova-api 发送消息  
    nova-api 向 Messaging（RabbitMQ）发送了一条消息：“迁移这个 Instance”，查看源代码 /opt/stack/nova/nova/compute/api.py，方法是 resize。  
    **是 resize 而非 migrate。**  
    这是由于 migrate 实际上是通过 resize 操作实现的
3.  nova-scheduler 执行调度  
    nova-scheduler 收到消息后，会为 instance 选择合适的目标计算节点。

--------------------

分析这段日志的时候，我发现 scheduler 选出来的计算节点有可能是当前节点源节点！因为 scheduler 并没在初始的时候将源节点剔除掉，而是与其他节点放在一起做 filter，按照这个逻辑，只要源节点的权值足够大，是有可能成为目标节点的。  
那紧接着的问题是：如果源节点和目标节点是同一个，migrate 操作会怎样进行呢？  
实验得知，nova-compute 在做 migrate 的时候会检查目标节点，如果发现目标节点与源节点相同，会抛出 UnableToMigrateToSelf 异常。Nova-compute 失败之后，scheduler 会重新调度，由于有 RetryFilter，会将之前选择的源节点过滤掉，这样就能选到不同的计算节点了。

--------------------

1.  nova-scheduler 发送消息  
    nova-scheduler 发送消息，通知计算节点可以迁移 instance 了。  
    源代码在 /opt/stack/nova/nova/scheduler/filter\_scheduler.py 第 95 行，方法为 select\_destinations
2.  nova-compute 执行操作  
    nova-compute 会在源计算节点和目标计算节点上分别执行操作。  
    **源计算节点**：迁移操作在源节点上首先会关闭 instance，然后将 instance 的镜像文件传到目标节点上。  
    (1) 开始 migrate  
    (2) 在目标节点上创建 instance 的目录：nova-compute 首先会尝试通过 ssh 在目标节点上的 instance 目录里 touch 一个临时文件。如果 touch 失败，说明目标节点上还没有该 instance 的目录，也就是说，源节点和目标节点没有共享存储。那么接下来就要在目标节点上创建 instance 的目录  
    (3) 关闭instance  
    (4) 将 instance 的镜像文件通过 scp 传到目标节点上  
    **目标节点**：  
    在目标节点上启动 instance，过程与 launch instance 非常类似。  
    会经过如下几个步骤：  
    (1) 为 instance 准备 CPU、内存和磁盘资源  
    (2) 创建 instance 镜像文件  
    (3) 创建 instance 的 XML 定义文件  
    (4) 创建虚拟网络并启动 instance
    
    **Confirm**  
    这时，instance 会处于 “Confirm or Revert Resize/Migrate”状态，需要用户确认或者回退当前的迁移操作，实际上给了用户一个反悔的机会。  
    ![在这里插入图片描述][20181213203959278.png]  
    当我们按下 Confirm 按钮后，会发生如下事情：  
    （1）nova-api 接收到 confirm 的消息  
    （2) 源计算节点删除 instance 的目录，并在 Hypervisor 上删除 instance。  
    （3) 目标计算节点不需要做任何事情
    
    **Revert**  
    (1) nova-api 接收到 revert 的消息  
    (2) 在目标计算节点上关闭 instance，删除 instance 的目录，并在 Hypervisor 上删除 instance。  
    (3) 源计算节点上启动 instance  
    因为之前迁移的时候只是在源节点上关闭了该 instance，revert 操作只需重新启动 instance。

这里有一点需要特别注意：  
迁移过程中源和目标节点之前需要使用 ssh 和 scp，为了使操作顺利进行，必须要保证 nova-compute 进程的启动用户（通常是 nova，也可能是 root，可以通过 ps 命令确认）能够在计算节点之间无密码访问。否则 nova-compute 会等待密码输入，但后台服务是无法输入密码的，迁移操作会一直卡在那里。

### 十四、Resize ###

*  Resize的作用是调整instance的**vCPU、内存和磁盘资源**。
 *  Instance 需要多少资源是定义在 **flavor** 中的，resize 操作是通过为 instance 选择新的 flavor 来调整资源的分配。
 *  Resize 是在 Migrate 的同时应用新的 flavor。 Migrate 可以看做是 resize 的一个特例：flavor 没发生变化的 resize。

**Resize的流程**

1.  向nova-api发送请求
2.  nova-api 发送消息
3.  nova-scheduler 执行调度
4.  nova-scheduler 发送消息
5.  nova-compute 执行操作

**Resize分两种**

1.  nova-scheduler 选择的目标节点与源节点是不同节点。操作过程跟上一节 Migrate 几乎完全一样，只是在目标节点启动 instance 的时候按新的 flavor 分配资源。 同时，因为要跨节点复制文件，也必须要保证 nova-compute 进程的启动用户（通常是 nova，也可能是 root，可以通过 ps 命令确认）能够在计算节点之间无密码访问。
2.  目标节点与源节点是同一个节点。则不需要 migrate。

**步骤详解：**  
第一步：

*  向 nova-api 发送请求，客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我 Resize 这个 Instance”。然后选择新的flavor。

第二步：

*  nova-api 向 Messaging（RabbitMQ）发送了一条消息：“Resize 这个 Instance”。查看源代码 /opt/stack/nova/nova/compute/api.py，方法是 resize\_instance。

第三步：

*  nova-scheduler 收到消息后，会为 instance 选择合适的目标计算节点。

第四步：

*  nova-scheduler 发送消息，通知计算节点可以迁移 instance 了，源代码在 /opt/stack/nova/nova/scheduler/filter\_scheduler.py 第 95 行，方法为 select\_destinations

第五步：  
（1）按新的 flavor 为 instance 准备 CPU、内存和磁盘资源  
（2）关闭instance.  
（3）将 instance 的目录备份一份，命名为<instance\_id>\_resize，以便 revert。  
（4）创建 instance 的 XML 定义文件  
（5）准备虚拟网络  
（6）启动 instance

**Confirm**  
（1）nova-api 接收到 confirm 的消息  
（2）删除计算节上备份的 instance 目录 <instance\_id>\_resize

**Revert**  
（1）nova-api 接收到 revert 的消息  
（2）在计算节点上关闭 instance  
（3）通过备份目录 <instance\_id>\_resize 恢复 instance 目录。  
（4）重新启动 instance

### 十五、Live Migrate (实例热迁移) ###

*  Migrate 操作会先将 instance 停掉，也就是所谓的“冷迁移”。而 Live Migrate 是“热迁移”，也叫“在线迁移”，instance不会停机。

**两种热迁移：**

1.  源和目标节点没有共享存储，instance 在迁移的时候需要将其镜像文件从源节点传到目标节点，这叫做 Block Migration（块迁移）
2.  源和目标节点共享存储，instance 的镜像文件不需要迁移，只需要将 instance 的状态迁移到目标节点。

**热迁移的条件**

*  源和目标节点的 CPU 类型要一致。
 *  源和目标节点的 Libvirt 版本要一致。
 *  源和目标节点能相互识别对方的主机名称，比如可以在 /etc/hosts 中加入对方的条目。
 *  在源和目标节点的 /etc/nova/nova.conf 中指明在线迁移时使用 TCP 协议。  
    ![在这里插入图片描述][20181214101759687.png]
 *  Instance 使用 config driver 保存其 metadata。在 Block Migration 过程中，该 config driver 也需要迁移到目标节点。由于目前 libvirt 只支持迁移 vfat 类型的 config driver，所以必须在 /etc/nova/nova.conf 中明确指明 launch instance 时创建 vfat 类型的 config driver。  
    ![在这里插入图片描述][20181214101848925.png]
 *  源和目标节点的 Libvirt TCP 远程监听服务得打开，需要在下面两个配置文件中做一点配置。![在这里插入图片描述][20181214101917924.png]  
    再重启Libvirtd服务：service libvirt-bin restart

**1. 非共享存储Block Migration**  
**流程**

*  向 nova-api 发送请求
 *  nova-api 发送消息
 *  nova-compute 执行操作

**步骤**

第一步：

*  客户（可以是 OpenStack 最终用户，也可以是其他程序）向API（nova-api）发送请求：“帮我将这个 Instance 从节点 A Live Migrate 到节点 B”。
 *  因为是非共享存储，记得将“Block Migration”勾选上。
 *  还有一个“Disk Over Commit”选项，如果勾选了此选项，nova 在检查目标节点的磁盘空间是否足够时，是以 instance 磁盘镜像文件定义的最大容量为准；否则，以磁盘镜像文件当前的实际大小为准。

第二步：

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

第三步：  
（1）目标节点执行迁移前的准备工作，首先将 instance 的数据迁移过来，主要包括镜像文件、虚拟网络等资源。  
（2）源节点启动迁移操作，暂停 instance。  
（3）在目标节点上 Resume instance。  
（4）在源节点上执行迁移的后处理工作，删除 instance。  
（5) 在目标节点上执行迁移的后处理工作，创建 XML，在 Hypervisor 中定义 instance，使之下次能够正常启动。  
**注：** Instance 在 Live Migrate 的整个过程中不会停机，我们通过 Ping 操作来观察

**2. 共享存储 Live Migration**

*  有多种方式可以实现共享存储，比如可以将 instance 的镜像文件放在 NFS 服务器上，或者使用 NAS 服务器，或者分布式文件系统。
 *  需要搭建NFS环境，在目标节点上挂在NFS服务器节点的共享目录。
 *  共享存储的迁移过程与 Block Migrate 基本上一样，只是几个环节有点区别：
    
    1.  向 nova-api 提交请求的时候，不能勾选“Block Migrate”
    2.  因为源和目标节点都能直接访问 instance 的镜像，所以目标节点在准备阶段不需要传输镜像文件，源节点在迁移后处理阶段也无需删除 instance 的目录。
    3.  只有 instance 的状态需要从源节点传输到的目标节点，整个迁移速递比 Block Migration 快很多。

### 十六、Evacuate ###

*  Rebuild 可以恢复损坏的 instance。
 *  那如果是宿主机坏了怎么办呢？ 比如硬件故障或者断电造成整台计算节点无法工作，该节点上运行的 instance 如何恢复呢？
 *  用 Shelve 或者 Migrate 可不可以？ 很不幸，这两个操作都要求 instance 所在计算节点的 nova-compute 服务正常运行。
 *  幸运的是，还有 Evacuate 操作。

**Evacuate**

*  Evacuate 可在 nova-compute 无法工作的情况下将节点上的 instance 迁移到其他计算节点上。但有个前提： Instance 的镜像文件必须放在共享存储上。

**流程**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 4]

1.  向 nova-api 发送请求
2.  nova-api 发送消息
3.  nova-scheduler 执行调度
4.  nova-scheduler 发送消息
5.  nova-compute 执行操作

**步骤详解**

第一步：通过断电模拟计算节点故障，然后执行 Evacuate 操作恢复 instance 。 目前 Evacuate 只能通过 CLI 执行。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 5]  
这里需要指定 --on-shared-storage 这个参数

第二步：

*  nova-api 向 Messaging（RabbitMQ）发送了一条消息：“Evacuate 这个 Instance” 查看源代码 /opt/stack/nova/nova/compute/api.py，方法是 evacuate。
 *  evacuate 实际上是通过 rebuild 操作实现的。

第三步：

*  evacuate 实际上是通过 rebuild 操作实现的。通过日志n-sch来查看选择的节点。

第四步：

*  nova-scheduler 发送消息，通知计算节点可以创建 instance 了。 源代码在 /opt/stack/nova/nova/scheduler/filter\_scheduler.py 第 95 行，方法为 select\_destinations。

第五步：

*  计算节点上的工作是用共享存储上的镜像文件重建 instance。  
    （1）为instance分配资源  
    （2) 使用共享存储上的镜像文件  
    （3) 启动 instance

### 总结 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 6]  
**常规操作**

*  常规操作中，Launch、Start、Reboot、Shut Off 和 Terminate 都很好理解。 下面几个操作重点回顾一下：

**Resize**  
通过应用不同的 flavor 调整分配给 instance 的资源。

**Lock/Unlock**  
可以防止对 instance 的误操作。

**Pause/Suspend/Resume**

*  暂停当前 instance，并在以后恢复。
 *  Pause 和 Suspend 的区别在于 Pause 将 instance 的运行状态保存在计算节点的内存中，而 Suspend 保存在磁盘上。
 *  Pause 的优点是 Resume 的速度比 Suspend 快；缺点是如果计算节点重启，内存数据丢失，就无法 Resume 了，而 Suspend 则没有这个问题。

**Snapshot**  
备份 instance 到 Glance。产生的 image 可用于故障恢复，或者以此为模板部署新的 instance。

**故障处理**

*  故障处理有两种场景：计划内和计划外。
 *  计划内是指提前安排时间窗口做的维护工作，比如服务器定期的微码升级，添加更换硬件等。
 *  计划外是指发生了没有预料到的突发故障，比如强行关机造成 OS 系统文件损坏，服务器掉电，硬件故障等。

**计划内故障处理**  
对于计划内的故障处理，可以在维护窗口中将 instance 迁移到其他计算节点。  
涉及如下操作：  
**Migrate**  
将 instance 迁移到其他计算节点。  
迁移之前，instance 会被 Shut Off，支持共享存储和非共享存储。  
**Live Migrate**

*  与 Migrate 不同，Live Migrate 能不停机在线地迁移 instance，保证了业务的连续性。也支持共享存储和非共享存储（Block Migration）
 *  Shelve/Unshelve Shelve 将 instance 保存到 Glance 上，之后可通过 Unshelve 重新部署。
 *  Shelve 操作成功后，instance 会从原来的计算节点上删除。
 *  Unshelve 会重新选择节点部署，可能不是原节点。

**计划外故障处理**

*  计划外的故障按照影响的范围又分为两类：Instance 故障和计算节点故障
    
    **Instance 故障**
    
     *  Instance 故障只限于某一个 instance 的操作系统层面，系统无法正常启动。
     *  可以使用如下操作修复 instance：  
        **Rescue/Unrescue**  
        用指定的启动盘启动，进入 Rescue 模式，修复受损的系统盘。成功修复后，通过 Unrescue 正常启动 instance。  
        **Rebuild**  
        如果 Rescue 无法修复，则只能通过 Rebuild 从已有的备份恢复。Instance 的备份是通过 snapshot 创建的，所以需要有备份策略定期备份。
    
    **计算节点故障**  
    Instance 故障的影响范围局限在特定的 instance，计算节点本身是正常工作的。如果计算节点发生故障，OpenStack 则无法与节点的 nova-compute 通信，其上运行的所有 instance 都会受到影响。这个时候，只能通过 Evacuate 操作在其他正常节点上重建 Instance。

**Evacuate**  
利用共享存储上 Instance 的镜像文件在其他计算节点上重建 Instance。  
所以提前规划共享存储是关键。

（注：本文根据《每天5分钟玩转openstack》进行操作）

[20181213155045485.png]: /images/20220405/6c6509904b5243748216100bc3276955.png
[20181213160143737.png]: /images/20220405/d2aa42652df04c08a5205ece6a7a8bf6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70]: /images/20220405/1383b1d1bd474b98a760ec7ffa568976.png
[20181213155438754.png]: /images/20220405/352da0e0d3af4cb0b0c1002ca365b5ac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 1]: /images/20220405/649637e1407444a4b354fa6cb4f4d15d.png
[2018121316263586.png]: /images/20220405/1e6c7bbd084c4da4b4c77e08dcf71c1c.png
[20181213163035955.png]: /images/20220405/8ca38afae13f4797b84464b554d645d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 2]: /images/20220405/cbad286fe9e74bfba21cb0e506906ffe.png
[20181213180351410.png]: /images/20220405/6c77ce245b6445b4967393849513ae07.png
[20181213180736542.png]: /images/20220405/9d5b792d7c7641ad8668d98b15d305ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 3]: /images/20220405/6118972094ee44d7a6ab9172f85ba8a6.png
[20181213203959278.png]: /images/20220405/8bda2889ddb04ed6bbf05d779e5bbe86.png
[20181214101759687.png]: /images/20220405/1a2f1c070dc643e892a2896531f381a4.png
[20181214101848925.png]: /images/20220405/6ec3262cce604e0d99e38a04f921bc5e.png
[20181214101917924.png]: /images/20220405/17eba7a345ef45ac9099552b0677f43f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 4]: /images/20220405/7d63e7610827463abc504221933f1b4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 5]: /images/20220405/83d6d96c0d5c4b0692c36e71b405b7dd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMxODQzNzg_size_16_color_FFFFFF_t_70 6]: /images/20220405/1f97575952fa4f57b89f044c2171d91f.png