准备 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 名为“stack-volumes-lvmdriver-1”。

Devstack 安装时并没有自动创建 volume group,所以需要我们手工创建。
如下步骤演示了在 /dev/sdb 上创建 VG “stack-volumes-lvmdriver-1”:

  1. 首先创建 physical volume /dev/sdb

    Linux 的 lvm 默认配置不允许在 /dev/sdb 上创建 PV,需要将 sdb 添加到 /etc/lvm.conf 的 filter 中。

  2. 然后创建 VG stack-volumes-lvmdriver-1

打开 Web GUI,可以看到 OpenStack 已经创建了 Volume Type “lvmdriver-1”

其 Extra Specs volume_backend_name 为 lvmdriver-1

后面各小节都将以 LVM 为 volume provider 详细讨论 volume 的各种操作。

时间: 2024-10-12 14:23:55

准备 LVM Volume Provider - 每天5分钟玩转 OpenStack(49)的相关文章

Snapshot Volume 操作 - 每天5分钟玩转 OpenStack(58)

Snapshot 可以为 volume 创建快照,快照中保存了 volume 当前的状态,以后可以通过 snapshot 回溯.snapshot 操作实现比较简单,流程图如下: 向 cinder-api 发送 snapshot 请求 cinder-api 发送消息 cinder-volume 执行 snapshot 操作 下面我们详细讨论每一个步骤. 向 cinder-api 发送 snapshot 请求 客户(可以是 OpenStack 最终用户,也可以是其他程序)向 cinder-api 发

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

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

Delete Volume 操作 - 每天5分钟玩转 OpenStack(57)

今天讨论 cinder 如何删除 volume . 状态为 Available 的 volume 才能够被 delete.如果 volume 当前已经 attach 到 instance,需要先 detach 后才能 delete. Delete操作实现比较简单,流程图如下: 向 cinder-api 发送 delete 请求 cinder-api 发送消息 cinder-volume 执行 delete 操作 下面我们详细讨论每一个步骤. 向 cinder-api 发送 delete 请求 客

Detach Volume 操作 - 每天5分钟玩转 OpenStack(55)

上一节我们成功地通过 attach 操作为 instance 添加了 volume,而与之相对的操作是 detach,就是将 volume 从 instance 上卸载下来. 下图是 Detach 操作的流程图 向 cinder-api 发送 detach 请求 cinder-api 发送消息 nova-compute detach volume cinder-volume 删除 target 下面我们详细讨论每一个步骤. 向 cinder-api 发送 attach 请求 客户(可以是 Ope

Neutron 如何支持多种 network provider - 每天5分钟玩转 OpenStack(70)

Neutron 的架构是非常开放的,可以支持多种 network provider,只要遵循一定的设计原则和规范.本节我们将开始讨论这个主题. 先讨论一个简单的场景:在 Neutorn 中使用 linux bridge 这一种 network provider. 根据我们上一节讨论的 Neutron Server 的分层模型,我们需要实现两个东西:linux bridge core plugin 和 linux bridge agent. linux bridge core plugin 与 n

Restore Volume 操作 - 每天5分钟玩转 OpenStack(60)

前面我们 backup 了 voluem,今天我们将讨论如何 restore volume. restore 的过程其实很简单,两步走: 在存储节点上创建一个空白 volume. 将 backup 的数据 copy 到空白 voluem 上. 下面我们来看 restore 操作的详细流程: 向 cinder-api 发送 backup 请求 cinder-api 发送消息 cinder-scheduler 挑选最合适的 cinder-volume cinder-volume 创建空白 volum

Extend Volume 操作 - 每天5分钟玩转 OpenStack(56)

前面我们讨论了 volume 的 attach 和 detach 操作,今天讨论如何扩大 volume 的容量.为了保护现有数据,cinder 不允许缩小 volume. Extend 操作用于扩大 Volume 的容量,状态为 Available 的 volume 才能够被 extend.如果 volume 当前已经 attach 给 instance,需要先 detach 后才能 extend. Extend 实现比较简单,流程图如下: 向 cinder-api 发送 extend 请求 c

外部 Storage Provider - 每天5分钟玩转 Docker 容器技术(149)

如果 Kubernetes 部署在诸如 AWS.GCE.Azure 等公有云上,可以直接使用云硬盘作为 Volume,下面是 AWS Elastic Block Store 的例子: 要在 Pod 中使用 ESB volume,必须先在 AWS 中创建,然后通过 volume-id 引用.其他云硬盘的使用方法可参考各公有云厂商的官方文档. Kubernetes Volume 也可以使用主流的分布式存,比如 Ceph.GlusterFS 等,下面是 Ceph 的例子: Ceph 文件系统的 /so

每天5分钟 玩转OpenStack

最近在学习OpenStack的相关知识,一直苦于OpenStack的体系庞大以及复杂程度,学习没有进度,停滞不前.偶然机会在51CTO上发现了一个热点的专题关于OpenStack的,题目叫做<每天5分钟 玩转OpenStack>,抱着试试的态度看了几篇,被文章的内容和书写风格吸引了,内容全面,思路清晰,简单易懂,关键是每篇博文的内容很少,绝对是一泡大便的功夫.每周一.周三.周五定时更新,微信也有同步更新.不过大神在博客园cnblogs上的博文没有目录,每次翻阅的时候甚是费劲,可能是大神太忙了,