Moosefs分布式文件系统应用实践

　　在存储架构专场的分论坛上，资深系统架构师田逸也跟大家分享了自己在Moosefs分布式文件系统的应用实践。

　　对于大多数企业来说，厂商方案无疑是更具安全性也更加“省事”的一种方案，而田逸利用开源文件系统开发的共享存储解决方案则为大多数资金并不十分充裕，而且对技术开发有极大研究兴趣的架构师提供了较好的借鉴经验。

资深系统架构师田逸

　　实际上，可用于开发的分布式文件系统还有很多，例如Google发布的GFS，雅虎发布的Hadoop，业界还有很多可供开发者使用的开源的分布式文件系统例如Lustre等等。田逸讲述自己也曾经在其他的分布式文件系统中试探选择过，尝试了PVFS,hadoop,moosefs这三种应用，参看了lustre、KFS等诸多技术实施方法，最后选择MFS，原因包括几个方面：

　　实施起来简单。MFS的安装、部署、配置相对于其他几种工具来说，要简单和容易得多。例如田逸介绍lustre 的技术文档长达700多页，而MFS的操作文档则简洁明了清晰简单。

　　不停服务扩容。MFS框架做好后，随时增加服务器扩充容量;扩充和减少容量皆不会影响现有的服务。注：hadoop也实现了这个功能。

　　恢复服务容易。除了MFS本身具备高可用特性外，手动恢复服务也是非常快捷的，原因参照第1条。

　　4、 另外一个方面是开发MFS的作者非常热心，田逸讲述自己在使用MFS进行开发时其实并不懂英文，因此用中文给MFS的开发作者邮件，结果得到了作者的详细的回复，给了田逸很大的帮助也让田逸在分布式文件系统的开发中得到了鼓舞和支持。

　　田逸介绍说，由于用户数量的不断攀升,田逸对自己系统中访问压力大的应用实现了可扩展、高可靠的集群部署(即lvs+keepalived的方式)，但仍然有用户反馈访问慢的问题。通过排查个服务器的情况，发现问题的根源在于共享存储服务器NFS。

　　在整个网络环境里，N个服务器通过nfs方式共享一个服务器的存储空间，使得NFS服务器不堪重负。察看系统日志，全是nfs服务超时之类的报错。一般情况下，当nfs客户端数目较小的时候，NFS性能不会出现问题;一旦NFS服务器数目过多，并且是那种读写都比较频繁的操作，所得到的结果就不是我们所期待的。下面是某个集群使用nfs共享的示意图：

　　这种架构除了性能问题而外，还存在单点故障，一旦这个NFS服务器发生故障，所有靠共享提供数据的应用就不再可用，尽管用rsync方式同步数据到另外一个服务器上做nfs服务的备份，但这对提高整个系统的性能毫无帮助。

　　基于这样一种需求，我们需要对nfs服务器进行优化或采取别的解决方案，然而优化并不能对应对日益增多的客户端的性能要求，因此唯一的选择只能是采取别的解决方案了;通过调研，分布式文件系统是一个比较合适的选择。采用分布式文件系统后，服务器之间的数据访问不再是一对多的关系(1个NFS服务器，多个NFS客户端)，而是多对多的关系，这样一来，性能大幅提升毫无问题。

　　田逸详细的演示了自己如何通过分布式文件系统改进系统性能的尝试过程和操纵步骤，图文并茂生动有趣，内容翔实丰富，得到了参会网友的极大好评。