lustre bonnie++測(cè)試

moxnet

用lustre做了個(gè)集群， 簡(jiǎn)單用bonnie++測(cè)試了一下， 貼個(gè)結(jié)果，大家評(píng)判一下。有許多對(duì)lustre不懂的地方， 還需要和大家多多交流.

用了三臺(tái)linux機(jī)器做oss, 第臺(tái)機(jī)器3個(gè)500G sata盤做ost,共9個(gè)ost,mdt和mgs在同一臺(tái)機(jī)器上，64位rhel4.4系統(tǒng), 使用的是TCP鏈接， 千M網(wǎng)卡，下面是在client上做的bonnie++測(cè)試結(jié)果。

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

復(fù)制代碼

有點(diǎn)不明白： 為什么千M網(wǎng)卡， 能跑700多Mbytes/s的IO？

還有一個(gè)用 iozone測(cè)試結(jié)果畫的立體圖：



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

nntp

性能正常，你可以在網(wǎng)卡驅(qū)動(dòng)和Qos上做調(diào)整，測(cè)試的手段在多一些，bonnie++給你一個(gè)baseline性能，未必就是實(shí)際使用的性能.

我看到你1/2/4G的測(cè)試，從結(jié)果來看也沒有什么好說的，應(yīng)該是這樣的表現(xiàn)的。

既然試驗(yàn)環(huán)境也有了，你就要做一些有意義的測(cè)試，比如 逐級(jí)減少文件尺寸，或者增加測(cè)試行為的多樣性. 看看多線程的測(cè)試結(jié)果如何? (tiobench)

有條件的話，還可以在測(cè)試中考察lustre在不同通訊通路上的性能，比如吧GigE改成IB.

molecar

我還是不會(huì)用那個(gè)插件畫圖。呵呵

moxnet

前幾天在上面跑了一下應(yīng)用， client上跑了緩存（文件大小平均在20M左右的樣子）， client的網(wǎng)口跑到500Mbits/s的時(shí)候（包括對(duì)外的流量和讀寫集群的流量）， 爬下了， 集群系統(tǒng)好好。的。

謝謝nntp老大， 這幾天在弄一個(gè)這樣的項(xiàng)目，有什么問題還請(qǐng)多多指教啊。

有沒有好的監(jiān)控方案？LLNL？打算搭一個(gè)。

另外， 還有個(gè)問題想請(qǐng)教，如果OST沒有容錯(cuò)， 如果有一個(gè)壞掉了， 比如一個(gè)磁盤， 把它拿下來了， 那以后訪問放在那個(gè)ost上的數(shù)據(jù)（比如文件file1)的時(shí)候， MDT上應(yīng)該還有那個(gè)文件file1的信息。 如果訪問file1的時(shí)候， 是直接返回錯(cuò)誤呢， 還是MDS會(huì)發(fā)現(xiàn)那個(gè)文件在所有OST上不存在（盡管MDT中有那個(gè)文件的元數(shù)據(jù)）， 而把元數(shù)據(jù)清掉而返回文件不存在？如果是前者， 當(dāng)OST壞掉了， 如果清掉MDS中的那些不完整的數(shù)據(jù)呢？

nntp

原帖由 moxnet 于 2008-2-26 20:32 發(fā)表
前幾天在上面跑了一下應(yīng)用， client上跑了緩存（文件大小平均在20M左右的樣子）， client的網(wǎng)口跑到500Mbits/s的時(shí)候（包括對(duì)外的流量和讀寫集群的流量）， 爬下了， 集群系統(tǒng)好好。的。

謝謝nntp老大， 這幾 ...

client 趴下應(yīng)該是client的問題.

lustre監(jiān)控，用nagios即可.

一個(gè)OSS上面的某個(gè)OST,維護(hù)這一個(gè)本地stripe列表，每個(gè)OSS上的OST都有. 不想你想的那樣是以某文件作為單位的. 橫向看過去，所有的相關(guān)OST組成的是一個(gè)匯聚stripes的pool, MDS作為master copy保留有stripes lists.
當(dāng)某個(gè)OST廢掉之后，比如對(duì)應(yīng)的盤陣硬件故障不可用. lustre保持著內(nèi)部在各個(gè)節(jié)點(diǎn)上的一致性檢查，當(dāng)client訪問到這個(gè)廢掉的OST之后，如果之前沒有經(jīng)過檢查間隔，就會(huì)報(bào)錯(cuò)，同時(shí)觸發(fā)一個(gè)此OST對(duì)應(yīng)的MDS上master copy的更新操作.更新完了之后，相應(yīng)的stripe lists會(huì)按照檢查間隔，同步到每個(gè)OSS的相關(guān)OST上.

我看到歐洲高能還有美國(guó)LLNL的人在作大型的lustre的時(shí)候, 除了購(gòu)置強(qiáng)勁的Lustre交換網(wǎng)絡(luò)比如Qudrics,還通過對(duì)lustre檢查間隔以及OST failed之后大量OSS節(jié)點(diǎn)和MDS的stripe lists同步的缺省操作代碼的修改，極大的優(yōu)化了lustre的性能. 你可以用google搜到CERN和LLNL的人撰寫的相關(guān)論文和實(shí)驗(yàn)室級(jí)的測(cè)試分析.

要做好lustre的性能優(yōu)化，最最影響lustre性能的就是write/read的allocation優(yōu)化，其次是device driver的優(yōu)化,包括比如2.6kernel中的Zero Copy.
等等.你可以在網(wǎng)上找到大量的lustre優(yōu)化的參考建議.

HP和Intel很早就介入CFS公司的lustre研發(fā)，我推薦你查閱HP的SFS, SFS是針對(duì)lustre進(jìn)行充分優(yōu)化的成型方案，適合用在生產(chǎn)環(huán)境. 由于lustre的部署對(duì)架構(gòu)和實(shí)施經(jīng)驗(yàn)要求非常高，所以build from scratch 對(duì)于普通的個(gè)人是很難做到及格的，成型的方案會(huì)讓你的項(xiàng)目成功率高很多.

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

molecar

謝謝老大，我用1.6做過日處理60T的lustre，后來由于備份和容災(zāi)跟不上，只好撤了下來。 挺懊惱的

nntp

原帖由 molecar 于 2008-2-28 00:47 發(fā)表
謝謝老大，我用1.6做過日處理60T的lustre，后來由于備份和容災(zāi)跟不上，只好撤了下來。 挺懊惱的

60T在國(guó)內(nèi)算是相當(dāng)大的項(xiàng)目了，應(yīng)該上SFS.

molecar

目前用了部分nas和san，lustre全部撤掉了！不過我還工作了。對(duì)lustre接觸的就比較少了！