Manila/MountAutomation

简介

我们考虑了多种方案来解决挂载自动化问题。自从两年前开始考虑这个问题以来，我们的思路已经有了很大的进步，但我们仍然没有一种“万能”方案，可以在各种应用场景下工作且没有缺点。

问题

我们决定使用以下指标来评估各种方案

• 该方案是否仅限于特定场景？
• 该方案是否允许即时/同步挂载？
• 该方案是否允许在重启后仍然存在的持久挂载？
• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？
• 存在哪些安全考虑？
• 存在哪些网络考虑？
• 是否存在任何外部依赖？
• 该方案是否要求Manila存储任何状态？
• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？
• 实施该方案需要多少精力？
• 用户对该方案的抵触情绪有多大？
• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

除了没有万能解决方案之外，这个功能的难点在于，该功能并不能让用户做任何以前无法做的事情。在大多数情况下，这只是简化了已经可以完成的事情（除了上述DR用例）。

方案总结

考虑的方案

• SSH/PsExec（我们从一开始就考虑过的、非常成熟的方案）
• Agent - 编写自定义agent来解决问题（同样是成熟且古老的想法）
• 基于Zeroconf的广播 - 来自巴黎峰会的一个新想法
• AutoFS - 利用autofs在UNIX上解决问题
• LDAP/AD - 将挂载信息插入目录服务，并让客户端从那里拉取
• Cloud-Init - 搭便车Cloudinit（为此提供了一个可交付的演示，将在Liberty峰会上展示）
• VirtFS - virtfs为我们提供了最接近cinder的模型，并且挂载/卸载在此上下文中更有意义
• 什么都不做，并规定如何使用现有工具（例如Heat）来自动化挂载。

方案

SSH/PsExec

自动化挂载最简单、最广泛使用的方案是使用操作系统中已有的管理软件。对于UNIX，这是SSH。对于Windows，将是各种形式的Windows远程管理，例如PsExec（PsExec是一种类似于SSH的工具，几乎可以在所有Windows机器上开箱即用）或PowerShell。

这里的想法是给Manila提供所有客户端的root密码、root密钥或管理员凭据，并让Manila联系它们以触发它们在适当的时候挂载或卸载共享。

该方案的价值在于它不依赖于标准操作系统设施以外的任何东西，因此很可能具有广泛的兼容性。

• 该方案是否仅限于特定场景？

好 否。

• 该方案是否允许即时/同步挂载？

好 是。

• 该方案是否允许在重启后仍然存在的持久挂载？

好 是。

• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？

坏 否。

• 存在哪些安全考虑？

坏 租户必须将管理员凭据交给Manila，用于所有他们希望Manila自动化挂载的客户机。这可能会造成巨大的信任障碍。

• 存在哪些网络考虑？

坏 Manila需要直接访问每个需要自动化挂载的客户端的网络。在某些情况下这很容易，而在其他情况下则几乎不可能。

• 是否存在任何外部依赖？

注意 Manila需要一个SSH客户端（容易）和一个PsExec客户端（困难）。PsExec是一个Windows二进制文件，可以移植到UNIX，但很可能需要付出相当大的成本。

• 该方案是否要求Manila存储任何状态？

注意 是。Manila需要存储客户端的凭据，以及IP地址和网络信息以查找客户端。

• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？

好 是。如果Manila可以随意推送挂载操作，那么在DR故障转移的情况下自动更新挂载就成为可能。

• 实施该方案需要多少精力？

注意 对于UNIX，中等。对于Windows，如果我们想使用PsExec，则要高得多。

• 用户对该方案的抵触情绪有多大？

好 是可选的，但有些用户可能会选择不使用此功能，因为需要将root凭据交给Manila。

• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

坏 是。Manila需要了解客户端及其网络。这目前超出了Manila的范围。

代理

编写agent为我们提供了终极的灵活性。agent可以监听来自Manila的请求，可以定期或在启动时从Manila拉取更新，并且可以在客户端的任何时间执行任何我们喜欢的更改。当您可以假定客户端上存在agent时，许多问题都变得简单。

这种方法显然存在缺点，主要是大多数用户对在客户机上安装新软件的信任问题，以及创建和维护新软件所涉及的巨大精力。还有安全问题，因为如果agent软件中的错误使用户面临危险和混乱，我们将承担责任。

• 该方案是否仅限于特定场景？

好 否。

• 该方案是否允许即时/同步挂载？

好 是。

• 该方案是否允许在重启后仍然存在的持久挂载？

好 是。

• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？

好 是。

• 存在哪些安全考虑？

