基于MPI的并行文件傳輸服務(wù)器群_第1頁
基于MPI的并行文件傳輸服務(wù)器群_第2頁
基于MPI的并行文件傳輸服務(wù)器群_第3頁
基于MPI的并行文件傳輸服務(wù)器群_第4頁
基于MPI的并行文件傳輸服務(wù)器群_第5頁
已閱讀5頁,還剩5頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1、基于MPI的并行文件傳輸服務(wù)器群 黃松林1王 鵬1, 2 嚴(yán)偉才1 李裕森1 聶 治3成都信息工程學(xué)院并行計算實驗室 四川 成都 610225;2. 電子科技大學(xué) 四川 成都 610054;3.成都理工大學(xué) 四川 成都 610059)摘 要:本文運用MPI、COM/ActiveX和面向緩存等技術(shù)設(shè)計并實現(xiàn)了文件并行傳輸理論的新模型,將傳統(tǒng)的最小負(fù)載均衡調(diào)度單位縮小至低于單文檔大小,并將命令處理和數(shù)據(jù)服務(wù)相分離。文中給出了系統(tǒng)拓?fù)鋱D、命令處理流程圖和核心模塊的設(shè)計原理圖。實際測試結(jié)果表明,該系統(tǒng)增強了處理并發(fā)請求的能力和帶寬,大大提高了數(shù)據(jù)傳輸速率,證明了這一設(shè)計方案的可行性和有效性。關(guān)鍵詞:并

2、行文件傳輸協(xié)議;MPI;并行文件I/O;集群監(jiān)控中圖分類號:TP393文獻(xiàn)標(biāo)識碼:ATree-Structure Web Server ClustersBased on MPIHuang Songlin1 Wang Peng1, 2 Yan Weicai1 Li Yusen1 Nie Zhi3(1.Parallel Computing Laboratory, ChengduUniversity of Information Technology, Sichuan, Chengdu, 610225; 2. University of Electronic Science and Technolo

3、gy of China, Sichuan, Chengdu, 610054; 3. ChengduUniversity of Technology, SichuanChengdu 610059)Abstract:This paper discusses a new model of paralleled transfer theory of files in detail with technology of MPICOM/ActiveX and caching-oriented,which effectively reduce to single document for tradition

4、al least load balance scheduling units.System topology graph、the deal flow charts of command and the diagram of central module are described in the same time.The circulation result shows:this system enhances the ability of parallel query and increases the data transfervelocity, moreover, validates t

5、he feasibility of this model.Key Words:PFTP ; MPI; Paralleled File I/O; Cluste Monitor.引言隨著網(wǎng)絡(luò)技術(shù)的發(fā)展和普及,人們對FTP傳輸?shù)乃俣扰c穩(wěn)定性要求越來越高。從結(jié)構(gòu)上講,F(xiàn)TP屬于客戶/服務(wù)器結(jié)構(gòu),是一種簡單的多對一結(jié)構(gòu),即多臺客戶機向一臺服務(wù)器發(fā)出請求,此服務(wù)器對各個客戶機分時作出應(yīng)答。隨著并行FTP用戶的增加,服務(wù)器的網(wǎng)絡(luò)傳輸效率會顯著下降,表現(xiàn)為:數(shù)據(jù)傳輸速度不穩(wěn)定,服務(wù)器對請求響應(yīng)遲緩,甚至拒絕應(yīng)答,傳統(tǒng)的解決方法是限制客戶的連接數(shù)。本文將并行計算理論應(yīng)用到傳統(tǒng)的FTP系統(tǒng)中,通過增加服務(wù)器結(jié)點的

