基于YARN集群的計算加速部件擴展支持

李　欽　朱延超　劉　軼　錢德沛

(北京航空航天大學計算機學院　北京　100191) (網(wǎng)絡技術北京市重點實驗室(北京航空航天大學)　北京　100191) (liqin0728@gmail.com)

?

基于YARN集群的計算加速部件擴展支持

李欽朱延超劉軼錢德沛

(北京航空航天大學計算機學院北京100191) (網(wǎng)絡技術北京市重點實驗室(北京航空航天大學)北京100191) (liqin0728@gmail.com)

摘要以GPU和Intel MIC為代表的計算加速部件已在科學計算、圖形圖像處理等領域得到了廣泛的應用，其在基于云平臺的高性能計算及大數(shù)據(jù)處理等方向也具有廣泛的應用前景.YARN是新一代Hadoop分布式計算框架，其對計算資源的分配調(diào)度主要針對CPU，缺少對計算加速部件的支持.在YARN中添加計算加速部件需要解決多個難點，分別是計算加速部件資源如何調(diào)度以及異構節(jié)點間如何共享問題、多個任務同時調(diào)用計算加速部件而引起的資源爭用問題和集群中對計算加速部件的狀態(tài)監(jiān)控與管理問題.為了解決這些問題，提出了動態(tài)節(jié)點捆綁策略、流水線式的計算加速部件任務調(diào)度等，實現(xiàn)了YARN對計算加速部件的支持，并通過實驗驗證了其有效性.

關鍵詞分布式系統(tǒng)；YARN；計算加速部件；混合異構節(jié)點；圖形圖像處理器；節(jié)點捆綁；任務調(diào)度

2013年，Apache推出了其Hadoop分布式計算框架的第2代，命名為yet another resource negotiator (YARN)[1]，其采用新的計算框架，使用專門的Resource Manager對整個集群資源進行管理，單個節(jié)點的資源被劃分成多個Container(Ct)，由Node Manager對其進行管理，而具體的集群應用則通過Application Master完成所有的調(diào)度和管理.這使得它以后將不僅僅支持MapReduce計算模型[2]，更可以拓展至對內(nèi)存計算(例如Spark[3])、實時計算(例如Storm[4])等的支持，并使得多種計算模型可以同時使用在同一個集群中.

近些年，如何在包括Hadoop等分布式平臺下添加對于計算加速部件的支持成為分布式集群系統(tǒng)的一個研究方向.該主要研究方向有3個：1)將對于如GPU這樣的計算加速部件的支持加入到MapReduce分布式計算模型中，通過對MapReduce模型的某個模塊或者邏輯的創(chuàng)新型改進，實現(xiàn)包括Hadoop分布式系統(tǒng)在內(nèi)的所有支持MapReduce模型的分布式集群系統(tǒng)對于計算加速部件的支持[5-10]；2)在參考Hadoop調(diào)度系統(tǒng)的基礎上，改進其調(diào)度策略或者設計一個新的分布式集群系統(tǒng)，使其原生態(tài)地支持計算加速部件資源，其中多以計算加速部件作為加速模塊或者加速節(jié)點使用[11-16]；3)不對Hadoop的架構和任務調(diào)度方法進行修改，而是在某一種或者某幾種的特定應用上進行針對性的優(yōu)化，以達到提高集群性能的目的[17-18].

本文提出并實現(xiàn)了基于YARN架構的計算加速部件(包括GPU和Intel MIC)擴展支持.通過使用動態(tài)節(jié)點捆綁以及流水線式計算加速部件任務調(diào)度策略，對YARN架構進行了擴展，使得在全部或部分節(jié)點配置計算加速部件的分布式系統(tǒng)中，上層應用可以使用計算加速部件.

1YARN基本架構

YARN是Hadoop2.0的資源管理系統(tǒng)，其基本的設計思想是將MRv1中的JobTracker拆分成2個獨立的服務：一個全局的資源管理器(resource manager, RM)和每個應用程序獨有的應用控制器(application master, AM).其中，RM負責整個系統(tǒng)的資源管理和分配，而AM負責單個應用程序的管理[19].

Fig. 1　YARN architecture.圖1　YARN架構示意圖

