四大专家案例剖析互联网存储架构
时间：2009-09-01 来源：linux论坛
8月28-29日，由澳信传媒旗下IT168、ITPUB社区以及ChinaUnix联合举办的2009年系统架构师大会在北京举行。在29日下午举办的存储分论坛上，乐视网首席技术官杨永强先生与大家分享了分布式存储网络在视频网站中的应用;F5公司北方区技术经理杨明飞先生介绍了F5公司文件虚拟化解决方案;资深系统架构师田逸为大家介绍了自己在Moosefs分布式文件系统方面的应用实践;最后，51.com数据库主管徐景春也展示了51.com应用Mysql数据库进行在线灾备的实践分析案例。支付宝网站首席架构师冯大辉先生为本次存储专场担任主持人。
分布式存储满足视频网站点播需求
乐视网首席技术官杨永强先生介绍到，乐视网是成立较早的视频点播网站之一。从网站成立发展至今，乐视网的存储架构设计也几经变迁。
从视频网站的建设需求来说，视频点播网站需求的最大特点是数据量大。首先，视频网站涉及的数据都是视频文件型数据，这类视频文件相比word文档和图片文件文件大小不在同一个数量级上。而高清视频的普及，使得单个文件大小级别进一步提高。同时，由于视频摄录设备日益普及，越来越多的人倾向于把自己日常生活中的片段上传到网上与大家分享，因此视频网站的文件数量增长也呈现快速的增长趋势。
从传输方面的需求来说，不同于某些视频下载类网站，实时播放的视频网站要求较强的实时性，持续稳定的画面传输质量。
最早乐视网采用的是集中DAS的存储架构，很快这种集中的DAS架构的局限性就暴露出来，首先是扩展不方便，由于视频网站涉及的文件比较大，增长速度也比较快，因此DAS首先在扩容性方面无法满足乐视网的访问需求。
其次，由于视频文件存在不同的访问压力需求，例如某个片子在某一段时间内很有可能出现集中的访问需求，而DAS的架构无法实现压力的负载均衡，因此，在访问流量均衡上也无法满足视频网站的访问需求。
乐视网改进的第二阶段存储架构是采用了NAS的存储架构，但很快乐视网发现NAS的前端主机带宽有限，整体存储系统运行效率低下，这段时间，乐视网遭到了很多用户投诉，为此，乐视网决定再次更换后台存储架构设计。
在乐视网存储后台架构的演变过程中，乐视网也曾经考虑过SAN网络存储架构，但是经过考察后，乐视网认为SAN的架构成本高昂，在当时乐视网考察的时期，每TB成本达到8万元，而乐视网需要在全国十多个城市的IDC机房布置提供视频点播服务的数据中心，这个成本对乐视网来说耗资巨大。
最终，乐视网选择了分布式网络存储架构。后台的基础架构仍然采用成熟稳定的DAS直连存储架构，多个DAS直连存储架构分散在全国十多个城市的IDC机房中，但是在DAS与DAS的基础架构之上，在应用层，乐视网自己开发了一套流量控制与管理软件，实现多个DAS节点之间的冗余、迁移与流量均衡。
例如，用户如果上传一份视频文件，应用层的流量控制管理软件会自动的查询该用户上传的性能最优的路径，并将路径分配给该用户进行视频上传，而这一过程对用户来说是完全透明的，用户完全不必知道自己究竟通过哪个节点路径在上传视频，也不必理会视频文档上传到了哪个存储节点上。与此同时，系统会自动的将用户上传的视频文件复制到三个不同的存储节点上，从而自动的保证了系统冗余。
而当用户从乐视网上点播视频文件时，系统也会自动的查询该用户的视频点播记录，并选择历史记录中，点播的性能最优的线路进行点播播放。换句话说，点播的路径分配未必严格按照最近的点播服务中心区分配。而乐视网在全国十多个城市均设有视频点播服务中心，已经覆盖到全国范围内的大部分视频点播需求。
同时杨永强还强调，每一份数据自第一次上传开始，系统就自动将这个视频文件分散保存在不同的三个视频节点上。而某个视频文件在某一阶段内，点播需求激增时，系统会自动的复制这个视频文件到访问需求较多的存储节点上，当点播需求下降后，系统会自动的删除不必要的副本，最终一个视频文件的副本只保留三个，对视频文件的冗余性已经有非常充分的保障。
“可以这样说，我们每一个节点上的数据都并不是完整的，但所有的节点上的视频文件加到一起，是我们的完整数据，而且我们保存了所有文件的三个拷贝。而我们所有的系统都是我们乐视网通过自己的技术力量自主开发的。”谈到乐视网的技术支持力量，杨永强表现出极强的信心和自豪感。
文件虚拟化在互联网存储架构设计中的应用
紧随其后，F5公司北方区技术经理 应用交付架构师杨明飞先生也介绍了F5公司文件虚拟化解决方案在互联网存储架构设计中的应用。
对于互联网企业，由于Web2.0应用体验模式的兴起，非结构化数据量有了较大的增长，实际上，对于大多数网站来说，解决数据库问题可以采用较为成熟的SAN应用模式，而对于非结构化数据的管理则一直没有较为行之有效的管理策略。
对于网站来说，采用NAS系统管理后台的非结构化数据应该说是一种成本较低也较易扩展的方案架构，但对于这些网站来说，采用了多台NAS同时管理后台大量的非结构化数据时，不可避免的同样带来管理上的混乱，一台一台的NAS设备形成了NAS存储孤岛，尤其当所用的NAS设备可能还是来自不同的厂商的时候，后台管理的复杂性就进一步提高了。
那么怎样能够把多台NAS里面的非结构化文件通过统一的文件管理平台进行管理呢，F5文件虚拟化技术就提供了这样的解决方案。
在一个最典型的文件虚拟化应用方案中，系统中可能已经存在了多台NAS，每台NAS系统中都保存有海量的不同的文件数据，F5文件虚拟化方案在整体系统旁边提供有MFS的Master，就是用一台单独的服务器通过预装一种软件来管理所有的Matadater。所有的客户端将要去读/写NAS的时候，首先要去Master上询问，读写的最佳位置和数据，然后才向指定的NAS设备和节点去读写数据。
F5的文件虚拟化解决方案在互联网存储架构应用中，可帮助互联网企业降低后台架构的复杂性和降低成本，在传统的NAS存储网络中，前端应用服务器与后端存储介质的存储访问关系非常复杂，管理效率低，容易出错。应用服务器直接访问存储介质，不能对存储介质进行有效管理。
例如在NAS模式下，如果我们要存储2TB的数据时，而存储网络的所有单台存储介质的容易都没有2TB时，此时，存储系统就没有办法了。在这种情况下，我们就可以在前端应用服务器与后端存储介质之间，虚拟化一个文件管理系统出来，这就是“文件虚拟化”。
通过文件虚拟化平台，将后端存储介质虚拟化成一个存储池，此时，就可以存储2TB的数据了。文件虚拟化平台可以自动地将1TB的数据存储在A存储器上，而把另外1TB的数据存储在B存储器上，从而实现对存储的有效访问。
此外，F5的解决方案能够管理多个路径同时并发的读写NAS系统，为系统设计最佳读写路径，从而提高文件读写的效率。例如，以往系统在写入的时候，系统会往单一的有足够空间的NAS设备上写入大量的文件，读取也只能通过这台单一的NAS设备中读取大量文件。这样单台的NAS设备就形成了读写瓶颈和热点。
经过F5文件虚拟化的路径优化后，系统会根据策略将多个文件同时写入到不同的NAS设备中，同样读取的时候也可以自动从不同的设备中读取，这样分担了单一设备的流量负载，提高了整体读写效率。
F5的文件虚拟化设备实际上只是提供文件名和路径的指针，用户无论是读取还是写入文件，首先访问F5文件虚拟化设备获得访问路径，然后根据路径直接访问后台NAS设备，而这一过程对于前面用户来说完全透明，对用户呈现的仍然是一个大目录下的不同文件，用户不必去理会后台文件究竟保存在哪一台NAS设备上，因而屏蔽了后台管理的复杂性。
根据杨明飞的介绍，与F5文件虚拟化解决方案类似的方案在业界还有很多，其中商业化的解决方案包括EMC的Rifinity，NetApp也同样有类似的解决方案。F5的方案优势在于，将负载均衡的思路引入到了NAS领域，通过F5全局命名空间技术，实现NAS文件的统一管理。
在性能保证上，F5的ARX则通过独有的运算加速芯片实现路径快速查找，极好的保证了文件访问和读取性能，此外，由于F5采用了基于硬件的文件虚拟化方案，对于扩展性方面仅受硬件处理能力的限制，而在芯片制造技术飞速发展的今天，显然基于硬件的文件虚拟化方案能提供“近乎无限”的扩展性。
另外一方面，当所有的文件存储都通过一台文件管理器来实现的时候，这台文件虚拟化管理设备将变得至关重要，基于软件的文件虚拟化解决方案则更容易产生不可预知的故障，一旦系统宕机，后台所有的文件将不可识别。基于硬件的文件虚拟化解决方案相比软件的文件虚拟化方案来说更为稳定，而一旦系统宕机，只需要重启一下系统，或者重新配置一下，后台数据即可轻松恢复。
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客户端)，而是多对多的关系，这样一来，性能大幅提升毫无问题。
田逸详细的演示了自己如何通过分布式文件系统改进系统性能的尝试过程和操纵步骤，图文并茂生动有趣，内容翔实丰富，得到了参会网友的极大好评。
51.com应用Mysql数据库进行在线灾备实践案例
田逸的演讲结束后，51.com数据库主管徐景春也向大家介绍了51.com在在线灾备方面的探索和研究。
徐景春介绍说，51.com公司从管理架构上就极为关注数据安全，因此身为数据库主管，徐景春本人在工作中也一直谨慎小心，从各种角度保障数据库的备份与灾备。而与此同时，一则报纸上的热点消息也更让51.com在灾备方面提高警惕：
去年，德克萨斯某公司丢失27GB档案数据没有备份，给该公司业务造成严重损失，为此，负责该备份项目的IBM公司被判罚90万美金。根据徐景春讲述，当时该公司老总以这例新闻提醒公司技术管理人员提高备份方面的安全措施，并要求彻底检查公司的备份措施是否完备。可见数据安全对于51.com的重要性。
提高数据安全性可能包括两个方面，首先是备份，其次是容灾，包括同城容灾和异地容灾，对于中国的大部分互联网公司来说，容灾方案实际上还是一个比较奢侈的方案，为此，徐景春详细介绍了51.com在备份方面的探索，实际上，备份也是灾备的重要组成部分，一个完整的备份方案已经能够应付大多数系统计划内和计划外的宕机情况。
最早51.com在成立初期，只有几台DB服务器，相互镜像，不要说灾备，普通的备份安全标准也完全没办法保证。一般来说都是通过手工输入命令进行备份。随着51.com业务发展，前端服务器数量迅速发展为几百台甚至上千台，此时，他们采用了自写的脚本进行自动化备份。但此时也同样产生一些问题，例如自写的脚本通常需要维护一个设备列表，当需要备份的服务器数量过于庞大的时候，通过认为操作这个列表变得极其繁琐，且出错率高。
而且随着公司业务模式的发展，备份需求也发生了较大的分化，某些应用例如交易结算型要求每小时就进行一次备份，某些应用则需要一天进行一次备份，而某些不重要的数据一个星期做一次备份即可。这个时候一套备份系统已经没办法满足需求了。因此需要为整个公司所有的备份需求进行统一的规划和整理。
这个时候51.com的备份体系已经非常复杂，Oracle备份与MySQL备份并存，手工备份与自动化备份并存，增量备份与全量备份混合使用，同时，该公司还实现了对电信和网通IDC机房的交叉同城异地备份，例如周一数据异地备份到电信机房，周二数据异地备份到网通机房，这样无论任何一边的机房挂掉，51.com整体系统仍然能尽可能多的数据，已经拥有一定的抗灾难能力。
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://images.lampchina.net/news/10/sGix41QqcNCJAHFPrVTymWMenRbLoKfI.jpg');}" onmousewheel="return imgzoom(this);" alt="" />
存储分论坛现场
分布式存储满足视频网站点播需求
乐视网首席技术官杨永强先生介绍到，乐视网是成立较早的视频点播网站之一。从网站成立发展至今，乐视网的存储架构设计也几经变迁。
从视频网站的建设需求来说，视频点播网站需求的最大特点是数据量大。首先，视频网站涉及的数据都是视频文件型数据，这类视频文件相比word文档和图片文件文件大小不在同一个数量级上。而高清视频的普及，使得单个文件大小级别进一步提高。同时，由于视频摄录设备日益普及，越来越多的人倾向于把自己日常生活中的片段上传到网上与大家分享，因此视频网站的文件数量增长也呈现快速的增长趋势。
从传输方面的需求来说，不同于某些视频下载类网站，实时播放的视频网站要求较强的实时性，持续稳定的画面传输质量。
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://images.lampchina.net/news/10/ehGCs3HatZnKXgVcIiLo8rUlOkWQYTvz.jpg');}" onmousewheel="return imgzoom(this);" alt="" />
乐视网首席技术官杨永强先生
最早乐视网采用的是集中DAS的存储架构，很快这种集中的DAS架构的局限性就暴露出来，首先是扩展不方便，由于视频网站涉及的文件比较大，增长速度也比较快，因此DAS首先在扩容性方面无法满足乐视网的访问需求。
其次，由于视频文件存在不同的访问压力需求，例如某个片子在某一段时间内很有可能出现集中的访问需求，而DAS的架构无法实现压力的负载均衡，因此，在访问流量均衡上也无法满足视频网站的访问需求。
乐视网改进的第二阶段存储架构是采用了NAS的存储架构，但很快乐视网发现NAS的前端主机带宽有限，整体存储系统运行效率低下，这段时间，乐视网遭到了很多用户投诉，为此，乐视网决定再次更换后台存储架构设计。
在乐视网存储后台架构的演变过程中，乐视网也曾经考虑过SAN网络存储架构，但是经过考察后，乐视网认为SAN的架构成本高昂，在当时乐视网考察的时期，每TB成本达到8万元，而乐视网需要在全国十多个城市的IDC机房布置提供视频点播服务的数据中心，这个成本对乐视网来说耗资巨大。
最终，乐视网选择了分布式网络存储架构。后台的基础架构仍然采用成熟稳定的DAS直连存储架构，多个DAS直连存储架构分散在全国十多个城市的IDC机房中，但是在DAS与DAS的基础架构之上，在应用层，乐视网自己开发了一套流量控制与管理软件，实现多个DAS节点之间的冗余、迁移与流量均衡。
例如，用户如果上传一份视频文件，应用层的流量控制管理软件会自动的查询该用户上传的性能最优的路径，并将路径分配给该用户进行视频上传，而这一过程对用户来说是完全透明的，用户完全不必知道自己究竟通过哪个节点路径在上传视频，也不必理会视频文档上传到了哪个存储节点上。与此同时，系统会自动的将用户上传的视频文件复制到三个不同的存储节点上，从而自动的保证了系统冗余。
而当用户从乐视网上点播视频文件时，系统也会自动的查询该用户的视频点播记录，并选择历史记录中，点播的性能最优的线路进行点播播放。换句话说，点播的路径分配未必严格按照最近的点播服务中心区分配。而乐视网在全国十多个城市均设有视频点播服务中心，已经覆盖到全国范围内的大部分视频点播需求。
同时杨永强还强调，每一份数据自第一次上传开始，系统就自动将这个视频文件分散保存在不同的三个视频节点上。而某个视频文件在某一阶段内，点播需求激增时，系统会自动的复制这个视频文件到访问需求较多的存储节点上，当点播需求下降后，系统会自动的删除不必要的副本，最终一个视频文件的副本只保留三个，对视频文件的冗余性已经有非常充分的保障。
“可以这样说，我们每一个节点上的数据都并不是完整的，但所有的节点上的视频文件加到一起，是我们的完整数据，而且我们保存了所有文件的三个拷贝。而我们所有的系统都是我们乐视网通过自己的技术力量自主开发的。”谈到乐视网的技术支持力量，杨永强表现出极强的信心和自豪感。
文件虚拟化在互联网存储架构设计中的应用
紧随其后，F5公司北方区技术经理 应用交付架构师杨明飞先生也介绍了F5公司文件虚拟化解决方案在互联网存储架构设计中的应用。
对于互联网企业，由于Web2.0应用体验模式的兴起，非结构化数据量有了较大的增长，实际上，对于大多数网站来说，解决数据库问题可以采用较为成熟的SAN应用模式，而对于非结构化数据的管理则一直没有较为行之有效的管理策略。
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://images.lampchina.net/news/10/3AqvFmgYDZGXUTSxb6hLVWdIEHpuoQ0n.jpg');}" onmousewheel="return imgzoom(this);" alt="" />
F5公司北方区技术经理杨明飞先生
对于网站来说，采用NAS系统管理后台的非结构化数据应该说是一种成本较低也较易扩展的方案架构，但对于这些网站来说，采用了多台NAS同时管理后台大量的非结构化数据时，不可避免的同样带来管理上的混乱，一台一台的NAS设备形成了NAS存储孤岛，尤其当所用的NAS设备可能还是来自不同的厂商的时候，后台管理的复杂性就进一步提高了。
那么怎样能够把多台NAS里面的非结构化文件通过统一的文件管理平台进行管理呢，F5文件虚拟化技术就提供了这样的解决方案。
在一个最典型的文件虚拟化应用方案中，系统中可能已经存在了多台NAS，每台NAS系统中都保存有海量的不同的文件数据，F5文件虚拟化方案在整体系统旁边提供有MFS的Master，就是用一台单独的服务器通过预装一种软件来管理所有的Matadater。所有的客户端将要去读/写NAS的时候，首先要去Master上询问，读写的最佳位置和数据，然后才向指定的NAS设备和节点去读写数据。
F5的文件虚拟化解决方案在互联网存储架构应用中，可帮助互联网企业降低后台架构的复杂性和降低成本，在传统的NAS存储网络中，前端应用服务器与后端存储介质的存储访问关系非常复杂，管理效率低，容易出错。应用服务器直接访问存储介质，不能对存储介质进行有效管理。
例如在NAS模式下，如果我们要存储2TB的数据时，而存储网络的所有单台存储介质的容易都没有2TB时，此时，存储系统就没有办法了。在这种情况下，我们就可以在前端应用服务器与后端存储介质之间，虚拟化一个文件管理系统出来，这就是“文件虚拟化”。
通过文件虚拟化平台，将后端存储介质虚拟化成一个存储池，此时，就可以存储2TB的数据了。文件虚拟化平台可以自动地将1TB的数据存储在A存储器上，而把另外1TB的数据存储在B存储器上，从而实现对存储的有效访问。
此外，F5的解决方案能够管理多个路径同时并发的读写NAS系统，为系统设计最佳读写路径，从而提高文件读写的效率。例如，以往系统在写入的时候，系统会往单一的有足够空间的NAS设备上写入大量的文件，读取也只能通过这台单一的NAS设备中读取大量文件。这样单台的NAS设备就形成了读写瓶颈和热点。
经过F5文件虚拟化的路径优化后，系统会根据策略将多个文件同时写入到不同的NAS设备中，同样读取的时候也可以自动从不同的设备中读取，这样分担了单一设备的流量负载，提高了整体读写效率。
F5的文件虚拟化设备实际上只是提供文件名和路径的指针，用户无论是读取还是写入文件，首先访问F5文件虚拟化设备获得访问路径，然后根据路径直接访问后台NAS设备，而这一过程对于前面用户来说完全透明，对用户呈现的仍然是一个大目录下的不同文件，用户不必去理会后台文件究竟保存在哪一台NAS设备上，因而屏蔽了后台管理的复杂性。
根据杨明飞的介绍，与F5文件虚拟化解决方案类似的方案在业界还有很多，其中商业化的解决方案包括EMC的Rifinity，NetApp也同样有类似的解决方案。F5的方案优势在于，将负载均衡的思路引入到了NAS领域，通过F5全局命名空间技术，实现NAS文件的统一管理。
在性能保证上，F5的ARX则通过独有的运算加速芯片实现路径快速查找，极好的保证了文件访问和读取性能，此外，由于F5采用了基于硬件的文件虚拟化方案，对于扩展性方面仅受硬件处理能力的限制，而在芯片制造技术飞速发展的今天，显然基于硬件的文件虚拟化方案能提供“近乎无限”的扩展性。
另外一方面，当所有的文件存储都通过一台文件管理器来实现的时候，这台文件虚拟化管理设备将变得至关重要，基于软件的文件虚拟化解决方案则更容易产生不可预知的故障，一旦系统宕机，后台所有的文件将不可识别。基于硬件的文件虚拟化解决方案相比软件的文件虚拟化方案来说更为稳定，而一旦系统宕机，只需要重启一下系统，或者重新配置一下，后台数据即可轻松恢复。
Moosefs分布式文件系统应用实践
在存储架构专场的分论坛上，资深系统架构师田逸也跟大家分享了自己在Moosefs分布式文件系统的应用实践。
对于大多数企业来说，厂商方案无疑是更具安全性也更加“省事”的一种方案，而田逸利用开源文件系统开发的共享存储解决方案则为大多数资金并不十分充裕，而且对技术开发有极大研究兴趣的架构师提供了较好的借鉴经验。
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://images.lampchina.net/news/10/snJcOwXMBG1yQq80SHpbIadCzPo56vxE.jpg');}" onmousewheel="return imgzoom(this);" alt="" />
资深系统架构师田逸
实际上，可用于开发的分布式文件系统还有很多，例如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客户端)，而是多对多的关系，这样一来，性能大幅提升毫无问题。
田逸详细的演示了自己如何通过分布式文件系统改进系统性能的尝试过程和操纵步骤，图文并茂生动有趣，内容翔实丰富，得到了参会网友的极大好评。
51.com应用Mysql数据库进行在线灾备实践案例
田逸的演讲结束后，51.com数据库主管徐景春也向大家介绍了51.com在在线灾备方面的探索和研究。
徐景春介绍说，51.com公司从管理架构上就极为关注数据安全，因此身为数据库主管，徐景春本人在工作中也一直谨慎小心，从各种角度保障数据库的备份与灾备。而与此同时，一则报纸上的热点消息也更让51.com在灾备方面提高警惕：
去年，德克萨斯某公司丢失27GB档案数据没有备份，给该公司业务造成严重损失，为此，负责该备份项目的IBM公司被判罚90万美金。根据徐景春讲述，当时该公司老总以这例新闻提醒公司技术管理人员提高备份方面的安全措施，并要求彻底检查公司的备份措施是否完备。可见数据安全对于51.com的重要性。
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://images.lampchina.net/news/10/U6HVGKPRpMOIas8D2cYCmfTBtdu53g0X.jpg');}" onmousewheel="return imgzoom(this);" alt="" />
51.com数据库主管徐景春
提高数据安全性可能包括两个方面，首先是备份，其次是容灾，包括同城容灾和异地容灾，对于中国的大部分互联网公司来说，容灾方案实际上还是一个比较奢侈的方案，为此，徐景春详细介绍了51.com在备份方面的探索，实际上，备份也是灾备的重要组成部分，一个完整的备份方案已经能够应付大多数系统计划内和计划外的宕机情况。
最早51.com在成立初期，只有几台DB服务器，相互镜像，不要说灾备，普通的备份安全标准也完全没办法保证。一般来说都是通过手工输入命令进行备份。随着51.com业务发展，前端服务器数量迅速发展为几百台甚至上千台，此时，他们采用了自写的脚本进行自动化备份。但此时也同样产生一些问题，例如自写的脚本通常需要维护一个设备列表，当需要备份的服务器数量过于庞大的时候，通过认为操作这个列表变得极其繁琐，且出错率高。
而且随着公司业务模式的发展，备份需求也发生了较大的分化，某些应用例如交易结算型要求每小时就进行一次备份，某些应用则需要一天进行一次备份，而某些不重要的数据一个星期做一次备份即可。这个时候一套备份系统已经没办法满足需求了。因此需要为整个公司所有的备份需求进行统一的规划和整理。
这个时候51.com的备份体系已经非常复杂，Oracle备份与MySQL备份并存，手工备份与自动化备份并存，增量备份与全量备份混合使用，同时，该公司还实现了对电信和网通IDC机房的交叉同城异地备份，例如周一数据异地备份到电信机房，周二数据异地备份到网通机房，这样无论任何一边的机房挂掉，51.com整体系统仍然能尽可能多的数据，已经拥有一定的抗灾难能力。
相关阅读 更多 +
