实用 Port：在 OpenZFS 上设置 NFSv4 文件服务器
最后更新于
最后更新于
原文链接：
作者：BENEDICT REUSCHLING
我们最近在工作中经历了一次小型灾难，这让我重新思考了当前的文件服务策略。我们通过 Ansible 部署 MongoDB、Hadoop、Spark 等分布式应用程序。这些应用程序的二进制文件并不来自软件仓库，而是从供应商网站下载，因为需要进行前期注册才能获取带有额外功能的企业版。包含这些二进制文件的归档文件非常大（即使经过压缩），并且通常需要一些时间才能通过网络将它们从 Ansible 控制器复制到目标机器。
曾经，我们认为可以有更快的方式来做这件事：将所有这些二进制文件放入网络共享（在这种情况下是来自 Ceph），在目标机器上挂载它们，然后让 Ansible 指向它们。对于 Ansible 来说，看起来这些文件对目标机器是“本地”的，因此它可以直接从共享中安装。即使在某些情况下，我们仍然需要将文件复制到本地目录（例如 Hadoop 或 Spark，它们本质上只是一个归档文件需要解压），相比从 Ansible 控制器首先传输文件，这种方式要快得多。
部署 playbook 中的最后一个动作是卸载共享。共享以只读方式挂载，以防止发生意外，同时在部署过程中我们根本不需要写访问权限。即使共享没有正确卸载，并且在我们的学生开始使用服务器时它仍然存在，由于缺少写权限，他们也无法删除任何重要文件。
一切都很好，直到有一天，我们的一位学生帮忙更新了 NoSQL 数据库的版本，他需要将新版软件放到共享中。将共享挂载为读写模式并将新二进制文件放在其他文件旁边是很简单的（他们可以这样做，是工作的一部分）。但再次运行脚本时，事情出错了：playbook 运行并如预期完成了工作。
后来我收到学生的一封电子邮件，告诉我脚本挂载了共享（仍然是读写模式），并执行了后续的清理操作。然而，它没有检查共享是否已从系统中干净地卸载。结果就是没有卸载。在这种情况下，清理工作顺利地在仍然挂载的 Ceph 共享上运行，并彻底清除了其中的所有文件。哎呀！学生的邮件问我是否还有来自 Ceph 共享的旧快照来恢复文件。我没有，因为共享是由我们的 IT 部门提供的。当我直接向他们询问时，结果发现他们根本没有备份那个共享。最近有一个新的备份系统投入使用，但还没准备好进行备份。而且没有其他备份可用，尽管 Ceph 共享在校园内的三栋不同楼宇中进行了复制。那里也没有运气。
我对此保持了冷静，原因有几个：首先，这件事本来很容易发生在我身上；其次，文件是可以恢复的，且共享中的文件并没有什么是无法替代的；第三，这给了我一个机会，使得在将来如果再发生类似事件时，系统可以变得更加稳健，这是从这种事件中学到的最佳经验。
我更新了 playbooks，在卸载任务之后增加了额外的检查，以确认共享是否确实已经卸载。如果没有，它将执行强制卸载操作；如果强制卸载也失败，playbook 执行将在此时停止。网络共享无法正确卸载通常是有正当原因的（通常是某些文件仍在被访问），但不继续执行总比冒险再次发生数据丢失更好。
由于我没有完全控制 Ceph 共享，并且我的网络共享需求并不大，我决定运行我自己的共享。于是我选择了 FreeBSD 的 ZFS，并使用其集成的 NFSv4 共享。这样，我可以定期创建快照，在没有变化的情况下，快照不会增长太多，因为大部分时间共享的文件都是只读的。而且，不再依赖于简单地将共享挂载为只读，我可以将 ZFS 的相同属性设置为“开启”。使用 readonly=on 后，即使是 root 用户也无法在具有该属性的数据集上删除文件。此外，我还可以获得 ZFS 提供的常规数据完整性检查，并可能通过压缩数据集来节省空间。
以下是我在 FreeBSD 系统上设置 NFSv4 服务器的笔记。首先，我去了 /etc/rc.conf 文件并添加了以下行：
这启用了 NFS 服务器，确保通过 nfsuserd 设置正确的权限，并为 NFS 发出的 RPC 调用执行正确的锁定。接下来，我检查了 /etc/exports 文件，确保它只包含以下行：
这告诉 FreeBSD 上的 NFS 服务器，它应该使用 NFS 版本 4，但实际共享的路径定义将由 ZFS 决定。我在网上看到这个文件现在甚至可以为空，但将它保留在那里也无妨。
我创建了用于文件共享的 ZFS 数据集，就像创建任何其他数据集一样。
ZFS 的一个优点是它的继承性。如果我决定在 fileshare 下创建一个子数据集，并且这个子数据集也应该提供 NFS 服务，我不需要单独配置它，因为它已经从父数据集继承了所有的属性（除了 mountpoint）。如果我不想共享这个子数据集，那么我可以通过将 sharenfs 属性设置为 off（这是默认值）来轻松禁用共享。
首先，我们将一些文件复制到 NFS 共享目录，然后将 readonly 属性设置为 "on"（这就是我们来这里的初衷）：
聪明的 ZFS 用户可以更进一步，先对共享目录进行快照，将其挂载到系统中，然后通过网络共享。这还可以确保文件不能被更改，因为 ZFS 快照本质上是只读的。不过，这个步骤留给你以后自己尝试。
在 sharenfs 属性中，我可以定义所有通常需要放入单独 NFS 配置文件中的参数。这样，关于如何通过 NFS 共享该数据集的信息将始终与它一起存在，即使它被发送到另一个池中。ZFS 的这种“一站式”特性使得配置变得更加简单，因为查找错误的地方减少了。
在我的例子中，我只想在特定子网内共享 NFS。你也可以列出由逗号分隔的主机名或 IP 地址。这样，你可以限制只有特定的主机才能挂载这个共享，从而提高一些安全性。
maproot=user 部分定义了，如果用户访问共享并且文件拥有该用户的权限，则服务器会将其映射到相同的本地权限，即使它们在服务器上可能不同。例如，Joe 可能在本地的 uid/gid 是 2000，而在 NFS 服务器上，所有用户的 uid/gid 都从 3000 开始。NFS 服务器会将 Joe 的文件设置为 uid/gid 为 3000，但当 Joe 访问共享时，他会看到本地系统上熟悉的 2000，而不会感到困惑。-alldirs 选项允许在 /fileshare 下的任何目录中进行挂载。通过阅读 exports(5) 可以了解更多这些及其他选项。
至此，服务器部分完成。我们需要启动 /etc/rc.conf 中列出的所有服务，以开始共享挂载的数据集。
这些服务中的一些应该在 NFS 服务器启动时自动启动，但请仔细检查每个服务的状态输出，以确保它们正在运行。可以使用以下命令来帮助确定共享无法挂载的原因：
sockstat -4l
rpcinfo
nfsstat
这些命令可以帮助你确定是否存在任何问题。
另一种查看当前共享数据集的方法是运行：
这将显示整个列表。
接下来，我们看一下客户端。我使用 FreeBSD 和 Ubuntu Linux 系统来挂载共享，并描述每个系统需要什么才能访问它。从 FreeBSD 客户端开始，它只需要在 /etc/rc.conf 中添加几行配置：
NFS 用户守护进程负责处理如上所述的从服务器映射用户 ID 和组。hostid 唯一标识此系统，以便 NFS 服务器识别，而 NFS 回调守护进程处理来自服务器的回调请求。它的手册页保证即使没有启动这个守护进程，挂载仍然可以正常工作，但立即激活它是不会有坏处的，这样以后就不必再为此困惑。
立即启动这些服务后，我们可以查看 NFS 服务器（名为 myfiler）正在提供给我们的共享：
这将为我们提供一个可以挂载的导出共享列表。从命令行中，使用如下命令调用 mount：
如果你希望每次系统启动时都挂载此共享，可以将其添加到 /etc/fstab，如下所示：
严格来说选项 noatime 和 rw 不是必须的，因为我们之前已经从 ZFS 方面处理了这些，但必须有 nfsv4 ，以便系统知道它正在使用 NFS 版本 4。
此时，你应该能够挂载共享，并查看其中的文件，并确保文件的用户和组 ID 是正确的。
在 Ubuntu Linux 系统上，我们首先需要安装 NFS 服务器组件，因为它们不是基本系统的一部分：
使用你特定发行版的包管理工具，之后的设置应该是相同的。事实证明，这就是所需的所有内容。在命令行上挂载共享可以通过以下命令完成：
当然，挂载可以发生在任何其他已存在的本地目录，而不仅仅是 /media。我之所以使用它，是因为它已经存在并且通常是空的。挂载在现有目录上会隐藏其内容，直到下一次卸载 NFS 共享。确保不要在系统运行所需的任何重要目录上进行挂载。无论你选择哪个目录，如果你还希望每次 Linux 系统启动时都挂载该共享，请将以下行添加到 /etc/fstab：
就这样。我设置的服务器将定期将 NFS 共享的内容复制到 Ceph，以进行额外备份。但现在，我不再那么担心，因为 ZFS 在支持我的文件：定期的快照和只读属性应该能避免像上述那样的未来错误。
BENEDICT REUSCHLING 是 FreeBSD 项目中的文档提交者，也是文档工程团队的成员。过去，他曾在 FreeBSD 核心团队任职两届。他在德国达姆施塔特应用科技大学管理一个大数据集群，还教授本科生课程“开发者的 Unix”。Benedict 还是每周 bsdnow.tv 播客的主持人之一。