1) RM

RM是一個全局的資源管理器，負責整個系統(tǒng)的資源管理和分配.它由調(diào)度器(scheduler)和應用程序管理器(applications manager)這2個組件構成.調(diào)度器根據(jù)容量、隊列等限制條件將系統(tǒng)中的資源分配給各個正在運行的應用程序.它不從事任何與具體應用程序有關的工作，而是根據(jù)各個應用程序的資源需求進行分配.應用程序管理器負責管理整個系統(tǒng)中的所有應用程序，包括應用程序的提交、與調(diào)度器協(xié)商已啟動AM、監(jiān)控AM的運行狀態(tài)并在失敗時重新啟動它等.

2) AM

用戶提交的每個應用程序都包含一個AM，它將與RM調(diào)度器協(xié)商獲取資源，再將得到的資源進一步分配給內(nèi)部的任務，與NM通信以啟動或停止任務，監(jiān)控任務的運行狀態(tài)，并在任務運行失敗時重新申請資源再次啟動任務.

3) NM

NM是每個節(jié)點上的資源和任務管理器，它會定時向RM匯報本節(jié)點的使用情況和各個Ct的運行狀態(tài)，以及接受并處理來自AM的Ct啟動或停止等請求.

4) Ct

Ct是YARN中的資源抽象，它封裝了某個節(jié)點的資源，主要包括CPU和內(nèi)存.當AM向RM申請資源時，RM為AM返回的資源就是使用Ct表示.YARN會為每一個任務分配一個Ct，且該任務只能使用該Ct中的資源.

2計算加速部件的支持擴展

2.1設計思路

在現(xiàn)有的YARN框架中添加例如GPU或者Intel MIC這樣的計算加速部件，并使之能夠滿足上層用戶對資源的需求，為此需要解決3個問題：

1) 集群中對計算加速部件的狀態(tài)監(jiān)控與管理問題.現(xiàn)有的YARN中不支持除CPU之外的計算資源，因此需要新添加對計算加速部件的管理.本文采用由NM負責獲取當前節(jié)點的計算加速部件的硬件信息，并在RM與NM之間增加實時計算加速部件的狀態(tài)反饋，使RM獲知計算加速部件的資源狀態(tài)，整個集群的計算加速部件狀態(tài)由RM進行監(jiān)控與管理.

2) 計算加速部件資源如何調(diào)度以及異構節(jié)點間如何共享問題.現(xiàn)有YARN框架將每個節(jié)點CPU計算資源分割成相同粒度的容器Ct，然后根據(jù)一定的調(diào)度策略對任務進行調(diào)度，其中各個Ct中的計算資源都是相互獨立的，不存在Ct到Ct之間的資源共享機制.但是與傳統(tǒng)的CPU資源不同，計算加速部件并不一定存在于每個節(jié)點上，并且在實際的應用場景中也不能要求每個節(jié)點都擁有計算加速部件.因此，計算加速部件的資源調(diào)度重點在于如何解決將集群中的計算加速部件資源讓每個節(jié)點都能夠獲取的問題.本文將集群中無計算加速部件的節(jié)點(NNode)與有計算加速部件的節(jié)點(ANode)建立動態(tài)捆綁關系，NNode中的需要計算加速部件執(zhí)行的任務將會提交給對應的ANode上，并異步等待計算結果的返回.詳細的節(jié)點捆綁策略將在2.3節(jié)中進行講述.

3) 多個任務同時調(diào)用計算加速部件而引起的資源爭用問題.單機環(huán)境下，多個進程如果同時使用例如GPU這樣的計算加速部件時，會造成計算、通信等資源的爭用，嚴重影響性能.在集群環(huán)境下同樣有這樣的問題.本文采用在ANode上建立一個特殊的Ct，稱為AcCt (accelerator container)，用來管理和調(diào)度獲取到的計算加速部件任務.詳細的AcCt任務調(diào)度策略將在2.4節(jié)講述.

2.2系統(tǒng)結構

在分布式集群系統(tǒng)YARN上支持帶有計算加速部件節(jié)點的設計方案的系統(tǒng)架構圖如圖2所示：

Fig. 2　Extended architecture of YARN.圖2　擴展后YARN架構示意圖

