注意

本文档适用于 Ceph 的开发版本。

报告文档错误

NFS

版本 Jewel 新增。

注意

使用基于 cephadm 或 Rook 的部署时，仅支持 NFSv4 协议。

Ceph 对象网关命名空间可以通过 NFSv4 导出，同时支持传统的 HTTP 访问协议（S3 和 Swift）。

特别是，现在可以将 Ceph 对象网关配置为在嵌入到 NFS-Ganesha NFS 服务器中时提供基于文件的访问。

管理 NFS-Ganesha 集群和 RGW 导出的最简单和首选方法是使用 ceph nfs ... 命令。有关详细信息，请参阅 通过 NFS 导出 CephFS 和 RGW。

librgw

librgw 库提供了一个可加载的接口来访问 Ceph 对象网关服务，并在初始化时实例化一个完整的 Ceph 对象网关实例。

反过来，librgw 导出 rgw_file，这是一个有状态的 API，用于对 RGW 存储桶和对象进行文件导向的访问。该 API 是通用的，但其设计受到 NFS-Ganesha 的文件系统抽象层 (FSAL) API 的强烈影响，主要就是为此设计的。

还提供了一组 Python 绑定。

命名空间约定

该实现符合 Amazon Web Services (AWS) 分层命名空间约定，该约定将 Unix 风格的路径名映射到 S3 存储桶和对象。

附加命名空间的顶层由 S3 存储桶组成，表示为 NFS 目录。从属于存储桶的文件和目录都表示为对象，遵循 S3 前缀和定界符约定，其中 '/' 是唯一支持的路径定界符 [1]。

例如，如果 NFS 客户端在“/nfs”挂载了一个 RGW 命名空间，那么 NFS 命名空间中的文件“/nfs/mybucket/www/index.html”对应于存储桶/容器“mybucket”中的 RGW 对象“www/index.html”。

尽管这对客户端来说通常是不可见的，但 NFS 命名空间是通过连接命名空间中对象所隐含的相应路径来组装的。叶子对象，无论是文件还是目录，都将始终在具有相应键名的 RGW 对象中实例化，如果是文件，则为“<name>”，如果是目录，则为“<name>/”。非叶子目录（例如上面的“www”）可能仅通过它们在一个或多个叶子对象的名称中的出现来隐含。在 NFS 中创建或由 NFS 客户端直接操作（例如，通过 chown 或 chmod 等属性设置操作）的目录始终具有用于存储实例化属性（例如 Unix 所有权和权限）的叶子对象表示。

支持的操作

RGW NFS 接口支持对文件和目录的大多数操作，但有以下限制

• 不支持链接，包括符号链接。

• 不支持 NFS ACL。

  • 支持 Unix 用户和组所有权以及权限。

• 目录不能移动/重命名。

  • 文件可以在目录之间移动。

• 仅支持完整、顺序的写入 I/O

  • 即，写入操作被限制为上传。

  • 许多典型的 I/O 操作（例如就地编辑文件）将由于执行非顺序存储而必然失败。

  • 一些表面上按顺序写入的文件实用程序（例如，某些版本的 GNU tar）可能会由于不常见的非顺序存储而失败。

  • 通过 NFS 挂载时，通常可以通过同步挂载选项（例如 Linux 中的 -osync）将顺序应用程序 I/O 限制为按顺序写入 NFS 服务器。

  • 无法同步挂载的 NFS 客户端（例如 MS Windows）将无法上传文件。

安全

RGW NFS 接口提供了一个具有以下特征的混合安全模型

• NFS 协议安全性由 NFS-Ganesha 服务器提供，由 NFS 服务器和客户端协商

  • 例如，客户端可以受信任 (AUTH_SYS)，或者要求提供 Kerberos 用户凭据 (RPCSEC_GSS)

  • RPCSEC_GSS 有线安全性可以是仅完整性 (krb5i) 或完整性和隐私性（加密，krb5p）

  • 各种 NFS 特定的安全和权限规则可用

    • 例如，root-squashing

• 一组 RGW/S3 安全凭据（NFS 未知）与每个 RGW NFS 挂载（即 NFS-Ganesha EXPORT）相关联

  • 通过 NFS 服务器执行的所有 RGW 对象操作都将由与正在访问的导出中存储的凭据相关联的 RGW 用户执行（目前仅支持 RGW 和 RGW LDAP 凭据）

    • 目前不支持其他 RGW 身份验证类型，例如 Keystone

手动配置 NFS-Ganesha 实例

每个 NFS RGW 实例都是一个嵌入完整 Ceph RGW 实例的 NFS-Ganesha 服务器实例。

