Migrate Instance 操做详解 - 天天5分钟玩转 OpenStack（40）

Migrate 操做的做用是将 instance 从当前的计算节点迁移到其余节点上。

Migrate 不要求源和目标节点必须共享存储，固然共享存储也是能够的。 Migrate 前必须知足一个条件：计算节点间须要配置 nova 用户无密码访问。

下面是 Migrate instance 的流程图

1. 向 nova-api 发送请求

2. nova-api 发送消息

3. nova-scheduler 执行调度

4. nova-scheduler 发送消息

5. nova-compute 执行操做

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

向 nova-api 发送请求

客户（能够是 OpenStack 最终用户，也能够是其余程序）向 API（nova-api）发送请求：“帮我迁移这个 Instance” Migrate 操做是特权操做，只能在 Admin 的 instance 菜单中执行

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

nova-api 发送消息

nova-api 向 Messaging（RabbitMQ）发送了一条消息：“迁移这个 Instance” 查看源代码 /opt/stack/nova/nova/compute/api.py，方法是 resize。 没错，是 resize 而非 migrate。
这是因为 migrate 其实是经过 resize 操做实现的，至于为何要这样设计，咱们会在下一节 resize 中详细分析。

nova-scheduler 执行调度

nova-scheduler 收到消息后，会为 instance 选择合适的目标计算节点。 查看日志 /opt/stack/logs/n-sch.log

能够看到，由于 devstack-compute1 的权值比 devstack-controller 大，最终选择 devstack-compute1 做为目标节点。

看到上面的日志，你们发现什么问题没有？

在分析这段日志的时候，我发现 scheduler 选出来的计算节点有多是当前节点源节点！ 由于 scheduler 并没在初始的时候将源节点剔除掉，而是与其余节点放在一块儿作 filter，按照这个逻辑，只要源节点的权值足够大，是有可能成为目标节点的。

那紧接着的问题是：若是源节点和目标节点是同一个，migrate 操做会怎样进行呢？

实验得知，nova-compute 在作 migrate 的时候会检查目标节点，若是发现目标节点与源节点相同，会抛出 UnableToMigrateToSelf 异常。Nova-compute 失败以后，scheduler 会从新调度，因为有 RetryFilter，会将以前选择的源节点过滤掉，这样就能选到不一样的计算节点了。 关于 RetryFilter，你们还有印象吗？若是生疏了能够看前面章节。

好，言归正传。在上面的操做中 sheduler 选择的目标节点是 devstack-compute1，意味着 instance 将从 devstack-controller 迁移到 devstack-compute1。

nova-scheduler 发送消息

nova-scheduler 发送消息，通知计算节点能够迁移 instance 了。 源代码在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行，方法为 select_destinations

nova-compute 执行操做

nova-compute 会在源计算节点和目标计算节点上分别执行操做。

源计算节点 devstack-controller

迁移操做在源节点上首先会关闭 instance，而后将 instance 的镜像文件传到目标节点上。 日志在 /opt/stack/logs/n-cpu.log，具体步骤以下：

开始 migrate

在目标节点上建立 instance 的目录

nova-compute 首先会尝试经过 ssh 在目标节点上的 instance 目录里 touch 一个临时文件，日志以下

若是 touch 失败，说明目标节点上尚未该 instance 的目录，也就是说，源节点和目标节点没有共享存储。那么接下来就要在目标节点上建立 instance 的目录，日志以下

关闭 instance

将 instance 的镜像文件经过 scp 传到目标节点上

目标计算节点 devstack-compute1

在目标节点上启动 instance，过程与 launch instance 很是相似。 会通过以下几个步骤： 1. 为 instance 准备 CPU、内存和磁盘资源 2. 建立 instance 镜像文件 3. 建立 instance 的 XML 定义文件 4. 建立虚拟网络并启动 instance

日志记录在 /opt/stack/logs/n-cpu.log，分析留给你们练习。

Confirm

这时，instance 会处于 “Confirm or Revert Resize/Migrate”状态，须要用户确认或者回退当前的迁移操做，实际上给了用户一个反悔的机会。

当咱们按下 Confirm 按钮后，会发生以下事情：

1. nova-api 接收到 confirm 的消息
   

2. 源计算节点删除 instance 的目录，并在 Hypervisor 上删除 instance。
   
   
   

3. 目标计算节点不须要作任何事情

Revert

若是执行的是 Revert 操做会发生什么事情呢？

1. nova-api 接收到 revert 的消息
   

2. 在目标计算节点上关闭 instance，删除 instance 的目录，并在 Hypervisor 上删除 instance。
   

3. 源计算节点上启动 instance 由于以前迁移的时候只是在源节点上关闭了该 instance，revert 操做只需从新启动 instance。
   
   
   

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

以上是 Migrate 操做的详细分析，下一节咱们讨论 Resize。