根據(jù)圖2的架構圖，應用調(diào)度流程總結如下：

1) 集群啟動時，運行在各個節(jié)點的NM會向RM提交當前節(jié)點資源信息，這其中包括計算加速部件的資源信息，RM會根據(jù)計算加速部件的資源信息按照節(jié)點捆綁策略建立NNode映射到ANode的捆綁列表，并返回給各個NM，這時，ANode就會將本地的AcCt啟動起來，并進行監(jiān)聽.

2) 用戶向RM提交作業(yè)后，會產(chǎn)生一個新的AM，這時，AM會向RM申請作業(yè)所需的資源(包括計算加速部件任務的資源).RM會按照之前建立好的捆綁映射列表返回給AM所需的Ct信息，但具體的捆綁映射列表對AM透明，不需AM獲知.

3) 作為Master的AM就會向分配給它的Ct發(fā)送任務并調(diào)度，若Ct遇到的是需求計算加速部件計算資源的任務，則會異步地向對應的ANode發(fā)送任務信息，這時，接收到任務的AcCt會按照流水線調(diào)度策略對任務進行處理，并在處理完成后將結果返回.

2.3節(jié)點捆綁策略

節(jié)點捆綁策略的基本原則是節(jié)點間距離最近原則，即同一機架內(nèi)視為距離最近可捆綁，機架間節(jié)點相互隔離、不可捆綁.策略的核心是在實現(xiàn)動態(tài)捆綁的前提下盡量使用“平衡且代價小”的調(diào)度算法，具體來講就是在動態(tài)變換時盡量保持原有NNode與ANode之間的對應關系.

RM會在各個NM啟動時接收到當前節(jié)點的計算加速部件信息，同時NM與RM之間的心跳線也會時刻傳遞當前節(jié)點的輔助存儲器信息.RM會根據(jù)這些接收到的資源信息進行NNode與ANode之間的捆綁.RM會為每個ANode建立1個以IP地址為鍵的棧結構，用來存儲其捆綁的NNode.同時，RM會為每個機架建立1個對應的排序隊列，用來放置之前建立的各個棧，排序隊列以棧的存儲節(jié)點個數(shù)為序.

1) 節(jié)點添加機制

① 接收NNode并添加時，將當前機架的排序隊列中最小的棧取出，將當前NNode放入，再將棧插入回隊列；

② 接收ANode并添加時，首先為其建立棧結構，然后判斷所在機架的排序隊列是否平衡(當前棧大小是否與隊列中最小的棧大小相同)，若已經(jīng)平衡，則將當前棧加入到排序隊列，就完成了策略；若不平衡，則從隊列中取出最大棧，從棧頭取出一個NNode放入到當前棧中，再將取出的棧插入回隊列中.這時，再次判斷是否平衡，如不平衡則再次進行以上操作直到隊列平衡，如圖3所示.

Fig. 3　Strategy of adding ANode.圖3　添加ANode節(jié)點策略

2) 死亡退出機制

① NNode節(jié)點超時斷開時，將其從對應的棧中刪除，再對排序隊列進行刷新；

② ANode節(jié)點斷開時，將其從排序隊列取出，在棧中的各個NNode都取出來，最后按照NNode的節(jié)點添加機制進行再次添加.

2.4計算加速部件任務調(diào)度策略

在ANode節(jié)點上，當NM開始運行時會同時啟動AcCt來完成對所在節(jié)點計算加速部件資源的管理和任務調(diào)度.它使用遠程讀、處理、遠程寫的3級流水方式，將計算加速部件的計算資源高效地利用.具體的實現(xiàn)方式如圖4所示：

Fig. 4　Accelerator task scheduling in single node.圖4　單節(jié)點內(nèi)計算加速部件任務流水線調(diào)度策略