坏 我们自己设计安全。这为我们提供了极大的灵活性，但我们必须设计一种在保护用户和可用性之间取得良好平衡的东西，这始终很难。无论如何，在没有经过验证的记录之前，我们将面临信任问题。

• 存在哪些网络考虑？

注意 网络考虑因素与SSH方法类似，因为Manila需要联系并戳agent。此外，agent还需要一条反向路径回到Manila服务器以执行拉取请求，这在启动时可能是可取的。

• 是否存在任何外部依赖？

注意 外部依赖是agent本身。我们不能强迫任何人安装它，因此在它不存在的情况下，我们将无法做任何事情。

• 该方案是否要求Manila存储任何状态？

注意 是。Manila需要跟踪agent和一些安全信息，以便与它们联系并进行身份验证。

• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？

好 是。

• 实施该方案需要多少精力？

坏 非常高。

• 用户对该方案的抵触情绪有多大？

坏 非常抵触。这是另一个需要安装的东西，另一个需要安全审计的东西。另一个需要担心的事情。

• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

坏 是。Manila不仅需要了解客户端和客户端网络，还需要创建一个全新的项目并维护该软件。

基于Zeroconf的广播

Zeroconf是一种有趣的在网络上广播服务的方法，它构建在DNS（或对等环境中mDNS）之上。Zeroconf对CIFS共享和NFS导出的广播具有现有支持，但没有证据表明现代操作系统会自动对这些广播做出反应（例如，自动挂载它们）。

Zeroconf也只能解决挂载自动化的半个问题。它可以通知客户端某个可以挂载的东西的存在，但它不会告诉他们确切地挂载在哪里。对于某些场景，随机挂载点可能可以接受（VDI），但对于其他场景，这将是致命的（数据库即服务）。

不太可能使用这种方法解决卸载问题。

• 该方案是否仅限于特定场景？

坏 是。

• 该方案是否允许即时/同步挂载？

注意 也许。

• 该方案是否允许在重启后仍然存在的持久挂载？

注意 也许。

• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？

好 是。

• 存在哪些安全考虑？

好 可能没有。

• 存在哪些网络考虑？

坏 Zeroconf严重依赖于多播，而多播很少跨越路由器边界（管理员必须配置多播路由）。为了将广播发送到正确的网络，Manila需要执行一些奇怪的体操，很可能涉及具有大量网络端口的服务VM。

• 是否存在任何外部依赖？

坏 是。Zeroconf并非在所有客户机镜像中普遍可用或启用。

• 该方案是否要求Manila存储任何状态？

注意 是。Manila需要知道向哪些客户端广播以及在哪些网络上广播。

• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？

坏 否。基于广播的方法不太可能允许快速卸载-移动-挂载语义，从而干净地进行故障转移。

• 实施该方案需要多少精力？

坏 未知，但不是小。可能存在我们可以用来进行基于zeroconf的广播的现有库，但为了使其工作，所有服务VM和网络工作仍然需要付出相当大的努力。

• 用户对该方案的抵触情绪有多大？

好 非常少。该方法并不具有侵入性，除了可能令人恐惧的服务VM，它连接到数千个网络以发送广播。

• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

坏 是。Manila需要了解客户端和网络才能向它们广播。此外，我们需要维护放置在广播服务VM上的软件镜像。这将需要创建一个新的GitHub仓库并维护一个新项目。

AutoFS

许多UNIX用户已经使用autofs来控制大量的NFS挂载。autofs的优势在于，您可以更改服务器上的单个文件，然后数千个客户端可以突然挂载新内容。

一个缺点是autofs实际上不会立即挂载内容。它是一个基于事件的系统，依赖于客户端侧的即时挂载，因此如果客户端在挂载之前尝试访问挂载点，它会询问服务器正确的挂载内容并挂载它。这给更改或卸载挂载带来了真正的问题，因为在没有重启或其他本文档中描述的方法的情况下，它们基本上是不可能的。

另一个缺点是autofs非常灵活。不同的用户可能以非常不同的方式使用它，并且单一方法可能无法满足所有用户的需求，而无需用户进行一些自定义。

• 该方案是否仅限于特定场景？

坏 是。它将仅适用于UNIX，并且仅当autofs在使用中时，并且仅当autofs配置为与Manila兼容时才有效。

• 该方案是否允许即时/同步挂载？

坏 不是真的。即时方法是即时的，除了挂载实际上在需要时才会发生。

• 该方案是否允许在重启后仍然存在的持久挂载？

好 是。

• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？

好 是。

• 存在哪些安全考虑？

注意 Manila需要对autofs表所在的位置具有写访问权限。这可能因情况而异，但它将是敏感信息，并且对其的访问将始终受到保护。

