使 cinder 驱动程序与多个存储兼容¶
https://blueprints.launchpad.net/glance_store/+spec/multiple-cinder-backend-support
从 Train 版本开始，Glance 完全支持配置多个 Glance 存储。Glance 可以配置为使用 cinder 作为存储，利用 glance_store 的可用 cinder 驱动程序。Cinder 提供卷类型，用于描述卷的特征。目前，Glance 的 cinder glance_store 只能使用一种卷类型。Train 版本中实现的多存储 Glance 的目的是让操作员能够向最终用户暴露具有不同特征的 Glance 存储。即使所有镜像最终都会存储在单个 cinder 安装中，操作员也可以通过创建不同的卷类型来暴露 cinder 中的不同存储类别。因此，当 cinder 安装暴露了具有不同特征的多个卷类型时，我们希望在这里做的是能够将不同的 Glance “存储”映射到 cinder 卷类型。
问题描述¶
1. 目前 cinder 可以配置不同的卷类型，但 Glance 只能使用其中一种可用的卷类型。如果 Glance 存储设置为使用 cinder，那么每次创建新镜像时，它总是会被上传到默认卷类型，除非操作员在 glance-api.conf 文件中配置了 cinder_volume_type。
2. 如果 cinder 存储配置为在 Glance 中使用，那么在创建镜像时，Glance 的 cinder 存储只会使用 cinder:// 前缀创建 location URL。当 cinder 配置了多个后端，并且 Glance 也配置了多个 cinder 存储时，很难分析镜像存储在哪个 cinder 存储中，因为镜像的 location url 格式为 cinder://<image_id>。
提议的变更¶
我们建议 Glance 能够暴露多个 cinder 存储，这些存储的区别在于每个存储使用的卷类型。这些存储应该以正常方式在 Glance 配置文件中使用 enabled_backends 选项定义（参见下面的示例）。此外，在使用多个 Glance 存储时，每个 cinder 存储必须设置 cinder_volume_type 选项。
在初始化存储对象时，Glance 将验证使用 cinder_volume_type 设置的卷类型是否存在于 cinder 中。如果不存在，则该存储将被排除，通过禁用“添加”和“删除”操作。要从 Glance 连接到 cinder，操作员需要在 glance-api.conf 文件中为每个存储指定 cinder_store_auth_address、cinder_store_user_name、cinder_store_password 和 cinder_catalog_info。
以下是一些多个 cinder 存储配置示例。
示例 1：全新部署
例如，如果 cinder 配置了 2 种卷类型 glance-fast 和 glance-slow，那么 Glance 配置应该如下所示；
[DEFAULT]
# list of enabled stores identified by their property group name
enabled_backends = fast:cinder,slow:cinder
# the default store, if not set glance-api service will not start
[glance_store]
default_backend = fast
# conf props for fast store instance
[fast]
rootwrap_config = /etc/glance/rootwrap.conf
cinder_volume_type = glance-fast
description = Really fast and expensive storage
cinder_catalog_info = volumev2::publicURL
cinder_store_auth_address = http://localhost/identity/v3
cinder_store_user_name = glance
cinder_store_password = admin
cinder_store_project_name = service
# etc..
# conf props for slow store instance
[slow]
rootwrap_config = /etc/glance/rootwrap.conf
cinder_volume_type = glance-slow
description = Slower but less expensive storage
cinder_catalog_info = volumev2::publicURL
cinder_store_auth_address = http://localhost/identity/v3
cinder_store_user_name = glance
cinder_store_password = admin
cinder_store_project_name = service
# etc..
示例 2：从单个 cinder 存储升级到多个 cinder 存储，如果 cinder.conf 中设置了 default_volume_type，并且 glance-api.conf 中也设置了 cinder_volume_type，那么管理员需要在 Glance 中创建一个 cinder_volume_type 与旧 Glance 配置相同的存储。
# cinder.conf
The glance administrator has to find out what the default volume-type is
in the cinder installation, so he/she needs to discuss with either cinder
admin or cloud admin to identify default volume-type from cinder and then
explicitly configure that as the value of ``cinder_volume_type``.
升级前示例配置
[glance_store]
stores = cinder, file, http
default_store = cinder
cinder_state_transition_timeout = 300
rootwrap_config = /etc/glance/rootwrap.conf
cinder_catalog_info = volumev2::publicURL
cinder_volume_type = glance-old
升级后示例配置
[DEFAULT]
enabled_backends = old:cinder, new:cinder
[glance_store]
default_backend = new
[new]
rootwrap_config = /etc/glance/rootwrap.conf
cinder_volume_type = glance-new
description = Newly defined second (cinder) store
cinder_catalog_info = volumev2::publicURL
cinder_store_auth_address = http://localhost/identity/v3
cinder_store_user_name = glance
cinder_store_password = admin
cinder_store_project_name = service
# etc..
[old]
rootwrap_config = /etc/glance/rootwrap.conf
cinder_volume_type = glance-old # as per old cinder.conf
description = Previously existing (cinder) store
cinder_catalog_info = volumev2::publicURL
cinder_store_auth_address = http://localhost/identity/v3
cinder_store_user_name = glance
cinder_store_password = admin
cinder_store_project_name = service
# etc..
操作员可以根据部署策略，通过与 cinder 管理员或云操作员协调，决定要使用的卷类型。
我们还建议修改 cinder 的 location url，并在 location url 中使用 store identifier，以便用户或操作员可以识别镜像存储在 Glance 的哪个 cinder 存储中。新的 location URL 应该如下所示：cinder://store-name/image-id。
对于存储在 cinder 后端中的旧镜像，我们将修改 Glance 的延迟加载机制，以根据新格式更新现有镜像的 location URL。延迟加载操作是在 GET API 调用之前进行的一个检查，它遍历镜像位置，并根据 location URI 识别镜像数据存储在哪个 Glance 存储中，并将该信息更新到 location 元数据中。这种机制也有用处，如果将来操作员决定更改 Glance 存储的名称或通过将镜像迁移到新存储来停用已配置的存储。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
安全性影响与单个存储时相同，但我们在此指出；镜像卷存储在配置的项目 cinder_store_project_name 中，并可以使用配置的用户 cinder_store_user_name 访问。
如果有人能够获取这些凭据并访问镜像卷，则可能存在潜在风险。最坏的情况是，如果他们有权执行 cinder 操作（例如 retype、attach 等），他们可能会更改镜像卷。
必须小心确保普通用户无法访问它。
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
从单个 cinder 存储升级到使用多个 cinder 存储后，第一次 image-list 或第一次 get 调用镜像将花费更多时间，因为我们正在执行延迟加载操作以使用新的镜像 location url 更新旧镜像 location url。后续的 get 或 list 调用将像以前一样执行。
其他部署者影响¶
操作员应该了解 cinder 中可用的不同卷类型。他们可以使用 cinder 客户端的 type-list 命令，或者与 cinder 管理员协调，决定应该在 glance-api.conf 中配置 cinder 的哪个卷类型。
开发人员影响¶
无
实现¶
负责人¶
主要负责人：* whoami-rajat * abhishek-kekane
- 其他贡献者
无
评审人员¶
核心评审人
jokke
rosmaita
smcginnis
工作项¶
修改 cinder 驱动程序初始化以设置新的 cinder location url
修改 cinder location url 的使用
修改延迟加载机制以更新旧镜像 location URL
单元测试
依赖项¶
无
测试¶
适当的单元和功能测试，以确保 Glance 的更改正常工作。我们还可以添加一个作业，该作业将使用 Glance 中的 cinder 存储运行测试。
文档影响¶
我们需要确保更新 glance/glance_store 文档，以说明
将 cinder 卷类型用作 Glance 的 cinder 存储。
我们还应该记录，如果 cinder 存储用作 Glance 后端，则应仅使用 Image Service API 来操作镜像。直接通过 Block Storage Service API 操作镜像数据不受支持，并且可能导致不利后果，包括数据丢失。
如何从单个 cinder 存储升级到多个 cinder 存储。
参考资料¶
无
