Resize 的做用是调整 instance 的 vCPU、内存和磁盘资源。api
Instance 须要多少资源是定义在 flavor 中的,resize 操做是经过为 instance 选择新的 flavor 来调整资源的分配。网络
有了前面对 Migrate 的分析,再来看 Resize 的实现就很是简单了。 由于 instance 须要分配的资源发生了变化,在 resize 以前须要借助 nova-scheduler 从新为 instance 选择一个合适的计算节点,若是选择的节点与当前节点不是同一个,那么就须要作 Migrate。spa
因此本质上讲:Resize 是在 Migrate 的同时应用新的 flavor。 Migrate 能够看作是 resize 的一个特例: flavor 没发生变化的 resize,这也是为何咱们在上一节日志中看到 migrate 其实是在执行 resize 操做。日志
下面是 Resize instance 的流程图进程
向 nova-api 发送请求内存
nova-api 发送消息资源
nova-scheduler 执行调度it
nova-scheduler 发送消息io
nova-compute 执行操做select
Resize 分两种状况:
nova-scheduler 选择的目标节点与源节点是不一样节点。操做过程跟上一节 Migrate 几乎彻底同样,只是在目标节点启动 instance 的时候按新的 flavor 分配资源。 同时,由于要跨节点复制文件,也必需要保证 nova-compute 进程的启动用户(一般是 nova,也多是 root,能够经过 ps 命令确认)可以在计算节点之间无密码访问。 对这一种状况咱们再也不赘述,请参看前面 Migrate 小节。
目标节点与源节点是同一个节点。则不须要 migrate。下面咱们重点讨论这一种状况。
客户(能够是 OpenStack 最终用户,也能够是其余程序)向 API(nova-api)发送请求:“帮我 Resize 这个 Instance”
选择新的 flavor
点击 Resize 按钮
查看日志 /opt/stack/logs/n-api.log
nova-api 向 Messaging(RabbitMQ)发送了一条消息:“Resize 这个 Instance” 查看源代码 /opt/stack/nova/nova/compute/api.py,方法是 resize_instance。
nova-scheduler 收到消息后,会为 instance 选择合适的目标计算节点。 查看日志 /opt/stack/logs/n-sch.log
在本例中,nova-scheduler 选择了 devstack-compute1 做为的目节点,与源节点相同。
nova-scheduler 发送消息,通知计算节点能够迁移 instance 了 源代码在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行,方法为 select_destinations
在目标节点上启动 instance,过程与 launch instance 很是相似。 日志记录在 /opt/stack/logs/n-cpu.log
会通过以下几个步骤:
按新的 flavor 为 instance 准备 CPU、内存和磁盘资源
关闭 instance
建立 instance 镜像文件
将 instance 的目录备份一份,命名为<instance_id>_resize,以便 revert。
建立 instance 的 XML 定义文件
准备虚拟网络
启动 instance
这时,instance 的状态处于“Confirm or Revert Resize/Migrate”状态,须要用户确认或者回退当前的迁移操做,实际上给了用户一个反悔的机会。
当咱们按下 Confirm 按钮后,会发生以下事情:
nova-api 接收到 confirm 的消息
删除计算节上备份的 instance 目录 <instance_id>_resize
反过来,若是执行 Revert 操做会发生什么事情呢?
nova-api 接收到 revert 的消息
在计算节点上关闭 instance
经过备份目录 <instance_id>_resize 恢复 instance 目录。
从新启动 instance
以上是 Resize 操做的详细分析,下一节咱们讨论 Live Migrate。