支持的文件系统协议简介

Filestore 支持以下文件系统协议：

NFSv3

  • 适用于所有服务层级。
  • 支持客户端与服务器之间的双向通信。
    • 使用多个端口。
    • 为网络流量和操作创建信任渠道。
  • 提供标准 POSIX 访问权限的快速设置。

NFSv4.1

  • 适用于可用区级、区域级和企业级服务层级。
  • 受 Filestore CSI 驱动程序支持，可用于创建区域实例或企业实例，并使用 NFSv4.1 语义装载这些实例。
  • 与现代防火墙配置兼容，并支持网络安全合规性要求。
    • 通信始终由客户端发起，并且始终通过单个服务器端口 2049 提供服务。
    • 支持客户端和服务器身份验证。

每种协议都最适合特定的使用情形。下表比较了每种协议的规格：

规范 NFSv3 NFSv4.1
支持的服务层级 所有服务层级 可用区级、区域级和企业级
双向通信 是 否。通信始终由客户端使用服务器端口 2049 发起。
身份验证 否 可以。需要使用 LDAP 和 Kerberos 实现的 RPCSEC_GSS 身份验证，这两者均可在 Managed Service for Microsoft Active Directory 中使用。
支持文件或目录访问控制列表 (ACL) 否 可以。每个列表最多支持 50 个访问权限控制条目 (ACE)。
群组支持 最多 16 个群组 连接到代管式 Microsoft AD 时，支持无限数量的群组。
安全设置 sys。创建信任渠道。 sys。创建信任渠道。krb5。对客户端和服务器进行身份验证。krb5i。提供身份验证和消息完整性检查。krb5p。提供身份验证、消息完整性检查和传输中数据加密。
操作延迟时间 无 操作延迟时间会随着所选安全等级的提高而增加。
恢复类型 无状态 有状态
文件锁定类型 网络许可管理器 (NLM)。锁定由客户端控制。 基于租约的咨询锁定。锁定由服务器控制。
支持客户端故障 否 是
支持专用服务访问通道 是 是
支持 Private Service Connect （已列入许可名单的正式版） 否 是

NFSv3 的优势

NFSv3 协议可快速设置标准 POSIX 访问权限。

NFSv3 限制

以下是 NFSv3 的限制列表：

  • 缺少客户端和服务器身份验证以及加密。
  • 缺少客户端故障处理。

NFSv4.1 的优势

NFSv4.1 协议使用 RPCSEC_GSS 身份验证方法，该方法通过使用 LDAP 和 Kerberos 来提供客户端和服务器身份验证、消息完整性检查以及传输中的数据加密。

这些安全功能使 NFSv4.1 协议能够满足现代网络安全合规性要求：

  • 使用单个服务器端口 2049 进行所有通信，有助于简化防火墙配置。

  • 支持 NFSv4.1 文件访问控制列表 (ACL)。

    • 每个 ACL 最多支持每个文件或目录 50 个访问控制条目 (ACE)。包括继承记录。

  • 使用托管式 Microsoft AD 集成时，支持无限数量的群组。

  • 支持通过基于租约的建议性锁定来更好地处理客户端故障。

    • 客户端必须验证与服务器的持续连接。如果客户端未续订租约，服务器会释放锁定，并且任何其他通过锁定租约请求访问的客户端都可以访问该文件。在 NFSv3 中，如果客户端在锁定状态下被删除，则其他客户端（例如新的 GKE 节点）无法访问该文件。

  • 支持有状态恢复。

    • 与 NFSv3 不同，NFSv4.1 是一种基于 TCP 和连接的有状态协议。恢复后，可以恢复上一个会话中的客户端和服务器状态。

Managed Service for Microsoft Active Directory

虽然 Managed Service for Microsoft Active Directory（代管式 Microsoft AD）不是严格要求，但它是唯一支持 LDAP 和 Kerberos 的 Google Cloud管理型解决方案，而这两者都是 Filestore NFSv4.1 协议的要求。

强烈建议管理员使用 Managed Service for Microsoft Active Directory（托管式 Microsoft AD）来实现和管理 LDAP 和 Kerberos。