任務調(diào)度由3個獨立線程和2個阻塞隊列構成.遠程讀線程不斷監(jiān)聽其他節(jié)點的連接，在獲取連接后將遠程需要處理的數(shù)據(jù)信息寫入到本地的處理緩沖區(qū)中；處理緩沖區(qū)的數(shù)據(jù)結構是阻塞隊列，處理線程會不斷地從中取出需要處理的數(shù)據(jù)并執(zhí)行；當處理線程完成處理操作后，會將處理好的結果寫入到寫緩沖區(qū)中；寫緩沖區(qū)也由1個阻塞隊列構成，它為遠程寫線程提供數(shù)據(jù)；遠程寫線程將從寫緩沖區(qū)中的數(shù)據(jù)遠程寫入到與之建立連接的節(jié)點上.這樣就完成了3級流水線的調(diào)度策略.

3實驗環(huán)境及結果

3.1實驗環(huán)境

本文的實驗部署在以4臺服務器建立起來的集群中，以GPU作為計算加速部件進行測試.詳細的軟硬件參數(shù)如表1所示：

Table 1　Test Environment

3.2實驗測試用例

MAGMA(matrix algebra on GPU and multicore architectures)是由田納西大學ICL實驗室創(chuàng)建并維護的一組GPU加速的線性代數(shù)(LA)集，它為基于GPU的異構體系結構提供了基于GPU的LA測試包，以及例如LAPACK和BLAS這樣的LA依賴包來進行CPU測試[20].

本文選取了MAGMA矩陣計算中最為常用的LU分解、Cholesky分解和QR分解算法作為集群中單次任務的基準程序，矩陣大小為10 000×10 000.表2給出了在本文實驗環(huán)境下單個節(jié)點使用GPU計算和CPU計算的時間和它們之間的加速比.

Table 2CPUGPU Execution Time and Speedup of MAGMA Benchmark in Single Node

表2單機環(huán)境下MAGMA基準程序的CPUGPU執(zhí)行時間和加速比

DecompositionAlgorithmsRunningTime∕sCPUGPUSpeedupLUDecomposition55.06.28.9QRDecomposition384.123.216.6CholeskyDecomposition60.57.68.0

每個測試應用中有100個相互獨立的任務組成，其中單個任務分別是LU分解、Cholesky分解和QR分解的基準程序.通過改變單次任務的強度(1，2，4，8倍強度)和運行任務時進行的數(shù)據(jù)傳輸大小(1 MB，5 MB，10 MB，20 MB，50 MB)來探索本文的適用范圍和性能.選擇最高8倍的單次任務強度系數(shù)，是因為其所對應的時間已接近集群的單任務時間上限，高時間消費的單次任務在集群容錯機制下，性能會下降得更加嚴重.選擇最大50 MB的數(shù)據(jù)傳輸大小是因為在實際的應用中單次的任務數(shù)據(jù)量一般不會超過50 MB.而對于超過的任務，應該首先考慮是否應該將任務分拆成多個進行.

Fig. 5　Test results of benchmark programs of LU, QR, Cholesky algorithms in different clusters.圖5　LU,QR,Cholesky算法基準程序在不同集群環(huán)境下的實驗結果

本文還選取了一個對5萬張圖片進行多種特征提取和聚類索引的MapReduce 操作的應用實例.該應用使用了GPU加速的圖片顏色和紋理LBP特征提取的Map操作，并在Reduce操作使用K-means算法對圖片特征進行聚類[21].

由于實驗環(huán)境的限制，本文使用了Cluster4-2(4個節(jié)點中2個節(jié)點擁有GPU)，Cluster4-3(4個節(jié)點中3個節(jié)點擁有GPU)和Cluster4-4(4個節(jié)點中4個節(jié)點擁有GPU)這3種集群環(huán)境進行測試，并與沒有使用本文方法(Cluster4-0，即4個節(jié)點都是用CPU進行計算)的環(huán)境進行對比.

3.3實驗數(shù)據(jù)及分析

圖5給出了由MAGMA矩陣計算中LU分解、Cholesky分解和QR分解算法Benchmark集群應用在使用不同的單次任務強度(1，2，4，8倍強度)和任務數(shù)據(jù)傳輸大小(1 MB，5 MB，10 MB，20 MB，50 MB)條件下，在Cluster4-4，Cluster4-3，Cluster4-2環(huán)境運行的時間與未使用本文方案的Cluster4-0環(huán)境運行時間的加速比折線圖.

