1. <tt id="5hhch"><source id="5hhch"></source></tt>
    1. <xmp id="5hhch"></xmp>

  2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

    <rp id="5hhch"></rp>
        <dfn id="5hhch"></dfn>

      1. 高性能計算機(jī)分布式內(nèi)存文件系統(tǒng)的網(wǎng)絡(luò)性能優(yōu)化方法論文

        時間:2022-11-08 10:58:42 計算機(jī)畢業(yè)論文 我要投稿
        • 相關(guān)推薦

        高性能計算機(jī)分布式內(nèi)存文件系統(tǒng)的網(wǎng)絡(luò)性能優(yōu)化方法論文

          高性能計算應(yīng)用對計算節(jié)點(diǎn)內(nèi)存的不均衡需求導(dǎo)致節(jié)點(diǎn)之間內(nèi)存利用率差異較大,為充分利用高性能計算機(jī)的內(nèi)存資源,產(chǎn)生了基于計算節(jié)點(diǎn)內(nèi)存構(gòu)建分布式文件系統(tǒng)的需求。此時,基于Socket的網(wǎng)絡(luò)通信成為制約系統(tǒng)性能的主要瓶頸。

        高性能計算機(jī)分布式內(nèi)存文件系統(tǒng)的網(wǎng)絡(luò)性能優(yōu)化方法論文

          高性能計算應(yīng)用對計算節(jié)點(diǎn)內(nèi)存的不均衡需求導(dǎo)致計算節(jié)點(diǎn)之間內(nèi)存利用率差異較大,為充分利用高性能計算機(jī)的內(nèi)存資源,為緩解這一狀況,產(chǎn)生了基于計算節(jié)點(diǎn)空閑內(nèi)存構(gòu)建分布式內(nèi)存文件系統(tǒng)的需求。當(dāng)存儲介質(zhì)從磁盤變?yōu)閮?nèi)存,系統(tǒng)服務(wù)端I/O性能大幅提高,基于Socket的網(wǎng)絡(luò)通信成為制約系統(tǒng)性能的主要瓶頸。針對這一問題,本文提出一種基于RDMA的數(shù)據(jù)傳輸機(jī)制RBP,通過在讀、寫不同場景下靈活配置和使用RBP,大幅提高了系統(tǒng)的網(wǎng)絡(luò)傳輸性能。

          1 相關(guān)工作

          1.1 MooseFS

          近年來,大數(shù)據(jù)、云計算、高性能計算蓬勃發(fā)展,分布式文件系統(tǒng)取得長足進(jìn)步。其中,GFS(Google File System)提出的以大量不可靠的服務(wù)器為基礎(chǔ)構(gòu)建高可靠的存儲系統(tǒng)的設(shè)計思想[1],對分布式文件系統(tǒng)發(fā)展具有重要意義。GFS并不開源,因此選擇設(shè)計接近的開源系統(tǒng)MooseFS[2],其具備支持POSIX語義、易擴(kuò)展、部署維護(hù)簡便等特點(diǎn),包括四個部件:

          元數(shù)據(jù)管理服務(wù)器Master,負(fù)責(zé)提供維護(hù)元數(shù)據(jù),提供元數(shù)據(jù)服務(wù),管理數(shù)據(jù)存儲服務(wù)器等。

          元數(shù)據(jù)日志服務(wù)器Metalogger,負(fù)責(zé)備份Master的變化日志文件。

          數(shù)據(jù)存儲服務(wù)器Chunkserver,在Master的調(diào)度下,為客戶端提供數(shù)據(jù)傳輸和存儲服務(wù)。

          客戶端Client,通過FUSE[3](File system in Userspace)掛載到MooseFS系統(tǒng)。

          1.2 RDMA

          RDMA是一種高帶寬、低延遲的網(wǎng)絡(luò)傳輸控制技術(shù),通過將可靠傳輸協(xié)議固化于網(wǎng)卡,支持繞過內(nèi)核的數(shù)據(jù)零拷貝。當(dāng)前,大多數(shù)高性能計算機(jī)的計算節(jié)點(diǎn)之間采用支持RDMA的網(wǎng)絡(luò)互連。以TH-1A系統(tǒng)為例,其采用支持RDMA的自主設(shè)計的高速互聯(lián)網(wǎng)絡(luò)[4]。通過Ping Pong方式測試,計算節(jié)點(diǎn)之間的最小單邊延遲低至1.57us。通過流水傳輸方式測試,單向數(shù)據(jù)傳輸峰值帶寬高達(dá)6.34GB/s。

          1.3 相關(guān)研究

          分布式存儲系統(tǒng)的分布式特性決定了其對通信是敏感的,因而往往要求通信能夠提供更高的帶寬和更低的延遲。鑒于RDMA通信在帶寬和延遲方面的良好特性,研究人員在如何利用RDMA通信機(jī)制改進(jìn)分布式存儲系統(tǒng)網(wǎng)絡(luò)性能方面做了很多工作。如N.S. Islam、M. W. Rahman等人為改進(jìn)HDFS(Hadoop Distributed File System的寫性能,在HDFS客戶端增加Java適配器,以便借助UCR(Unified Communication Runtime)提供的功能使用RDMA進(jìn)行通信[5]。Christopher Mitchell、Yifeng Geng等人設(shè)計了一個名為Pilaf的分布式內(nèi)存鍵值對存儲,根據(jù)鍵值對存儲以讀請求為主的特點(diǎn),實(shí)現(xiàn)了一個基于RDMA的get操作,用來處理只讀的服務(wù)請求,可以獲得顯著的性能收益[6]。顯然,在利用RDMA改進(jìn)分布式存儲系統(tǒng)網(wǎng)絡(luò)性能時,需要考慮分布式系統(tǒng)的特點(diǎn)、部署方式、額外開銷等諸多因素。

          2 MooseFS基于Socket的性能瓶頸

          MooseFS在處理一個讀/寫請求過程中,有2個環(huán)節(jié)涉及實(shí)際的數(shù)據(jù)操作:一是Chunkserver對本地磁盤進(jìn)行I/O操作,二是Client與Chunkserver之間通過Socket傳輸數(shù)據(jù)。當(dāng)MooseFS部署在磁盤時,Chunkserver中的數(shù)據(jù)塊以EXT4等本地文件系統(tǒng)的文件形式存儲在磁盤中;當(dāng)把MooseFS部署在內(nèi)存時,則可以借助tmpfs等內(nèi)存文件系統(tǒng)實(shí)現(xiàn)。

          為對比基于磁盤和內(nèi)存兩種形式,服務(wù)端I/O性能和系統(tǒng)I/O性能方面的差異,以寫為例進(jìn)行測試。Chunkserver使用TH-1A部署的Lustre系統(tǒng)作為本地文件系統(tǒng)。實(shí)驗(yàn)結(jié)果表明,相比基于磁盤的存儲形式,基于內(nèi)存存儲可以使Chunkserver的寫性能提高數(shù)倍,然而對系統(tǒng)整體寫性能的提升非常有限。此時系統(tǒng)的性能受到基于Socket的數(shù)據(jù)傳輸性能的制約。

          3 優(yōu)化方法

          3.1 基于RDMA的高速緩沖池RBP

          RBP的原理是預(yù)先注冊一塊或多塊支持RDMA操作的內(nèi)存區(qū),按照系統(tǒng)需求將這片區(qū)域劃分成不同規(guī)格的緩沖塊RBB(RDMA Buffer Block)。再根據(jù)不同用途,將同樣規(guī)格的RBB組織成不同的緩沖池RBP,并配合一套專用API,以RBB為單位提供高性能的數(shù)據(jù)傳輸服務(wù)。

          (1)RBP的結(jié)構(gòu)設(shè)計

          RBB由描述區(qū)、請求區(qū)和數(shù)據(jù)區(qū)三部分組成。描述區(qū)負(fù)責(zé)提供RBB進(jìn)行RDMA通信信息,包括RBB數(shù)據(jù)區(qū)所在注冊內(nèi)存區(qū)的端點(diǎn)信息、數(shù)據(jù)區(qū)偏移、大小等。請求區(qū)負(fù)責(zé)提供傳輸控制消息,包括Socket連接描述符、請求類型、請求數(shù)據(jù)偏移、大小等。數(shù)據(jù)區(qū)負(fù)責(zé)提供位于注冊內(nèi)存區(qū)的存儲空間。在利用RBB進(jìn)行RDMA通信時,RBB需要在通信兩端成對使用。

          RBP,即RDMA緩沖池,RBP的基礎(chǔ)是一個由RBB作為元素的雙向鏈表,此外還包括RBP所包含的注冊內(nèi)存區(qū)數(shù)組,用于進(jìn)行RBB管理的計數(shù)器,互斥量,條件變量等。

          (2)RBP的使用方式

          RBP的使用方式分為顯式和隱式兩種,顯式使用是指使用者在RBP創(chuàng)建好后就分配得到全部的RBB,此后由使用者自行管理,適用于用途明確且管理簡單的情形;隱式使用是指使用者在需要時從RBP分配RBB,使用完后再將RBB釋放,由專門的RBP管理模塊進(jìn)行管理,RBB分配與釋放對使用者是透明的,適于用作臨時用途的情形。一次基于RBP完整的RDMA通信可以分為三個階段:

          數(shù)據(jù)準(zhǔn)備,本地節(jié)點(diǎn)將數(shù)據(jù)寫入到分配的RBB數(shù)據(jù)區(qū)中,并向遠(yuǎn)程節(jié)點(diǎn)發(fā)送控制消息。

          數(shù)據(jù)接收,本地或遠(yuǎn)程節(jié)點(diǎn)根據(jù)控制信息通過RDMA操作讀/寫RBB數(shù)據(jù)區(qū)中的數(shù)據(jù)。

          資源釋放,本地和遠(yuǎn)程節(jié)點(diǎn)釋放此前分配的RBB。

          3.2 讀優(yōu)化

          (1)增加特定的讀RBP

          Client的每個讀請求都會被分配1個數(shù)據(jù)區(qū),于是為Client增加了一個64MB的Req RBP,其RBB大小等于Chunk大小,設(shè)為4MB,用于提供讀請求的數(shù)據(jù)區(qū),從而繞過臨時數(shù)據(jù)緩沖區(qū),直接利用RDMA通信從Chunkserver讀取數(shù)據(jù)。但是,Req RBP中RBB較大,限制了其數(shù)量,無法滿足多線程下大量請求對數(shù)據(jù)區(qū)的需求。于是Client增加一個作為臨時數(shù)據(jù)緩沖區(qū)的Read RBP,與Req RBP互為補(bǔ)充。為配合Client的RBP,Chunkserver增加一個作為臨時數(shù)據(jù)緩沖區(qū)Read RBP。兩端Read RBP的RBB大小均與CB相同,設(shè)為64KB。此外,讀優(yōu)化中的RBP都是隱式使用,因此兩端都需要RBP管理模塊。

          (2)引入連續(xù)讀流水線

          RBP對RBB的分配和釋放非常靈活,完全可以利用一個RBB準(zhǔn)備數(shù)據(jù),另一個RBB向Client提供數(shù)據(jù),因此,在Chunkserver的讀服務(wù)線程中對采用RMDA進(jìn)行連續(xù)讀的情形引入了流水線。

          (3)設(shè)計多通道策略

          為了充分利用Client端Req RBP和Read RBP兩個RBP的性能,增加了策略控制。當(dāng)讀請求的接收區(qū)大小超過1MB時,首先從Req RBP分配RBB作為數(shù)據(jù)區(qū),若分配失敗則繼續(xù)采用原有的方式分配內(nèi)存。由于傳輸非連續(xù)小數(shù)據(jù)時更適合采用Socket。因此,Chunkserver在提供數(shù)據(jù)時決定采用哪種通信方式,當(dāng)要傳輸?shù)臄?shù)據(jù)小于32KB時,采用Socket通信,其他情況,采用RDMA通信;谝陨喜呗,讀請求的數(shù)據(jù)傳輸有3條數(shù)據(jù)通道。如圖1(a)所示,通道①②都通過RDMA讀取數(shù)據(jù),通道①為Client采用Req RBP接收數(shù)據(jù),通道②為Client采用Read RBP接收數(shù)據(jù);通道③通過Socket讀取數(shù)據(jù)。

          3.3 寫優(yōu)化

          (1)增加特定的寫RBP

          Client已存在一個用于提高寫性能的Write Cache,于是增加一個顯示使用的Write RBP,將Write RBP與Write Cache進(jìn)行合并。為實(shí)現(xiàn)合并,Write RBP的大小與Write Cache設(shè)置保持一致,在初始化Write Cache時,每個CB都會綁定一個從Write RBP分配的RBB。同時,Write RBP初始化后由Write Cache進(jìn)行管理。

          為配合Client增加的Write RBP,Chunkserver增加一個Write RBP作為臨時數(shù)據(jù)緩沖區(qū),其RBB大小等于CB大小。Chunkserver的Write RBP與Read RBP均由RBP管理模塊進(jìn)行管理。

          (2)設(shè)計多通道策略

          出于和讀相同的考慮,寫同樣支持RDMA和Socket兩種通信方式。不同的是,由Client端在將CB寫入ChunkServer前決定采用哪種通信方式。因此,寫請求的數(shù)據(jù)傳輸會存在2條數(shù)據(jù)通道,如圖1(b)所示,通道(1)通過RDMA寫入數(shù)據(jù),通道(2)通過Socket寫入數(shù)據(jù)。

          4 性能評測

          (1)測試環(huán)境

          硬件環(huán)境:TH-1A系統(tǒng),6個計算節(jié)點(diǎn),1個作為Master,4個作為Client,1個大內(nèi)存節(jié)點(diǎn)作為Chunkserver。

          軟件版本:MooseFS3.0.73,IOR2.10.1。

          測試方法:測試文件大小為2GB,塊大小從16KB到4MB不等,采用直接IO模式進(jìn)行順序讀、寫測試。

          (2)測試結(jié)果與分析

          客戶端對比測試在1個Client下進(jìn)行,分別采用1、2、4、8個進(jìn)程進(jìn)行并行讀寫,以測試單個客戶端的整體性能。測試結(jié)果如圖2所示,在相同文件塊大小和相同進(jìn)程數(shù)時,改進(jìn)后系統(tǒng)的順序讀寫速度全面優(yōu)于原系統(tǒng)。讀速度最大可達(dá)到原系統(tǒng)的2.02倍;寫速度最大可達(dá)到原系統(tǒng)的2.63倍。此外,當(dāng)原系統(tǒng)進(jìn)程數(shù)從4個增加到8個時,已無明顯提升,說明接近基于Socket通信下的性能上限。但對于改進(jìn)后系統(tǒng),讀塊大小超過64KB的文件和寫塊大小超過512KB的文件,速度依然隨進(jìn)程數(shù)增加而穩(wěn)定提高。

          服務(wù)端對比測試在1個Chunkserver下進(jìn)行,采用4個Client,每個Client采用單進(jìn)程進(jìn)行并發(fā)讀寫,以測試單個服務(wù)端在順序讀寫時提供的聚合帶寬,測試結(jié)果如圖3所示。改進(jìn)后系統(tǒng)的單個服務(wù)端在順序讀時,向4個Client提供的帶寬最大可達(dá)到原系統(tǒng)的2.04倍;順序?qū)憰r的帶寬最大可以達(dá)到原系統(tǒng)的2.35倍。而且順序?qū)憰r的帶寬最大值為4.42GB/s,占到計算節(jié)點(diǎn)之間RDMA通信最大單向帶寬的接近70%。

          5 結(jié)束語

          本文提出一種基于RDMA的數(shù)據(jù)傳輸機(jī)制RBP,在MooseFS原有控制流程的基礎(chǔ)上,采用多種切實(shí)有效的設(shè)計,使其在RDMA網(wǎng)絡(luò)下的數(shù)據(jù)傳輸性能得到大幅提升,但對小數(shù)據(jù)和多進(jìn)程的支持還存在改進(jìn)空間。下一步考慮結(jié)合數(shù)據(jù)預(yù)取、寫合并、最小匹配等技術(shù),使RBP具有更全面的性能表現(xiàn)和更廣泛的應(yīng)用前景。

        【高性能計算機(jī)分布式內(nèi)存文件系統(tǒng)的網(wǎng)絡(luò)性能優(yōu)化方法論文】相關(guān)文章:

        互聯(lián)網(wǎng)金融風(fēng)險監(jiān)管存在的問題及優(yōu)化策略與方法論文04-25

        藝術(shù)的方法論文06-02

        優(yōu)化美術(shù)課堂教學(xué)能力論文11-03

        擬訂論文提綱的步驟與方法12-02

        論文的寫作技巧與方法08-04

        論文發(fā)表技巧及投稿方法09-01

        科技論文寫作方法04-27

        科技論文寫作方法11-03

        網(wǎng)絡(luò)管理論文07-31

        高校公共管理模式優(yōu)化策略分析論文04-25

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码

        1. <tt id="5hhch"><source id="5hhch"></source></tt>
          1. <xmp id="5hhch"></xmp>

        2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

          <rp id="5hhch"></rp>
              <dfn id="5hhch"></dfn>