F5公司北方区技术经理杨明飞先生介绍了F5公司文件虚拟化解决方案

    文件虚拟化在互联网存储架构设计中的应用
 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客户端),而是多对多的关系,这样一来,性能大幅提升毫无问题。
  田逸详细的演示了自己如何通过分布式文件系统改进系统性能的尝试过程和操纵步骤,图文并茂生动有趣,内容翔实丰富,得到了参会网友的极大好评。

更多相关资讯,请关注F5中国官方网站:www.f5.com.cn