Libvirt RBD 镜像后端对 glance 多存储的支持¶
https://blueprints.launchpad.net/nova/+spec/rbd-glance-multistore
目前，Nova 并不原生支持 Glance 知道的多个 Ceph RBD 后端。如果只有一个，Nova 和 Glance 将协同工作，实现快速轻量级的镜像到 VM 克隆行为。如果有多个，Nova 通常无法很好地处理这种情况，在最坏的情况下会导致无声的缓慢行为，在最好的情况下会导致实例启动失败保护机制。我们可以做得更好。
问题描述¶
在某些情况下，在单个 OpenStack 部署中拥有多个独立的 Ceph 集群是可取的。最常见的是多站点或边缘部署，重要的是 Ceph 集群在物理上靠近它所服务的计算节点。Glance 已经能够处理多个 Ceph 集群，但 Nova 对此一无所知，因此这种配置会导致非常不理想的行为。
通常，当 Glance 和 Nova 协同处理单个 Ceph 部署时，镜像由 Glance 在操作员或用户上传时存储在 Ceph 中。当 Nova 开始启动实例时，它会要求 Ceph 对该镜像进行写时复制克隆，这非常快速和高效，不仅可以减少启动时间并降低网络流量，还可以跨所有计算节点共享基本镜像。
另一方面，如果您有两个计算节点组，每个组都有自己的 Ceph 部署，则目前必须格外小心，以确保存储在一个 Ceph 中的镜像不会在分配给另一个 Ceph 的计算节点上启动。Glance 可以表示单个逻辑镜像存储在一个或两个 Ceph 存储中，Nova 在实例启动期间会查看此信息。但是，如果镜像不在其本地 Ceph 集群中，它将安静地从 Glance 下载镜像，然后每次从该镜像启动实例时，将其作为原始扁平镜像上传到其本地 Ceph。这会导致比预期更多的网络流量和磁盘使用量。我们合并了一个解决方法，以使 Nova 拒绝这种反常行为，但这只会导致实例启动失败。
用例¶
作为操作员，我希望能够在具有每个站点一个 Ceph 集群的单 Nova 部署中，并保留在使用单个 Ceph 时获得的这种高性能的写时复制行为。
作为一名高级用户，目前必须先将镜像预复制到远程站点的 Ceph 后端，然后才能启动实例，我希望不必担心这些事情，只需让 Nova 为我完成即可。
提议的变更¶
Glance 已经可以表示单个逻辑镜像存储在多个位置。最近，它获得了一个 API 来促进后端存储之间镜像的复制。这意味着 API 消费者可以通过执行方法为“copy-image”的“import”操作来请求将镜像从一个存储复制到另一个存储。
此规范中提出的更改是增强现有的 libvirt RBD 镜像后端代码，以便在需要时可以使用此镜像复制 API。目前，我们已经查看所有镜像位置以找到与我们的 Ceph 集群匹配的位置，然后使用该位置进行克隆。在实施此规范后，该代码仍将检查所有当前位置，如果没有任何匹配项，则要求 Glance 将镜像复制到适当的后端存储，以便我们可以继续进行操作，而不会出现故障或其他不良行为。
在我们需要 Glance 将镜像复制到我们的存储的情况下，Nova 可以通过 Glance 维护在镜像上的特殊镜像属性来监视操作的进度。这些指示该过程正在进行中（通过 os_glance_importing_to_stores），并提供导入失败的通知（通过 os_glance_failed_import）。Nova 需要轮询镜像，等待过程完成，并且需要一些配置旋钮来允许进行适当的调整。
备选方案¶
另一种选择是始终什么都不做。这是在现有支持之上增强的行为。我们可以只是告诉人们不要使用多个 Ceph 部署，或者添加进一步的检查以确保如果他们这样做，我们不会做愚蠢的事情。
我们可以以更全面的方式教 Nova 了解多个 RBD 存储，这基本上需要从 Glance 中提取 Ceph 信息，或者将 Nova 配置为具有 Glance 拥有的所有相同的 RBD 后端。但是，我们需要教 Nova 了解拓扑结构，并配置它以避免使用远程 Ceph，仅仅因为镜像就在那里。
数据模型影响¶
无。
REST API 影响¶
无。
安全影响¶
用户已经可以使用 Glance 中的镜像导入机制，因此 Nova 代表他们使用它不会导致权限升级。
通知影响¶
无。
其他最终用户影响¶
这消除了用户需要了解部署配置和拓扑结构的细节，并消除了手动将镜像预先放置在存储中的需要。
性能影响¶
镜像启动时间当然会受到复制发生时影响。总体性能会更好，因为操作员将能够利用更多的 Ceph 集群（如果他们希望），并将它们放置在靠近它们所服务的计算节点的位置。
其他部署者影响¶
为了使这项工作正常进行，需要进行一些额外的配置。具体来说，Nova 需要知道表示其配置为使用的 RBD 后端的 Glance 存储名称。此外，将需要一些与我们轮询 Glance 服务器以获取复制状态的频率以及我们愿意等待的总体超时时间相关的超时可调参数。
另一个部署注意事项是，Glance 需要一个能够执行后台任务的 API 设置，才能支持 image_import API。这意味着 mod_wsgi 或类似工具，因为 uwsgi 不提供可靠的后台任务支持。这只是 Glance 的要求，但值得在此处说明。
开发人员影响¶
对 imagebackend 代码的实际影响并不大，因为我们只是使用 Glance API 中的一种新机制来完成镜像在后端之间复制的复杂工作。
升级影响¶
为了利用此新功能，至少需要来自 Ussuri 的 Glance，才能用于 Victoria Nova。单个 nova-compute 服务可以在部分升级场景中立即利用此新功能，因此不需要对该服务的最低版本进行检查。控制平面不知道每个计算节点连接的 RBD 后端，因此此功能不需要控制平面级别的升级敏感性。
实现¶
负责人¶
- 主要负责人
danms
功能联络人¶
- 功能联络人
danms
工作项¶
将
image_import函数通过nova.image.glance模块传递教 libvirt RBD 镜像后端模块如何使用新的 API 在必要且适当的时候将镜像复制到其自己的后端。
记录管理员的正确设置要求
依赖项¶
Glance 的要求已经着陆并可用
测试¶
显而易见的单元测试。
功能测试结果证明非常困难，因为我们在模拟的 libvirt 实现下模拟了大量的底层镜像处理代码。为这个添加功能测试需要对所有这些测试基础设施进行大量重构，这超过了此更改中的实际代码量。
Devstack 测试结果相对容易。我认为我们可以在每次运行中通过更改该作业来获得此功能的可靠测试，方法是
启用 Glance 和 Nova 多存储支持。
启用 Glance 镜像转换支持，以便在上传默认 QCOW Cirros 镜像时自动将其转换为原始格式。
创建两个存储，一个基于文件（如其他作业），一个基于 RBD（如当前的 Ceph 作业）。
将 Cirros 上传默认设置为基于文件的存储。
Tempest 测试中 Cirros 镜像的首次使用将导致 Nova 要求 Glance 将镜像从基于文件的存储复制到基于 RBD 的存储。后续测试会将其视为已在 RBD 存储中，并按正常方式进行。
这个真正的目标是促进 RBD 到 RBD 后端存储的复制，但从 Nova 的角度来看，文件到 RBD 是一个相同的过程，因此它是一个很好的类比，而无需在 devstack 作业中引导两个独立的 Ceph 集群。
文档影响¶
这主要是面向管理员的。目前意识到此限制的用户如果正在规避它，已经具有管理级别的知识。成功实施将只是消除未来对多个 Ceph 部署的关注。因此，管理员和配置文档就足够了。
参考资料¶
历史¶
发布名称 |
描述 |
|---|---|
Victoria |
引入 |