6、數(shù)量來增加帶寬和同時訪問連接數(shù),并對這些服務(wù)器結(jié)點進(jìn)行集中控制和管理,以確保整個系統(tǒng)中對用戶是透明的,多臺服務(wù)器節(jié)點并行地傳輸同一個文件的不同塊,因而既增大了系統(tǒng)帶寬又提高了文件傳輸速度。基于這種思想的并行文件傳輸服務(wù)器群,可以有效地解決現(xiàn)有FTP系統(tǒng)存在問題1-5。MPI及相關(guān)技術(shù)MPI (Message Passing Interface)是由MPI論壇開發(fā)的一個非專利且獨立于平臺的消息傳遞函數(shù)庫的與語言無關(guān)的標(biāo)準(zhǔn)規(guī)范,而不特指某一具體實現(xiàn)6。MPI是目前最重要的并行編程工具,它具有移植性好、功能強大、效率高等優(yōu)點,而且有多種不同的實現(xiàn)版本,幾乎所有的并行計算機廠商都提供對它的支持,這是其

7、他并行編程環(huán)境所無法比擬的。MPI不僅提供了多種通訊模式,其打/解包收發(fā)不連續(xù)數(shù)據(jù)功能有效的減少了通訊次數(shù);他的擴充版本MPI-2提供文件并行I/O,能夠方便的實現(xiàn)文件的并行讀寫?;谶@些原因,本文選用了MPI作為服務(wù)端系統(tǒng)的開發(fā)平臺?;贛PI的并行文件傳輸服務(wù)器群模型3.1 并行服務(wù)器群的拓?fù)浣Y(jié)構(gòu)服務(wù)器節(jié)點呈層疊結(jié)構(gòu)排列,分為調(diào)度節(jié)點與子結(jié)點。調(diào)度結(jié)點只有一個,調(diào)度服務(wù)器可能在下層搜尋負(fù)載最輕的子節(jié)點和進(jìn)行并行I/O操作。子結(jié)點有多個,結(jié)點數(shù)可擴展,增加層內(nèi)節(jié)點數(shù)目即可提升系統(tǒng)處理大批量請求的能力。當(dāng)然,服務(wù)樹具體的規(guī)模應(yīng)以實際需求和單個服務(wù)器性能而定。監(jiān)控結(jié)點只有一個,獨立于服務(wù)器群。如

8、圖1圖1 PFTP系統(tǒng)拓?fù)鋱D【注:11,接收用戶請求。12分析消息中包含的文檔大小,文件并行I/O。13,本地數(shù)據(jù)服務(wù)。14,MPI消息傳遞。15,響應(yīng)客戶請求;21,收集各結(jié)點監(jiān)控數(shù)據(jù)。22,讀取監(jiān)控數(shù)據(jù)】3.2 并行服務(wù)器群的調(diào)度策略傳統(tǒng)的分布式調(diào)度策略和負(fù)載均衡算法所采用的最小調(diào)度單位為文件甚至為本次連接,很難實現(xiàn)理想中的負(fù)載均衡。我們的目標(biāo)是要設(shè)計并行服務(wù)的調(diào)度策略。模型中主服務(wù)器(單臺)所維護的文件索引列表面向緩存,當(dāng)解析到用戶發(fā)出信息為列表目錄時,立即在該索引表中應(yīng)列表信息并返回用戶;對應(yīng)解析為下載信號時則根據(jù)用戶所創(chuàng)線程數(shù)和子服務(wù)器實時負(fù)載對任務(wù)分解、動態(tài)調(diào)度,并由子服務(wù)器(多臺

9、)并行提供數(shù)據(jù)服務(wù),調(diào)度算法遵循在并行粒度范圍內(nèi)按最輕網(wǎng)絡(luò)流量負(fù)載節(jié)點優(yōu)先調(diào)度的法則,使得各子服務(wù)器在任意時刻其負(fù)載量均趨于一致,整體負(fù)載更加均衡。具體流程請參考表1。表1 主服務(wù)器處理用戶的不同命令b a獲取列表信息下載文件第一步讀取文件索引表調(diào)用任務(wù)分配算法第二步由主服務(wù)器返回用戶由子服務(wù)器并行返回用戶(a. 用戶命令;b. 主服務(wù)器處理步驟)與分布式系統(tǒng)一樣7, 文件并行傳輸系統(tǒng)(稱為PFTP系統(tǒng))把命令處理和數(shù)據(jù)服務(wù)分離,并分別在不同的機器上執(zhí)行,能有效的在不增加連接數(shù)的前提下增加帶寬。子服務(wù)器能具體到對某一個文件進(jìn)行并行服務(wù),且任一子服務(wù)器間無交互,很容易實現(xiàn)分布化。主服務(wù)器的內(nèi)存中

