第 5 章 Nova - 040 - Migrate Instance 操作详解

Migrate Instance 操作详解

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

Migrate 不要求源和目标节点必须共享存储,当然共享存储也是可以的。

Migrate 前必须满足一个条件:计算节点间需要配置 nova 用户无密码访问。

下面是 Migrate instance 的流程图:

1、向 nova-api 发送请求

2、nova-api 发送消息

3、nova-scheduler 执行调度

4、nova-scheduler 发送消息

5、nova-compute 执行操作

详细分析:

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 选择合适的目标计算节点。

可以看到,因为 devstack-compute1 的权值比 devstack-controller 大,最终选择 devstack-compute1 作为目标节点。

在分析这段日志的时候,可以发现 scheduler 选出来的计算节点有可能是当前节点源节点!

因为 scheduler 并没在初始的时候将源节点剔除掉,而是与其他节点放在一起做 filter,按照这个逻辑,只要源节点的权值足够大,是有可能成为目标节点的。

如果源节点和目标节点是同一个,migrate 操作会怎样进行呢?

实验得知,nova-compute 在做 migrate 的时候会检查目标节点,如果发现目标节点与源节点相同,会抛出 UnableToMigrateToSelf 异常。

Nova-compute 失败之后,scheduler 会重新调度,由于有 RetryFilter,会将之前选择的源节点过滤掉,这样就能选到不同的计算节点了。

在上面的操作中 sheduler 选择的目标节点是 devstack-compute ,意味着 instance 将从 devstack-controller 迁移到 devstack-compute 。

4、nova-scheduler 发送消息

nova-scheduler 发送消息,通知计算节点可以迁移 instance 了。

源代码在 /opt/stack/nova/nova/scheduler/filter_scheduler.py ,方法为 select_destinations

5、nova-compute 执行操作

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

(1)源计算节点

迁移操作在源节点上首先会关闭 instance,然后将 instance 的镜像文件传到目标节点上。

具体步骤如下:

1、开始 migrate

2、在目标节点上创建 instance 的目录

3、nova-compute 首先会尝试通过 ssh 在目标节点上的 instance 目录里 touch 一个临时文件

4、如果 touch 失败,说明目标节点上还没有该 instance 的目录,也就是说,源节点和目标节点没有共享存储。

5、那么接下来就要在目标节点上创建 instance 的目录

6、关闭 instance

7、将 instance 镜像文件通过 scp 传到目标节点

(2)目标计算节点

在目标节点上启动 instance,过程与 launch instance 非常类似。

具体步骤如下:

1、为 instance 准备 CPU、内存和磁盘资源

2、创建 instance 镜像文件

3、创建 instance 的 XML 定义文件

4、创建虚拟网络并启动 instance

(3)Confirm

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

当按下 Confirm 按钮后:

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

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

3、目标计算节点不需要做任何事情

(4)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 会等待密码输入,但后台服务是无法输入密码的,迁移操作会一直卡在那里。

-------------------------------------------------引用来自---------------------------------------------------------------

https://www.cnblogs.com/CloudMan6/p/5538599.html

https://mp.weixin.qq.com/s?__biz=MzIwMTM5MjUwMg==&mid=2653587787&idx=1&sn=3b1503699b9cfd1efc42233a04f69cfc&chksm=8d308152ba47084495f66aad0338d6780ab009527bf92666c53c08682d3fb1443846d0331cf9&scene=21#wechat_redirect

原文地址:https://www.cnblogs.com/gsophy/p/11023660.html

时间: 2024-10-09 02:24:28

第 5 章 Nova - 040 - Migrate Instance 操作详解的相关文章

第 5 章 Nova - 039 - Unshelve Instance 操作详解

Unshelve Instance 操作详解 因为 Glance 中保存了 instance 的 image,unshelve 的过程其实就是通过该 image launch 一个新的 instance,nova-scheduler 也会调度合适的计算节点来创建该 instance. instance unshelve 后可能运行在与 shelve 之前不同的计算节点上,但 instance 的其他属性(比如 flavor,IP 等)不会改变. 下面是 Unshelve instance 的流程

