Cheesecake

包含您的 Launchpad 蓝图的 URL

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

本规范提出进一步完善 Cinder 的复制功能。在更多的厂商尝试实施复制后，并且我们学习了更多关于不同后端及其语义的经验教训，我们决定退一步，进一步简化这一功能。

新设计的目标是解决大量混淆和解释差异。与其尝试在第一个迭代中涵盖多种用例，本规范旨在解决一个相当明确的用例。然后我们可以迭代并从中前进。

问题描述

现有设计对于某些后端来说很棒，但对于许多设备来说很难适应。它也充满了陷阱，涉及到管理/非管理的问题，更不用说尝试处理某些卷的故障转移，而让其他卷保持运行。虽然基于卷而不是基于设备进行故障转移在测试中很好，但它并不适合预期的用例，并且会导致相当大的复杂性，而且也不是许多后端可以支持的事情。

用例

这旨在作为一种 DR 机制。使用案例模型是灾难性事件发生在后端存储设备上，但一些或所有位于主后端上的卷可能已复制到另一个后端设备，在这种情况下，这些卷可能仍然可访问。

事件流程如下：1. 管理员配置后端设备以启用复制。我们像往常一样配置了一个 cinder 后端（后端 A），但我们添加了用于复制目标（后端 B）的配置选项。

1. 我们不再处理管理和非管理之间的区分。现在，要启用复制目标，replication_target 条目是唯一允许的方法，并且在驱动程序中指定为一部分。

2. 根据后端设备，启用此功能可能意味着在设备上创建的每个卷都将被复制，或者对于那些具有该功能并且如果管理员选择这样做，可以创建一个“replicated=True”的卷类型，并由租户使用。

请注意，如果后端仅支持复制“所有”卷，或者管理员希望设置使“所有”卷都复制的情况，则可能不需要类型创建。

2. 租户创建一个已复制的卷（通过指定适当的类型，或通过后端设备的性质）。在此示例中的结果是一个名为“Foo”的卷。

3. 后端 A 卷入了不应该发生在数据中心的水球大战，并失去了它的魔力烟雾，“它死了吉姆！”

4. 管理员发出“cinder replication-failover”命令，可能带有参数 a. 调用传播到 Cinder 驱动程序，该驱动程序执行适当的步骤，以便该驱动程序现在指向辅助（目标）设备（后端 B）。

   2. Cinder 数据库中的服务表已更新，以指示已发生复制故障转移事件，并且驱动程序当前指向替代目标设备。

   在此场景中，已复制的卷应仍然可供租户访问。根据故障转移命令中提供的选项，使用可能会受到限制。如果没有设置任何限制，我们预计能够像在故障事件之前一样继续使用它们。

   已附加/正在使用的卷在此场景中是一个特殊情况，需要额外的步骤。在这种情况下，租户需要手动从任何实例中分离这些卷。Cinder 无法调用 Nova 的卷分离方法，因此必须由租户或管理员完成此操作。

   3. 作为故障转移参数提供的冻结选项。故障转移命令包括一个“freeze”选项。此选项指示卷仍然可以读取或写入，但是，在管理员发出“thaw”命令之前，我们不允许任何其他资源创建或删除选项。这意味着尝试调用 snapshot-create、xxx-delete、resize、retype 等应该返回 InvalidCommand 错误。这旨在尝试将事物保持在尽可能稳定的状态，以帮助从灾难性事件中恢复。我们认为后端资源从管理/控制平面角度来看变为只读。这并不意味着你无法从实例向卷进行 R/W IO。

5. 如何恢复到“正常”状态 a. 如果原始后端设备可以抢救，则应使用故障转移命令切换回原始主设备。这当然意味着后端应该有一些机制，并且管理员执行的操作以确保资源仍然存在于主设备（后端 A）上，并且它们的数据已根据在后端 B 上托管期间可能写入的数据进行更新。这表明对于支持此功能的后端，将需要类似双向复制的东西。对于无法支持此功能的后端，我们可能需要交换主次配置信息（重新配置，使后端 B 成为主设备）。

重要的是要强调，如果卷不是“replicated”类型，它在故障转移后将不可访问。这种方法将整个后端故障转移到另一个设备。

提议的变更

此补丁的目标之一是尝试消除管理和非管理复制目标之间差异的一些挑战。在此模型中，我们使后端更容易实现这一点。与其在不同的后端上拥有一些卷，并且不执行像统计更新这样的操作，我们现在故障转移整个后端，包括统计更新和所有内容。

这意味着非复制类型卷将被遗弃且无法访问（不可用），这是此用例中的预期情况（设备着火了）。我们应该像当前处理后端断开连接场景中的卷一样处理这些卷。这本质上就是这里发生的事情，实际上并没有什么不同。

为了简化第一次迭代，我们指定设备作为配置文件中的驱动程序参数，并且我们不尝试读取配置的辅助后端设备。

[driver-foo] volume_driver=xxxx valid_replication_devices=’remote_device={‘some unique access meta}’,…

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

• 添加以下 API 调用 replication-enable/disable ‘backend-name’

  这将向后端发出命令，以更新报告的复制功能。

  replication-failover [–freeze] ‘backend-name’ 这会触发故障转移事件，假设当前的主后端已不可访问。

  replication-thaw ‘backend-name’ 解冻经历故障转移并被冻结的后端

特殊考虑

• 异步与同步 本规范不对后端使用的复制方法做出任何假设，也不关心。

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

• 复制的后端卷驱动程序必须能够与另一个后端通信，并根据选择的当前主设备正确路由调用。这里的一个重要细节示例是“更新统计信息”调用。

  在发生故障转移的情况下，预计辅助/目标设备现在正在报告统计信息/功能，而不是现在已死的后端。

• 租户可见性 租户的可见性有限！！！换句话说，租户应该对正在发生的事情知之甚少。真正应该传播的唯一信息是后端和卷处于“故障转移”状态，以及它是否“冻结”。

在故障转移期间卷在新的后端上不可用时，驱动程序应为尝试访问它们的 API 调用引发 NotFound 异常。

备选方案

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

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

一个有吸引力的选择是让 Cinder 更加云端化，甚至不提供复制。

数据模型影响

我们需要在主机表中添加一列，指示“故障转移”和“冻结”状态。

我们还需要为卷添加一个新属性，指示它们是否已故障转移以及它们是否被冻结。

最后，为了规划后端可能具有多个复制目标的情况，我们需要为它们提供一种机制来持久化一些 ID 信息，以便发送故障转移的位置。换句话说，确保驱动程序可以在初始化时正确设置事物。

REST API 影响

replication-enable/disable ‘backend-name’

这将向后端发出命令，以更新报告的复制功能。

replication-failover [–freeze] ‘backend-name’

这会触发故障转移事件，假设当前的主后端已不可访问。

安全影响

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

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

  不

• 此更改是否以可能影响安全性的方式更改了 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 中的代码？或者它是否依赖于库的特定版本？

• 需要 Horizon 支持

测试

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

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

文档影响

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

显然，这需要在 cinder 文档树中添加文档和 devref 信息

参考资料

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

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

• 峰会会议记录的链接

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

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

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

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