10、文件索引列表覆蓋了鏡像子服務(wù)器內(nèi)共享目錄的全部信息。對應(yīng)在子服務(wù)器內(nèi)存有簡化版的文件索引表,只具有文件編號和路徑的映射功能。主服務(wù)器直接返回列表信息于用戶避免的大量的費時的tcp轉(zhuǎn)接操作,而在所有服務(wù)器均設(shè)置文件索引表則優(yōu)化了任務(wù)分配時的內(nèi)部網(wǎng)絡(luò)通信。主服務(wù)器申請load集合,用于緩存當(dāng)前各子服務(wù)器實際文件服務(wù)負(fù)載信息,該全局信息為任務(wù)的精確調(diào)度提高了依據(jù)。該load集合的維護采用異步模式,即能在每次調(diào)度時直接于內(nèi)存中獲得信息又能根據(jù)子服務(wù)器的狀態(tài)改變或當(dāng)前文件服務(wù)完畢而發(fā)往主服務(wù)器的信號引起主服務(wù)器動態(tài)改變load集合的值。子服務(wù)器申請一隊列用于緩存主服務(wù)器分配的任務(wù),該隊列設(shè)有超時功能,在

11、規(guī)定時限內(nèi)一旦有用戶通過連接驗證立即將對應(yīng)任務(wù)取出并按任務(wù)規(guī)定的偏移量I/O和提高數(shù)據(jù)服務(wù)。3.3 并行服務(wù)器群的MPI實現(xiàn)文件索引表本文提出的并行文件傳輸服務(wù)器群建立在MPI的消息傳遞機制之上. 為了減少主服務(wù)器給子服務(wù)器通信的數(shù)據(jù)量, 在各子服務(wù)器內(nèi)存中維護了同樣的文件索引表(字符串?dāng)?shù)組), 數(shù)組的下標(biāo)代表文件編號, 相應(yīng)的字符串代表此文件的完整路徑。 主服務(wù)器只需告訴子服務(wù)器文件編號, 子服務(wù)器就能從文件索引表得到完整路徑。 但這樣做的結(jié)果是主服務(wù)器每更改一次文件列表都要對子服務(wù)器上的索引表進(jìn)行更新。而對數(shù)組進(jìn)行增加/減少元素開銷比較大, 但穩(wěn)定運行的服務(wù)器都不會經(jīng)常變動文件,這種運行期

12、間的文件列表更新操作是很少的, 所以不會對服務(wù)器性能造成影響。服務(wù)器命令處理流程圖根據(jù)不同命令的處理情況, 將常用的命令分為以下5個組。1 申請數(shù)據(jù)通道命令, 用于主服務(wù)器傳送文件列表信息給客戶; 2 讀文件列表命令; 3 寫文件列表命令; 4 讀寫文件命令; 5 其它命令。 主服務(wù)器初始化完成后等待客戶發(fā)送命令請求, 接收到客戶端命令后, 通過命令解析,根據(jù)以上分類,進(jìn)行不同的處理。流程圖如下:圖2 命令處理流程圖本文提出的并行文件傳輸服務(wù)器群建立在MPI的消息傳遞機制之上。 由主節(jié)點維護文件列表(沒有數(shù)據(jù)文件),各子服務(wù)器必須具有相同的文件。 主服務(wù)器根據(jù)子服務(wù)器的負(fù)載進(jìn)行任務(wù)分配, 然后

