面向?qū)ο蟠鎯Φ奈募到y(tǒng)Lustre

梁 軍，聶瑞華

（1.華南師范大學(xué) 網(wǎng)絡(luò)中心，廣東 廣州510631；2.華南師范大學(xué) 計(jì)算機(jī)學(xué)院，廣東 廣州510631）

0 引 言

相比于傳統(tǒng)的文件系統(tǒng)及存儲系統(tǒng)存在主機(jī)帶寬、內(nèi)存容量以及主機(jī)可用性等性能方面的限制，分布式文件系統(tǒng)不僅能為用戶提供海量的存儲空間和高聚合的I／O 帶寬，并且支持眾多的客戶端同時(shí)并發(fā)訪問，具有良好的可擴(kuò)展性。

在分布式文件系統(tǒng)［1－3］中，面向?qū)ο蟠鎯Φ奈募到y(tǒng)成為研究熱點(diǎn)。Lustre文件系統(tǒng)［4，5］是面向?qū)ο蟠鎯Φ奈募到y(tǒng)中的一種，它是一個(gè)大規(guī)模的、高性能的、高可用的集群文件系統(tǒng)。本文通過普通PC和TCP／IP協(xié)議搭建了Lustre文件系統(tǒng)，并測試和優(yōu)化了整個(gè)系統(tǒng)的性能。在TCP／IP協(xié)議上實(shí)現(xiàn)和優(yōu)化Lustre文件系統(tǒng)，使Lustre大規(guī)模應(yīng)用成為可能。

1 Lustre文件系統(tǒng)架構(gòu)

Lustre文件系統(tǒng)由3 部分組成［6］：元數(shù)據(jù)服務(wù)器（MDS）、對象存儲服務(wù)器 （OSS）和客戶 端 （Client）。MDS負(fù)責(zé)元數(shù)據(jù)的管理，向客戶端提供整個(gè)文件系統(tǒng)的元數(shù)據(jù)信息，并維護(hù)整個(gè)文件系統(tǒng)的目錄創(chuàng)建、刪除、修改等訪問控制，向外提供元數(shù)據(jù)存儲和訪問接口。OSS負(fù)責(zé)客戶端和物理存儲之間的交互及數(shù)據(jù)的存儲，向外提供數(shù)據(jù)的I／O 接口。client與MDS進(jìn)行元數(shù)據(jù)的交互，與OSS進(jìn)行文件對象的交互，用戶通過client透明地訪問數(shù)據(jù)，而不用關(guān)心數(shù)據(jù)的存儲位置。MDS、OSS和clent可以安裝在不同的機(jī)器上，也可以安裝在同一臺機(jī)器上。MDS、OSS和client相互分離，可以提高Lustre系統(tǒng)的性能。

2 Lustre工作機(jī)制

2.1 Lustre交互過程

Lustre內(nèi)部組件如圖1 所示［7，8］。在客戶端 （Clent），Lustre通過把Llite層掛在linux 內(nèi)的VFS層上，來實(shí)現(xiàn)統(tǒng)一的文件系統(tǒng)接口訪問。客戶端通過MDC 向MDS獲取元數(shù)據(jù)，包括文件對象的布局信息。客戶端中的LOV 解釋文件布局信息，使OSC可以和OSS中的OST 請求交互信息；在對象存儲服務(wù)器端 （OSS），通過OST 組件調(diào)用不同的函數(shù)來處理客戶端的請求：鎖相關(guān)請求和數(shù)據(jù)相關(guān)請求。OST 調(diào)用ldlm 處理鎖相關(guān)的請求，調(diào)用obdfilter處理數(shù)據(jù)相關(guān)的請求；在元數(shù)據(jù)服務(wù)器端 （MDS），通過MDS組件調(diào)用ldlm 和Journal來處理不同的事務(wù)［9］。Client和OSS、client和MDS 都是以RPC 請求和應(yīng)答的形式交互，組件PTR－RPC和LNET 實(shí)現(xiàn)該功能。

圖1 Lustre內(nèi)部組件

