VolumeReplication_V2

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/cinder/+spec/replication-v2

本规范提出复制功能的版本 2。目标是从 Juno 版本中添加的第一个版本的复制功能中吸取经验教训，看看是否可以对其进行改进，使其更广泛地被其他后端设备使用。

本规范建议使用我们所有的工具箱来实现复制。

1. 能力 - 确定我们是否可以执行与复制相关的任何操作

2. 类型/Extra-Specs - 提供用于供应商特定的自定义信息的机制，并帮助平衡不同后端的一些独特方面。

3. API 调用 - 提供一些通用的 API 调用，用于启用、禁用等操作

如果可以的话，简化状态管理也是一个不错的选择。

问题描述

当前实现相当复杂，并且已被证明对于后端设备来说难以实现，并且难以维护。关于状态管理和存储在数据库中的方式也存在一些担忧。

现有设计对于某些后端来说很棒，但对于许多设备来说很难适应。

用例

待定。

提议的变更

本规范建议对 Cinder 中的复制功能进行一些重大更改。我们仍然依赖于使用能力和类型来识别后端是否支持复制，并确保如果我们想使用该功能可以正确地放置卷。然而，主要区别在于副本的创建以及随之而来的生命周期。对于第一次迭代，我们只支持单个远程设备，但这在本规范中得到了考虑，并且可以轻松地扩展到包含在未来的工作中。后端设备（驱动程序）将列在 cinder.conf 文件中，我们添加条目以指示配对。这在配置文件中可能如下所示

[driver-foo]
volume_driver=xxxx
valid_replication_devices='backend=backend_name-a',
  'backend=backend_name-b'....

或者复制目标可能是 Cinder 未知的设备

[driver-foo]
volume_driver=xxxx
valid_replication_devices='remote_device={'some unique access meta}',...

或者两者的组合

[driver-foo]
volume_driver=xxxx
valid_replication_devices='remote_device={'some unique access meta}',
  'backend=backend_name-b'....

注意：远程设备的访问必须通过配置的驱动程序处理。

本建议表明我们将从创建调用中解耦复制信息。流程如下

• 创建一个类型为“replication_capable=True”且特定后端需要的任何自定义信息的卷。

• Cinder 使用能力过滤器的现有功能来选择支持请求复制类型的后端。这与当前的创建工作流程一致，我们只是在调度器中添加了另一个能力。

• 添加以下 API 调用 - enable_replication(volume) - disable_replication(volume) - failover_replicated_volume(volume) - update_replication_targets()

  • [添加配置外部目标的机制 * 可选]

  • get_replication_targets() + [管理员查询后端已配置内容的机制]

特殊考虑

• volume-types 在复制集中，主卷和辅助卷之间不需要 volume-types 的精确匹配。如果后端“可以”精确匹配这些类型，那很好，如果它们不能，那也可以。

  理想情况下，如果卷发生故障转移，类型规范应该匹配，但如果这不可能，可能可以接受，如果需要由驱动程序通过故障转移后的重定型/修改来处理，那也可以。

• 异步 vs 同步 本规范目前仅假设异步复制。以后可以轻松地扩展到同步情况，但目前它特定于异步。如果/何时添加同步，可以将其指定为额外的后端能力。如果需要，也可以通过 extra-specs 来指定。

• 传输 实现细节以及后端执行复制的方式完全取决于后端。要求是接口和最终结果保持一致。

• Cinder 不需要了解两个后端设备，但可以。本规范旨在提供灵活性，这意味着如果管理员希望配置 Cinder 未知的后端设备，那绝对是可以的。当然，事实相反也是如此，该细节在本规范中概述。

• 租户可见性 租户的可见性有限！！！换句话说，租户应该对正在发生的事情（如果有的话）知之甚少。

  例如，服务提供商可以将复制简单地作为定义为“高可用性”的卷类型来销售，并使其等同于复制。关键是，最终用户绝对不需要了解任何关于复制的信息（除非它让他们花费更多的钱）。

• 那些无法进行单个卷复制的设备怎么办？他们需要弄清楚他们想要做什么。例如，如果他们按池复制，那么他们也许足够复杂，可以将所有复制类型的卷放在同一个池中并复制整个池。

  我认为这里有很多选择，本规范的重点是不排除任何实现。

工作流程图

左侧的创建调用

• 工作流程没有改变

右侧的复制调用

• 直接到管理器，然后通过主机条目到驱动程序

     +-----------+
+--< +Volume API + >---------+        Enable routing directly to
|    +-----------+           |        Manager then driver, via host
|                            |
|                            |
|    +-----------+           |
+--> + TaskFlow  |           |
+--< +-----------+           |
|                            |
|                            |
|    +-----------+           |
+--> + Scheduler |           |
+--< +-----------+           |
|                            |
|                            |
|    +-----------+           |
+--> +  Manager  | <---------+
+--< +-----------+ >---------+
|                            |
|                            |
|    +-----+-----+           |
+--> +  Driver   + <---------+
     +-----+-----+

对于 attach、extend、clone、delete 等调用；如果后端主机不可达，或者如果 primary_host_status 列已设置，我们将重定向到 secondary_hosts 列中的主机。如果不可用，我们将失败，就像我们今天一样。

请参阅下面的 DB 部分

备选方案

有很多替代方案，最明显的是保留我们现有的实现并对其进行完善。也许这很好，也许不是。在我看来，这种方法更简单、更易于维护和更灵活；否则我不会提出它。现有设置中只有一家供应商实现了复制，并且他们目前有一些未解决的问题，我们现在采取行动不会造成太大的混乱或干扰。

结果应该是更容易实现的东西，并且作为一种选择，它对核心代码的影响更小。

