支持 Glance 多存储

https://blueprints.launchpad.net/cinder/+spec/support-glance-multiple-backend

此蓝图建议支持 Glance 多存储。

问题描述

在 Rocky 和 Stein 中,Glance 添加了配置多个存储作为 EXPERIMENTAL 特性的能力 [1]。此功能计划在 Train 周期中完全支持。 这样,操作员可以配置一个或多个相同或不同类型的存储,并使用其中一个作为默认存储。 如果在上传镜像时未指定存储,则镜像将存储在默认存储中。

对于 Cinder upload-volume-to-image,如果不对 Cinder 进行任何更改,即使配置了多个存储,卷镜像始终会上传到默认存储。 这不会导致任何问题,但不能让操作员利用 Glance 多存储。

用例

  1. 一位操作员提供多个 Glance 镜像存储,这些存储通过某种期望度指标区分(如向每个存储的最终用户解释的那样),并且希望用户可以选择将哪个存储用于存储从 Cinder 卷创建的镜像。

提议的变更

在 volume-type extra-specs 中定义一个名为 ‘image_service:store_id’ 的字段。 使用 ‘image_service’ 作为 ‘store_id’ 键的命名空间,向调度器发出信号,该字段在卷构建调度时应被忽略。

该值是 Image Service API v2 stores discovery 响应中指示的存储 ‘id’

GET $IMAGE_API_URL/v2/info/stores

{
    "stores": [
        {
            "id":"reliable",
            "description": "Has a good transfer speed/price ratio"
        },
        {
            "id":"fast",
            "description": "Fast store with short transfer time",
            "default": true
        },
        {
            "id":"cheap",
            "description": "Inexpensive store for seldom used images"
        }
    ]
}

在 Train Forum 和 PTG 中讨论了 extra_specs 的验证 [2],因此出现了一个问题,即这将如何影响为 Glance 存储信息提议的 extra_specs 的使用。 如果验证实现遵循 Kilo 规范 [3],则验证将在 REST API 中发生。 验证代码可以在验证其他字段与适当的 Cinder 后端驱动程序之前过滤掉 ‘image_service:store_id’ 字段。 此外,代码可以通过对 Image Service API stores-info 进行调用并验证该值是否作为响应中 JSONPath $.stores[*].id 给出的列表的元素来验证 ‘image_service:store_id’ 设置。(在上面的示例中,这将是 ["reliable", "fast", "cheap"]。)

对该提案的一个反对意见是,Glance 存储应直接与 image-type 关联,而不是隐藏在 extra-specs 中。 但是,请考虑这对最终用户来说会是什么样子。 如果将新字段设为 volume_type 的一部分,它将像 ‘qos_specs_id’ 一样处理,并且 type-show 响应将如下所示

{
    "volume_type": {
        "description": "A new type",
        "extra_specs": {},
        "id": "9f319ace-a53c-40cb-8171-f12c4547baaf",
        "is_public": true,
        "name": "a_new_type",
        "os-volume-type-access:is_public": true,
        "qos_specs_id": null,
        "image_service:store_id": null
    }
}

这里的空值意味着将使用默认 Glance 镜像存储,但这让最终用户感到困惑,因为对空值的自然解释是此 volume_type 不允许将镜像上传到 Glance。 但是,如果我们使用 extra_specs,则使用默认 Glance 镜像存储的 volume type 将如下所示

{
    "volume_type": {
        "description": "Volume type using Glance default store",
        "extra_specs": {
            "volume_backend_name": "lvmdriver-1"
        },
        "id": "686cc9f0-f4ca-4a5a-b113-eeb57d3977fd",
        "is_public": true,
        "name": "lvmdriver-1",
        "os-volume-type-access:is_public": true,
        "qos_specs_id": null
    }
}

这与我们目前的情况完全相同,而希望指定存储的 volume type 将如下所示

{
    "volume_type": {
        "description": "Volume type specifying a Glance store",
        "extra_specs": {
            "volume_backend_name": "lvmdriver-1",
            "image_service:store_id": "cheap"
        },
        "id": "686cc9f0-f4ca-4a5a-b113-eeb57d3977fd",
        "is_public": true,
        "name": "lvmdriver-1",
        "os-volume-type-access:is_public": true,
        "qos_specs_id": null
    }
}

正如您所期望的那样,只有在指定与通常情况不同的内容时,才会引起您对 Glance 存储 ID 的注意。

此外,该提案不需要对 Cinder 数据模型或 REST API 进行任何更改,尽管这些考虑因素次于上述可用性影响。

厂商特定更改

备选方案

  • 将 ‘image_service:store_id’ 设为 volume_type 的属性,而不是 extra_specs 字段。 虽然这将尊重 extra_specs 描述 Cinder 后端属性的意图,但它具有 Proposed change 部分中提到的可用性问题,并且需要新的 API 微版本和数据库更改。

  • 在 ‘glance’ 部分添加一个新的 Cinder 配置选项 ‘store’,以将所有卷镜像上传到特定的 glance 存储。 如果未提供此选项,则所有卷镜像将上传到默认 glance 存储。 如果操作员不想向最终用户公开将卷镜像上传到特定存储的使用情况,则此解决方案将非常有效。 这是一个非常简单的更改,不需要任何 Block Storage API 更改或 python-cinderclient 中的更改。

    此替代方案的缺点是 Cinder 卷的所有镜像必须存储在同一个存储中。 如果操作员费心在 Glance 中配置了多个存储,那么很可能存在最终用户要求为不同的目的使用不同存储,并且很可能该操作员希望块存储用户能够利用 Glance 多存储功能。

  • 添加一个新的微版本到 volume-upload-to-image API,以支持将卷镜像上传到最终用户选择的特定 glance 存储。 这可以通过将一个新的输入请求参数 ‘store’ 添加到 volume-upload-to-image API 来完成。 如果请求中未指定 ‘store’ 选项,则镜像将上传到默认存储。 这样,最终用户可以选择任何可用的 Glance 存储。

    此替代方案的缺点是最终用户必须对 Image API 进行 GET /v2/info/stores 调用,以发现特定云中使用的存储标识符。 它还有一个缺点,即它的工作方式与 Cinder 对多个后端的支持不同,其中卷存储在哪个后端由卷类型确定。 最好使用对 Cinder 用户来说更熟悉的工作流程。

数据模型影响

REST API 影响

安全影响

通知影响

其他最终用户影响

无。 用户体验将与当前实践保持一致,即最终用户根据云操作员公开的特定功能选择卷类型。

性能影响

其他部署者影响

开发人员影响

实现

负责人

主要负责人

abhishek-kekane

其他贡献者

brian-rosmaita

工作项

  • 将 ‘image_service:store_id’ 处理添加到 Cinder create-image-from-volume 工作流程

  • 添加相关测试

依赖项

测试

  • 添加相关单元测试

  • 添加相关功能测试

  • 添加 tempest 测试

文档影响

操作员文档应根据规范实现进行更新。

参考资料