我是 Goutham Pacha Ravi，OpenStack Manila 项目的核心贡献者。以下是一份由一位希望保持匿名的运维人员提出的功能请求。幸运的是，该运维人员参与了上游 OpenStack 社区，该功能已在 OpenStack 2023.2 中交付，该版本被称为 Bobcat。
一位运维人员向 OpenStack Manila 团队报告称，一位用户在没有意识到该操作不可逆的情况下删除了 Manila 中的共享文件系统。该用户随后意识到应用程序正在积极地向共享文件系统写入数据，并在删除共享文件系统后崩溃。与块存储卷不同，共享文件系统不会跟踪连接的客户端，因此没有先决条件可以阻止删除共享文件系统。该用户没有执行“软删除”，将共享文件系统放入回收站一段时间，而是请求了永久删除。该用户没有使用 OpenStack Dashboard GUI (Horizon)，该 GUI 会为删除操作提供确认对话框。该用户没有对共享文件系统进行快照，无法从中恢复数据。像这样的意外操作可能会危及业务连续性。因此，Manila 的资源锁旨在避免这种情况。它们允许在传统共享文件系统的限制之上构建一个安全机制，并跟踪正在使用的共享文件系统。用户可以为任何原因在给定的共享文件系统上创建任意数量的锁，从而防止可能对其用例有害的操作。
目前，资源锁可以保护共享文件系统及其访问控制规则免受删除。由于共享文件系统是为 OpenStack 项目内的多个用户并发访问而构建的，因此可以创建多个锁。在创建锁时，用户提供他们希望阻止的操作以及锁定的原因。然后，资源锁被视为完成操作时 API 检查 的先决条件。如果有任何锁阻止了操作，则操作将被中止，并且向请求操作的用户提供适当的反馈。
资源锁还可以用于隐藏共享文件系统访问控制列表中的敏感字段。通常，访问控制列表对所有项目用户可用。但是，在某些情况下，用户可能希望阻止其他项目用户收集访问密钥或客户端标识符，例如提供访问权限的主机 IP 地址。通过在访问规则创建期间放置一个可见性锁，用户可以确保此数据对项目中的其他用户保持隐藏。您可以访问资源锁规范 此处 和 此处。
在 OpenInfra Summit 项目团队会议 (PTG) 上，我们收到了许多对 OpenStack Nova 中即将发布的功能的兴趣，即 VirtIOFS 附件。通过 VirtIOFS，OpenStack Manila 中的共享文件系统可以以类似于块存储卷的安全、超visor 介导的方式连接到虚拟机实例。Nova 需要在共享文件系统附加到虚拟机时放置一个删除锁。因此，在 Manila 中引入资源锁非常重要。VirtIOFS 是公共云运营商特别期待的一项功能，他们帮助我们优先交付它。独立地，Manila 团队计划在未来的版本中继续扩展资源锁框架，以应用于其他 API 资源和操作。
“VirtIOFS 功能是我们 Cleura 一直期待的，因为它将使我们的架构作为公共云运营商来说更好。它也使最终用户的用户体验和资源效率更好，创建与使用块存储卷相同的感觉。资源锁功能在这里也至关重要，可以获得良好的用户体验。有了这些功能，我们有信心将 Manila 投入生产，并向我们的客户提供作为服务提供的共享文件系统的长期要求的功能。我们非常感谢与社区，特别是 Manila 团队的良好合作，这确实表明了运营商和开发人员之间的协作有多么重要，以及我们如何通过这种协作做成伟大的事情。” – Tobias Rydberg，Cleura 的设计和架构负责人
感谢加入我一起为 OpenStack Bobcat 版本交付此功能的贡献者，Rene Ribaud，Red Hat 的软件工程师和 Carlos Eduardo da Silva，Red Hat 的软件工程师。
讨论将在即将到来的虚拟 PTG（10 月 23-27 日）上继续，届时运营商和开发人员将讨论 Manila 功能和计划用于 OpenStack 2024.1、Caracal 版本的错误请求。
了解更多关于 OpenStack Bobcat 的信息，OpenStack 第 28 个版本于 2023 年 10 月 4 日发布。
发表评论