2024年6月6日发(作者：)

由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署（即

lvs+keepalived的方式），但仍然有用户反馈访问慢的 问题。通过排查个服务器的情况，

发现问题的根源在于共享存储服务器NFS。在我这个网络环境里，N个服务器通过nfs方

式共享一个服务器的存储空间，使得 NFS服务器不堪重负。察看系统日志，全是nfs服务

超时之类的报错。一般情况下，当nfs客户端数目较小的时候，NFS性能不会出现问题；

一旦NFS服 务器数目过多，并且是那种读写都比较频繁的操作，所得到的结果就不是我

们所期待的。

下面是某个集群使用nfs共享的示意图：

这种架构除了性能问题而外，还存在单点故障，一旦这个NFS服务器发生故障，所有

靠共享提供数据的应用就不再可用，尽管用rsync方式同步数据到 另外一个服务器上做

nfs服务的备份，但这对提高整个系统的性能毫无帮助。基于这样一种需求，我们需要对

nfs服务器进行优化或采取别的解决方案，然而优 化并不能对应对日益增多的客户端的性

能要求，因此唯一的选择只能是采取别的解决方案了；通过调研，分布式文件系统是一个

比较合适的选择。采用分布式文件系 统后，服务器之间的数据访问不再是一对多的关系（1

个NFS服务器，多个NFS客户端），而是多对多的关系，这样一来，性能大幅提升毫无问

题。

到目前为止，有数十种以上的分布式文件系统解决方案可供选择，如

lustre,hadoop,Pnfs等等。我尝试了 PVFS,hadoop,moosefs这三种应用，参看了lustre、

KFS等诸多技术实施方法，最后我选择了moosefs（以下简称MFS）这种 分布式文件系

统来作为我的共享存储服务器。为什么要选它呢？我来说说我的一些看法：

1、 实施起来简单。MFS的安装、部署、配置相对于其他几种工具来说，要简单和容

易得多。看看lustre 700多页的pdf文档，让人头昏吧。

2、 不停服务扩容。MFS框架做好后，随时增加服务器扩充容量；扩充和减少容量皆

不会影响现有的服务。注：hadoop也实现了这个功能。

3、 恢复服务容易。除了MFS本身具备高可用特性外，手动恢复服务也是非常快捷的，

原因参照第1条。

4、 我在实验过程中得到作者的帮助，这让我很是感激。