Manila/design/manila-ceph-native-driver

Ceph Native Driver

在此上下文中，native 指的是客户机将使用 Ceph 网络协议访问共享，而不是通过任何网关（如 NFS 或 CIFS）。此驱动程序将成为任何后续启用对 CephFS 的 NFS 访问的驱动程序的基础。

协议和认证

CephFS 有自己的网络协议。要访问共享，客户机必须使用 CephFS 客户端之一（FUSE 或 Kernel 客户端）：这需要客户机上安装正确的软件包。它还需要对 Manila 进行扩展，以处理新的协议——这类似于 GlusterFS native 驱动程序的变更。

CephFS 有自己的认证系统。请参阅 https://wiki.openstack.org/wiki/Manila/design/manila-auth-access-keys，了解通过 Manila 以友好的方式公开此功能的提案。我们不使用 IP 地址或 X509 证书。访问权限授予用户 ID，这些 ID 由驱动程序隐式在 Ceph 中创建。当我授予“alice”访问权限时，如果该用户不存在，则会创建该用户。

如果没有 auth-access-keys 蓝图描述的机制，我们可以使用一种不太优雅的用户工作流程来实现 CephFS 驱动程序，在这种工作流程中，用户需要使用 Ceph CLI 加上 Manila API 来处理他们的用户认证需求。事实上，由于 auth-access-keys 的实现依赖于驱动程序从 allow_access 返回密钥（并且现有的 API 忽略返回值），因此 CephFS 驱动程序可以从 allow_access() 返回其密钥，如果 auth-access-keys 代码不存在，则会被忽略。

特性

Ceph 驱动程序将最初实现快照和一致性组。它将不会实现复制。

驱动程序之外的变更

API 代码中允许使用新的 access_type "cephx"，用于验证访问控制请求。

在 SUPPORTED_SHARE_PROTOCOLS 中添加了新的协议 "CEPHFS"

驱动程序实现细节

为了 Manila 和类似 Manila 的系统，创建了一个新的 Python 接口来访问 Ceph，称为 ceph_volume_client。这将在 Ceph master 中很快发布（撰写本文时为 2015 年 12 月 3 日），并将包含在 2016 年春季的 Ceph Jewel 稳定版本中。此驱动程序需要 Ceph 集群版本 >= Jewel，并且与任何旧版本的 Ceph 根本无法工作。

大部分实现都在 Ceph 内部，因此 Manila 驱动程序只是一个相当轻量级的包装器，只有几百行代码。

在 Ceph 内部，Manila 共享只是目录，其大小限制使用配额实现。这些对客户端看起来像单独的文件系统，因为它们挂载命名的子目录作为它们的共享。客户端被限制在其子目录中，通过 Ceph 授权功能：任何具有 Manila 发出的 auth identity 的客户端尝试挂载与正确配置的共享不同的目录，都将在服务器端被拒绝。

安全性和注意事项

由于驱动程序可能会使用 auth-access-keys 机制反馈访问密钥，因此必须小心防止类似以下的情况：

* Manila API consumer requests to grant access to "admin" user and receives the Ceph admin key in response
* Tenant A authorises "alice" to Share 1, and Tenant B also authorises "alice" to access Share 2, thereby giving Tenant B access to Share 1.

这将在驱动程序内部处理。

默认情况下，多个共享将共享相同的 Ceph 数据池。这将依赖于行为良好的客户端，不要随意窥探其他共享的数据。中期解决方案是通过 RADOS 命名空间划分共享。短期解决方案是在共享类型上提供一个可选的“data_isolated”标志：这将为每个共享创建一个物理上独立的的数据池，但会以额外的系统资源为代价。

由于共享大小使用配额设置，并且 Ceph 配额当前在客户端强制执行，因此我们依赖于行为良好的客户端，不要写入超过他们允许的数据量。目前只有 ceph-fuse 客户端尊重配额：使用 Kernel 客户端挂载其 Manila 共享的用户会发现他们可以写入任意多的数据。需要 Ceph 中的更改来解决此问题。