因此，RGW NFS 配置包括本地 ceph.conf 中的 Ceph 和 Ceph 对象网关特定配置，以及 NFS-Ganesha 配置文件 ganesha.conf 中的 NFS-Ganesha 特定配置。

ceph.conf

RGW NFS 所需的 ceph.conf 配置包括

• 有效的 [client.rgw.{instance-name}] 部分

• 最小实例配置的有效值，特别是已安装且正确的 keyring

其他配置变量（例如 rgw data 和 rgw backend store）是可选的。

少数配置变量（例如 rgw_nfs_namespace_expire_secs）是 RGW NFS 所独有的。

特别是，前端选择由 librgw.so 运行时专门处理。默认情况下，仅启动 rgw-nfs 前端。额外的G前端（例如 beast）通过 rgw nfs frontends 配置选项启用。其语法与普通的 rgw frontends 选项相同。非默认前端的默认选项通过 rgw frontend defaults 正常指定。

ganesha.conf

用于 RGW NFS 的严格最小 ganesha.conf 包括一个带有嵌入式 RGW 类型 FSAL 块的 EXPORT 块

EXPORT
{
     Export_ID={numeric-id};
     Path = "/";
     Pseudo = "/";
     Access_Type = RW;
     SecType = "sys";
     NFS_Protocols = 4;
     Transport_Protocols = TCP;

     # optional, permit unsquashed access by client "root" user
     #Squash = No_Root_Squash;

     FSAL {
             Name = RGW;
             User_Id = {s3-user-id};
             Access_Key_Id ="{s3-access-key}";
             Secret_Access_Key = "{s3-secret}";
     }
}

Export_ID 必须具有整数值，例如“77”

Path（对于 RGW）应为“/”

Pseudo 定义 NFSv4 伪根名称（仅限 NFSv4）

SecType = sys; 允许客户端在没有 Kerberos 身份验证的情况下连接

Squash = No_Root_Squash; 允许客户端 root 用户覆盖权限（Unix 约定）。启用 root-squashing 时，root 用户尝试的操作将作为 NFS-Ganesha 服务器上的本地“nobody”（和“nogroup”）用户执行

RGW FSAL 还在 RGW 配置部分中支持 RGW 特定配置变量

RGW {
    cluster = "{cluster name, default 'ceph'}";
    name = "client.rgw.{instance-name}";
    ceph_conf = "/opt/ceph-rgw/etc/ceph/ceph.conf";
    init_args = "-d --debug-rgw=16";
}

cluster 设置 Ceph 集群名称（必须与正在导出的集群匹配）

name 设置 RGW 实例名称（必须与正在导出的集群匹配）

ceph_conf 提供要使用的非默认 ceph.conf 文件的路径

其他有用的 NFS-Ganesha 配置

任何应支持 NFSv3 的 EXPORT 块都应在 NFS_Protocols 设置中包含版本 3。此外，NFSv3 是支持 UDP 传输的最后一个主要版本。要启用 UDP，请将其包含在 Transport_Protocols 设置中。例如

EXPORT {
 ...
   NFS_Protocols = 3,4;
   Transport_Protocols = UDP,TCP;
 ...
}

一个重要的选项族涉及与 Linux idmapping 服务的交互，该服务用于跨系统标准化用户和组名称。此处不提供 idmapper 集成的详细信息。

对于 Linux NFS 客户端，NFS-Ganesha 可以配置为接受带有 NFSv4 的客户端提供的数字用户和组标识符，默认情况下，NFSv4 会将其字符串化——这可能在小型设置中以及用于实验时有用

NFSV4 {
    Allow_Numeric_Owners = true;
    Only_Numeric_Owners = true;
}

故障排除

NFS-Ganesha 配置问题通常通过使用调试选项运行服务器来调试，由 LOG 配置部分控制。

NFS-Ganesha 日志消息分为各种组件，可以为每个组件分别启用日志记录。组件日志记录的有效值包括

*FATAL* critical errors only
*WARN* unusual condition
*DEBUG* mildly verbose trace output
*FULL_DEBUG* verbose trace output

示例

LOG {

  Components {
      MEMLEAKS = FATAL;
      FSAL = FATAL;
      NFSPROTO = FATAL;
      NFS_V4 = FATAL;
      EXPORT = FATAL;
      FILEHANDLE = FATAL;
      DISPATCH = FATAL;
      CACHE_INODE = FATAL;
      CACHE_INODE_LRU = FATAL;
      HASHTABLE = FATAL;
      HASHTABLE_CACHE = FATAL;
      DUPREQ = FATAL;
      INIT = DEBUG;
      MAIN = DEBUG;
      IDMAPPER = FATAL;
      NFS_READDIR = FATAL;
      NFS_V4_LOCK = FATAL;
      CONFIG = FATAL;
      CLIENTID = FATAL;
      SESSIONS = FATAL;
      PNFS = FATAL;
      RW_LOCK = FATAL;
      NLM = FATAL;
      RPC = FATAL;
      NFS_CB = FATAL;
      THREAD = FATAL;
      NFS_V4_ACL = FATAL;
      STATE = FATAL;
      FSAL_UP = FATAL;
      DBUS = FATAL;
  }
# optional: redirect log output
# Facility {
#     name = FILE;
#     destination = "/tmp/ganesha-rgw.log";
#     enable = active;
# }
}

