支持的文件系统协议简介

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

NFSv3

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

NFSv4.1

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

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

NFSv3 的优势

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

NFSv3 限制

以下是 NFSv3 限制的列表:

  • 不支持专用服务访问通道
  • 缺少客户端和服务器身份验证和加密。
  • 缺少客户端故障处理。

NFSv4.1 的优势

NFSv4.1 协议使用 RPCSEC_GSS 身份验证方法,该方法使用 LDAPKerberos 实现,用于提供客户端和服务器身份验证、消息完整性检查和传输中的数据加密。

这些安全功能使 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 托管解决方案,这两者都是 Filestore NFSv4.1 协议的要求。

强烈建议管理员使用 Managed Service for Microsoft Active Directory (Managed Microsoft AD) 来实现和管理 LDAP 和 Kerberos。

作为 Google Cloud 管理的解决方案,托管式 Microsoft AD 具有以下优势:

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

    • 通过确保用户和其各自的登录服务器距离较近,缩短延迟时间。
  • 支持 POSIX RFC 2307RFC 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 appendwrite 操作。nfs4_setfacl 实用程序还接受 RWX 作为快捷方式,并自动启用所有适当的标志。

  • nfs4_getfacl 不会自行对主账号进行任何转换。nfs4_getfacl 实用程序将显示正文的数字 UIDGUID。因此,系统会显示特殊的 OWNER@GROUP@EVERYONE@ 主账号。

  • 无论是否使用代管式 Microsoft AD,在使用 AUTH-SYSnfs4_setfacl 实用程序时,管理员都必须指定数字 UIDGUID,而不是用户名。此实用程序无法将名称转换为这些值。如果未正确提供,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 身份验证。此身份验证方法仅使用 LDAPKerberos 实现,这两种方法均可在代管式 Microsoft AD 中使用。不支持其他身份验证机制。

  • 不支持专用服务访问通道

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

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

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

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

后续步骤