数据模型影响

• 这将需要哪些新的数据对象和/或数据库模式更改？

没有，对于第一次传递，我们应该能够有效地使用现有的与复制相关的列。

REST API 影响

我们需要添加上面提到的 API 调用

• enable_replication(volume)

• disable_replication(volume)

• failover_replicated_volume(volume)

• udpate_replication_targets() [添加配置外部目标的机制 * 可选]

• get_replication_targets() [管理员查询后端已配置内容的机制]

我认为增强现有的调用比重用它们更好，但我们可以在提交阶段更仔细地研究。

安全影响

描述对系统造成的任何潜在安全影响。需要考虑的一些项目包括

• 此更改是否涉及敏感数据，例如令牌、密钥或用户数据？

  不

• 此更改是否以可能影响安全性的方式更改了 API，例如访问敏感信息的新方式或登录的新方式？

  不，据我所知

• 此更改是否涉及密码学或哈希？

  不，据我所知

• 此更改是否需要使用 sudo 或任何特权？

  不，据我所知

• 此更改是否涉及使用或解析用户提供的数据？这可能是直接在 API 级别，或间接例如更改缓存层。

  不，据我所知

• 此更改是否会启用资源耗尽攻击，例如允许单个 API 交互消耗大量的服务器资源？这方面的一些例子包括为每个连接启动子进程，或 XML 中的实体扩展攻击。

  不，据我所知

有关更详细的指导，请参阅 OpenStack 安全指南作为参考 (https://wiki.openstack.org/wiki/Security/Guidelines)。这些指南正在不断完善中，旨在帮助您识别安全最佳实践。有关更多信息，请随时通过 openstack-security@lists.openstack.org 联系 OpenStack 安全组。

通知影响

请指定任何通知的更改。无论是额外的通知、对现有通知的更改，还是删除通知。

其他最终用户影响

除了 API 之外，用户还有其他方式与此功能交互吗？

• 此更改是否对 python-cinderclient 有影响？那里的用户界面看起来如何？

性能影响

描述对系统造成的任何潜在性能影响，例如新代码将被调用多少次，以及现有代码的调用模式是否有重大变化。

需要考虑的一些示例包括

• 周期性任务可能看起来是一个小的补充，但在考虑大规模部署时，建议的调用实际上可能在数百个节点上执行。

• 调度器过滤器在为每个正在创建的卷为每个主机调用一次，因此它们引入的任何延迟与系统的大小成线性关系。

• 对实用函数或常用装饰器的微小更改可能对性能产生巨大影响。

• 导致数据库查询的调用会对性能产生深刻的影响，尤其是在代码的关键部分。

• 此更改是否包含任何锁定，如果是这样，对持有锁有什么考虑？

其他部署者影响

讨论将影响您部署和配置 OpenStack 的事情，这些事情尚未提及，例如

• 正在添加哪些配置选项？它们是否应该比建议的更通用（例如，其他卷驱动程序可能想要实现的标志）？默认值是否适用于实际部署？

• 此更改是否在合并后立即生效，还是需要显式启用？

• 如果此更改是新的二进制文件，将如何部署它？

• 请说明那些进行持续部署或从以前版本升级的人需要注意的任何事情。还描述了弃用配置值或功能的计划。例如，如果我们更改存储目标（LVM）的目录名称，我们如何处理更改落地之前创建的任何已使用的目录？我们是否移动它们？我们是否在代码中有一个特殊情况？我们是否假设操作员将重新创建云中的所有卷？

开发人员影响

讨论将影响在 OpenStack 上工作的其他开发人员的事情，例如

• 如果蓝图提出了对驱动程序 API 的更改，则需要讨论其他卷驱动程序如何实现该功能。

实现

负责人

谁在编写代码？或者这是一个蓝图，您正在将其抛出以查看谁会接受它？

如果有多个人正在进行实现，请指定主要作者和联系人。

主要负责人

john-griffith

其他贡献者

<launchpad-id 或 None>

工作项

工作项目或任务 – 将该功能分解为实施它需要完成的事情。这些部分可能最终由不同的人完成，但我们主要试图了解实施的时间表。

依赖项

• 包括对 Cinder 或其他项目中，此规范依赖或相关的规范和/或蓝图的具体引用。

• 如果这需要 Cinder 当前未使用的另一个项目的功能（例如，当我们以前只需要 v1 时，glance v2 API），请记录这一事实。

• 此功能是否需要任何新的库依赖项或未包含在 OpenStack 中的代码？或者它是否依赖于库的特定版本？

测试

请讨论如何测试更改。我们特别想知道将添加哪些 tempest 测试。假设将添加单元测试覆盖率，因此无需显式提及，但讨论为什么您认为单元测试就足够了，我们不需要添加更多 tempest 测试将需要包括在内。

鉴于当前的限制（可用的特定硬件/软件配置），这在 gate 中是否无法测试？如果是这样，是否有缓解计划（第三方测试、gate 增强等）。

文档影响

此更改对文档团队有什么影响？有些更改可能需要向文档团队捐赠资源以更新文档。不要重复上面讨论的细节，但请在此处引用它们。

显然，这将需要文档

参考资料

请添加任何有用的参考资料。您不需要有任何参考资料。此外，当您的参考资料不可用时，此规范仍然应该有意义。您可以包括的内容示例是

• 邮件列表或 IRC 讨论的链接

• 峰会会议记录的链接

• 如果合适，相关研究的链接

• 相关规范（例如，链接到任何厂商文档）

• 您认为值得参考的任何其他内容

  规范流程有点多，我们应该重新审视它。它有点臃肿，虽然前几个部分对于要求思考和计划来说很棒，但到最后它变得很荒谬。