13、各個子服務(wù)器同時發(fā)送數(shù)據(jù)到客戶端。其基本流程圖如下:3.3.3 客戶端的實現(xiàn)COM (Component Object Model, 組件對象模型)是Microsoft創(chuàng)建的一種編程規(guī)范, 它允許任意兩個組件互相通信, 在二進(jìn)制級別上重用代碼。 activeX是COM規(guī)范的一個實現(xiàn)。客戶端以activeX插件的形式實現(xiàn), 它能夠在Microsoft 的 Internet Explorer中被html代碼調(diào)用, 這樣就將c/s和b/s應(yīng)用無縫集成。用戶第一次訪問時插件將自動下載并注冊。在客戶端的角度看,基本流程如圖3:圖3.時序圖3.4 并行服務(wù)器的監(jiān)控模型為了確保服務(wù)器各個服務(wù)器節(jié)點安全地運行

14、,增加一個節(jié)點作為監(jiān)控節(jié)點,該節(jié)點獨立運行于windows平臺。監(jiān)控內(nèi)容包含: 機器名,CPU利用率,內(nèi)存利用率,網(wǎng)卡流量,用戶線程數(shù),結(jié)點負(fù)載和系統(tǒng)時間等。服務(wù)器各結(jié)點每隔一秒寫入一條記錄。為了便于顯示數(shù)據(jù),采用B/S模式,用圖形把當(dāng)前各個節(jié)點的狀態(tài)動態(tài)地顯示在網(wǎng)頁上。紅色的柱形描述每秒各節(jié)點狀況,曲線圖描述各個節(jié)點最近10秒的記錄。這樣,管理員即使在遠(yuǎn)程,也能查看到系統(tǒng)的運行狀況。4. 系統(tǒng)實際運行性能評價表2為系統(tǒng)在不同節(jié)點數(shù)的情況下傳輸不同大小的文件所需要的時間,從表中我們可以看出,采用本文所提出的并行FTP(PFTP)系統(tǒng)后,系統(tǒng)的傳輸速度隨著節(jié)點數(shù)的增加呈線性增長趨勢。證明系統(tǒng)性能

15、達(dá)到我們的設(shè)計要求。表2 不同節(jié)點數(shù)下系統(tǒng)文件傳輸時間實測表節(jié)點數(shù)文件大?。∕B)12341012秒6秒4秒3秒5061秒31秒21秒16秒100124秒42秒43秒32秒200248秒130秒86秒64秒5. 結(jié)語本文通過采用層疊式服務(wù)器結(jié)構(gòu)及MPI作為通訊實現(xiàn)了并行文件傳輸?;贛PI的并行文件傳輸服務(wù)器群,可以很好地解決文件下載速度與并行連接上限等問題。通過系統(tǒng)數(shù)據(jù)傳輸性能進(jìn)行實測,取得了良好的效果,驗證了這種方案的可行性。該模型具有較高的性價比,實現(xiàn)了低成本、高性能服務(wù)器構(gòu)架方法。在理論上,只需增加子服務(wù)器結(jié)點的個數(shù),即可提高服務(wù)器的性能,這就為網(wǎng)絡(luò)視頻傳輸,網(wǎng)絡(luò)硬盤等存在大量數(shù)據(jù)傳輸

16、的應(yīng)用提供了一種新的思路。參考文獻(xiàn):1 Zhang XL,Barrientos M,Chen JBSeltzer M.HACC : An architecture for cluster-based Web servers.Proceedings of the 3rd USENIX Windows NT Symposium.1999.155-164.2Yang CS, Luo MY. Efficient support for content-based routing in web server clusters.Proceeding of the 2nd USENIX/IEEESymposium on Internet Technologies and Systems. 1999.3 徐忻,吳介一. Web服務(wù)結(jié)構(gòu)模型的研究與實現(xiàn)J.微計算機信息,2006,5-3:103-105。4 Cohen A, Rangarajan S, Slye H. On the performance of TCP splicing for URL

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論