2.2 分布式鎖模式

分布式鎖管理器使集群系統(tǒng)中的節(jié)點(diǎn)或進(jìn)程可以同步訪問共享資源。在圖1 中，OSS和MDS都有l(wèi)dlm 鎖組件來處理鎖相關(guān)的操作。Lustre系統(tǒng)中鎖模式有6 種，如下所示。

（1）獨(dú)占模式 （exclusive，EX），獨(dú)占獲得的資源，并且其它進(jìn)程不能讀寫該資源。

（2）保護(hù)寫模式 （protective write，PW），允許資源持有者讀和寫，非持有者并發(fā)讀，不允許其它訪問者寫操作。

（3）保護(hù)讀模式 （protective read，PR），允許所有訪問者并發(fā)讀，不允許寫操作。

（4）并發(fā)寫模式 （concurrent write，CW），允許資源持有者和其它訪問者并發(fā)讀寫操作。

（5）并發(fā)讀模式 （concurrent read，CR），允許資源持有者和其它訪問者并發(fā)讀操作。

（6）空模式 （NULL，NL），當(dāng)沒有其它鎖存在時(shí)，為空模式。

2.3 分布式鎖的獲取與釋放［10，11］

當(dāng)有客戶端請求對資源進(jìn)行鎖模式時(shí)，OSS和MDS中通過ldlm 組件處理該請求。當(dāng)客戶端持有鎖時(shí)，它不會主動釋放，當(dāng)其它客戶端請求的鎖與它相沖突或者鎖過期時(shí)，才會釋放鎖。

獲取分布式鎖的過程如下：

（1）鎖客戶端首先匹配鎖請求，首先調(diào)用ldlm＿cli＿enqueue函數(shù)檢查ns＿client標(biāo)志來判斷鎖請求是否屬于本地名字空間。如果是本地的，不需要發(fā)送RPC 來通信，跳轉(zhuǎn)到第 （5）步；否則，需鎖服務(wù)器來處理。

（2）當(dāng)鎖服務(wù)器收到鎖請求時(shí)。首先重新建立一個(gè)鎖，然后檢查該鎖是否有意圖。如果沒有，則跳到第 （3）步，如果有，則調(diào)用意圖處理函數(shù)決定是否授權(quán)鎖，當(dāng)客戶端從服務(wù)器獲取返回的鎖獲得授權(quán)后，客戶端進(jìn)程就能對資源進(jìn)行訪問了。

（3）如果沒有鎖意圖，DLM 檢查該鎖與要訪問的資源上的鎖是否有沖突，如果沒有，鎖將被授權(quán)，同時(shí)返回授權(quán)的鎖。

（4）如果有沖突，DLM 將新鎖放入隊(duì)列等待，然后通知沖突鎖的持有者撤銷沖突鎖，直到?jīng)]有沖突。這時(shí)新鎖被授權(quán)，DLM 通過回調(diào)函數(shù)通知客戶端它請求的鎖已獲得授權(quán)。

（5）對于本地鎖請求，首先創(chuàng)建一個(gè)鎖，然后調(diào)用ldlm＿lock＿enqueue（）來檢查這個(gè)鎖是否被批準(zhǔn)。如果鎖被批準(zhǔn)或者出現(xiàn)了錯(cuò)誤，則返回。否則，鎖加入鎖等待隊(duì)列，需等待。

釋放分布式鎖的過程如下：當(dāng)鎖的讀計(jì)數(shù)和寫計(jì)數(shù)有一個(gè)不為0時(shí)，則需等待其它進(jìn)程不使用該鎖的資源。當(dāng)它們都為0時(shí)，客戶端會根據(jù)鎖的類型清除緩沖的數(shù)據(jù)，然后從本地鎖命名空間中刪除該鎖，并通知鎖服務(wù)器釋放該鎖。

3 性能測試