• 存在哪些网络考虑？

好 没有。

• 是否存在任何外部依赖？

注意 是，需要autofs。

• 该方案是否要求Manila存储任何状态？

好 可能不是。Manila可以简单地推送autofs更新，然后忘记它们，正确的事情就会发生。

• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？

坏 可能不是。Autofs对更改不友好，因为一旦客户端挂载了它，它就不会再回过头从服务器拉取更改。

• 实施该方案需要多少精力？

好 相当低。这只是修改autofs表的一些代码。如果尝试变得聪明并支持许多使用autofs的方式，则工作量会增加。

• 用户对该方案的抵触情绪有多大？

好 非常低。用户喜欢这个想法，但他们可能没有仔细考虑所有缺点。

• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

好 否。此功能可以在不显着更改Manila本身的情况下实现。

LDAP/AD

目录服务创建了一个集中式位置，供客户端获取信息。挂载列表可以是一种存储在目录服务中的信息。例如，对于Windows，AD服务器会告诉每个用户他的主目录在哪里。在UNIX上，LDAP可以是一个类似存储库，但与autofs结合使用进行挂载。

我们尚未100%确定这些工具是否开箱即用就足够灵活，但它们提供了一个合理的构建块，可以与一些脚本结合使用以促进挂载自动化。也就是说，这种方法有足够的缺点，以至于我们没有认为深入研究是值得的。

• 该方案是否仅限于特定场景？

坏 是。并非所有环境都有LDAP/AD。

• 该方案是否允许即时/同步挂载？

坏 否。

• 该方案是否允许在重启后仍然存在的持久挂载？

好 是。

• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？

好 是。

• 存在哪些安全考虑？

注意 Manila需要对LDAP/AD服务器具有写访问权限。理论上，我们已经通过共享网络安全服务的一部分拥有了这一点，但并非所有客户端都实际使用该功能，因此这将使设置安全服务成为先决条件。

• 存在哪些网络考虑？

好 没有。

• 是否存在任何外部依赖？

注意 是，LDAP/AD服务器。以及与这些服务器通信的Manila软件。

• 该方案是否要求Manila存储任何状态？

好 否。

• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？

坏 否。

• 实施该方案需要多少精力？

注意 中等。将一些记录存储在服务器上并不难。挑战是让客户端软件与这些服务通信。

• 用户对该方案的抵触情绪有多大？

好 相当低。它不具有侵入性，并且搭便车他们已经做的事情。

• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

好 否，除非我们需要编写一些与AD或LDAP通信的新软件。

Cloud-Init

Clout-init在OpenStack云中广泛可用（但远非普遍可用）。它在启动时运行并从目录服务中拉取身份信息。我们可以将我们的挂载信息存储在该目录中，并让Cloud-Init为我们执行挂载。

这类似于基于agent的方法，除了agent由其他人拥有并且仅在启动时运行，因此无法监听请求。

作为一种略微不同的方法，由Cloud-Init插入的脚本可以从Nova元数据服务获取挂载信息，该服务不会存储Manila数据，但会按需查询Manila以获取最新的共享挂载。

• 该方案是否仅限于特定场景？

注意 是。Cloud-Init很常见，但绝非普遍存在。

• 该方案是否允许即时/同步挂载？

坏 否。

• 该方案是否允许在重启后仍然存在的持久挂载？

好 是。

• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？

好 是。

• 存在哪些安全考虑？

注意 Manila需要访问修改Cloud-Init拉取的目录，或者Cloud-Init调用的服务（即Nova元数据服务）需要Manila凭据）。但是，这是一种简单的信任关系，应该易于配置。

• 存在哪些网络考虑？

好 没有。

• 是否存在任何外部依赖？

注意 依赖于Cloud-Init。

• 该方案是否要求Manila存储任何状态？

好 否。

• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？

好 否（除非客户端在相同的DR故障转移期间重新启动）。

• 实施该方案需要多少精力？

好 相当低。我们对此进行了原型设计（Nova元数据服务+Cloud-Init），只需一周时间。

• 用户对该方案的抵触情绪有多大？

好 相当低。喜欢Cloud-Init的用户会发现这是自然扩展。

• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

好 否。

VirtFS

VirtFS由hypervisor控制，并且非常类似于Cinder/基于块的方法，因为客户机只是看到一个PCI PnP事件并对其做出反应。Manila只需要与Nova通信，我们可以安全地忽略客户机。

VirtFS的缺点是众所周知的——主要是Windows客户机缺乏支持、某些hypervisor缺乏支持以及对裸机的缺乏支持。

• 该方案是否仅限于特定场景？

坏 是，仅在可以使用VirtFS的情况下。

