支持的文件系统协议简介

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

NFSv3

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

NFSv4.1

每种协议都最适合特定的用例。下表比较了每种协议的规范：

规范 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（已列入许可名单的 GA 版） 否 是

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 (Managed Microsoft AD) 不是严格要求，但它是唯一一个同时支持 LDAP 和 Kerberos 的 Google Cloud管理解决方案，这两者都是文件存储空间 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 中创建用户和群组，也可以将其迁移到托管式 Microsoft AD。

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

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

访问权限控制和其他行为

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

  • 每个 ACL 最多支持 50 个 ACE。系统会预留 6 个条目，供客户端 chmod 操作创建的自动生成的 ACE 使用。这些 ACE 在创建后可以修改。

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

    • OWNER@ 的 DENY and ALLOW ACEs
    • GROUP@ 的 DENY and ALLOW ACEs

    • EVERYONE@的DENY and ALLOW ACEs

      如果已存在此类 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 的限制列表：

  • NFSv4.1 协议不能与以下功能结合使用：

  • NFSv4.1 协议不支持 AUDIT and ALARM ACEs。Filestore 不支持数据访问审核。

  • 配置完成后，请勿删除托管式 Microsoft AD 和网络对等互连。这样做会导致在客户端上挂载 Filestore 共享时无法访问该共享，从而导致您无法访问数据。 Google Cloud 对由管理员或用户操作导致的中断不承担责任。

  • 使用任何经过身份验证的 Kerberos 安全设置时，用户可能会遇到一些操作延迟。延迟率因指定的服务层级和安全设置而异。随着安全级别的提高，延迟时间也会增加。

  • 不支持数据访问审核。

  • Filestore NFSv4.1 解决方案使用 RPCSEC_GSS 身份验证，该身份验证是使用 LDAP 和 Kerberos 实现的，这两者均可在受管 Microsoft AD 中使用。与 NFSv3 类似，Filestore NFSv4.1 也可以在无需任何身份验证机制的情况下使用。不支持其他身份验证机制。

  • 如果您希望 Filestore 实例通过共享 VPC 加入托管式 Microsoft AD，则必须使用 gcloud 或 Filestore API。您无法使用Google Cloud 控制台将实例加入到托管式 Microsoft AD。

  • 受管理的 Microsoft AD 域名不得超过 56 个字符。

  • 如需创建企业实例，您必须直接通过 Filestore API 运行操作。如需了解详情，请参阅服务层级。

  • 恢复备份时，新实例必须使用与来源实例相同的协议。

后续步骤