启用卷的多重挂载

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/cinder/+spec/multi-attach-v3-attach

多年来，一直有用户要求能够同时将一个卷挂载到多个主机/服务器上。然而，Cinder 中的挂载工作流的实现使得这变得有些困难且不够健壮。

有了新的 Cinder 挂载 API [1]，这变得更容易了，因为挂载被视为独立的对象。

本规范提出了一系列更改，以启用和控制 Cinder 侧卷的多重挂载的使用。

问题描述

目前，如果卷已被挂载（正在使用），我们将拒绝挂载它。在某些情况下，云用户可能已经在 Cinder 卷上部署了集群文件系统，并且希望能够同时将卷挂载到多个主机/服务器上。

请注意，Cinder 不提供任何类型的文件系统检查或共享叠加，完全由用户来处理这些问题，并确定是否可以在不导致文件系统/数据损坏的情况下将卷挂载到多个位置。

本规范旨在解决的问题仅仅是启用将卷挂载到多个位置的能力，并为云运营商提供策略来启用/禁用云的功能。我们不提供任何机制来阻止用户损坏他们的数据或做一些可怕的事情。

术语

多重挂载 RO

以通常的方式（读写访问）挂载卷，然后以只读模式将其挂载到另一个主机/服务器的能力。请注意，这实际上很棘手，因为通常这需要消费者（例如 Nova/KVM）知道如何设置和强制只读访问已挂载的卷。

多重挂载 RW

以通常的方式（读写访问）挂载卷，然后将其挂载到另一个主机/服务器。在这种情况下，初始挂载和任何后续挂载之间没有区别。它们都被视为独立的项目，都是读写卷，没有真正的区别，超出了单个挂载所提供的范围。

将只读选项设置为挂载将作为 attachment-create 参数中的单独工作来处理。此功能不被视为本规范的范围的一部分，并将独立处理。

支持多重挂载的后端

某些后端设备可能根本不支持此功能。那些支持的被认为是“支持多重挂载的后端设备”，需要在其功能中报告这一点。

示例卷类型以通信多路径信息

{ ‘multiattach’: ‘<is> True’, }

Cinder 调度器将决定策略是否允许创建这些类型的卷，然后驱动程序需要以其模型返回中相应地形成相应的连接和卷属性。

再次注意，我们不会允许重新设置正在使用的卷的多重挂载设置。

用例

  • 可以使用 Oracle RAC 等产品，通过共享块设备实现类似 H/A 数据库的功能，这引起了一些兴趣。

  • 提出的另一个用例是能够拥有被动待机服务器/卷。

  • 从另一个实例或主机分析/榨取实例

提议的变更

多重挂载策略

创建一个 Cinder 策略，以启用/禁用卷的多重挂载能力。此策略是端点的全局策略，只需启用或禁用该功能即可。

此外，我们还需要一个特定的策略来启用/禁用可启动卷（设置了 bootable 参数为 True 的卷）的多重挂载能力。

支持多重挂载的卷类型

为了确保卷是在支持多重挂载的后端上创建的，需要在创建卷时使用允许此功能的后端。确保这一点唯一安全的方法是要求创建一种“multiattach”类型的卷并在卷创建时使用它。

如果对不是 multi-attach 启用的卷发出额外的挂载请求，则该请求应失败，因为该卷已被使用，或者应创建具有正确类型的新的卷，或者应重新设置卷类型。当然，如果策略允许并且类型正确，则应处理额外的挂载请求，并且现有的挂载保持活动状态且不会中断。

为了避免各种边缘情况和用户的困惑，本规范建议我们设置一条硬性规则，禁止重新设置正在使用的卷的挂载参数。无论这些更改是什么；multi–>non-multi，non-multi–>multi。

任何重新设置命令都应检查 multiattach 键，如果说键中有任何更改被请求，则重新设置应立即在 API 服务处失败。

请注意，默认值为 multiattach:False

还有一个额外的必需任务，卷创建时包含的 –allow-multiattach 参数需要被弃用，并且需要明确该标志与本规范中提出的并在 Cinder API 微版本 xyz 中实现的多重挂载实现无关。

关于强制分离的特殊考虑；最近的更改将没有连接器的挂载的分离视为 强制分离 操作。这在多重挂载场景中应该没问题，因为强制分离仅针对该挂载实例发出。换句话说，强制分离所做的一切就是忽略状态检查并断开指定的会话，而保持其他会话不变。Cinder 侧的过程应遵循标准的多重挂载分离过程，除了忽略卷的状态之外。

FWIW，该调用很少像用户期望的那样工作，所以也许现在是时候重新审视它了。也许弃用它，并将强制参数包含在 attachment-delete API 调用本身中？

备选方案

  • 保持云端并编写集群应用程序

  • 使用独立的数据实例

  • 接受它，你可能真的不需要这个

数据模型影响

N/A 所有需要的数据模型更改都应该已经到位。特别是卷对象上的现有 multiattach 列，它将向消费者发出信号，表明他们正在使用支持多重挂载的卷。因此，如果请求/创建了 multiattach:True 类型的卷，则其 multiattach 列设置为 True，否则设置为 False。

详细说明创建流程：管理员创建卷类型 multiattach，并使用 extra-specs: { ‘multiattach’: ‘<is> True’ }

如果用户想要一个多重挂载卷，他/她会发出指定 multiattach 类型的创建调用：cinder create –volume-type multiattach –name my-mavol 20

如果没有后端报告 multiattach: True，则调度将失败。不幸的是，此过程包括任务流重试，并且对象将被创建，调用者将获得 202 响应，但在任务流和调度器完成重试并无法找到后端后，卷状态将被设置为错误。如果需要，我们可以加快此过程，并在 API 层进行功能检查，以便我们可以立即使用无效请求进行响应。我们现在提供一个 API 调用，可以从系统中提取功能，因此我们可以在收到创建请求时进行检查，并确保可以满足该请求。根据定期功能报告缓存此信息而不是每次提取它可能明智。

REST API 影响

这会对 API 产生许多影响，最明显的是可以多次挂载一个卷。其他更改可能不太明显，例如表示卷的挂载状态，以及在处理或删除辅助挂载时管理状态更改。

一旦启用了多个挂载，当前的卷状态表示可能不足。

安全影响

N/A

通知影响

N/A

其他最终用户影响

用户可能会将卷挂载到多个服务器，并损坏他们的数据。

性能影响

N/A

开发人员影响

驱动程序需要添加一个功能字段“multiattach: True/False”，并对其端进行任何特殊处理以连接/断开此类卷。

实现

负责人

主要负责人

无

其他贡献者

无

工作项

  • 更新 Cinder 挂载/卸载以适应共享目标（大部分工作正在独立进行，有关更多信息，请参阅 依赖项 部分）

  • 实施策略更改

  • 实施 API 更改以允许/忽略挂载创建调用上的现有挂载。

  • 更新挂载/卸载卷状态转换，使其了解多重挂载，并确保它们反映正确的值。

  • 更新详细卷视图，可能还有摘要视图，以清楚地告知用户卷是否挂载到多个服务器。

依赖项

测试

https://review.openstack.org/#/c/266605/

将添加新的单元测试来测试更改后的代码，并且还需要添加功能测试。

文档影响

这将需要更新部署指南以及最终用户指南。

参考资料

相关的 Nova 规范：https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/cinder-volume-multi-attach.html