有关mfs分布式文件系统的本科毕业论文设计.doc

设计总说明 当前互联网高速发展，在互联网的众多应用中，视频网站是其中主要应之一。视频文件中央存储是视频网站的视频总库，拥有该视频网站的所有视频文件。以前的存储系统是san + nas 的方式由于中央存储是视频网站后端管理系统视频下发与分发的一个环节，性能要求主要来自于视频网站新视频下发与分发的环节。以每天发布50部视频，每部视频 1G 为例，要求中央存储写性能 20MB/s，以视频网站流媒体节点 6的为例，同时读的性能要120MB/s。稳定性要求是不会因为大流量而宕机。冗余要求每个数据文件至少要有2份拷贝。易用性要求当系统发生故障时能快速的恢复，当存储空间不足时，能够快速的扩容 目录 1 绪论 1 1.1 可靠性 1 1.1.1 可靠度的重要性 1 1.1.2 可信性基准程序法 1 1.2 故障注入 2 1.2.1 故障注入实现方法综述 2 1.2.2 软件实现的故障注入方法 2 2 方案综述 3 2.1 课题思路 3 2.2 模拟方法选择 3 2.2.1 故障、错误、失效概念 3 2.2.2 故障参数选择 3 3 软件模拟方案生成 4 3.1 故障、错误分类法及传播模型 4 3.1.1 ODC故障、错误分类 4 3.1.2 ODC分类下的数据 4 3.1.3 故障传播模型 4 3.2 错误、故障细化分析和模拟 4 3.2.1 错误类型分析 4 3.2.2 故障分析基础 4 3.2.3 赋值故障分析和模拟 4 3.2.4 控制故障分析和模拟 4 3.2.5 算法故障分析和模拟 5 3.2.6 时间/序列故障分析和模拟 5 3.2.7 接口故障分析和模拟 5 3.2.8 功能故障分析 5 3.3 软件故障模拟方案 5 4 硬件模拟方案生成 6 4.1 电气级硬件故障 6 4.2 硬件故障的表征及模拟方案 6 4.2.1 处理器硬件故障分析和模拟 6 4.2.2 地址总线硬件故障分析和模拟 6 4.2.3 内存和数据总线硬件故障分析和模拟 6 4.3 硬件故障模拟方案 6 5 结论 8 参考文献 9 附录 10 谢辞 11 1 分布式文件系统moosefs 由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署（即lvs+keepalived的方式），但仍然有用户反馈访问慢的问题。通过排查各服务器的情况，发现问题的根源在于共享存储服务器NFS。在我这个网络环境里，多个服务器通过nfs方式共享一个服务器的存储空间，使得NFS服务器不堪重负。察看系统日志，全是nfs服务超时之类的报错。一般情况下，当nfs客户端数目较小的时候，NFS性能不会出现问题；一旦NFS服务器数目过多，并且是那种读写都比较频繁的操作，所得到的结果就不是我们所期待的。图8-1为某个集群使用nfs共享的情形： 图1-1 多个应用共享nfs文件系统 这种架构除了性能问题而外，还存在单点故障，一旦这个NFS服务器发生故障，所有靠共享提供数据的应用就不再可用。尽管用rsync方式同步数据到另外一个服务器上做nfs服务的备份，但这对提高整个系统的性能毫无帮助。基于这样一种需求，我们需要对nfs服务器进行优化或采取别的解决方案。然而优化并不能对应对日益增多的客户端的性能要求，因此唯一的选择只能是采取别的解决方案了。通过调研，分布式文件系统是一个比较合适的选择。采用分布式文件系统后，服务器之间的数据访问不再是一对多的关系（1个NFS服务器，多个NFS客户端），而是多对多的关系，这样一来，性能大幅提升毫无问题。 1.1 关于moosefs 到目前为止，有数十种以上的分布式文件系统解决方案可供选择，如lustre,hadoop,Pnfs等等。我尝试了PVFS,hadoop,moosefs这三种应用，参看了lustre、KFS等诸多技术实施方法，最后我选择了moosefs（以下简称MFS）这种分布式文件系统来作为我的共享存储服务器。为什么要选它呢？我来说说我的一些看法： 实施起来简单。MFS的安装、部署、配置相对于其他几种工具来说，要简单和容易得多。看看lustre 700多页的pdf文档，让人头昏吧。 不停服务扩容。MFS框架做好后，随时增加服务器扩充容量；扩充和减少容量皆不会影响现有的服务。注：hadoop也实现了这个功能。 恢复服务容易。除了MFS本身具备高可用特性外，手动恢复服务也是非常快捷的，原因参照第1条。 我在实验过程中得到作者的帮助，这让我很是感激。 1.1.1 MFS特性（根据官方网站翻译） 高可靠性（数据能被分成几个副本存储在不同的计算机里）。图8-2展示了这种特性： 图1-2 MFS文件副本存储位置 通过增加计算机或增加新的硬盘动态扩充可用磁盘空间 可以