观点：了解NFS 版本4的新动向

    自从 1984 年推出以来，网络文件系统 (NFS) 已成为网络文件共享的标准，尤其是在 UNIX® 和 Linux® 社区中。过去 20 年以来，NFS 协议已慢慢适应新需求和市场变化。

　　当时，NetApp 花费大量时间致力于推动 NFS 的发展以更好地满足用户需求。NetApp 首席技术官 Brian Pawlowski 是 NFS 版本 3 规范创作者之一 — 这是现在最为广泛使用的 NFS 版本 — 并且担任 NFS 版本 4 (NFSv4) 工作组的联合主席。NetApp 的 Mike Eisler 和 Dave Noveck 是 NFS 的最新可用版本 NFS 版本 4 规范的合著者，他们还是目前正在开发中的 NFS 版本 4.1 规范的编辑。

　　NFS 由服务器软件组成 — 例如，在 NetApp® 存储上运行的软件 — 要求访问网络存储并在主机上运行的客户端软件。恰当的操作要求连接的两端、即客户端和服务器端成熟并且已正确实施。尽管 NetApp 自 Data ONTAP® 6.4 以来就已发布我们的代码库 NFS 版本 4，但是直到今天 NFSv4 经过许多变更，并已明显成熟之后，才达到我们相信适用于生产的点。

　　今天，客户端的实施已趋于稳定。NetApp 在 Data ONTAP 7.3 中也进行了一些重要的更改和增强，以支持 NFS v4。在本文中，我将探索 NFSv4 的受到广泛关注的三个重要功能：

　　l 用于安全和 Windows® 兼容性的访问控制列表 (ACL)

　　l Kerberos 带来的强制安全性

　　l 客户端缓存委派

　　尽管此讨论将大量应用于任何 NFSv4 实施，但是我还将描述一些 NetApp 特有的详细信息并在合适时讨论最佳实践。

　　表 1) NFSv3 和 NFSv4 的比较。

　　

　　表 2) NFSv4 客户端和服务器实施状态。

　　

　　关于 ACL 的唯一其他最佳实践是每个 ACL. 使用不超过 192 个 ACE 您可以提高每个 ACL 的 ACE 数量到当前的最大数 400，但是执行这样的操作意味着带来是否必需转为 Data ONTAP 的更早版本或是否使用 SnapMirror® 转至较早版本的问题。

　　强制安全性

　　除包括 ACL 之外，NFSv4 还通过以下措施提高了上个 NFS 版本的安全性：

　　l 要求带加密的具有很强的 RPC 安全性

　　l 通过一个安全的带内系统，协商在服务器和客户端之间使用的安全性类型

　　l 使用字符串而不是整数来表示用户和组标识符

　　NFS 安全性已获得基于“一般安全性服务 API (GSS-API)”的安全性附加功能支持，称为 RPCSEC_GSS [RFC2203]。NFS 的所有版本均可以使用 RPCSEC_GSS。但是，要实施一致的 NFS 版本 4 就必须实施 RPCSEC_GSS。RPCSEC_GSS 是分配的类似于常用的 AUTH_SYS 安全性，后者是上个 NFS 版本中标准的身份验证方法。

　　RPCSEC_GSS 在以下两个方面有别于 AUTH_SYS 和其他传统的 NFS 安全机制：

　　l RPCSEC_GSS 不只是身份验证。它能执行完整性校验和与整个 RPC 请求和响应体的加密。因此，RPCSEC_GSS 提供远远不只身份验证的安全性。

　　l 由于 RPCSEC_GSS 只封装 GSS-API 消息标记 — 它仅作为 Kerberos 等安全机制的特定机制标签的传输 — 添加新安全机制(只要它们符合 GSS-API)不要求重新编写 NFS 的重要部分。

　　
图 1) 配有 AUTH_SYS 的 NFS 与 RPCSEC-GSS 安全性相比。

　　NFSv3 和 NFSv4 可以使用 RPCSEC-GSS。但是，AUTH_SYS 是 NFSv3 的默认值。

　　目前 NetApp 或大多数 NFSv4 客户端在 RPCSEC_GSS 下提供的唯一安全机制是 Kerberos 5。Kerberos 是使用对称密钥加密的一种身份验证机制。它从不以明文或加密形式在整个网络中发送密码，并且从不在用户使用网络资源之前，依靠加密票证和会话密钥验证他们的身份。Kerberos 系统采用含有用户名和密码的集中式数据库的密钥分配中心 (KDC)。NetApp 支持两种类型的 KDC：UNIX 和 Windows Active Directory。

　　只要您需要，您仍然可以选择使用上个 NFS 版本 (AUTH_SYS) 的弱身份验证方法。您可以通过在 exportfs 命令行或 /etc/exports 文件中指定 sec=sys 来完成。使用 AUTH_SYS 时，Data ONTAP 仅支持一个证书内的最多 16 个补充组 ID 加上 1 个主要组 ID。 Kerberos 支持最多 32 个补充组 ID。

　　客户端缓存委派

　　在 NFSv3 中，客户端通常当作它们已打开的文件之间存在竞争(尽管通常不是这种情况)来处理。通过从客户端到服务器的频繁请求以查证是否打开的文件已被其他人修改，系统保持了较弱的一致性，这会导致不必要的网络流量并在高延迟的环境中造成延误。在客户端锁定文件的情况下，所有写 I/O 必须同步，这在很多情况下将进一步影响客户端性能。

　　NFSv4 与 NFS 以前的版本不同，它允许服务器将文件上的专门活动委派给客户端，以便实现更多积极的客户端数据缓存并允许缓存锁定状态。服务器通过委派放弃对文件更新和客户端的锁定状态的控制。通过允许客户端在本地执行不同的操作和缓存数据，减少了延迟。目前存在两种类型的委派：读和写。服务器在存在文件竞争时能够从客户端调回委派。

　　一旦客户端具有委派，它就能在已在本地缓存数据的文件上执行操作，以避免网络延迟并优化 I/O。由委派引起的更为积极的缓存在具有以下特点的环境中能发挥较大的作用：

　　l 频繁打开和关闭

　　l 频繁的 GETATTR

　　l 文件锁定

　　l 只读共享

　　l 高延迟

　　l 快客户端

　　l 具有多个客户端的重负荷服务器

　　Data ONTAP 支持读写委派，并且您可以单独调整 NFSv4 服务器以启用或禁用委派的一种或全部两种类型。打开委派时，Data ONTAP 会自动向客户端授予打开文件读取的读委派，或向客户端授予打开文件写入的写委派。

　　系统提供启用或禁用读写委派选项，以便您对委派影响具有一定水平的控制。理想情况下，服务器将确定是否向客户端提供委派。在读操作高度密集的环境中，打开读委派会很有用。在工程设计中写委派将构建这样的环境，环境中每个用户写入单独的构建文件并且性能还会由于不存在竞争而改善。但是，在同一文件具有多个写入者的情况中，写委派可能没有多大用处。