☰

NFS 挂载组

tag-icon • tag-icon systemd nfs
NFS 挂载组

我有许多服务器，它们安装了一系列 NFS 安装点。用于这些安装点的导出分组定义了每个服务器的“个性”。每个“个性”往往包括许多相同的安装点，但也包括一些独特的安装点。

这通常是通过为每个角色存储一个唯一的 fstab 来完成的（实际上使用 Ansible 将挂载组添加到每个服务器）。

我想为我的用户提供一种按需切换服务器 NFS 个性的方法（如果可能，无需重新启动），同时仍然通过 Ansible 保持对个性的控制。我确信有一百万种方法可以解决这个问题，但我想调查一些更常见的技术（如果有的话）。

  • 我应该尝试使用基于 fstab 的方法吗？
  • 有没有更好的方法使用 systemd 目标来做到这一点？
  • RHEL7/8 领域还有其他更适合的工具吗？

感谢您的任何想法！

答案1

我不确定我是否完全理解这个问题。但如果你的目标是让玛丽有一些坐骑，而约翰有另一套坐骑，那么......

这很容易做到。

  1. 创建一个具有允许的挂载点和地址的文件（或多个文件），您也可以模仿 fstab 结构。真实的/etc/fstab将用于常见的安装并且仅由 root 控制。所以对于用户来说，你可以这样做：
# /etc/fstab.user/mary
10.0.0.40:/source-repo repository nfs

# /etc/fstab.user/john
//server/Secret-Documents documents cifs
  1. 添加/etc/profile如下代码（或为每个用户调用的等效代码）：
if [ -e /etc/fstab.user/$USER ] ; then
   while read device dir tp
   do
      mkdir -p /home/$USER/mnt/$dir
      mount -t $tp $device /home/$USER/mnt/$dir 
   done < /etc/fstab.user/$USER
fi

因此，每个用户都有自己的一组安装，$HOME/mnt/并且实际的根用户将控制谁获得什么。

即使实际文件夹/etc/fstab.users本身是从网络安装的，这种方法也能正常工作。

答案2

你可以使用 .target 单元来启动和停止安装 - 例如，如果您将一组 .mount 单元放入 individual-one.target 中，用户可以systemctl enable立即或禁用整个目标。 （尽管停止一个目标并将其传播到其“子”单元可能需要更多工作，可能每个 .mount 单元中都有一个“StopWhenUnneeded=”。）

但是，请考虑使用autofs自动安装程序。它的主要工作是管理 NFS 安装组。 （它还有一个优点，即它管理的挂载是“按需”的，因此，如果您有 200 个主机，每个主机挂载 200 个文件系统，则重新启动它们不会同时因数千个挂载请求而使文件服务器不堪重负。）

如果每组挂载都在同一目录下（例如，它们都是 /data 的子目录），则可以将整个目录定义为自动挂载映射（例如 /etc/auto.data），然后从“master”引用该映射地图（/etc/auto.master）。不适合此结构的独立安装可以通过“直接”地图定义。例如：

  • 主地图，可为该主机量身定制：

    # cat /etc/auto.master

/data   /etc/auto.data
/tools  /etc/auto.tools
/-      /etc/auto.direct

  • /data自动挂载映射（/data/one、/data/two 等）下的一组挂载：

    # cat /etc/auto.data

one     -nosuid,nodev datahost.example.com:/exports/data_one
two     -nosuid,nodev datahost.example.com:/exports/data_two

  • “直接”安装的自动安装映射（到处）：

    # cat /etc/auto.direct

/opt/sometool    filehost.example.com:/exports/software/sometool
/var/backup      filehost.example.com:/exports/backups/$HOST

    （如果您曾经使用过 systemd .automount 单元，它们依赖于相同的 autofs 功能，并且工作方式非常类似于“直接”自动挂载映射。）

启动自动挂载服务将在 /data 挂载一个“autofs”虚拟文件系统 – 这将似乎最初为空，但一旦出现 /data/one 等子目录访问过任何程序都会从​​相应的 NFS 共享挂载。

您可以通过 Ansible 部署所有映射，并将可用主映射之一符号链接到“/etc/auto.master”。用户将能够通过重新符号链接（例如“/etc/dist/auto.master.groupA”）到主映射并重新加载 automount 守护程序来切换主机个性，这将自动添加或删除它管理的 autofs 挂载。

（auto.master 文件还可以使用特殊条目（例如）来包含来自目录的“插件” +dir:/etc/auto.master.d/，因此如果需要混合系统，用户可以符号链接较小的片段。）

答案3

经过几轮由主目标单元分组的 systemd mount 和 automount 单元的迭代后，我发现我陷入了依赖项和复制正常 fstab 生成器已提供的行为所需的各种选项中。

对于每个“个性”有许多（近 50 个）挂载点，整个工作变得太麻烦而无法继续。因此，我备份并编写了一个 python 工具，该工具获取 fstab 条目的整个部分（由关键字阻止），并有效地取消注释这些部分，同时注释掉其他组的 fstab 条目的块。服务器重新启动会强制 fstab 生成器重建单元。

然后，授权管理员可以使用新工具切换服务器个性并重新启动服务器。

吸取的教训是，不应尝试重新实现像 systemd fstab 生成器这样复杂的东西。我当然学到了很多关于它是如何工作的知识，但是对于我拥有的挂载点的数量和无数的依赖项（一个挂载依赖于另一个挂载，自动挂载等......），能够在 fstab 中指定事物的便利性是非常有益的，不容忽视。能够在 Ansible 中管理单个主 fstab（blockinfile）（而不是 100 个单元文件）的简单性也不容忽视。

可以肯定的是，如果 fstab 生成器有办法从任意输入文件 (fstab) 生成单元并输出到可以与 systemd 搜索路径组合的任意路径（在我的 RHEL7 环境中不可能实现这些），可能有不同的解决方案。

感谢大家的投入！

相关内容