Bikash R.Choudhury目前担任NFS/技术应用程序解决方案架构师，他现在主要是为使用NFS的技术应用程序解决方案设计体系结构，执行功能测试和认证，以及为 NFS 最佳实践提供全球合作伙伴联盟支持。Bikash 八年前在 NetApp 作为一名技术支持工程师开始自己的职业生涯，后来，他成为NetApp其中一位大客户的全球技术顾问 (TGA)。　　

自从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的受到广泛关注的三个重要功能：

　　·用于安全和 Windows兼容性的访问控制列表 (ACL)
　　·Kerberos 带来的强制安全性
　　·客户端缓存委派

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

　　访问控制列表

　　ACL对于寻求更大的Windows客户端兼容性的NetApp客户而言，它是请求最为频繁的功能之一。NFSv4 ACL 大大改善了NFS的安全性和与CIFS的互操作性。

　　ACL允许在每个用户的基础上授予或拒绝针对各个文件对象的访问权限，提供更为细化的访问权限控制和与传统的UNIX模式权限位相比程度更大的可选性。NFSv4 ACL基于NT原型，但是它们不包含所有者/组信息。NFSv4 ACL由访问权限控制条目(ACE)的数组组成，包含有关允许/拒绝访问的信息、许可权限位、用户名称/组名称和标记。

　　由于NetApp已向CIFS客户端提供ACL支持，NFSv4中的额外ACL功能将创建一些独特的考虑。NetApp提供三种类型的配额树 —UNIX、NTFS和混合型 — 用于不同的客户端。NFSv4 ACL的处理方式取决于配额树的类型：

　　UNIX配额树
　　·NFSV4 ACL 和模式位有效
　　·Windows 客户端不能设置属性
　　·UNIX 语义学占优势

　　NTFS配额树
　　·NT ACL 和模式位有效，；UNIX 客户端不能设置属性
　　·NFSv4 ACL 从用 NT ACL 访问文件的 NFS 客户端的模式位生成
　　·NT 语义学占优势

　　混合型配额树
　　·NFSv4 ACL、NT ACL 和模式位有效
　　·Windows 和 UNIX 客户端可以设置属性
　　·NFSv4 ACL 是为具有 NT ACL 的文件从模式位生成的
 
　　显然，您应该仔细选择您使用的配额树类型，以获得期望结果：

　　·仅限访问NFS：UNIX配额树
　　·混合访问：混合型配额树
　　·多数CIFS访问：NTFS配额树
　　·仅限访问CIFS：NTFS配额树

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

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

　　·要求带加密的具有很强的 RPC 安全性
　　·通过一个安全的带内系统，协商在服务器和客户端之间使用的安全性类型
　　·使用字符串而不是整数来表示用户和组标识符

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

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

　　·RPCSEC_GSS不只是身份验证。它能执行完整性校验和与整个RPC请求和响应体的加密。因此，RPCSEC_GSS 提供远远不只身份验证的安全性。
　　·由于RPCSEC_GSS只封装 GSS-API 消息标记 — 它仅作为Kerberos等安全机制的特定机制标签的传输 — 添加新安全机制（只要它们符合 GSS-API）不要求重新编写NFS的重要部分。

　　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。由委派引起的更为积极的缓存在具有以下特点的环境中能发挥较大的作用：

　　·频繁打开和关闭
　　·频繁的 GETATTR
　　·文件锁定
　　·只读共享
　　·高延迟
　　·快客户端
　　·具有多个客户端的重负荷服务器

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

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