- 论坛徽章:
- 0
|
原帖由 suran007 于 2005-12-9 17:16 发表
看了看lustre的maillist,说lustre在大文件写入和很多client的时候,才能充分体现lustre的性能优势,而他在小文件和单个client的性能方面并不是很出色,不知道对不对,那位朋友做过测试的,把测试结果贴出来看看, ...
没错,的确如此。目前在整个行业,要找到一个对大量小文件并发读写的解决方案,还非常困难。
所以你所言的确不假,其实我对lustre实际的性能是心里有数的,只不过也在观望是否有朋友创造了"奇迹"
大块的文件,非常得益于这种分布式的存储方式,client 发起I/O请求之后,只需要MDS按照优化的检索设计就可以获取目标的所有信息,然后因为做成了横跨多个OST的striping 的方式,加上每个OST自己也可以用external RAID stroage,做单个OST硬件上的raid striping,比如RAID10. 所以并发访问的时候,基本上效果和单独一个storage上访问一个RAID0差不多. 如果的ADM, MDS, OSTs之间,通过Infiniband联结,性能会好很多.
小文件则完全不同,比如我关心的<16k的文件,不可能stripe到多个OSTs上,也就是说,只有一个OST存放这个文件,更糟糕的时候,本来我single client 读写single server上同样大小的小文件的时候,metadata直接在fs上可以获得,没有外部延迟,现在MDS在ethernet上了,读写这样的小文件,我还要跨过一个ethernet来和MDS打交道. 等于是额外的开销增加了,当然同大文件一样,infiniband会好很多. 你可以想象读写海量的这样的文章,网络和来自单独设备上的延迟叠加起来会有多大.
然后,还有糟糕的事情,嘿嘿。 小文件在single OST上,因为我们现在的常规hardware 设备+现代OS,读写小文件本来性能就不会好.所以还会有一个延迟。
总而言之,如果你想要看到我上面说的这些状况,硬件上至少建议4个PC,最好6个, 1xADM, 1xMDS, 2/4 x OST. 你可以try try 大文件和小文件的区别. 就会发现结果还是会令人沮丧。换句话说,要想得到大并发,小文件多client的超级效果,目前还是要掏大把银子从硬件上解决.
vmware里面建议不要做性能的测试,因为根本没有意义。没有网络的区别,没有脱离Host OS 的fs 对guest OS的影响,你很难得到一个正确的基础数据。
single client or large amount client 的问题,我觉得没有必要担忧,毕竟没有人花了大把的银子,请了做lustre的顾问来设计和实施系统,然后只让很少的client 来访问的。现实应用中不太可能。
我看按照目前的性能表现,国内现在做游戏和数码电影的中小型公司比较多了,可以用廉价的设备来搭建这样一套东西,比如作DCC的 rendering Farm之类的。好歹也不用每次都购买上百万的硬件存储设备了.
SATAII马上就要变成mainstream乐,听说对小文件的i/o performance 让人惊讶,虽然MTBF及不上SCSI, 但是便宜就是硬道理。每个OST到时候挂上2个SATAII的external storage, 就可以把整套TB级的Lustre控制在100万人民币以内了,这样还是有很高的现实意义的。
就是配套的擅长lustre应用的顾问并不多,在这里能够看到有对lustre感兴趣的朋友震得很好。 希望多做交流。
[ 本帖最后由 nntp 于 2005-12-10 06:34 编辑 ] |
|