《有关MFS分布式文件系统的设计》-毕业设计(论文).docVIP

《有关MFS分布式文件系统的设计》-毕业设计(论文).doc

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ 装 ┊ ┊ ┊ ┊ ┊ 订 ┊ ┊ ┊ ┊ ┊ 线 ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ 毕业设计(论文)报告纸 PAGE 共 Ⅲ 页 第 PAGE II 页 设计总说明 当前互联网高速发展,在互联网的众多应用中,视频网站是其中主要应之一。视频文件中央存储是视频网站的视频总库,拥有该视频网站的所有视频文件。以前的存储系统是san + nas 的方式,特点是需要的厂家支持,要用专业的网络设备,专业的人才稀少,设备成本高昂。1TB的存储空间的成本要5000,而现在互联网海量的视屏文件,上EB的存储空间,其主要的收入来自于广告,而版权,带宽是其主要的支出,加上运营,损耗,传统的存储方式成本实在太高,无法使用,于是需要使用低成本,高性能的解决方案。由于科学技术的不断的发展,硬件成本不断的降低,大容量硬盘已经价格低廉,而传统的存储价格没有降低,于是有了利用硬盘价格便宜,用本地磁盘当存储的分布式存储的解决方案,来应对现在的形式。 由于中央存储是视频网站后端管理系统视频下发与分发的一个环节,性能要求主要来自于视频网站新视频下发与分发的环节。以每天发布50部视频,每部视频 1G 为例,要求中央存储写性能 20MB/s,以视频网站流媒体节点 6的为例,同时读的性能要120MB/s。稳定性要求是不会因为大流量而宕机。冗余要求每个数据文件至少要有2份拷贝。易用性要求当系统发生故障时能快速的恢复,当存储空间不足时,能够快速的扩容。 目录 TOC \o 1-3 \h \z 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 共 11 页 第 PAGE 1 页 1 分布式文件系统moosefs 由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署(即lvs+keepalived的方式),但仍然有用户反馈访问慢的问题。通过排查各服务器的情况,发现问题的根源在于共享存储服务器NFS。在我这个网络环境里,多个服务器通过nfs方式共享一个服务器的存储空间,使得NFS服务器不堪重负。察看系统日志,全是nfs服务超时之类的报错。一般情况下,当nfs客户端数目较小的时候,NFS性能不会出现问题;一旦NFS服务器数目过多,并且是那种读写都比较频繁的操作,所得到的结果就不是我们所期待的。图8-1为某个集群使用nfs共享的情形: 图1-1 多个应用共享nfs文件系统 这种架构除了性能问题而外,还存在单点故障,一旦这个NFS服务器发生故障,所有靠共享提供数据的应用就不再可用。尽管用rsync方式同步数据到另外一个服务器上做nfs服务的备份,但这对提高整个系统的性能毫无帮助。基于这样一种需求,我们需要对nfs服务器进行优化或采取别的解决方案。然而优化并不能对应对日益增多的客户端的性能要求,因此唯一的选择只能是采取别的解决方案了。通过调研,分布式文件系统是一个比较合适的选择。采用分布式文件系统后,服务器之间的数据访问不再是一对多的关系(1个NFS服务器,多个NFS客户端

您可能关注的文档

文档评论(0)

小红帽 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档