NFS Volume Provider(Part III) - 每天5分钟玩转 OpenStack(64)

今天我们将前一小节创建的 NFS volume “nfs-vol-1” attach 到 instance “c2”上。

这里我们重点关注 nova-compute 如何将“nfs-vol-1” attach 到“c2”。

通过日志分析,nova-compute 会将存放 volume 文件的 NFS 目录 mount 到本地 /opt/stack/data/nova/mnt 目录下,然后修改 instance 的 XML 将 volume 文件配置为虚拟磁盘,日志为 /opt/stack/logs/n-cpu.log

通过 findmnt 和 mkdir 测试和创建 mount point。

mount NFS 目录。

更新 instance 的 XML 配置文件,将 volume 文件映射给 instance。

我们也可以通过 virsh edit 查看更新后的XML。

GUI 界面也会更新相关 attach 信息。

NFS volume 的其他操作(detach, backup……)留个大家做练习了。

本章小节

自此,关于 Cinder 的主要内容已经讨论完了,下面做个总结。
Cinder 作为 OpenStack 的块存储服务,为 instance 提供虚拟磁盘。
本章我们首先学习了 Cinder 的架构,然后讨论了 Cinder 的各个服务组件,最后通过使用场景详细分析了 Volume 的各种操作。

操作中的详细日志和截图可以帮助我们更好地理解 Cinder 内部运行机制,并为故障分析提供了非常有益的线索。

下节开始,我们将学习 OpenStack 最后一个核心模块 Neutron,难度会比前面所有模块都大一些,内容也多一些。
为了帮助大家更好的掌握 Neutorn,CloudMan 也会分析地更详细一些。

咱们下节见。

时间: 2024-07-30 13:17:48

NFS Volume Provider(Part III) - 每天5分钟玩转 OpenStack(64)的相关文章

NFS Volume Provider(Part I) - 每天5分钟玩转 OpenStack(62)

cinder-volume 支持多种 volume provider,前面我们一直使用的是默认的 LVM,本节我们将增加 NFS volume provider. 虽然 NFS 更多地应用在实验或小规模 cinder 环境,由于性能和缺乏高可用的原因在生产环境中不太可能使用,但是学习 NFS volume provider 的意义在于:1. 理解 cinder-volume 如何支持多 backend2. 更重要的,可以理解 cinder-volume,nova-compute 和 volume

NFS Volume Provider(Part II) - 每天5分钟玩转 OpenStack(63)

上一节我们将 NFS volume provider 配置就绪,本节将创建 volume. 创建 volume 创建 NFS volume 操作方法与 LVM volume 一样,唯一区别是在 volume type 的下拉列表中选择"nfs". 点击"Create Volume",cinder-api,cinder-scheduler 和 cinder-volume 共同协作创建 volume "nfs-vol-1".这个流程与 LVM vol

Boot from Volume - 每天5分钟玩转 OpenStack(61)

  Volume 除了可以用作 instance 的数据盘,也可以作为启动盘(Bootable Volume),那么如何使 volume 成为 bootable 呢? 现在我们打开 instance 的 launch 操作界面. 这里有一个下拉菜单"Instance Boot Source".以前我们 launch instance 要么直接从 image launch(Boot from image),要么从 instance 的 snapshot launch(Boot from

写在最前面 - 每天5分钟玩转 OpenStack(1)

<每天5分钟玩转 OpenStack>是一个 OpenStack 教程,这是第 1 篇. 这个教程有下面两个特点: 系统讲解 OpenStack 从架构到各个组件:从整体到细节逐一讨论 重实践并兼顾理论 主要从实际操作的角度带着大家学习 OpenStack.   为啥要写这个? 简单回答是:因为OpenStack 学习难度大,但如果掌握了价值会很大 先做一个自我介绍吧. 本人网名CloudMan,在 IT 这个行当已经摸爬滚打了十多年,05年之前是搞上层应用开发的,那时候 Java 比较火,所

准备 LVM Volume Provider - 每天5分钟玩转 OpenStack(49)

Cinder 真正负责 Volume 管理的组件是 volume provider. Cinder 支持多种 volume provider,LVM 是默认的 volume provider.Devstack 安装之后,/etc/cinder/cinder 已经配置好了 LVM,如下图所示: 上面的配置定义了名为"lvmdriver-1"的 volume provider,也称作 back-end.其 driver 是 LVM,LVM 的 volume group 名为"st

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. vol

Backup Volume 操作 - 每天5分钟玩转 OpenStack(59)

本节我们讨论 volume 的 Backup 操作. Backup 是将 volume 备份到别的地方(备份设备),将来可以通过 restore 操作恢复. Backup VS Snapshot 初看 backup 功能好像与 snapshot 很相似,都可以保存 volume 的当前状态,以备以后恢复.但二者在用途和实现上还是有区别的,具体表现在: Snapshot 依赖于源 volume,不能独立存在:而 backup 不依赖源 volume,即便源 volume 不存在了,也可以 rest

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

前面已经学习了 Cinder 的架构和相关组件,从本节我们开始详细分析 Cinder 的各种操作,首先讨论 Cinder 如何创建 volume. Create 操作流程如下: 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 API(cinder-api)发送请求:"帮我创建一个 volume". API 对请求做一些必要处理后,向 Messaging(RabbitMQ)发送了一条消息:"让 Scheduler 创建一个 volume". Sche

你真的会 snapshot 吗? - 每天5分钟玩转 OpenStack(163)

​这是 OpenStack 实施经验分享系列的第 13 篇.   instance snapshot 操作可用于备份或者将 instance 保存为新的 image.如果在生产系统中执行 snapshot 操作,必须确保此操作快速且安全.这里有两个关键点: 快速. 为保证数据的一致性,snapshot 时需要 pause instance,操作完后再 resume.在这个过程中 instance 是无法对外服务的,为了减少对业务的影响,我们希望 snapshot 越快越好. 安全. 即数据一致性