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

李　欽　朱延超　劉　軼　錢德沛

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

?

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

李欽朱延超劉軼錢德沛

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

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

關鍵詞分布式系統；YARN；計算加速部件；混合異構節點；圖形圖像處理器；節點捆綁；任務調度

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

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

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

1YARN基本架構

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

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

1) RM

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

2) AM

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

3) NM

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

4) Ct

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

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

2.1設計思路

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

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

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

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

2.2系統結構

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

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

根據圖2的架構圖，應用調度流程總結如下：

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

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

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

2.3節點捆綁策略

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

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

1) 節點添加機制

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

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

Fig. 3　Strategy of adding ANode.圖3　添加ANode節點策略

2) 死亡退出機制

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

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

2.4計算加速部件任務調度策略

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

Fig. 4　Accelerator task scheduling in single node.圖4　單節點內計算加速部件任務流水線調度策略

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

3實驗環境及結果

3.1實驗環境

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

Table 1　Test Environment

3.2實驗測試用例

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

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

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

表2單機環境下MAGMA基準程序的CPUGPU執行時間和加速比

DecompositionAlgorithmsRunningTime∕sCPUGPUSpeedupLUDecomposition55.06.28.9QRDecomposition384.123.216.6CholeskyDecomposition60.57.68.0

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

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

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

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

3.3實驗數據及分析

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

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

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

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

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

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

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

4結論

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

5未來工作展望

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

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

參考文獻

[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的高性能海量數據處理平臺研究[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)(王香榮, 高飛, 李欽, 等. 面向互聯網應用的圖像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

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

中圖法分類號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.