作为一种 Google Cloud托管式解决方案，托管式 Microsoft AD 具有以下优势：

  • 提供多区域部署，支持在同一网域中最多部署在 5 个区域。

    • 通过确保用户及其各自的登录服务器彼此靠近，缩短延迟时间。

  • 支持 POSIX RFC 2307 和 RFC 2307bis，这是 NFSv4.1 实现的要求。

  • 自动执行唯一标识符 (UID) 和全局唯一标识符 (GUID) 用户映射。

  • 用户和群组可以在托管式 Microsoft AD 中创建或迁移到其中。

  • 管理员可以与当前的本地自管理型 Active Directory (AD) 和 LDAP 网域创建网域信任。使用此选项，无需迁移。

  • 提供服务等级协议 (SLA)。

访问权限控制和其他行为

  • Filestore NFSv4.1 ACE 在 Linux 上使用以下命令进行管理：

  • 每个 ACL 最多支持 50 个 ACE。有 6 个条目预留给由客户端 chmod 操作自动生成的 ACE。这些 ACE 可以在创建后进行修改。

    表示模式位的自动生成的 ACE 记录按以下优先级顺序列出：

    • DENY and ALLOW ACEs，共 OWNER@
    • DENY and ALLOW ACEs，共 GROUP@

    • EVERYONE@的DENY and ALLOW ACEs

      如果已存在此类 ACE，系统将根据新应用模式位重新使用并修改这些 ACE。

  • Filestore NFSv4.1 仅在 POSIX 模式 RWX（读取、写入和执行）下支持检查所需访问权限。它不会区分修改内容或 SETATTR 规范的 write append 和 write 操作。nfs4_setfacl 实用程序还接受 RWX 作为快捷方式，并自动开启所有合适的标志。

  • nfs4_getfacl 本身不会对主账号进行任何翻译。nfs4_getfacl 实用程序将显示主账号的数字 UID 和 GUID。因此，系统会显示 OWNER@、GROUP@ 和 EVERYONE@ 的特殊正文。

  • 无论是否使用托管式 Microsoft AD，在与 AUTH-SYS 和 nfs4_setfacl 实用程序搭配使用时，管理员都必须指定数字 UID 和 GUID，而不是用户名。此实用程序无法将名称转换为这些值。如果未正确提供，Filestore 实例将默认为 nobody ID。

  • 为文件指定写入权限时，或者为受继承的 ACE 影响的文件指定写入权限时，ACE 必须同时包含 w（写入）和 a（附加）标志。

  • 检查 SETATTR 的权限时，返回的响应类似于 POSIX，如下所示：

    • 超级用户或 ROOT 用户可以执行任何操作。
    • 只有文件所有者才能将模式位、ACL 和时间戳设置为特定时间和群组，例如文件所属的某个 GUID。
    • 文件所有者以外的用户可以查看属性，包括 ACL。

  • 单个 ACE 同时包含有效权限和仅限继承的权限。与其他 NFSv4.1 实现不同，Filestore 不会自动复制继承的 ACE，以区分有效 ACE 和仅继承的 ACE。

NFSv4.1 限制

NFSv4.1 协议具有以下限制：

  • 一般限制

    • 恢复备份时，新实例必须使用与源实例相同的协议。
    • 使用任何经过身份验证的 Kerberos 安全设置时，用户可能会遇到一些操作延迟。延迟时间会随着安全等级的提高而增加。
    • NFSv4.1 协议不支持 AUDIT 和 ALARM ACE。
    • 不支持数据访问审核。

  • GKE 限制

    NFSv4.1 协议无法与 Filestore Multishares for GKE 搭配使用。此功能仅支持 NFSv3。 如需查看每种 Filestore 服务层级和协议支持的 GKE 版本的完整列表，请参阅使用 Filestore CSI 驱动程序访问 Filestore 实例中的兼容性表格。

  • Managed Microsoft AD 限制

    • 配置完成后，请勿删除托管式 Microsoft AD 网域或网络对等互连。这样做会导致 Filestore 共享变得无法访问。
    • 唯一受支持的身份验证机制是 RPCSEC_GSS，该机制使用 LDAP 和 Kerberos（两者在托管式 Microsoft AD 中均可用）实现。
    • 如需让 Filestore 实例通过共享 VPC 加入托管式 Microsoft AD，您必须使用 gcloud 或 Filestore API，而不是 Google Cloud。
    • 受管 Microsoft AD 域名不得超过 56 个字符。

后续步骤