從不同的集群環(huán)境上看，Cluster4-2和Cluster4-4都出現(xiàn)了與GPU個數(shù)相匹配的加速比，并且LU和Cholesky算法在單次任務強度增大到8倍時出現(xiàn)了高于單機環(huán)境下的加速比情況.這主要是因為隨著任務強度的增大，CPU算法耗費的時間過長，會更多地觸發(fā)集群容錯中的機制保證集群的正常運轉，例如推測式執(zhí)行等.但是本文方案中的任務異步執(zhí)行和GPU加速的方法防止了這樣的情況發(fā)生.

Cluster4-3也出現(xiàn)了一定的加速比，但是因為其在進行動態(tài)節(jié)點捆綁策略時，無法均勻地將有GPU節(jié)點和沒有GPU節(jié)點綁定，造成了2個節(jié)點各獨立使用1個GPU而另外2個節(jié)點共用1個GPU的不平衡.同時，Cluster4-2在節(jié)點綁定后，出現(xiàn)2個節(jié)點共用1個GPU、另2個節(jié)點也共用1個GPU的拓撲結構，與Cluster4-3不平衡的拓撲同構，因而其加速比曲線與Cluster4-2基本重合.這種GPU分配不均勻的問題，在集群節(jié)點個數(shù)增多的情況下會有一定程度的改善.

從單次任務強度變化上看，LU，Cholesky，QR這3個算法在不同集群環(huán)境下，加速比除了在強度為1的情況外，都會隨著單次任務強度的升高而變大，單次任務強度與加速比成正相關.而強度為1時出現(xiàn)的個別數(shù)據(jù)不符合正相關曲線情況，是因為整個集群啟動時間在運行時間較短的應用中影響更大.

Fig. 6　Test result of the application for pictureextraction and clustering.圖6　圖片特征提取聚類應用程序的實驗結果

從數(shù)據(jù)傳輸大小變化上看，LU，Cholesky，QR這3個算法在不同集群環(huán)境下，其加速比都沒有表現(xiàn)出與數(shù)據(jù)傳輸大小之間的正反相關性，因此可以認為單次任務的數(shù)據(jù)傳輸大小在對整個應用的運行時間并沒有明確的正反相關性.

圖6給出了5萬張圖片進行特征提取和聚類的MapReduce操作的應用實例在不同集群環(huán)境下的運行時間柱狀圖.從實驗數(shù)據(jù)可以看出，應用實例的運行時間基本能夠隨著集群節(jié)點中增加GPU計算資源而顯著地減少運行時間.雖然在Cluster4-3環(huán)境下出現(xiàn)了與Benchmark應用程序相同的情況導致與Cluster4-2運行時間相同，但這種情況在集群節(jié)點個數(shù)增多時能夠得到改善.

4結論

本文方案使用了集群計算加速部件統(tǒng)一管理、動態(tài)節(jié)點捆綁和流水線式計算加速部件任務調(diào)度策略，對原有的YARN架構進行了改進，增加了對包括GPU和Intel MIC在內(nèi)的計算加速部件資源的調(diào)度和管理，使得在全部或部分節(jié)點配置計算加速部件的分布式系統(tǒng)中，能夠較好地對集群中的計算加速部件進行利用.本文通過在4臺節(jié)點組成的帶有GPU計算加速部件的集群環(huán)境中，使用LU，QR，Cholesky分解算法以及5萬張圖片特征提取及聚類索引的應用實例，對本文方案進行了實驗測試，實驗結果驗證了本文方案的有效性.

5未來工作展望

針對實驗結果中Cluster4-3出現(xiàn)的性能問題，可以將現(xiàn)有方案中對節(jié)點的捆綁更加細化為基于Container的綁定，即在RM中維護的不再是節(jié)點間的捆綁關系，而是每個節(jié)點上的Container之間的捆綁關系.這樣，就會更為細粒度地對集群資源進行分配和共享.但是也會遇到一些困難，例如Container并非真正的物理模塊，而是由YARN對節(jié)點內(nèi)資源進行隔離產(chǎn)生的邏輯模塊，它的產(chǎn)生和銷毀會更加靈活和頻繁，這對整個管理模塊的調(diào)度策略和性能是個挑戰(zhàn).