本文使用6臺普通PC機(jī)、1臺服務(wù)器和1臺千兆交換機(jī)做性能測試。PC機(jī)的配置為：AMD 雙核處理器、2G 內(nèi)存、千兆網(wǎng)卡；服務(wù)器的配置為：四核Intel處理器、8G內(nèi)存、千兆網(wǎng)卡，網(wǎng)絡(luò)拓?fù)淙鐖D2 所示。在3.1 和3.3 節(jié)中，5臺PC機(jī)單獨(dú)做5個(gè)OST，1臺PC機(jī)單獨(dú)做客戶端，服務(wù)器做MDS。在3.2節(jié)中，4臺PC 機(jī)單獨(dú)做4個(gè)OST，1 臺PC機(jī)同時(shí)做OST 和客戶端，1 臺PC 機(jī)單獨(dú)做客戶端，服務(wù)器做MDS。

圖2 網(wǎng)絡(luò)拓?fù)?/p>

在各節(jié)點(diǎn)中，使用的操作系統(tǒng)版本為CentOS5.3，Lustre文件系統(tǒng)版本是1.8.1，測試工具是IOzone3.4。假設(shè)client＿num 表示客戶端數(shù)，stripe＿count表示Lustre系統(tǒng)的條塊數(shù)，stripe＿size 表示Lustre 系統(tǒng)的條塊大小，block＿trans表示塊傳輸大小，file＿size表示讀寫文件的大小，start－ost等于－1表示目標(biāo)文件會條塊化存儲在所有可用的OST 上。

3.1 Lustre參數(shù)設(shè)置測試

3.1.1 stripe＿count參數(shù)

假設(shè)client＿num＝1，stripe＿size＝2MB，start－ost＝－1，file＿size＝4GB。在不同大小的stripe＿count下，Lustre的讀性能和寫性能如圖3和圖4所示。

圖3 不同stripe＿count下的Lustre讀文件性能

圖4 不同stripe＿count下的Lustre寫文件性能

從圖3 和圖4 可以看出：在block＿trans＝64、128、256、512、2048，stripe＿count設(shè)置為3時(shí)，Lustre系統(tǒng)的讀文件速度和寫文件速度最優(yōu)。當(dāng)block＿trans＝1024時(shí)，Lustre系統(tǒng)不穩(wěn)定，有明顯的波動。從理論上說，隨著stripe＿count的增加，系統(tǒng)可以同時(shí)進(jìn)行多個(gè)讀寫任務(wù)，Lustre文件系統(tǒng)的并發(fā)性能逐漸提升，系統(tǒng)的讀寫系統(tǒng)應(yīng)該更高。但在實(shí)際測試中，當(dāng)stripe＿count等于4 時(shí)，Lustre系統(tǒng)讀寫4GB 文件的速度小于stripe＿count＝3 的情況，說明文件的分解、網(wǎng)絡(luò)的傳輸?shù)阮~外的開銷會對Lustre文件系統(tǒng)的并發(fā)性能產(chǎn)生很大的影響。

3.1.2 stripe＿size參數(shù)

在3.1.1節(jié)中，stripe＿count設(shè)置為3使得Lustre系統(tǒng)在大多數(shù)塊傳輸中讀寫文件性能最優(yōu)。假設(shè)client＿num＝1，stripe＿count＝3，start－ost＝－1，file＿size＝4GB，改變stripe＿size的大小，測試其對系統(tǒng)性能所帶來的影響。不同stripe＿size下的Lustre讀寫文件性能如圖5和圖6所示。

從圖中看出：當(dāng)block＿trans＝64、256、1024、2048、4096時(shí)，設(shè)置stripe＿size為4MB，系統(tǒng)讀文件性能最優(yōu)；當(dāng)block＿trans＝64、128、256、512、2048、4096 時(shí)，設(shè)置stripe＿size為4MB，系統(tǒng)寫文件性能最優(yōu)。當(dāng)block＿trans等于其它的值時(shí)，設(shè)置stripe＿size為4MB，系統(tǒng)讀文件和寫文件的性能雖然不是最優(yōu)，但也有較好的性能表現(xiàn)。當(dāng)stripe＿size設(shè)置偏小時(shí)，文件被分割成塊的數(shù)量增多，塊數(shù)過多會加重MDS的管理負(fù)擔(dān)和增加網(wǎng)絡(luò)延時(shí)，將會造成整個(gè)文件系統(tǒng)的讀寫性能不佳；當(dāng)stripe＿size設(shè)置偏大時(shí)，文件被分割成塊的數(shù)量減少，不能充分利用系統(tǒng)的并發(fā)系統(tǒng)，也會使文件系統(tǒng)的讀寫性能達(dá)不到最優(yōu)。所以，需要設(shè)置合適的stripe＿size的大小來優(yōu)化整個(gè)系統(tǒng)的性能。

