Create Volume 操作(Part III) - 每天5分钟玩转 OpenStack(52)

本节是创建 Volume 的第三部分,也是最后一部分:cinder-volume 的处理过程。

第一部分和第二部分可以参考前面两个小节。
cinder-volume 通过 driver 创建 volume,日志为 /opt/stack/logs/c-vol.log。

与 cinder-api 和 cinder-scheduler 执行方式类似,cinder-volume 也启动了一个 Flow 来完成 volume 创建工作,Flow 的名称为 volume_create_manager。

volume_create_manager 首先执行 ExtractVolumeRefTask, OnFailureRescheduleTask, ExtractVolumeSpecTask, NotifyVolumeActionTask 为 volume 创建做准备。

接下来 CreateVolumeFromSpecTask 执行 volume 创建任务。

因为 volume provider 为 LVM, CreateVolumeFromSpecTask 通过 lvcreate 命令在 VG stack-volumes-lvmdriver-1 中创建了一个 1G 的 LV,cinder-volume 将这个 LV 作为volume。
新创建的 LV 命名为“volume-1e7f6bd7-ce11-4a73-b95e-aabd65a5b188”,其格式为“volume-<volume ID>”。

最后,CreateVolumeOnFinishTask 完成扫尾工作。

至此,volume 成功创建,Flow volume_create_manager 结束。

下一节我们讨论如何将新建的 volume 挂到 instance 上,即 attach 操作。

时间: 2024-12-19 04:26:45

Create Volume 操作(Part III) - 每天5分钟玩转 OpenStack(52)的相关文章

Nova Suspend/Rescue 操作详解 - 每天5分钟玩转 OpenStack(35)

本节我们讨论 Suspend/Resume 和 Rescue/Unrescue 这两组操作. Suspend/Resume 有时需要长时间暂停 instance,可以通过 Suspend 操作将 instance 的状态保存到宿主机的磁盘上.当需要恢复的时候,执行 Resume 操作,从磁盘读回 instance 的状态,使之继续运行. 这里需要对 Suspend 和 Pause 操作做个比较: 相同点两者都是暂停 instance 的运行,并保存当前状态,之后可以通过 Resume 操作恢复

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

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

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

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

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发送请求

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

本节通过日志文件详细分析 instance start 操作. 下面是 start instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下面我们详细讨论每一个步骤. 向 nova-api 发送请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向API(nova-api)发送请求:“帮我启动这个 Instance” 查看日志 /opt/stack/logs/n-api.log nova-api 发送消息 no

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

上一节我们讨论了 snapshot,snapshot 的一个重要作用是对 instance 做备份. 如果 instance 损坏了,可以通过 snapshot 恢复,这个恢复的操作就是 Rebuild. Rebuild 会用 snapshot 替换 instance 当前的镜像文件,同时保持 instance 的其他诸如网络,资源分配属性不变. 下面是 rebuild instance 的流程图 向 nova-api 发送请求 nova-api 发送消息 nova-compute 执行操作 下

Launch和Shut Off操作详解 - 每天5分钟玩转 OpenStack(30)

本节详细分析 instance launch 和 shut off 操作,以及如何在日志中快速定位有用信息的技巧. Launch Launch instance 应该算 Nova 最重要的操作. 仔细研究 lanuch 操作能够帮助我们充分理解 Nova 各个子服务的协调配合和运行机制. 前面我们已经以 launch 操作为例详细讨论了各个 nova-* 子服务. 这里不再赘述,只是再回顾一下流程. 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(nova-api)发送