再者，可以對計算加速部件的性能建立權值表，并按照節(jié)點的權值信息優(yōu)化動態(tài)捆綁策略.因為在本文當前的版本中，節(jié)點上的計算加速部件只是無與有之分，但是在實際環(huán)境中，不同型號和性能的計算加速部件可能同時存在于一個集群中.因此，如果建立一個性能的權值表，動態(tài)生成或者讓用戶自己修改和維護這個表格，并根據(jù)權值信息優(yōu)化動態(tài)捆綁策略，這樣就可以更好地利用不同的計算加速部件，從而實現(xiàn)效率的提升.

參考文獻

[1]Vinod V, Arun M, Chris D. Apache Hadoop YARN: Yet another resource negotiator[C] //Proc of SoCC’13. New York: ACM, 2013: 5

[2]Jeffrey D, Sanjay G. MapReduce: Simplified data processing on large clusters[C] //Proc of OSDI’04. Berkeley, CA:USENIX Association, 2004: 135-150

[3]Apache Spark: Lightning-fast cluster computing[EB/OL]. [2014-07-31]. https://spark.apache.org

[4]Apache Storm: Distributed and fault-tolerant realtime computation[EB/OL]. 2014 [2015-07-31]. https://storm.apache.org

[5]Jeff S, John O. Multi-GPU MapReduce on GPU clusters[C] //Proc of IPDPS’2011. Piscataway, NJ: IEEE, 2011: 1068-1079

[6]Liu Mingliang, Jin Ye, Zhai Jidong. ACIC: Automatic cloud I/O configurator for HPC applications[C] //Proc of SC’13. Piscataway, NJ: IEEE, 2013: 1-12

[7]Li Xiaobing, Wang Yandong, Jiao Yizheng, et al. CooMR: Cross-task coordination for efficient data management in MapReduce programs[C] //Proc of SC’13. Piscataway, NJ: IEEE, 2013: 1-11

[8]Max G, Mauricio B, Vivek S. HadoopCL: MapReduce on distributed heterogeneous platforms through seamless integration of Hadoop and OpenCL[C] //Proc of IPDPSW’13. Piscataway, NJ: IEEE, 2013: 1918-1927

[9]Gunho L, Byung-Gon C, Randy H. Heterogeneity-aware resource allocation and scheduling in the cloud[C/OL] //Proc of HotCloud’11. Berkeley, CA: USENIX Association, 2011 [2014-07-31]. http://static.usenix.org/event/hotcloud11/tech

[10]Faraz A, Srimat C, Anand R, et al. Tarazu: Optimizing MapReduce on heterogeneous clusters[C] //Proc of ASPLOS’12. New York: ACM, 2011: 61-74

[11]Fengguang S, Jack D. A scalable framework for heterogeneous GPU-based clusters[C] //Proc of SPAA’12. New York: ACM, 2012: 91-100

[12]Kuen T, Wayne L. Axel: A heterogeneous cluster with FPGAs and GPUs[C] //Proc of FPGA’10. New York: ACM, 2010: 115-124

[13]George B, Aurelien B, Anthony D, et al. DAGuE: A generic distributed DAG engine for high performance computing[J]. Parallel Computing, 2012, 38(1): 37-51

[14]Cédric A, Jérme C, Samuel T, et al. Data-aware task scheduling on multi-accelerator based platforms[C] //Proc of the 16th IEEE Int Conf on Parallel and Distributed Systems. Piscataway, NJ: IEEE, 2010: 291-298

[15]Vignesh T R, Michela B, Gagan A, et al. ValuePack: Value-based scheduling framework for CPU-GPU clusters[C] //Proc of SC’12. Piscataway, NJ: IEEE, 2012: 1-12

[16]Jungwon K, Sangmin S, Jun L, et al. SnuCL: An OpenCL framework for heterogeneous CPU/GPU clusters[C] //Proc of ICS’12. New York: ACM, 2012: 341-352

[17]Wittek P, Darányi S. Accelerating text mining workloads in a MapReduce-based distributed GPU environment[J]. Journal of Parallel and Distributed Computing, 2013, 73(2): 198-206