• 该方案是否允许即时/同步挂载？

好 是。

• 该方案是否允许在重启后仍然存在的持久挂载？

好 是。

• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？

好 未定义。就像Cinder一样，没有附加到当前未运行的实例的卷的概念。

• 存在哪些安全考虑？

好 没有。

• 存在哪些网络考虑？

好 没有。

• 是否存在任何外部依赖？

坏 VirtFS。以及一些管理virtfs/hypervisor设置的东西——Nova将是执行此操作的明显选择。

• 该方案是否要求Manila存储任何状态？

好 否。

• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？

好 是。事实上，这种方法是使DR无缝化的最佳方法。

• 实施该方案需要多少精力？

好 低。在这种情况下，我们实际上在Manila中没有做很多事情，因为所有VirtFS工作都在Nova中进行。

• 用户对该方案的抵触情绪有多大？

注意 混合。有些人喜欢virtfs，有些人讨厌它。对于可能的情况，它将非常吸引人。对于不可能的情况，谁在乎？

• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

好 否。

什么都不做

这里的想法是认识到挂载自动化不是一个功能。我们在Manila中添加的任何内容都无法实现您手动无法完成的操作，而且试图简化一个已经可以使用现有工具更有效地简化的任务是没有意义的。

考虑一个使用Heat创建Manila共享，并使用Nova实例提供某种服务的流程。Heat拥有执行挂载所需的所有信息，并且Heat完全有能力自动化这些类型的操作。客户可能更喜欢自己执行此操作，因为他们将获得额外的灵活性，并且不会被Manila内部实施的狭隘方法所限制。

如果我们选择这种方法，我们将专注于向用户提供如何利用Heat等工具自动化挂载的示例，并将这些示例添加到文档中。

这种方法没有明显的缺点，除了它感觉像是在回避问题。

• 该方案是否仅限于特定场景？

好 否。

• 该方案是否允许即时/同步挂载？

好 是。

• 该方案是否允许在重启后仍然存在的持久挂载？

好 是。

• 当客户端在挂载/卸载时处于离线状态时，该方案是否能够处理？

好 是。

• 存在哪些安全考虑？

好 在Manila中没有。显然，执行自动化的工具（例如Heat）需要身份验证凭据，但这些工具无论如何都需要这些凭据，因此它们在很多方面最适合解决安全问题。

• 存在哪些网络考虑？

好 在Manila中没有。显然，执行自动化的工具（例如Heat）需要访问客户端的网络权限，但这些工具无论如何都需要这些权限，因此它们在很多方面最适合处理网络复杂性。

• 是否存在任何外部依赖？

好 没有真正的依赖关系。您需要自带自动化工具，并且依赖关系是您带来的任何内容。

• 该方案是否要求Manila存储任何状态？

好 否。

• 该方案是否允许Manila启用在没有挂载自动化情况下不可能实现的使用场景，例如在DR故障转移时自动更新挂载？

坏 不，除非灾难恢复故障转移也由与挂载自动化相同的流程自动化。

• 实施该方案需要多少精力？

好 很少。这主要是一项文档工作。

• 用户对该方案的抵触情绪有多大？

好 完全不抵制，因为这种选择赋予他们最大的灵活性。一些用户可能会对没有“一键搞定”的功能感到失望，但那本来就是幻想。

• 该方案是否要求Manila扩展其项目范围（以管理当前不了解的事物）？

好 否。

插件方法

基于上述方法的优缺点，以及基于其他人可能会有其他解决此问题的方法的可能性，我们建议通过在Manila中构建一个“插件”框架来解决此问题，该框架可以使用各种方法实现挂载自动化。

我们将假设上述所有方法最终都将由社区中的不同人实现，并且核心功能的目的是提供基本的原始操作，以允许所有方法工作。实际使用哪些方法将取决于单个部署者或租户做出的选择。

插件方法需要提供一种机制来跟踪客户端和共享之间的“附件”，并允许负责执行挂载和卸载的软件查询该机制并接收更改通知。

设计需要回答的一些问题

• 共享可以附加到哪些类型的对象？IP？网络？用户？Nova实例？
• 共享何时变为“已附加”？在授予访问权限时？还是在调用单独的“附加”API时？
• 谁是附件信息/通知的消费者？管理员？租户？两者都有？

插件设计应包含足够的细节，以便我们确信可以容纳所有提出的方法，但是我们不会实际设计所有上述方法。我们将从设计1或2个非常流行的方法开始（以证明该方法并使其真正可用），并鼓励社区扩展其他方法。

假设的流行方法

• Cloud-Init 与 Nova 元数据
• Nova 代理