如何理解Resize Instance操作
这篇文章给大家介绍如何理解Resize Instance操作，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
Resize 的作用是调整 instance 的 vCPU、内存和磁盘资源。
Instance 需要多少资源是定义在 flavor 中的，resize 操作是通过为 instance 选择新的 flavor 来调整资源的分配。
有了前面对 Migrate 的分析，再来看 Resize 的实现就非常简单了。 因为 instance 需要分配的资源发生了变化，在 resize 之前需要借助 nova-scheduler 重新为 instance 选择一个合适的计算节点，如果选择的节点与当前节点不是同一个，那么就需要做 Migrate。
所以本质上讲：Resize 是在 Migrate 的同时应用新的 flavor。 Migrate 可以看做是 resize 的一个特例： flavor 没发生变化的 resize，这也是为什么我们在上一节日志中看到 migrate 实际上是在执行 resize 操作。
Resize 分两种情况：
nova-scheduler 选择的目标节点与源节点是不同节点。操作过程跟上一节 Migrate 几乎完全一样，只是在目标节点启动 instance 的时候按新的 flavor 分配资源。 同时，因为要跨节点复制文件，也必须要保证 nova-compute 进程的启动用户（通常是 nova，也可能是 root，可以通过 ps 命令确认）能够在计算节点之间无密码访问。 对这一种情况我们不再赘述，请参看前面 Migrate 小节。
目标节点与源节点是同一个节点。则不需要 migrate。下面我们重点讨论这一种情况。
向 nova-api 发送请求
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求："帮我 Resize 这个 Instance"
选择新的 flavor
点击 Resize 按钮
查看日志 /opt/stack/logs/n-api.log
nova-api 发送消息
nova-api 向 Messaging（RabbitMQ）发送了一条消息："Resize 这个 Instance" 查看源代码 /opt/stack/nova/nova/compute/api.py，方法是 resize_instance。
nova-scheduler 执行调度
nova-scheduler 收到消息后，会为 instance 选择合适的目标计算节点。 查看日志 /opt/stack/logs/n-sch.log
nova-scheduler 选择了 devstack-compute1 作为的目节点，与源节点相同。
nova-scheduler 发送消息
nova-scheduler 发送消息，通知计算节点可以迁移 instance 了 源代码在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行，方法为 select_destinations
nova-compute 执行操作
在目标节点上启动 instance，过程与 launch instance 非常类似。 日志记录在 /opt/stack/logs/n-cpu.log
会经过如下几个步骤：
按新的 flavor 为 instance 准备 CPU、内存和磁盘资源
关闭 instance
创建 instance 镜像文件
将 instance 的目录备份一份，命名为
_resize，以便 revert。 创建 instance 的 XML 定义文件
准备虚拟网络
启动 instance
Confirm
这时，instance 的状态处于"Confirm or Revert Resize/Migrate"状态，需要用户确认或者回退当前的迁移操作，实际上给了用户一个反悔的机会。
当我们按下 Confirm 按钮后，会发生如下事情：
nova-api 接收到 confirm 的消息
删除计算节上备份的 instance 目录
_resize
Revert
反过来，如果执行 Revert 操作会发生什么事情呢？
nova-api 接收到 revert 的消息
在计算节点上关闭 instance
通过备份目录
_resize 恢复 instance 目录。 重新启动 instance
关于如何理解Resize Instance操作就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