[18]Zhai Yanlong, Luo Zhuang, Yang Kai, et al. High performance massive data computing framework based on Hadoop cluster[J]. Computer Science, 2013, 40(3): 100-103 (in Chinese)(翟巖龍, 羅壯, 楊凱, 等. 基于Hadoop的高性能海量數(shù)據(jù)處理平臺研究[J]. 計算機科學, 2013, 40(3): 100-103)

[19]Apache Hadoop. Apache Hadoop: Apache Hadoop nextgen MapReduce[EB/OL]. [2014-07-31]. http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html

[20]Innovative Computing Laboratory (ICL) of University of Tennessee. MAGMA: Matrix algebra on GPU and multicore architectures[EB/OL]. [2014-07-31]. http://icl.cs.utk.edu/magma/news/index.html

[21]Wang Xiangrong, Gao Fei, Li Qin, et al. GPU-based acceleration of local binary pattern algorithm for Internet applications[J]. Computer Engineering and Science, 2013, 35(11): 153-159 (in Chinese)(王香榮, 高飛, 李欽, 等. 面向互聯(lián)網(wǎng)應用的圖像LBP算法GPU并行加速[J]. 計算機工程與科學, 2013, 35(11): 153-159)

Li Qin, born in 1989. Master. His main research interests include distributed system and high performance computing.

Zhu Yanchao, born in 1989. PhD candidate. His research interests include high performance computer architecture and distributed systems (zyc0627cool@163.com).

Liu Yi, born in 1968. Professor of Beihang University since 2006, and associate professor of Xi’an Jiaotong University from 2001 to 2006. Received his PhD degree in computer science from Xi’an Jiaotong University. His main research interests include high performance computing and computer architecture (yi.liu@jsi.buaa.edu.cn).

Qian Depei, born in 1952. Master in computer science, professor of Beihang University, director of the Sino-German Joint Software Institute. Fellow member of China Computer Federation. His current research interests include high performance computer architecture and implementation technologies, multicoremany-core programming, distributed systems, overlay networks, and network measurement (depeiq@buaa.edu.cn).

Accelerator Support in YARN Cluster

Li Qin, Zhu Yanchao, Liu Yi, and Qian Depei

(SchoolofComputerScienceandEngineering,BeihangUniversity,Beijing100191) (BeijingKeyLaboratoryofNetworkTechnology(BeihangUniversity),Beijing100191)

AbstractAccelerators, such as GPU and Intel MIC, are widely used in scientific computing and image processing, and have strong potentials in big data processing and HPC based on cloud platform. YARN is a new generation of Hadoop distributed computing framework. Its adoption of computing resources is only limited to CPU, lacking of support for accelerators. This paper adds the support to nodes with accelerators to YARN to solve the problem. By analyzing the problem of supporting heterogeneous node, there are three identified difficulties which should be solved to introduce hybrid?heterogeneous to YARN. The first one is how to manage and schedule the added accelerator resources in the cluster; the second one is how to collect the status of accelerators to the master node for management; the third one is how to address the contention issue among multiple accelerator tasks concurrently running on the same node. In order to solve the above problems, the following design tasks have been carried out. Resource encapsulation which bundles neighbor nodes into one resource encapsulation is designed to solve the first problem. Management functions which collect the real-time accelerators status from working nodes are designed on the master node to solve the second problem. Accelerator task pipeline which splits accelerator tasks into three parts and executes them in parallel is designed on the nodes with accelerators to solve the third problem. Our scheme is verified with a cluster consisting of 4 nodes with GPU, and the workload testing the cluster includes LU, QR and Cholesky decomposition from the third party benchmark MAGMA, and the program performes feature extraction and clustering upon 50000 images. The results prove the effectiveness of the scheme presented.

Key wordsdistributed system; yet another resource negotiator (YARN); accelerator; heterogeneous nodes; graphics processing unit (GPU); node binding; task scheduling

收稿日期：2014-12-10；修回日期：2015-09-22

基金項目：國家“八六三”高技術研究發(fā)展計劃基金項目(2012AA01A302)；北京市科學研究與研究生培養(yǎng)共建項目

中圖法分類號TP316.4

This work was supported by the National High Technology Research and Development Program of China (863 Program) (2012AA01A302) and the Scientific Research and Graduate Student Education Project of Beijing.