使用NFS托管主文件夹是否可行？

我打算部署一些信息亭计算机，并希望将它们放置在一个小笔式驱动器中作为启动磁盘，将其余信息保留在易于备份的服务器ala LTSP中。

现在，我正在考虑两个选择。NFSed / home /，或在登录时复制的〜/的本地副本，在注销时进行rsync。

我担心使用文件可能会变得太慢，或者我的网络可能会堵塞。

我在生产环境中将NFS用于主目录。有一些技巧。

1. 不要将NFS挂载到/home-这样，您可以拥有一个本地用户，该本地用户允许您在NFS服务器关闭的情况下进入。我们登上/mnt/nfs/home

2. 使用软安装和非常短的超时-这将防止进程永远阻塞。

3. 使用自动安装器。这将减少资源使用量，也意味着您无需担心NFS服务器由于某种原因而停机时重新启动服务。

   auto.master:
     +auto.master
     /mnt/nfs /etc/auto.home --timeout=300
   
   auto.home
      home -rw,soft,timeo=5,intr      home.bzzprod.lan:/home
   

4. 使用单点登录系统，这样就不会遇到权限相关的问题。我有一个OpenLDAP服务器。

http://www.howtoforge.com最近发布了一篇有关使用GlusterFS作为NFS替代品/替代品的文章，您可能想查看一下。

http://www.howtoforge.com/creating-an-nfs-like-standalone-storage-server-with-glusterfs-on-debian-lenny

这是GlusterFS项目页面http://www.gluster.org/上简短说明为什么它是NFS的“可行”替代品的原因：

“ GlusterFS可以自行自我修复。没有fsck。存储后端可以作为常规文件和文件夹（NFS样式）直接访问。启用复制后，GlusterFS可以承受硬件故障。”

可以在项目文档中找到更多信息。

另外，使用GlusterFS的另一个好处是，如果您需要在SAN上占用更多空间，您只需添加另一个存储块（服务器节点），便可以在需要时以并行方式扩展/增长您的存储。

希望这有助于或至少帮助您指出正确的方向！

注意软安装！软安装NFS文件系统意味着IO将在发生超时后失败。请确保这是您要在用户主目录上使用的内容！我的猜测是你不会。结合使用intr选项在主目录上使用硬挂载在这里更加安全。

Hard不会超时：IO操作将无限期重试。使用intr选项可以中断安装过程。因此，如果您安装导出并遇到故障，则硬安装将锁定您的会话。intr选项将使中断挂载成为可能，因此该组合非常安全，并确保您不会轻易丢失用户的数据。

无论如何，autofs使这一切变得更加容易。

需要注意的一件事是，当NFS服务器出局时-挂载会冻结-进行软挂载不会阻塞，因此可以避免“冻结”本身，但是这不能解决没有主目录的主目录问题目录，无论如何，用户都被搞砸了。

即使当NFS服务器恢复时，除非您对其进行处理，否则冻结问题仍然存在-您将不得不终止挂载计算机上的进程，然后重新挂载。这样做的原因是，当NFS服务器重新启动时，它分配了一个不同的fsid-因此，您至少可以通过fsid在NFS服务器上对s进行硬编码来解决此问题。

#. Home Directories
/usr/users \
  192.168.16.0/22(rw,sync,no_root_squash,fsid=1) \
  192.168.80.0/22(rw,sync,no_root_squash,fsid=1)

#. Scratch Space
/var/ftp/scratch \
  192.168.16.0/22(rw,async,no_root_squash,fsid=3) \
  192.168.80.0/22(rw,async,no_root_squash,fsid=3) \
  172.28.24.151(rw,async,root_squash,fsid=3)

该exports(5)手册页指出...

fsid=num
          This option forces the filesystem identification portion of the file handle
          and  file attributes used on the wire to be num instead of a number derived
          from the major and minor number of the block device on which the filesystem
          is  mounted.   Any 32 bit number can be used, but it must be unique amongst
          all the exported filesystems.

          This can be useful for NFS failover, to ensure that  both  servers  of  the
          failover  pair use the same NFS file handles for the shared filesystem thus
          avoiding stale file handles after failover.

...虽然这表明只要主要/次要数字保持不变（通常不发生变化，除了当您导出SAN /多路径卷时，可能会改变），我发现我们已经完全解决了问题-即，如果NFS服务器恢复了-连接已迅速恢复-我仍然真的不知道为什么这对诸如此类的设备有所影响/dev/sdaX。

我现在应该指出，我的论点很大程度上是轶事-它为什么解决了这个问题实际上并没有意义，但是它似乎“似乎”已经解决了-某种程度上-我在这里可能还有其他变量在起作用尚未发现。=）

无论您采用哪种网络文件系统，都将适用一些一般性建议：许多程序将数据缓存在用户的主目录中，当通过网络访问主目录时，这样做通常弊大于利。

如今，您可以通过XDG_CACHE_HOME在登录脚本中设置环境变量来告诉许多程序将其缓存存储在其他位置（例如，在本地磁盘上）。但是，许多程序（例如Firefox）仍需要手动配置，因此您可能需要做一些额外的工作才能为所有用户以统一的方式识别和配置它们。

我工作过的很多地方都使用NFS挂载的主目录。通常，性能没有很大的差异（信息亭用户的需求可能比知道如何掌握本地IT人才的开发人员要少一些）。我看到的一个问题是，当我登录到Gnome桌面并且NFS服务器由于任何原因而消失时会发生什么。事情变得毫无反应。

我使用的是NFSed家庭住宅，并且运行良好。但是您必须确保网络速度足够快，并且永远不会宕机。

实际上，如果有一个100兆位或更高的交换网络，则NFS在主目录上的性能很好。对于10-20个以上的自助服务亭，服务器应具有千兆位连接能力。您不会赢得性能竞赛，但是Firefox和Open Office之类的东西可以正常运行。

在登录延迟方面（在最大12MB / s的100mbit网络上。在100MB主目录接近10秒的情况下），登录主目录中的复制将是一个主要的痛苦。Rsync将影响您同步Web浏览器缓存... 10分钟和500个文件受伤。

看一下cachefilesd。我没有亲自使用过，但是看起来很有希望。

cachefilesd守护程序管理诸如AFS和NFS之类的网络文件系统用来对本地磁盘进行持久缓存的缓存文件和目录。

同样，不要忘记调整rsize和wsize参数，并在可能的情况下使用巨型帧。