第 5 章 Nova - 038 - Shelve Instance 操作详解

Shelve Instance 操作详解 Instance 被 Suspend 后虽然处于 Shut Down 状态,但 Hypervisor 依然在宿主机上为其预留了资源,以便在以后能够成功 Resume. 如果希望释放这些预留资源,可以使用 Shelve 操作. Shelve 会将 instance 作为 image 保存到 Glance 中,然后在宿主机上删除该 instance. 下面是 shelve instance 的流程图 1.向 nova-api 发送请求 2.nova-api

Migrate Instance 操作详解 - 每天5分钟玩转 OpenStack(40)

Migrate 操作的作用是将 instance 从当前的计算节点迁移到其他节点上. Migrate 不要求源和目标节点必须共享存储,当然共享存储也是可以的. Migrate 前必须满足一个条件:计算节点间需要配置 nova 用户无密码访问. 下面是 Migrate instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-scheduler 执行调度 nova-scheduler 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤.

(转载)Resize Instance 操作详解

(转载)Resize Instance 操作详解 - 每天5分钟玩转 OpenStack(41) 原文路径:https://www.cnblogs.com/CloudMan6/p/5548294.html 内容根据本人测试,可能有删改补充. Resize 的作用是调整 instance 的 vCPU.内存和磁盘资源. Instance 需要多少资源是定义在 flavor 中的,resize 操作是通过为 instance 选择新的 flavor 来调整资源的分配. 有了前面对 Migrate 的

Resize Instance 操作详解 - 每天5分钟玩转 OpenStack(41)

Resize 的作用是调整 instance 的 vCPU.内存和磁盘资源. Instance 需要多少资源是定义在 flavor 中的,resize 操作是通过为 instance 选择新的 flavor 来调整资源的分配. 有了前面对 Migrate 的分析,再来看 Resize 的实现就非常简单了. 因为 instance 需要分配的资源发生了变化,在 resize 之前需要借助 nova-scheduler 重新为 instance 选择一个合适的计算节点,如果选择的节点与当前节点不是同

Unshelve Instance 操作详解 - 每天5分钟玩转 OpenStack(39)

上一节我们 shelve instance 到 Glance,本节讨论如何通过 unshelve 操作恢复该 instance. 因为 Glance 中保存了 instance 的 image,unshelve 的过程其实就是通过该 image launch 一个新的 instance,nova-scheduler 也会调度合适的计算节点来创建该 instance. instance unshelve 后可能运行在与 shelve 之前不同的计算节点上,但 instance 的其他属性(比如 f

Shelve Instance 操作详解 - 每天5分钟玩转 OpenStack(38)

Instance 被 Suspend 后虽然处于 Shut Down 状态,但 Hypervisor 依然在宿主机上为其预留了资源,以便在以后能够成功 Resume. 如果希望释放这些预留资源,可以使用 Shelve 操作. Shelve 会将 instance 作为 image 保存到 Glance 中,然后在宿主机上删除该 instance. 下面是 shelve instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面

Snapshot Instance 操作详解 - 每天5分钟玩转 OpenStack(36)

本节我们通过日志详细讨论 instance 的 snapshot 操作. 有时候操作系统损坏得很严重,通过 Rescue 操作无法修复,那么我们就得考虑通过备份恢复了.当然前提是我们之前对instance做过备份. Nova 备份的操作叫 Snapshot,其工作原理是对 instance 的镜像文件(系统盘)进行全量备份,生成一个类型为 snapshot 的 image,然后将其保存到 Glance 上. 从备份恢复的操作叫 Rebuild,将在下一节重点讨论. 下面是 snapshot in

Pause/Resume Instance 操作详解 - 每天5分钟玩转 OpenStack(34)

本节通过日志详细分析 Nova Pause/Resume 操作. 有时需要短时间暂停 instance,可以通过 Pause 操作将 instance 的状态保存到宿主机的内存中.当需要恢复的时候,执行 Resume 操作,从内存中读回 instance 的状态,然后继续运行 instance. 下面是 pause instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤. 向nova-api发送请求