运行多个 NFS 网关

每个 NFS-Ganesha 实例都充当一个完整的网关端点，但有一个限制，即目前无法将 NFS-Ganesha 实例配置为导出 HTTP 服务。与普通网关实例一样，可以启动任意数量的 NFS-Ganesha 实例，导出集群中相同或不同的资源。这使得 NFS-Ganesha 实例的集群化成为可能。但是，这并不意味着高可用性。

当常规网关实例和 NFS-Ganesha 实例重叠相同的数据资源时，它们将可以通过标准 S3 API 和通过 NFS-Ganesha 实例导出访问。您可以将 NFS-Ganesha 实例与 Ceph 对象网关实例放在同一主机上。

RGW 与 RGW NFS

目前不支持从同一程序实例导出 NFS 命名空间和其他 RGW 命名空间（例如，通过 Civetweb HTTP 前端导出的 S3 或 Swift）。

当在 NFS 之外添加对象和存储桶时，这些对象将在 rgw_nfs_namespace_expire_secs 设置的时间内出现在 NFS 命名空间中，默认值为 300 秒（5 分钟）。在 Ceph 配置文件中覆盖 rgw_nfs_namespace_expire_secs 的默认值以更改刷新率。

如果导出的 Swift 容器不符合有效的 S3 存储桶命名要求，请在 Ceph 配置文件的 [client.rgw] 部分中将 rgw_relaxed_s3_bucket_names 设置为 true。例如，如果 Swift 容器名称包含下划线，则它不是有效的 S3 存储桶名称，除非将 rgw_relaxed_s3_bucket_names 设置为 true，否则将被拒绝。

配置 NFSv4 客户端

要访问命名空间，请将配置的 NFS-Ganesha 导出挂载到本地 POSIX 命名空间中所需的位置。如前所述，此实现有一些独特的限制

• 首选 NFS 4.1 及更高版本协议

  • NFSv4 OPEN 和 CLOSE 操作用于跟踪上传事务

• 要成功上传数据，客户端必须保留写入顺序

  • 在 Linux 和许多 Unix NFS 客户端上，使用 -osync 挂载选项

挂载 NFS 资源的约定是特定于平台的。以下约定适用于 Linux 和某些 Unix 平台

从命令行

mount -t nfs -o nfsvers=4.1,noauto,soft,sync,proto=tcp <ganesha-host-name>:/ <mount-point>

在 /etc/fstab 中

<ganesha-host-name>:/ <mount-point> nfs noauto,soft,nfsvers=4.1,sync,proto=tcp 0 0

指定 NFS-Ganesha 主机名和客户端上的挂载点路径。

配置 NFSv3 客户端

Linux 客户端可以通过提供 nfsvers=3 和 noacl 作为挂载选项来配置为使用 NFSv3 挂载。要使用 UDP 作为传输，请将 proto=udp 添加到挂载选项中。但是，TCP 是首选传输

<ganesha-host-name>:/ <mount-point> nfs noauto,noacl,soft,nfsvers=3,sync,proto=tcp 0 0

如果挂载将使用版本 3 和 UDP，请使用版本 3 配置 NFS Ganesha EXPORT 块 Protocols 设置，并使用 UDP 配置 Transports 设置。

NFSv3 语义

由于 NFSv3 不向文件服务器传达客户端 OPEN 和 CLOSE 操作，RGW NFS 不能使用这些操作来标记文件上传事务的开始和结束。相反，当第一次写入发送到偏移量为 0 的文件时，RGW NFS 会开始新的上传，并在一段时间内（默认 10 秒）没有看到对文件的新写入时完成上传。要更改此超时，请在 Ceph 配置文件的 RGW 部分中为 rgw_nfs_write_completion_interval_s 设置备用值。

参考资料

[1]

http://docs.aws.amazon.com/AmazonS3/latest/dev/ListingKeysHierarchy.html

由 Ceph 基金会为您呈现

Ceph 文档是由非营利性 Ceph 基金会 资助和托管的社区资源。如果您希望支持这项工作和我们的其他努力，请考虑 立即加入。