圖5 不同stripe＿size下的Lustre讀文件性能

圖6 不同stripe＿size下的Lustre寫文件性能

3.2 客戶端數(shù)大于2的Lustre性能測試

假設(shè)client＿num＝2，stripe＿size＝2MB，start－ost＝－1，file＿size＝4GB，lutre系統(tǒng)在不同的stripe＿count下的讀文件性能、寫文件性能如圖7和圖8所示：當(dāng)stripe＿count＝1、2、3時(shí)，Lustre集群系統(tǒng)的讀寫性能曲線呈現(xiàn)出拋物線形式；當(dāng)stripe＿count＝4時(shí)，Lustre集群系統(tǒng)性能相對穩(wěn)定。當(dāng)Lustre客戶端增加時(shí)，增大stripe＿count值才能使集群系統(tǒng)的性能較穩(wěn)定。

把圖7、圖8和圖3、圖4相比較，可以看出：在其它參數(shù)一樣的情況下，客戶端為2的Lustre集群系統(tǒng)比客戶端為1的Lustre集群系統(tǒng)的讀寫速度普遍要低。圖9是stripe＿count＝4時(shí)，不同客戶端下Lustre的讀性能。分析以上圖可得出結(jié)論：增加客戶端數(shù)不僅沒有發(fā)揮Lustre系統(tǒng)的并發(fā)性，而且還降低了整個(gè)集群系統(tǒng)的性能，這可能是網(wǎng)絡(luò)速度較低或MDS的性能較低引起的。這也說明了中間的傳輸開銷和控制開銷也會使Lustre系統(tǒng)發(fā)揮不出并發(fā)性能。

圖7 客戶端數(shù)為2的Lustre讀文件性能

圖8 客戶端數(shù)為2的Lustre寫文件性能

圖9 不同客戶端數(shù)的Lustre讀文件性能

3.3 Lustre與本地文件系統(tǒng)的比較

傳統(tǒng)的文件系統(tǒng)操作簡單，管理方便，但它的擴(kuò)展性差和吞吐量低，同時(shí)也無法實(shí)現(xiàn)多個(gè)平臺之間的資源共享。Lustre采用條帶化存儲技術(shù)，以類似RAID0方式將文件分割成多個(gè)數(shù)據(jù)塊對象存儲于OST 上，每一個(gè)條塊都作為一個(gè)對象存儲在一個(gè)OST 上，即一個(gè)文件對應(yīng)多個(gè)OST，同時(shí)每個(gè)OST 上也分布有多個(gè)不同文件的條塊。

在Lustre系統(tǒng)中，假設(shè)client＿num＝1，stripe＿count＝3，stripe＿size＝4MB，start－ost＝－1，file＿size＝4GB。圖10是本地磁盤與Lustre讀寫性能的比較，從圖中看出：本地文件系統(tǒng)的讀文件速度為40MB／s～60MB／s，寫速度為38MB／s～45MB／s；Lustre的讀文件速度為79MB／s～85MB／s，寫速度為72MB／s～78MB／s。所以，相對本地文件系統(tǒng)，Lustre讀寫速度更快。Lustre系統(tǒng)在infiniband交換機(jī)上的寫文件速度大于讀文件速度，但在千兆交換機(jī)上測試的寫文件速度小于讀文件速度，說明網(wǎng)絡(luò)延遲會顛覆Lustre系統(tǒng)的特性。

圖10 Lustre與本地文件系統(tǒng)的比較

