OpenStack Cinder 与 Ceph 使用进阶篇（基于 Icehouse 版本）

本帖最后由 pig2 于 2014-10-14 09:13 编辑
阅读导读：
1.Cinder QoS API可以完成什么功能？
2.RabbitMQ在openstack中作用是什么？
3.每个卷在 Cinder 中都有一个对应的 Host 负责管理该卷是为了解决什么问题？

OpenStack Cinder 作为 OpenStack 世界里一个早期项目之一，实质上现在已经成为一个相当成熟的项目了。它的 API 实现已经基本覆盖了对于卷管理的需求，剩下的都是比较难以两全的如高可用卷。Ceph 是 Cinder 非常受欢迎的 Backend 之一，对于 API 的实现也非常完整。因此，本文主要会主要介绍以 Ceph 作为 Backend 的 Cinder 的一些使用。下面内容主要面向 Ceph Backend(RBD)，但也可能适用其他存储类型，主要基于 Icehouse 版本。

Ceph 的选项
“rbd_flatten_volume_from_snapshot”: RBD Snapshot 在底层会快速复制一个元信息表，但不会产生实际的数据拷贝，因此当从 Snapshot 创建新的卷时，用户可能会期望不要依赖原来的 Snapshot，这个选项开启会在创建新卷时对原来的 Snapshot 数据进行拷贝来生成一个不依赖于源 Snapshot 的卷。
“rbd_max_clone_depth”: 与上面这个选项类似的原因，RBD 在支持 Cinder 的部分 API(如从 Snapshot 创建卷和克隆卷)都会使用 rbd clone 操作，但是由于 RBD 目前对于多级卷依赖的 IO 操作不好，多级依赖卷会有比较严重的性能问题。因此这里设置了一个最大克隆值来避免这个问题，一旦超出这个阀值，新的卷会自动被 flatten。对于这个问题，实际上社区已经有相关的解决方案了(RBD: Shared flag, object map)，这个实现目前是由本人完成大部分工作，由于依赖 Sage 的 notify 改进，因此还需要一定时间。

“rbd_store_chunk_size”: 每个 RBD 卷实际上就是由多个对象组成的，因此用户可以指定一个对象的大小来决定对象的数量，默认是 4 MB，在不太了解 Ceph 核心的情况下，这个选项的默认值已经足够满足大部分需求了。

Cinder Host 与高可用
我们这里的高可用并不是指 Cinder-API 的高可用，而是 Cinder-Volume。每个卷在 Cinder 中都有一个对应的 Host 负责管理该卷，主要是为了解决卷操作的竞争问题(当然 LVM 实质上只有该 Host 才能操作)，对于一个卷的所有操作对会被 API 节点转发到对应的 Host 上处理。这个 Host 实际上就是创建该卷的 Cinder-Volume Host 名。因此，如果某一个 Cinder-Volume 所在的主机挂掉，会导致该主机之前创建的所有卷无法操作。对于共享存储类型的 Backend 来说，它需要能够让其他 Cinder-Volume也能处理这些请求。

利用 Migrate API
既然由 Volume 的 Host 字段来负责请求的分发，那么最初的方案就是直接修改一个卷的 Host，如使用 cinder migrate-volume 对于共享存储类型的 Backend 来说，只需要简单修改 Host 就行了。那么这样就可以在每次 Cinder-Volume 挂掉以后迁移所有属于该 Host 的 Volume 就行了，这个对于共享存储类型来说操作实际上还是很轻量的，只需要修改数据库的一个字段。

利用 RabbitMQ
上面这个方案在面对私有云内部来说实际上还是有点麻烦，那么利用 RabbitMQ 就是做到类似 Proxy 的机制，在两个不同的服务器上启动两个 Cinder-Volume，但是在 cinder.conf 里指定 Host 名为同一个，那么这样就可以利用 RabbitMQ 默认的 round-robin 调度策略来轻松实现卷操作的高可用可以利用 VIP 和 Placemaker 实现 Host 可达方案。

Cinder 的多 Backend
通常来说，用户的存储需求是多样化且复杂的，因此需要 Cinder 提供不同类型的 Backend 支持。这里我们举例使用 Cinder Multi Backend 机制来实现 Ceph 多个 Pool 的管理。

首先基本的管理和指南可以参考官方的文档Configure multiple-storage back ends。在已存在卷的 Cinder 环境下，如果将 Cinder 配置切换成支持 Multi-Backend 的版本，需要一些 Tricky 的方式来修改卷的 Host。在配置好 Multi-Backend 以后，可以看到 Cinder-Volume 的 Host 会变成原来的 Host 名加上 Backend 名，因此数据库中原来卷和 Snapshot 都需要修改对应的 Host。

Ceph 的多 Pool 支持就可以简单修改对应 backend 配置组里的 “rbd_pool” 就行了，使用户可以使用 –volume-type 来指定卷所属的 Pool。

Nova 根分区 QoS
利用 Cinder QoS API 实现对卷 QoS 的管理OpenStack Cinder的QoS特性预览，实际上，如果将 Nova 与 Ceph 整合，那么根分区同样需要 QoS 的支持。在目前的 Nova 版本里，实际上早就有对应的 QoS 支持。但是 Ceph 所挂载的卷是 Network 类型，因此目前还需要使用者自己加上 ‘Network’ 选项。