lustre bonnie++测试

moxnet

用lustre做了个集群， 简单用bonnie++测试了一下， 贴个结果，大家评判一下。有许多对lustre不懂的地方， 还需要和大家多多交流.

用了三台linux机器做oss, 第台机器3个500G sata盘做ost,共9个ost,mdt和mgs在同一台机器上，64位rhel4.4系统, 使用的是TCP链接， 千M网卡，下面是在client上做的bonnie++测试结果。

1. 
   
2. 
   
3. Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
   
4.                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
   
5. Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
   
6. CFSHOST  1G 11141  17 12233   2 11490   4 69465  99 787158  99  9484  19
   
7.                     ------Sequential Create------ --------Random Create--------
   
8.                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
   
9.               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
   
10.                  16  1106   5  1013   9  1926   4  1115   5   980   8  1947   5
    
11. CFSHOST,1G,11141,17,12233,2,11490,4,69465,99,787158,99,9483.6,19,16,1106,5,1013,9,1926,4,1115,5,980,8,1947,5
    
12. 
    
13. 
    
14. Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
    
15.                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
    
16. Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
    
17. CFSHOST  2G 11644  18 11835   2 11422   3 69463  99 768134  99 +++++ +++
    
18.                     ------Sequential Create------ --------Random Create--------
    
19.                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
    
20.               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
    
21.                  16  1128   6   992   8  1928   7  1118   5   991   8  2005   6
    
22. CFSHOST,2G,11644,18,11835,2,11422,3,69463,99,768134,99,+++++,+++,16,1128,6,992,8,1928,7,1118,5,991,8,2005,6
    
23. 
    
24. Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
    
25.                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
    
26. Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
    
27. CFSHOST  4G 11655  18 11545   2 11441   3 69361  99 765375  99 +++++ +++
    
28.                     ------Sequential Create------ --------Random Create--------
    
29.                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
    
30.               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
    
31.                  16  1129   5   972   9  1893   6  1118   5  1007   9  1937   5
    
32. CFSHOST,4G,11655,18,11545,2,11441,3,69361,99,765375,99,+++++,+++,16,1129,5,972,9,1893,6,1118,5,1007,9,1937,5h

复制代码

有点不明白： 为什么千M网卡， 能跑700多Mbytes/s的IO？

还有一个用 iozone测试结果画的立体图：



[ 本帖最后由 moxnet 于 2008-2-24 12:42 编辑 ]

nntp

性能正常，你可以在网卡驱动和Qos上做调整，测试的手段在多一些，bonnie++给你一个baseline性能，未必就是实际使用的性能.

我看到你1/2/4G的测试，从结果来看也没有什么好说的，应该是这样的表现的。

既然试验环境也有了，你就要做一些有意义的测试，比如 逐级减少文件尺寸，或者增加测试行为的多样性. 看看多线程的测试结果如何? (tiobench)

有条件的话，还可以在测试中考察lustre在不同通讯通路上的性能，比如吧GigE改成IB.

molecar

我还是不会用那个插件画图。呵呵

moxnet

前几天在上面跑了一下应用， client上跑了缓存（文件大小平均在20M左右的样子）， client的网口跑到500Mbits/s的时候（包括对外的流量和读写集群的流量）， 爬下了， 集群系统好好。的。

谢谢nntp老大， 这几天在弄一个这样的项目，有什么问题还请多多指教啊。

有没有好的监控方案？LLNL？打算搭一个。

另外， 还有个问题想请教，如果OST没有容错， 如果有一个坏掉了， 比如一个磁盘， 把它拿下来了， 那以后访问放在那个ost上的数据（比如文件file1)的时候， MDT上应该还有那个文件file1的信息。 如果访问file1的时候， 是直接返回错误呢， 还是MDS会发现那个文件在所有OST上不存在（尽管MDT中有那个文件的元数据）， 而把元数据清掉而返回文件不存在？如果是前者， 当OST坏掉了， 如果清掉MDS中的那些不完整的数据呢？

nntp

原帖由 moxnet 于 2008-2-26 20:32 发表
前几天在上面跑了一下应用， client上跑了缓存（文件大小平均在20M左右的样子）， client的网口跑到500Mbits/s的时候（包括对外的流量和读写集群的流量）， 爬下了， 集群系统好好。的。

谢谢nntp老大， 这几 ...

client 趴下应该是client的问题.

lustre监控，用nagios即可.

一个OSS上面的某个OST,维护这一个本地stripe列表，每个OSS上的OST都有. 不想你想的那样是以某文件作为单位的. 横向看过去，所有的相关OST组成的是一个汇聚stripes的pool, MDS作为master copy保留有stripes lists.
当某个OST废掉之后，比如对应的盘阵硬件故障不可用. lustre保持着内部在各个节点上的一致性检查，当client访问到这个废掉的OST之后，如果之前没有经过检查间隔，就会报错，同时触发一个此OST对应的MDS上master copy的更新操作.更新完了之后，相应的stripe lists会按照检查间隔，同步到每个OSS的相关OST上.

我看到欧洲高能还有美国LLNL的人在作大型的lustre的时候, 除了购置强劲的Lustre交换网络比如Qudrics,还通过对lustre检查间隔以及OST failed之后大量OSS节点和MDS的stripe lists同步的缺省操作代码的修改，极大的优化了lustre的性能. 你可以用google搜到CERN和LLNL的人撰写的相关论文和实验室级的测试分析.

要做好lustre的性能优化，最最影响lustre性能的就是write/read的allocation优化，其次是device driver的优化,包括比如2.6kernel中的Zero Copy.
等等.你可以在网上找到大量的lustre优化的参考建议.

HP和Intel很早就介入CFS公司的lustre研发，我推荐你查阅HP的SFS, SFS是针对lustre进行充分优化的成型方案，适合用在生产环境. 由于lustre的部署对架构和实施经验要求非常高，所以build from scratch 对于普通的个人是很难做到及格的，成型的方案会让你的项目成功率高很多.

[ 本帖最后由 nntp 于 2008-2-27 04:10 编辑 ]

molecar

谢谢老大，我用1.6做过日处理60T的lustre，后来由于备份和容灾跟不上，只好撤了下来。 挺懊恼的

nntp

原帖由 molecar 于 2008-2-28 00:47 发表
谢谢老大，我用1.6做过日处理60T的lustre，后来由于备份和容灾跟不上，只好撤了下来。 挺懊恼的

60T在国内算是相当大的项目了，应该上SFS.

molecar

目前用了部分nas和san，lustre全部撤掉了！不过我还工作了。对lustre接触的就比较少了！