4 結(jié)束語

通過以上的實(shí)驗(yàn)測試分析可知：Lustre集群系統(tǒng)在TCP／IP協(xié)議下，通過千兆網(wǎng)絡(luò)交換機(jī)實(shí)現(xiàn)時(shí)，設(shè)置start－ost＝－1，file＿size＝4GB，stripe＿size＝4MB，stripe＿count＝3，client＿num ＝1，Lustre 系統(tǒng)性能較優(yōu)，因此，Lustre文件系統(tǒng)的參數(shù)設(shè)置對其性能發(fā)揮有較大的影響，合理的參數(shù)配置能提升Lustre文件系統(tǒng)性能。在該環(huán)境下，網(wǎng)絡(luò)延遲、傳輸開銷和控制開銷都會極大影響，甚至顛覆Lustre系統(tǒng)的特性，但相對本地磁盤系統(tǒng)，Lustre系統(tǒng)仍有較大的性能提升，有一定的實(shí)用性。

［1］Marshall Kirk McKusick，Sean Quinlan.GFS：Evolution on fastforward ［J］.ACM Queue，2009，7 （7）：10－20.

［2］Mohamad Sindi.Evaluating MPI implementations using HPL on an infiniband Nehalem Linux cluster［C］／／Seventh International Conference on Information Technology：New Generations，2010：19－25.

［3］Olson M.HADOOP：Scalable，flexible data storage and analysis［J］.IQT Quarterly，2010，1 （3）：14－18.

［4］Oracle.LustreTM 1.8operations manuaL ［EB／0L］.http：／／wiki.lustre.org／images／0／09／821－0035＿v1.3.pdf，2010.

［5］Sun microsystems，lustre file system datasheet ［R］.Santa Clara：Sun Microsystems，2008.

［6］Swapnil Patil，Garth Gibson.Scale and concurrency of GIGA＋：File system directories with millions of files ［C］／／Proceedings of the 9th USENIX Conference on File and Storage Technologies，2011.

［7］ZHOU Jiang，WANG Weiping，MENG Dan，et al.Key technology in distributed file system towards big data analysis［J］.Journal of Computer Research and Development，2014，51（2）：382－394 （in Chinese）.［周江，王偉平，孟丹，等.面向大數(shù)據(jù)分析的分布式文件系統(tǒng)關(guān)鍵技術(shù) ［J］.計(jì)算機(jī)研究與發(fā)展，2014，51 （2）：382－394.］

［8］Carns P，Lang S，Ross R，et al.Small－file access in parallel file systems［C］／／Processdings of the 23rd IEEE International Parallel and Distributed Processing Symposium，2009.

［9］ZHAN Keyu，LIU Haitao，LI Xiaoyong.Design of metadata high availability in distributed file systems［J］.Journal of Chinese Computer Systems，2013，34 （4）：801－805 （in Chinese）.［戰(zhàn)科宇，劉海濤，李小勇.分布式文件系統(tǒng)元數(shù)據(jù)服務(wù)器高可用性設(shè)計(jì) ［J］.小型微型計(jì)算機(jī)系統(tǒng)，2013，34（4）：801－805.］

［10］QIAN Yingjin.Research on key issues in large scale clustered file system lustre［D］.Changsha：National University of Defense Technology，2011 （in Chinese）. ［錢迎進(jìn).大規(guī)模Lustre集群文件系統(tǒng)關(guān)鍵技術(shù)的研究 ［D］.長沙：國防科學(xué)技術(shù)大學(xué)，2011.］

［11］CHENG Yu，LI Xiaoyong，DONG Xiaoming，et al.Design and implementation of a highly concurrent client in distributed storage systems［J］.Journal of Chinese Computer Systems，2014，35 （1）：24－29 （in Chinese）. ［程煜，李小勇，董曉明，等.分布式存儲系統(tǒng)中高并發(fā)客戶端的設(shè)計(jì)與實(shí)現(xiàn) ［J］.小型微型計(jì)算機(jī)系統(tǒng)，2014，35 （1）：24－29.］