毛安琪 湯小春 丁 朝 李戰(zhàn)懷

(西北工業(yè)大學(xué)計(jì)算機(jī)學(xué)院 西安 710129) (工信部大數(shù)據(jù)存儲(chǔ)與管理重點(diǎn)實(shí)驗(yàn)室(西北工業(yè)大學(xué)) 西安 710129)

(maoanqi@mail.nwpu.edu.cn)

隨著大數(shù)據(jù)處理技術(shù)的發(fā)展，數(shù)據(jù)內(nèi)在價(jià)值的分析與挖掘成為這個(gè)時(shí)代的研究熱點(diǎn)之一.當(dāng)數(shù)據(jù)的體量以驚人的速度增長(zhǎng)時(shí)，單臺(tái)機(jī)器已經(jīng)無法滿足大數(shù)據(jù)的存儲(chǔ)與處理，于是以Hadoop分布式文件系統(tǒng)(Hadoop distributed file system, HDFS)為代表的分布式文件系統(tǒng)應(yīng)運(yùn)而生.它以主從架構(gòu)管理模式，將數(shù)據(jù)劃分到多臺(tái)機(jī)器節(jié)點(diǎn)上存儲(chǔ)，形成一個(gè)集群系統(tǒng)，也稱數(shù)據(jù)中心，推動(dòng)了大數(shù)據(jù)計(jì)算的發(fā)展.在企業(yè)或組織內(nèi)，數(shù)據(jù)中心上通常會(huì)存在各種不同類型的數(shù)據(jù)處理應(yīng)用程序.如果為每種數(shù)據(jù)處理應(yīng)用程序建立專用的集群基礎(chǔ)設(shè)施，不但為企業(yè)帶來巨大的建設(shè)成本，也導(dǎo)致數(shù)據(jù)在各個(gè)集群之間來回復(fù)制，容易產(chǎn)生錯(cuò)誤.因此，越來越多的企業(yè)開始在數(shù)據(jù)中心上部署集群資源管理系統(tǒng)，確保各種各樣的數(shù)據(jù)處理應(yīng)用程序共享一套硬件基礎(chǔ)設(shè)施.

集群資源管理系統(tǒng)的主要功能是管理集群的可用計(jì)算資源并分配給不同的數(shù)據(jù)處理應(yīng)用程序.集群計(jì)算資源的分配要按照一定的策略進(jìn)行，保證各個(gè)應(yīng)用程序獨(dú)自使用集群的部分資源，避免各個(gè)數(shù)據(jù)處理應(yīng)用程序之間的資源競(jìng)爭(zhēng)和相互干涉，實(shí)現(xiàn)各個(gè)應(yīng)用程序?qū)Y源的公平使用.

現(xiàn)有的集群資源管理系統(tǒng)種類非常豐富，如文獻(xiàn)[1-43]都是有關(guān)集群資源管理和用戶應(yīng)用程序調(diào)度的系統(tǒng).從集群資源調(diào)度框架的觀點(diǎn)看，集群資源管理系統(tǒng)分為3個(gè)大類，即集中式資源調(diào)度框架、分布式資源調(diào)度框架以及混合式資源調(diào)度框架.集中式資源調(diào)度框架又分為單一資源調(diào)度和二級(jí)資源調(diào)度模型，前者采用“拉”的模式，后者采用“推”的模式.文獻(xiàn)[1-25]研究單一資源調(diào)度模型，文獻(xiàn)[26-34]研究二級(jí)資源調(diào)度模型.文獻(xiàn)[35-40]研究分布式調(diào)度框架，文獻(xiàn)[41-43]研究集中分布混合的資源調(diào)度框架.文獻(xiàn)[22]是一種典型的單一資源調(diào)度模型，分3步完成資源的分配：應(yīng)用程序向資源管理主節(jié)點(diǎn)請(qǐng)求計(jì)算資源；資源管理主節(jié)點(diǎn)負(fù)責(zé)資源的分配；應(yīng)用程序提交任務(wù)執(zhí)行.文獻(xiàn)[34]是一種二級(jí)調(diào)度模型，也分為3步完成資源的分配：應(yīng)用程序按照次序向資源管理框架請(qǐng)求資源；資源管理器按照各個(gè)應(yīng)用程序使用資源情況，依次為各個(gè)應(yīng)用程序分配計(jì)算資源；應(yīng)用程序使用資源執(zhí)行任務(wù).文獻(xiàn)[38]是分布式資源調(diào)度框架，分2步完成資源分配：各個(gè)應(yīng)用程序獨(dú)立向請(qǐng)求發(fā)出“采樣請(qǐng)求”；根據(jù)采樣結(jié)果提交任務(wù).文獻(xiàn)[42]是集中分布混合的資源調(diào)度框架，短時(shí)間的應(yīng)用程序使用分布式調(diào)度框架，長(zhǎng)時(shí)間應(yīng)用程序采用集中式調(diào)度框架.

文獻(xiàn)[44]指出，集中式資源調(diào)度框架的優(yōu)點(diǎn)是調(diào)度實(shí)現(xiàn)簡(jiǎn)單，所以應(yīng)用廣泛，但是集中式調(diào)度框架存在著可擴(kuò)展的瓶頸.相比于集中式調(diào)度框架，分布式資源調(diào)度框架不存在單一的資源管理節(jié)點(diǎn)，所以在可擴(kuò)展性方面具有較大的優(yōu)點(diǎn)，但是分布式資源管理缺乏集中管理，增加了資源狀態(tài)的同步和并發(fā)控制的難度，也無法做到最優(yōu)全局決策與資源控制，所以真正應(yīng)用的系統(tǒng)較少.混合式資源管理框架結(jié)合了2個(gè)系統(tǒng)，由于存在集中式資源監(jiān)視，雖然在一定程度上緩解了分布式調(diào)度的不一致問題，但是其集中式調(diào)度和分布式調(diào)度相互獨(dú)立，需要維護(hù)2套代碼，維護(hù)代價(jià)較大.另外，分布式調(diào)度和集中式調(diào)度相互預(yù)留資源，影響總體資源利用率，因此混合式資源管理框架處于研究狀態(tài)，很少有成熟的系統(tǒng)廣泛使用.

從以上的研究文獻(xiàn)看，80%以上的集群資源管理模型采用集中式，如果再加上混合式中的集中式調(diào)度模型，集中式資源調(diào)度框架可以達(dá)到85%左右.一些大的互聯(lián)網(wǎng)公司，例如微軟、騰訊、百度等，目前也使用集中式資源調(diào)度框架來處理自己的大數(shù)據(jù)業(yè)務(wù).但是，集中式資源調(diào)度框架中，資源管理器為了獲得集群可用資源，需要集群上的每個(gè)計(jì)算節(jié)點(diǎn)周期性地發(fā)送健康狀態(tài)信息以及容器狀態(tài)信息到集中式調(diào)度器，以便監(jiān)控整個(gè)集群計(jì)算節(jié)點(diǎn)的健康狀態(tài)以及整個(gè)集群節(jié)點(diǎn)上容器(任務(wù))的運(yùn)行情況.當(dāng)計(jì)算節(jié)點(diǎn)的數(shù)量擴(kuò)大到一定的規(guī)模后，大量心跳信息的存儲(chǔ)和處理給資源管理器帶來較大的負(fù)載壓力.另外，網(wǎng)絡(luò)延遲以及通信次數(shù)的快速增長(zhǎng)使得集群資源管理中的調(diào)度器無法在調(diào)度許可的時(shí)間內(nèi)處理全部的心跳信息，造成調(diào)度過程的失效.

隨著集群規(guī)模的增大，集中式資源管理器很快達(dá)到心跳信息處理上限，從而限制了集群節(jié)點(diǎn)規(guī)模的橫向擴(kuò)展.所以，當(dāng)集群節(jié)點(diǎn)的規(guī)模較大時(shí)，集中式集群資源管理通常采用增加心跳的時(shí)間間隔的方法來減少心跳發(fā)生的頻率，降低心跳信息的產(chǎn)生次數(shù).但是心跳時(shí)間間隔的增大，會(huì)導(dǎo)致資源狀態(tài)的變化不能及時(shí)地匯報(bào)到調(diào)度器，一邊是資源的空閑，另一邊是用戶作業(yè)需要等待更長(zhǎng)的時(shí)間才能被調(diào)度.文獻(xiàn)[45]在備用節(jié)點(diǎn)上開啟資源監(jiān)控服務(wù)提高大規(guī)模心跳信息的處理效率，并借助分布式存儲(chǔ)服務(wù)(MySQL NDB)對(duì)心跳信息一致性進(jìn)行保證.雖然文獻(xiàn)[45]的測(cè)試結(jié)論中，使用模擬器可以將YARN支持的機(jī)器數(shù)量從4 000臺(tái)擴(kuò)展到7 500臺(tái)，但是其引入了C++版本的MySQL數(shù)據(jù)庫(kù)以及NDB事件流庫(kù)，使用JNI與YARN進(jìn)行耦合，增加了代碼的維護(hù)代價(jià)，同時(shí)MySQL NDB需要增加多個(gè)資源監(jiān)視節(jié)點(diǎn)，不但增加了硬件代價(jià)，也增加了數(shù)據(jù)一致性檢測(cè)代價(jià).

集中式資源調(diào)度框架的易用性和可擴(kuò)展性是一對(duì)矛盾.一面是大量用戶使用集中式資源管理系統(tǒng)，一面是集中式資源管理可擴(kuò)展的困境.基于這兩方面原因，對(duì)集中式資源管理系統(tǒng)進(jìn)行可擴(kuò)展的優(yōu)化研究有一定的迫切性，而且也實(shí)實(shí)在在地符合用戶的意愿.因此，本文對(duì)集中式資源管理系統(tǒng)的可擴(kuò)展性進(jìn)行了優(yōu)化，改善了集中式資源管理系統(tǒng)的可擴(kuò)展性.

論文的主要貢獻(xiàn)有3個(gè)方面：

1) 提出了基于差分模式的資源狀態(tài)監(jiān)控模型，減少了心跳信息的大小和規(guī)模，減輕了資源調(diào)度器的存儲(chǔ)和處理壓力，使得調(diào)度器可以處理更多計(jì)算節(jié)點(diǎn)的消息；

2) 提出了基于環(huán)形監(jiān)視的節(jié)點(diǎn)監(jiān)控模型，將調(diào)度器的監(jiān)控功能分散到各個(gè)計(jì)算節(jié)點(diǎn)，緩解了調(diào)度器的處理壓力；

3) 對(duì)YARN[22]系統(tǒng)的資源管理功能進(jìn)行了優(yōu)化，并使用YARN提供的模擬器進(jìn)行了可擴(kuò)展測(cè)試，實(shí)驗(yàn)證明我們的方法可以使集群的規(guī)模提高1.88倍以上.

1 可擴(kuò)展資源管理系統(tǒng)模型

本節(jié)首先針對(duì)集中式資源監(jiān)控模塊的流程進(jìn)行了分析，揭示了可擴(kuò)展性問題.然后，提出基于差分模型的心跳信息處理流程，在計(jì)算節(jié)點(diǎn)上對(duì)心跳信息進(jìn)行預(yù)處理.最后提出了基于環(huán)形監(jiān)視的節(jié)點(diǎn)監(jiān)控過程.

1.1 資源監(jiān)控服務(wù)的性能瓶頸分析

集中式資源調(diào)度框架有3個(gè)主要的服務(wù)：1)應(yīng)用程序管理服務(wù)，用戶的資源請(qǐng)求由應(yīng)用程序管理服務(wù)提交到資源調(diào)度器，請(qǐng)求分配計(jì)算資源來運(yùn)行任務(wù);2)資源調(diào)度器，集群計(jì)算資源上運(yùn)行著許多應(yīng)用程序，而每個(gè)應(yīng)用程序會(huì)包含大量的任務(wù)，這些任務(wù)會(huì)分散在不同的計(jì)算節(jié)點(diǎn)上并行運(yùn)行，資源調(diào)度器的任務(wù)是將不同應(yīng)用程序的任務(wù)映射到集群計(jì)算節(jié)點(diǎn)上并執(zhí)行任務(wù);3)資源監(jiān)控服務(wù)，它是調(diào)度器與計(jì)算節(jié)點(diǎn)之間連接的紐帶，負(fù)責(zé)接收集群計(jì)算節(jié)點(diǎn)的加入和退出消息，同時(shí)周期性捕獲計(jì)算節(jié)點(diǎn)的心跳信息，即將各個(gè)集群節(jié)點(diǎn)的容器(任務(wù))狀態(tài)信息進(jìn)行匯總處理后通知調(diào)度器，更新集群資源的最新狀態(tài).這些更新信息對(duì)資源調(diào)度器來說非常重要，它們是資源分配的依據(jù).

當(dāng)集群計(jì)算節(jié)點(diǎn)注冊(cè)到資源管理器后，便周期性向集群資源管理的資源監(jiān)控服務(wù)匯報(bào)心跳消息.心跳信息包含2個(gè)重要的內(nèi)容，即機(jī)器的健康狀態(tài)信息和集群節(jié)點(diǎn)上全部任務(wù)的運(yùn)行狀態(tài)信息.健康狀態(tài)信息主要用于檢測(cè)資源的使用情況以及評(píng)價(jià)系統(tǒng)的性能等.計(jì)算節(jié)點(diǎn)的全部任務(wù)運(yùn)行狀態(tài)信息用來維護(hù)資源管理器中的全局資源視圖.另外，任務(wù)狀態(tài)的變化決定了資源可用狀態(tài)的變化.因此，周期性的心跳信息使得資源管理器與計(jì)算節(jié)點(diǎn)之間保持聯(lián)系，并保證集群資源與任務(wù)狀態(tài)的一致性.

當(dāng)心跳信息到達(dá)資源監(jiān)控服務(wù)后，首先判斷計(jì)算節(jié)點(diǎn)的健康狀態(tài).若該計(jì)算節(jié)點(diǎn)為非健康狀態(tài)，則通知調(diào)度器減少相關(guān)計(jì)算節(jié)點(diǎn)的可用資源配額，防止進(jìn)一步將該機(jī)器的資源分配給其他計(jì)算任務(wù).否則，資源監(jiān)控服務(wù)就開始檢查該節(jié)點(diǎn)上任務(wù)運(yùn)行狀態(tài)，通過與上次心跳信息的對(duì)比，提取出新啟動(dòng)的任務(wù)與運(yùn)行結(jié)束的任務(wù)相關(guān)信息.如果存在新啟動(dòng)任務(wù)和結(jié)束任務(wù)，說明任務(wù)狀態(tài)有變化，資源監(jiān)控服務(wù)產(chǎn)生一個(gè)更新事件通知給資源調(diào)度器，資源調(diào)度器將相關(guān)任務(wù)運(yùn)行狀態(tài)進(jìn)行更新維護(hù)，并對(duì)集群資源全局視圖進(jìn)行更新.另外，對(duì)于已經(jīng)結(jié)束的任務(wù)，將任務(wù)的結(jié)束狀態(tài)保存到日志中，這些信息是資源分配模塊進(jìn)行系統(tǒng)優(yōu)化時(shí)的參考依據(jù).

在計(jì)算節(jié)點(diǎn)心跳匯報(bào)以及資源監(jiān)控服務(wù)處理心跳這2個(gè)過程中，資源管理的資源監(jiān)控服務(wù)要承受的通信量以及計(jì)算量將會(huì)給資源管理器帶來較重的負(fù)載壓力.隨著集群規(guī)模的增大，該問題將更加明顯.究其原因，有2個(gè)方面問題：1)當(dāng)集群節(jié)點(diǎn)上無運(yùn)行的任務(wù)，仍會(huì)周期性向資源監(jiān)控服務(wù)發(fā)送心跳信息，以便記錄心跳更新時(shí)刻，作為新的心跳信息處理依據(jù).這些信息僅能代表節(jié)點(diǎn)處于正常運(yùn)行中，并沒有實(shí)質(zhì)的數(shù)據(jù)傳輸.它不但增加了集群節(jié)點(diǎn)內(nèi)部的通信開銷，也增加了資源監(jiān)控服務(wù)的處理開銷.2)集群計(jì)算節(jié)點(diǎn)只是按心跳時(shí)間間隔，定期將本機(jī)所有容器以及任務(wù)狀態(tài)等相關(guān)信息匯報(bào)給集群資源監(jiān)控服務(wù).如果任務(wù)的運(yùn)行時(shí)間較長(zhǎng)，心跳間隔期間狀態(tài)沒有發(fā)生變化，無變化信息也會(huì)被匯報(bào)到資源監(jiān)控服務(wù)，那么這將給資源監(jiān)控服務(wù)增加額外的工作量，浪費(fèi)計(jì)算資源.

綜上，當(dāng)集群計(jì)算節(jié)點(diǎn)進(jìn)行大規(guī)模擴(kuò)展后，資源監(jiān)控服務(wù)需要處理大量的無用心跳信息，導(dǎo)致負(fù)載過重，無法及時(shí)處理應(yīng)用程序的資源分配請(qǐng)求，延遲了調(diào)度器的資源分配.而擴(kuò)大心跳間隔雖然減少了單位時(shí)間內(nèi)心跳信息的發(fā)送和處理，卻導(dǎo)致計(jì)算節(jié)點(diǎn)的有用狀態(tài)信息無法被及時(shí)更新，使得這些計(jì)算節(jié)點(diǎn)的資源處于閑置狀態(tài).因此，減少計(jì)算節(jié)點(diǎn)與資源監(jiān)控服務(wù)之間的通信次數(shù)，降低資源監(jiān)控服務(wù)的數(shù)據(jù)處理強(qiáng)度，是集中式資源管理橫向擴(kuò)展的主要策略.

1.2 基于差分的心跳信息處理模型

鑒于資源監(jiān)控服務(wù)承擔(dān)著太多的心跳信息處理，本文提出一種策略，將心跳信息處理功能進(jìn)行分解，一部分功能由計(jì)算節(jié)點(diǎn)承擔(dān)，一部分功能由資源監(jiān)控服務(wù)承擔(dān)，即：讓計(jì)算節(jié)點(diǎn)承擔(dān)容器狀態(tài)的過濾功能以及健康狀態(tài)的檢測(cè)，資源監(jiān)控服務(wù)只承擔(dān)容器狀態(tài)和健康狀態(tài)的更新，降低資源監(jiān)控服務(wù)的負(fù)荷.圖1給出了基于差分的心跳信息處理模型，具體流程如下描述.

用戶應(yīng)用程序向集中式資源管理器的客戶端管理服務(wù)進(jìn)行注冊(cè)并提交應(yīng)用程序，如圖1中的1.1.資源分配模塊為該計(jì)算框架分配第1個(gè)容器資源用于運(yùn)行用戶應(yīng)用程序，并通知計(jì)算節(jié)點(diǎn)的容器管理服務(wù)啟動(dòng)該應(yīng)用程序，如圖1中的1.2～1.4.

應(yīng)用程序成功啟動(dòng)后，向應(yīng)用程序管理服務(wù)注冊(cè)并為其包含的任務(wù)申請(qǐng)資源，如圖1中的2.1.應(yīng)用程序管理服務(wù)從資源分配模塊讀取資源的分配結(jié)果返回給應(yīng)用程序，如圖1中的2.2.應(yīng)用程序拿到資源后，將資源與任務(wù)映射匹配后，通知各計(jì)算節(jié)點(diǎn)容器管理服務(wù)，如圖1中的2.3.計(jì)算節(jié)點(diǎn)容器管理服務(wù)接收到啟動(dòng)容器消息后，啟動(dòng)容器并配置任務(wù)所需的運(yùn)行環(huán)境，監(jiān)控與管理任務(wù)的生命周期，如圖1中的2.4.心跳匯報(bào)程序首先從周期性健康檢測(cè)程序中讀取健康狀態(tài)進(jìn)行保存，然后與上次所緩存的健康狀態(tài)進(jìn)行對(duì)比，獲得健康狀態(tài)的差分值.另外，心跳匯報(bào)程序還需要讀取當(dāng)前任務(wù)相關(guān)狀態(tài)信息時(shí)，并與上一次緩存的任務(wù)狀態(tài)進(jìn)行對(duì)比，得到有任務(wù)狀態(tài)變化的差分值.如果差分值不為空，則向資源監(jiān)控服務(wù)發(fā)送心跳信息，如圖1中的3.1；否則，省略本次心跳匯報(bào)過程.

資源監(jiān)控服務(wù)收到心跳信息后，無需進(jìn)行過濾處理，直接將本次接收的任務(wù)狀態(tài)信息更新，并通知資源分配模塊進(jìn)行資源更新，如圖1中3.2.資源分配模塊收到通知后，對(duì)相關(guān)資源進(jìn)行更新維護(hù)，并通過一定資源分配方法將可用資源分配給應(yīng)用程序，等待應(yīng)用程序資源請(qǐng)求并領(lǐng)取資源.

1.3 基于環(huán)形監(jiān)視的節(jié)點(diǎn)監(jiān)控模型

定時(shí)發(fā)送心跳信息是資源管理器判定計(jì)算節(jié)點(diǎn)正常運(yùn)行的依據(jù)，如果長(zhǎng)時(shí)間不發(fā)送心跳信息，資源管理器就可以認(rèn)為節(jié)點(diǎn)出現(xiàn)故障，將該節(jié)點(diǎn)納入不可用計(jì)算節(jié)點(diǎn)列表中.基于差分的心跳信息處理模型中，任務(wù)狀態(tài)或健康狀態(tài)不發(fā)生變化就不產(chǎn)生心跳信息，這可能會(huì)導(dǎo)致資源管理器錯(cuò)誤判斷計(jì)算節(jié)點(diǎn)的運(yùn)行狀態(tài).由于計(jì)算節(jié)點(diǎn)在不發(fā)生狀態(tài)變化的情況下取消心跳信息的發(fā)送，從而使得資源管理器無法辨別長(zhǎng)期不發(fā)送心跳信息的節(jié)點(diǎn)是宕機(jī)還是計(jì)算節(jié)點(diǎn)無狀態(tài)變化.例如，在運(yùn)行過程中某個(gè)計(jì)算節(jié)點(diǎn)宕機(jī)后，宕機(jī)節(jié)點(diǎn)就不能匯報(bào)任務(wù)的狀態(tài)導(dǎo)致應(yīng)用程序無法得到任務(wù)的最新狀態(tài)，必須等待超過設(shè)定的超時(shí)范圍后，應(yīng)用程序才會(huì)終止該任務(wù)并重新申請(qǐng)資源，進(jìn)而影響相關(guān)作業(yè)的執(zhí)行效率.

針對(duì)該問題，本文提出將所有的集群計(jì)算節(jié)點(diǎn)組成對(duì)等的環(huán)形監(jiān)視網(wǎng)絡(luò)，處于環(huán)形網(wǎng)絡(luò)的每個(gè)計(jì)算節(jié)點(diǎn)都有一個(gè)前驅(qū)節(jié)點(diǎn)和后繼節(jié)點(diǎn).當(dāng)前計(jì)算節(jié)點(diǎn)向自己的后繼節(jié)點(diǎn)定時(shí)發(fā)送自己的心跳消息.對(duì)于后繼節(jié)點(diǎn)，發(fā)送消息的就是它的前驅(qū)節(jié)點(diǎn).如果后繼節(jié)點(diǎn)在設(shè)置的時(shí)間間隔內(nèi)沒有收到前驅(qū)節(jié)點(diǎn)的心跳消息，就認(rèn)為前驅(qū)節(jié)點(diǎn)出現(xiàn)故障，立即向資源監(jiān)控服務(wù)發(fā)送該節(jié)點(diǎn)宕機(jī)的信息描述，以便資源管理器做出相應(yīng)的處理.當(dāng)存在新的節(jié)點(diǎn)加入或者一個(gè)節(jié)點(diǎn)出現(xiàn)故障后，系統(tǒng)需要重組對(duì)等環(huán)形監(jiān)控網(wǎng)絡(luò)，保證集群節(jié)點(diǎn)的正常運(yùn)行，實(shí)現(xiàn)節(jié)點(diǎn)監(jiān)控心跳信息的及時(shí)收集和發(fā)送.

針對(duì)對(duì)等環(huán)形監(jiān)控網(wǎng)絡(luò)，資源管理器對(duì)集群中的計(jì)算節(jié)點(diǎn)分配一個(gè)唯一的機(jī)器編號(hào)，編號(hào)按照從小到大的順序產(chǎn)生.這些信息被各個(gè)計(jì)算節(jié)點(diǎn)維護(hù)，當(dāng)新加入計(jì)算節(jié)點(diǎn)或者節(jié)點(diǎn)故障退出時(shí)，需要同步這些信息.節(jié)點(diǎn)的生存狀態(tài)發(fā)送過程按照節(jié)點(diǎn)的機(jī)器編號(hào)大小來進(jìn)行，即編號(hào)為N的節(jié)點(diǎn)接收編號(hào)為N-1的節(jié)點(diǎn)的心跳消息(第1個(gè)節(jié)點(diǎn)接收最后一個(gè)節(jié)點(diǎn)的心跳消息).當(dāng)節(jié)點(diǎn)N-1出現(xiàn)故障時(shí)，它既不能接收消息，也無法發(fā)送消息.當(dāng)心跳周期到達(dá)期間，節(jié)點(diǎn)N未收到節(jié)點(diǎn)N-1的生存狀態(tài)匯報(bào)消息，則立即將節(jié)點(diǎn)N-1故障的消息通知資源管理器，資源管理器則將計(jì)算節(jié)點(diǎn)設(shè)置為不可用狀態(tài)，并通知各個(gè)集群節(jié)點(diǎn)更新緩存的機(jī)器編號(hào)信息.當(dāng)新節(jié)點(diǎn)加入或者故障節(jié)點(diǎn)從失效狀態(tài)恢復(fù)正常，這些節(jié)點(diǎn)向資源管理器發(fā)送注冊(cè)消息，資源管理器從機(jī)器編號(hào)緩沖中獲得一個(gè)編號(hào)分配給當(dāng)前節(jié)點(diǎn)，同時(shí)通知各個(gè)集群節(jié)點(diǎn)更新緩存的機(jī)器編號(hào)信息.計(jì)算節(jié)點(diǎn)接收到這些消息后，則重新設(shè)置自己接收心跳消息和發(fā)送心跳消息的節(jié)點(diǎn)，維持一個(gè)完整的對(duì)等環(huán)形監(jiān)控網(wǎng)絡(luò).

當(dāng)計(jì)算節(jié)點(diǎn)宕機(jī)時(shí)，環(huán)形監(jiān)控處理流程如圖2所示.圖2中1.1表示集群有5個(gè)節(jié)點(diǎn)組成為環(huán)形監(jiān)控網(wǎng)絡(luò).如果節(jié)點(diǎn)4宕機(jī)，則節(jié)點(diǎn)5在當(dāng)前心跳時(shí)間內(nèi)未收到節(jié)點(diǎn)4的生存狀態(tài)匯報(bào)信息，則默認(rèn)該計(jì)算節(jié)點(diǎn)不可用，并向資源監(jiān)控服務(wù)匯報(bào)監(jiān)視節(jié)點(diǎn)的故障信息，如圖2中2.1.資源監(jiān)控服務(wù)收到節(jié)點(diǎn)5匯報(bào)信息后，將節(jié)點(diǎn)4從監(jiān)視列表中刪除，并釋放節(jié)點(diǎn)4編號(hào)，同時(shí)通知集群節(jié)點(diǎn)更新監(jiān)視列表，如圖2中2.2～2.5.當(dāng)計(jì)算節(jié)點(diǎn)收到監(jiān)視列表更新通知后，重新設(shè)置監(jiān)視節(jié)點(diǎn)與匯報(bào)節(jié)點(diǎn).因此在下一次心跳周期到達(dá)后，節(jié)點(diǎn)3向節(jié)點(diǎn)5匯報(bào)心跳消息，同時(shí)，節(jié)點(diǎn)5等待節(jié)點(diǎn)3的心跳匯報(bào)，如圖2中2.6.最終節(jié)點(diǎn)1、節(jié)點(diǎn)2、節(jié)點(diǎn)3以及節(jié)點(diǎn)5組成了新環(huán)形監(jiān)控結(jié)構(gòu).

當(dāng)新的計(jì)算節(jié)點(diǎn)加入時(shí)，環(huán)形監(jiān)控處理流程如圖3所示.圖3中1.1表示有4個(gè)節(jié)點(diǎn)組成了環(huán)形監(jiān)控網(wǎng)絡(luò)，即節(jié)點(diǎn)1、節(jié)點(diǎn)2、節(jié)點(diǎn)3以及節(jié)點(diǎn)5.當(dāng)一個(gè)節(jié)點(diǎn)向資源監(jiān)控服務(wù)注冊(cè)節(jié)點(diǎn)信息，如圖3中2.1.資源監(jiān)控服務(wù)檢查節(jié)點(diǎn)管理列表，找到1個(gè)可用編號(hào)4號(hào)為該節(jié)點(diǎn)分配，然后更新監(jiān)視列表，并通知集群節(jié)點(diǎn)更新監(jiān)視列表，如圖3中2.2～2.5.當(dāng)計(jì)算節(jié)點(diǎn)收到節(jié)點(diǎn)列表更新通知后，重新設(shè)置監(jiān)視節(jié)點(diǎn)與匯報(bào)節(jié)點(diǎn).因此在下一次心跳周期到達(dá)后，節(jié)點(diǎn)3向節(jié)點(diǎn)4發(fā)送心跳信息，且節(jié)點(diǎn)4向節(jié)點(diǎn)5發(fā)送心跳信息，如圖3中2.6.最終這5個(gè)節(jié)點(diǎn)重新組成了環(huán)形監(jiān)控結(jié)構(gòu).

Fig. 3 The node is added to the ring monitoring network圖3 節(jié)點(diǎn)加入環(huán)形監(jiān)控網(wǎng)絡(luò)

在傳統(tǒng)的資源調(diào)度框架中，資源管理器需要通過接收集群計(jì)算節(jié)點(diǎn)的周期性心跳匯報(bào)來判定節(jié)點(diǎn)是否宕機(jī).通過圖2和圖3的改進(jìn)，宕機(jī)的監(jiān)視由對(duì)等的計(jì)算節(jié)點(diǎn)來完成，不再由資源管理器來實(shí)施，只有當(dāng)某個(gè)計(jì)算節(jié)點(diǎn)出現(xiàn)故障時(shí)，才向資源管理器匯報(bào)，從而降低了資源管理器的壓力.雖然資源監(jiān)控服務(wù)增加了監(jiān)視列表的管理功能，但是在通常運(yùn)行過程中，宕機(jī)的概率較小，發(fā)生的頻度也較低，對(duì)系統(tǒng)的整體調(diào)度的影響有限.

總之，集群的計(jì)算節(jié)點(diǎn)通過增加有狀態(tài)變化的心跳匯報(bào)以及環(huán)形監(jiān)控功能，改變資源監(jiān)控服務(wù)嚴(yán)格地接收周期性心跳信息的機(jī)制，加快資源監(jiān)控模塊心跳信息處理效率，降低資源狀態(tài)更新延遲，改善資源管理器的可擴(kuò)展性問題.

2 可擴(kuò)展資源管理系統(tǒng)的實(shí)現(xiàn)

YARN的資源管理器稱為ResourceManager，其資源監(jiān)控服務(wù)稱為ResourceTrackerService.計(jì)算節(jié)點(diǎn)管理程序稱為NodeManager，該程序的Node-StatusUpdater組件負(fù)責(zé)與ResourceTrackerService建立RPC通信機(jī)制，完成相應(yīng)的節(jié)點(diǎn)注冊(cè)以及心跳的匯報(bào)功能.YARN同樣存在心跳信息周期性發(fā)送問題，因此本文按照基于差分的心跳信息處理模型以及基于環(huán)形監(jiān)視的節(jié)點(diǎn)監(jiān)控模型對(duì)YARN進(jìn)行了優(yōu)化.主要針對(duì)計(jì)算節(jié)點(diǎn)組件NodeStatusUpdater以及資源管理器的資源監(jiān)控服務(wù)ResourceTracker-Service進(jìn)行相關(guān)修改.

2.1 集群計(jì)算節(jié)點(diǎn)的修改

為了完成差分心跳信息的匯報(bào)以及宕機(jī)監(jiān)控功能，計(jì)算節(jié)點(diǎn)需要在計(jì)算節(jié)點(diǎn)的注冊(cè)過程以及心跳匯報(bào)過程進(jìn)行相應(yīng)修改，并增加環(huán)形列表的異步更新，保證計(jì)算節(jié)點(diǎn)組成完整的環(huán)形監(jiān)控網(wǎng)絡(luò).

1) 計(jì)算節(jié)點(diǎn)注冊(cè)過程修改

計(jì)算節(jié)點(diǎn)上的服務(wù)啟動(dòng)后，NodeStatusUpdater組件首先調(diào)用內(nèi)部函數(shù)registerWithRM()完成節(jié)點(diǎn)向資源監(jiān)控服務(wù)發(fā)起注冊(cè)請(qǐng)求的信息.為了保證環(huán)形監(jiān)控列表的建立，每個(gè)計(jì)算節(jié)點(diǎn)在注冊(cè)成功后，應(yīng)保存由資源監(jiān)控服務(wù)分配的唯一標(biāo)識(shí).因此，在函數(shù)registerWithRM()流程中增加機(jī)器序列號(hào)的保存工作.

流程1.節(jié)點(diǎn)注冊(cè).

輸入：當(dāng)前節(jié)點(diǎn)信息curMac；

輸出：當(dāng)前被更新的節(jié)點(diǎn)信息curMac.

① 初始化通信接口resourceTracker；

② 發(fā)送RegisterNodeManagerRequest(curMac)；

③ 接收RegisterNodeManagerResponse；

④ ifRegisterNodeManagerResponse是正常狀態(tài)

⑤ 更新curMac.Mid；

⑥ end if

行①初始化建立resourceTracker通信接口.行②表示計(jì)算節(jié)點(diǎn)與資源監(jiān)控服務(wù)的通信注冊(cè)過程，RegisterNodeManagerRequest將節(jié)點(diǎn)IP地址、對(duì)外端口號(hào)以及總資源的描述信息進(jìn)行封裝，通過resourceTracker通信接口，調(diào)用遠(yuǎn)程RegisterNode-Manager函數(shù)向資源監(jiān)控服務(wù)注冊(cè)節(jié)點(diǎn)信息.行③表示資源監(jiān)控服務(wù)向計(jì)算節(jié)點(diǎn)返回注冊(cè)成功消息，其消息類型為RegisterNodeManagerResponse.例如當(dāng)返回消息標(biāo)識(shí)為shutdown時(shí)，可能的原因是當(dāng)前注冊(cè)節(jié)點(diǎn)資源不符合集群最小分配資源，因此拒絕該節(jié)點(diǎn)注冊(cè)，該節(jié)點(diǎn)的服務(wù)應(yīng)該關(guān)閉.而在正常情況下被接受注冊(cè)的節(jié)點(diǎn)會(huì)收到信息標(biāo)識(shí)為normal.另外，我們對(duì)該消息格式增加變量描述，即資源監(jiān)控服務(wù)為計(jì)算節(jié)點(diǎn)返回1個(gè)機(jī)器編號(hào).行④～⑥表示計(jì)算節(jié)點(diǎn)收到正常執(zhí)行消息后保存機(jī)器編號(hào)，使得節(jié)點(diǎn)知道自身所在環(huán)形網(wǎng)絡(luò)的位置，便于找到其前驅(qū)以及后繼節(jié)點(diǎn).

2) 心跳信息匯報(bào)的修改

在心跳信息匯報(bào)過程中，目的是減少不必要的心跳信息發(fā)送，并完成計(jì)算節(jié)點(diǎn)的監(jiān)控.其過程分為2個(gè)步驟：第1步，當(dāng)心跳時(shí)刻到達(dá)，計(jì)算節(jié)點(diǎn)對(duì)比本次與上一次緩存的容器狀態(tài)和資源健康狀態(tài)，根據(jù)對(duì)比結(jié)果有選擇地匯報(bào)心跳信息.第2步，增加各個(gè)計(jì)算節(jié)點(diǎn)環(huán)形網(wǎng)絡(luò)的監(jiān)控功能，保證宕機(jī)節(jié)點(diǎn)能夠被監(jiān)測(cè)到.

流程2.節(jié)點(diǎn)心跳匯報(bào).

輸入：當(dāng)前節(jié)點(diǎn)信息curMac；

輸出：當(dāng)前被更新的節(jié)點(diǎn)信息curMac.

① 初始化Tnew，Told，Healthnew，Healthold，

TaskInfo；

② 創(chuàng)建1個(gè)線程；

③ while !isstopped

④ 讀取消息Tnew，Healthnew；

⑤ ifTnew-Told??或Healthnew≠Healthold；

⑥TaskInfo=Tnew-Told；

⑦ 發(fā)送NodeHeartbeatRequest(TaskInfo,

Healthnew)；

⑧ 接收NodeHeartbeatResponse；

⑨ if 檢測(cè)NodeHeartbeatResponse為

shutdow或resync

⑩ 通知NodeManager關(guān)閉計(jì)算節(jié)點(diǎn)服務(wù)或重啟NodeStatusUpdater服務(wù);

內(nèi)容不為空

行①為變量初始化，行④周期性獲取節(jié)點(diǎn)容器狀態(tài)以及健康狀態(tài).行⑤～⑧表示若有任務(wù)狀態(tài)或健康狀態(tài)變化，則先將任務(wù)進(jìn)行過濾處理后，再向資源監(jiān)控服務(wù)匯報(bào)心跳信息.行⑨～表示如果資源監(jiān)控服務(wù)返回心跳回復(fù)信息執(zhí)行狀態(tài)為shutdown或resync，則根據(jù)相應(yīng)行為狀態(tài)通知NodeManager關(guān)閉計(jì)算節(jié)點(diǎn)全部服務(wù)或僅重啟NodeStatusUpdater服務(wù)，并影響NodeStatusUpdater服務(wù)的isstopped值的變化，防止當(dāng)前心跳匯報(bào)函數(shù)進(jìn)入下一次循環(huán).行表示按照心跳回復(fù)消息內(nèi)容更新心跳序號(hào)，保證計(jì)算節(jié)點(diǎn)有序匯報(bào)心跳信息，同時(shí)更新上一次的容器狀態(tài)以及健康狀態(tài)信息.行表示計(jì)算節(jié)點(diǎn)向后繼節(jié)點(diǎn)發(fā)送生存狀態(tài)信息.行～表示如果當(dāng)前節(jié)點(diǎn)檢測(cè)前驅(qū)節(jié)點(diǎn)未發(fā)送生存狀態(tài)消息，則認(rèn)為節(jié)點(diǎn)宕機(jī)，并向資源監(jiān)控服務(wù)匯報(bào)該節(jié)點(diǎn)不可用.否則，不用匯報(bào).行～表示如果節(jié)點(diǎn)監(jiān)控關(guān)系不符合當(dāng)前資源監(jiān)控服務(wù)所維護(hù)的環(huán)形監(jiān)控列表，則計(jì)算節(jié)點(diǎn)需要重新更新前驅(qū)與后繼節(jié)點(diǎn).

3) 環(huán)形監(jiān)控列表的更新

由于節(jié)點(diǎn)的加入或退出會(huì)引起計(jì)算節(jié)點(diǎn)環(huán)形監(jiān)控列表的變化，因此計(jì)算節(jié)點(diǎn)需要及時(shí)更新環(huán)形監(jiān)控列表.為此，在計(jì)算節(jié)點(diǎn)上增加了環(huán)形監(jiān)控列表更新功能，該功能由資源監(jiān)控服務(wù)觸發(fā).針對(duì)環(huán)形監(jiān)控列表的更新功能，計(jì)算節(jié)點(diǎn)相當(dāng)于服務(wù)端，資源監(jiān)控服務(wù)相當(dāng)于客戶端.通過YARN提供的類YarnRPC，在計(jì)算節(jié)點(diǎn)上構(gòu)建RPC協(xié)議，實(shí)現(xiàn)了與環(huán)形監(jiān)控列表更新功能相關(guān)的函數(shù)接口，并在NodeStatus-Updater組件初始化時(shí)啟動(dòng)該通信服務(wù).同時(shí)，對(duì)該函數(shù)的參數(shù)與返回消息進(jìn)行相關(guān)定義與封裝.

流程3.處理環(huán)型列表更新消息.

輸入：計(jì)算節(jié)點(diǎn)環(huán)形列表更新消息請(qǐng)求；

輸出：計(jì)算節(jié)點(diǎn)環(huán)形列表更新消息回復(fù).

① ifrequest不是來源于中心節(jié)點(diǎn)

② returnNodeListUpdateResponse(reject)；

③ end if

④ 更新curMac.NodeList；

⑤ 更新curMac.next，curMac.prev；

⑥ returnNodeListUpdateResponse(accept).

函數(shù)參數(shù)為NodeListUpdateRequest消息，內(nèi)容主要包含節(jié)點(diǎn)來源信息以及環(huán)形監(jiān)控列表信息.函數(shù)返回為NodeListUpdateResponse消息，內(nèi)容主要包含1個(gè)標(biāo)志信息，即是否接受處理該信息.行①～③檢測(cè)該請(qǐng)求來源信息，如果該請(qǐng)求不是資源管理器發(fā)來的消息，則拒絕該消息.行④表示讀取該消息內(nèi)容，并更新環(huán)形節(jié)點(diǎn)列表.行⑤表示計(jì)算節(jié)點(diǎn)根據(jù)自身機(jī)器編號(hào)以及環(huán)形列表，更新前驅(qū)節(jié)點(diǎn)以及后繼節(jié)點(diǎn)，即計(jì)算節(jié)點(diǎn)形成新的環(huán)形監(jiān)控網(wǎng)絡(luò).行⑥表示計(jì)算節(jié)點(diǎn)接受并完成本次列表更新事件，并返回消息.

2.2 資源監(jiān)控服務(wù)處理的實(shí)現(xiàn)

利用計(jì)算節(jié)點(diǎn)差分心跳信息匯報(bào)機(jī)制，減輕了集中式資源管理器的負(fù)載.然而，計(jì)算節(jié)點(diǎn)的存活狀態(tài)監(jiān)控需要資源管理器進(jìn)行一致性保證.因此，資源管理器的資源監(jiān)控服務(wù)端需要增加環(huán)形監(jiān)控列表的維護(hù)功能，相應(yīng)實(shí)現(xiàn)如下.

1) RPC注冊(cè)函數(shù)的修改

當(dāng)計(jì)算節(jié)點(diǎn)發(fā)來注冊(cè)請(qǐng)求消息時(shí)，資源監(jiān)控服務(wù)需要對(duì)環(huán)形監(jiān)控列表進(jìn)行更新構(gòu)建.

流程4.處理節(jié)點(diǎn)注冊(cè)消息.

輸入：注冊(cè)請(qǐng)求消息；

輸出：注冊(cè)回復(fù)消息.

① ifrequest不是來自有效節(jié)點(diǎn)

② returnRegisterNodeManagerResponse

(shutdown)；

③ end if

④rmnode=newRMNode(request)；

⑤NodeList+=rmnode.Mid；

⑥ 排序NodeList；

⑦ 異步通知各節(jié)點(diǎn)更新NodeList；

⑧ returnRegisterNodeManagerResponse

(normal,rmnode.Mid).

行①～③是對(duì)該消息相關(guān)內(nèi)容進(jìn)行安全檢測(cè).行④表示根據(jù)消息中節(jié)點(diǎn)信息為新注冊(cè)節(jié)點(diǎn)創(chuàng)建狀態(tài)機(jī)，用來管理該節(jié)點(diǎn)的生命周期，并為該節(jié)點(diǎn)分配1個(gè)可用機(jī)器編號(hào).行⑤表示將該節(jié)點(diǎn)編號(hào)加入環(huán)形監(jiān)控列表中.行⑥⑦表示將環(huán)形列表按照節(jié)點(diǎn)序號(hào)進(jìn)行排序，并異步地通知各個(gè)計(jì)算節(jié)點(diǎn)更新環(huán)形監(jiān)控列表，保證計(jì)算節(jié)點(diǎn)收到節(jié)點(diǎn)列表更新消息后，根據(jù)自身節(jié)點(diǎn)機(jī)器編號(hào)找到對(duì)應(yīng)的前驅(qū)與后繼節(jié)點(diǎn)，組成完整環(huán)形監(jiān)控網(wǎng)絡(luò).行⑧表示對(duì)節(jié)點(diǎn)注冊(cè)信息的回復(fù)，為計(jì)算節(jié)點(diǎn)額外返回1個(gè)節(jié)點(diǎn)編號(hào)，用于標(biāo)識(shí)該計(jì)算節(jié)點(diǎn)在環(huán)形網(wǎng)絡(luò)的序列關(guān)系.

2) RPC心跳響應(yīng)函數(shù)的修改

RPC心跳響應(yīng)函數(shù)中，刪除了心跳信息的過濾步驟，直接發(fā)送更新通知.下面描述了該函數(shù)的正常執(zhí)行流程.

流程5.處理節(jié)點(diǎn)心跳匯報(bào)消息.

輸入：心跳匯報(bào)請(qǐng)求消息；

輸出：心跳匯報(bào)回復(fù)消息.

① ifrequest不是來自有效節(jié)點(diǎn)

② returnNodeHeartbeatResponse

(shutdown)；

③ end if

④ if管理列表中無request.Node

⑤ returnNodeHeartbeatResponse(resync)；

⑥ end if

⑦ ifrequest.heartbeatID不是有序的

⑧ returnNodeHeartbeatResponse(resync)；

⑨ end if

⑩ ifrequest.NodeStatus是健康狀態(tài)

HearbeatID).

行①～⑨表示收到計(jì)算節(jié)點(diǎn)的心跳匯報(bào)請(qǐng)求后，對(duì)心跳匯報(bào)的節(jié)點(diǎn)信息進(jìn)行安全性檢測(cè)、判斷是否為注冊(cè)的節(jié)點(diǎn)以及是否嚴(yán)格符合消息匯報(bào)順序，如果不符合要求則返回相應(yīng)計(jì)算節(jié)點(diǎn)下一步執(zhí)行行為.由于計(jì)算節(jié)點(diǎn)狀態(tài)的變化，會(huì)引起資源的變化，因此當(dāng)資源監(jiān)控服務(wù)收到心跳后進(jìn)入行⑩～過程，對(duì)相應(yīng)計(jì)算節(jié)點(diǎn)狀態(tài)進(jìn)行更新同步.行表示計(jì)算節(jié)點(diǎn)從健康狀態(tài)或非健康狀態(tài)轉(zhuǎn)化為健康狀態(tài)的過程.如果該計(jì)算節(jié)點(diǎn)處于健康狀態(tài)，則說明容器狀態(tài)有變化，把計(jì)算節(jié)點(diǎn)上的變化信息直接通知調(diào)度器，完成資源的更新與釋放.如果計(jì)算節(jié)點(diǎn)之前處于非健康狀態(tài)，則在狀態(tài)轉(zhuǎn)化過程中，向調(diào)度器通知計(jì)算節(jié)點(diǎn)資源可用消息.行表示計(jì)算節(jié)點(diǎn)從健康狀態(tài)到非健康狀態(tài)的轉(zhuǎn)化，在狀態(tài)轉(zhuǎn)化過程中，通知調(diào)度器當(dāng)前計(jì)算節(jié)點(diǎn)資源不可用.行～更新節(jié)點(diǎn)心跳序號(hào)，并返回心跳回復(fù)信息，控制計(jì)算節(jié)點(diǎn)心跳信息的發(fā)送順序.

3) 宕機(jī)節(jié)點(diǎn)監(jiān)控消息的處理

為保證集群計(jì)算節(jié)點(diǎn)環(huán)形一致性監(jiān)控，資源監(jiān)控服務(wù)需要額外增加功能函數(shù)，即計(jì)算節(jié)點(diǎn)發(fā)生宕機(jī)時(shí)的響應(yīng)與處理.

流程6.處理節(jié)點(diǎn)宕機(jī)匯報(bào)消息.

輸入：宕機(jī)消息請(qǐng)求；

輸出：宕機(jī)消息回復(fù).

① ifrequest不是來自有效節(jié)點(diǎn)

② returnUnLivelinessResponse(shutdown)；

③ end if

④ if管理列表中無request.Node

⑤ returnUnLivelinessResponse(resync)；

⑥ end if

⑦ ifrequest.Node,request.Pre不符合NodeList

⑧ returnUnLivenessResponse(NodeList)；

⑨ end if

⑩ 狀態(tài)轉(zhuǎn)化request.Pre→Lost；

在當(dāng)前通信協(xié)議中增加了1個(gè)RPC函數(shù)，定義為UnLivenessNodeManager，該函數(shù)包含1個(gè)參數(shù)UnLivelinessRequest消息結(jié)構(gòu)和1個(gè)返回值UnLive-linessResponse消息結(jié)構(gòu).UnLivelinessRequest主要包含當(dāng)前計(jì)算節(jié)點(diǎn)的信息，以及被監(jiān)控的計(jì)算節(jié)點(diǎn)的信息.UnLivelinessResponse主要包含當(dāng)前環(huán)形監(jiān)控列表信息，以及節(jié)點(diǎn)下一步執(zhí)行行為.

行①～⑥首先進(jìn)行計(jì)算節(jié)點(diǎn)的安全性檢測(cè).行⑦～⑨檢查當(dāng)前計(jì)算節(jié)點(diǎn)以及它的前驅(qū)節(jié)點(diǎn)之間的監(jiān)控關(guān)系，判斷是否符合當(dāng)前的環(huán)形監(jiān)控列表，如果不符合則返回最新環(huán)形監(jiān)控列表，通知該計(jì)算節(jié)點(diǎn)更新前驅(qū)與后繼的監(jiān)控關(guān)系；否則，接受本次匯報(bào).行⑩將該節(jié)點(diǎn)所匯報(bào)的前驅(qū)節(jié)點(diǎn)的狀態(tài)轉(zhuǎn)為丟失狀態(tài)，同時(shí)向調(diào)度器發(fā)送節(jié)點(diǎn)資源減少消息.行～表示將宕機(jī)節(jié)點(diǎn)從環(huán)形監(jiān)控列表中移除，重新將環(huán)形監(jiān)控列表排序并異步通知各個(gè)計(jì)算節(jié)點(diǎn).

另外，YARN資源管理器的NMLivelinessMonitor服務(wù)，會(huì)根據(jù)上一次心跳時(shí)間與當(dāng)前時(shí)間之間的差值，判斷節(jié)點(diǎn)是否宕機(jī).若2個(gè)時(shí)間差值超過規(guī)定時(shí)間，則認(rèn)為該節(jié)點(diǎn)宕機(jī)，從計(jì)算節(jié)點(diǎn)管理列表中移除當(dāng)前節(jié)點(diǎn)信息.采用基于差分的心跳信息處理模型后，NMLivelinessMonitor服務(wù)就不再承擔(dān)這項(xiàng)功能，因此該服務(wù)被刪除.

由于YARN采用基于事件驅(qū)動(dòng)的資源調(diào)度，為避免心跳數(shù)量減少而影響資源調(diào)度過程，我們開啟YARN的持續(xù)調(diào)度機(jī)制.

Fig. 4 Architecture of YARN SLS圖4 YARN SLS運(yùn)行結(jié)構(gòu)圖

3 實(shí)驗(yàn)與結(jié)果

為了評(píng)價(jià)YARN調(diào)度器的性能，YARN官方針對(duì)YARN資源管理架構(gòu)提供了一套性能模型工具SLS(scheduler load simulator)，它可以在單臺(tái)機(jī)器上模擬大規(guī)模集群，然后根據(jù)歷史日志信息，獲得應(yīng)用程序負(fù)載、資源分配、任務(wù)調(diào)度和資源回收過程的信息.但是隨著模擬的計(jì)算節(jié)點(diǎn)數(shù)量增多以及模擬負(fù)載的加大，SLS中的線程數(shù)也相應(yīng)增加，線程數(shù)量的增加導(dǎo)致線程上下文切換開銷加大，致使模擬的性能數(shù)據(jù)受到影響.經(jīng)過測(cè)試，單臺(tái)機(jī)器的最大模擬節(jié)點(diǎn)數(shù)量為5 000個(gè).

為了驗(yàn)證優(yōu)化后的資源管理框架的可擴(kuò)展性，提高模擬節(jié)點(diǎn)的數(shù)量，本文將SLS模擬器的應(yīng)用程序模擬部分以及節(jié)點(diǎn)運(yùn)行模擬部分進(jìn)行了分離，使其可以運(yùn)行在多個(gè)物理機(jī)器上，改進(jìn)了SLS模擬器的運(yùn)行結(jié)構(gòu)，改進(jìn)后的SLS如圖4(b)所示，稱為分布式模擬器.

實(shí)驗(yàn)評(píng)價(jià)過程中，使用了3臺(tái)服務(wù)器，每臺(tái)機(jī)器均為NF5468M5服務(wù)器，包含2顆Xeon2.1處理器，每個(gè)處理器包含8個(gè)核、32 GB DDR4內(nèi)存、2塊RTX2080TI GPU卡、10 GB顯存.3臺(tái)服務(wù)器中的1臺(tái)服務(wù)器作為資源管理器使用，另外2臺(tái)作為集群計(jì)算節(jié)點(diǎn)使用.

SLS的系統(tǒng)結(jié)構(gòu)如圖4(a)，YARN的資源管理器的主要服務(wù)有Scheduler，ResourceTrackerService，ApplicationMasterService，它們分別為調(diào)度器、資源監(jiān)控服務(wù)、應(yīng)用程序管理服務(wù).在模擬過程中，應(yīng)用程序主要模擬作業(yè)申請(qǐng)與任務(wù)調(diào)度.計(jì)算節(jié)點(diǎn)主要模擬接受應(yīng)用程序發(fā)布的任務(wù)，維護(hù)其運(yùn)行狀態(tài)并周期性向資源監(jiān)控服務(wù)心跳匯報(bào).單節(jié)點(diǎn)模擬器發(fā)送的心跳方式是通過本地調(diào)用的方法來實(shí)現(xiàn)，應(yīng)用程序以及計(jì)算節(jié)點(diǎn)不通過網(wǎng)絡(luò)與資源管理系統(tǒng)進(jìn)行交互，因此無法真實(shí)地模擬通信過程.分布式模擬器的資源管理器運(yùn)行在單獨(dú)的節(jié)點(diǎn)上，計(jì)算節(jié)點(diǎn)與應(yīng)用程序運(yùn)行在其他物理機(jī)上.它們之間需要通過RPC協(xié)議與資源管理系統(tǒng)的各個(gè)模塊進(jìn)行信息的交互.另外，應(yīng)用程序獲得資源后，將任務(wù)封裝成容器描述信息，通過RMI通信方式來調(diào)用本地或遠(yuǎn)程機(jī)器的對(duì)象方法，將容器信息添加到相應(yīng)模擬計(jì)算節(jié)點(diǎn)的任務(wù)運(yùn)行管理隊(duì)列中，保證調(diào)度器分配的資源與任務(wù)的映射關(guān)系在模擬計(jì)算節(jié)點(diǎn)上得到正確的體現(xiàn).

為了測(cè)試調(diào)度器的可擴(kuò)展性，分布式模擬器的資源管理系統(tǒng)則使用優(yōu)化后YARN的實(shí)際代碼，集群計(jì)算節(jié)點(diǎn)使用模擬代碼，模擬代碼上添加了任務(wù)狀態(tài)與健康狀態(tài)差分過濾功能，即有變化時(shí)匯報(bào)心跳消息.

3.1 可擴(kuò)展性測(cè)試

對(duì)于計(jì)算節(jié)點(diǎn)上的負(fù)載變化，使用正在運(yùn)行的容器數(shù)量作為負(fù)載單位.把計(jì)算節(jié)點(diǎn)正在運(yùn)行的容器數(shù)與其總?cè)萜鲾?shù)的比值稱為負(fù)載壓力.為了合理模擬不同集群節(jié)點(diǎn)的負(fù)載壓力，應(yīng)保證作業(yè)的負(fù)載量與集群資源總量成正比.每個(gè)作業(yè)需要運(yùn)行的任務(wù)數(shù)量與計(jì)算節(jié)點(diǎn)數(shù)量和最大運(yùn)行任務(wù)數(shù)有關(guān).作業(yè)數(shù)量的計(jì)算公式為t=(n×c×l)/a，其中n為計(jì)算節(jié)點(diǎn)模擬數(shù)量，c為每個(gè)計(jì)算節(jié)點(diǎn)最大運(yùn)行任務(wù)數(shù)量,c=20，l為負(fù)載因子，在實(shí)驗(yàn)中規(guī)定l=0.95，a為作業(yè)的數(shù)量,a=30.每個(gè)作業(yè)相繼每隔10 s啟動(dòng)一個(gè)，每個(gè)作業(yè)預(yù)計(jì)執(zhí)行時(shí)間為400 s，其任務(wù)的運(yùn)行時(shí)間隨機(jī).預(yù)計(jì)總運(yùn)行時(shí)長(zhǎng)為T=a×Toffset+(Tjob-Toffset)，其中Toffset為每個(gè)作業(yè)啟動(dòng)的時(shí)間間隔，Tjob為每個(gè)作業(yè)的預(yù)計(jì)執(zhí)行時(shí)間，代入公式得到最終總的預(yù)計(jì)完成時(shí)間為690 s.隨著作業(yè)逐個(gè)啟動(dòng)，處于運(yùn)行狀態(tài)的容器數(shù)量逐漸增加，這些信息被周期性匯報(bào)給資源監(jiān)控服務(wù)，資源監(jiān)控服務(wù)負(fù)載開始上升，當(dāng)時(shí)間到達(dá)400 s后，資源監(jiān)控服務(wù)的負(fù)載開始下降.從第1個(gè)作業(yè)開始到全部作業(yè)結(jié)束，負(fù)載類似正態(tài)分布，并在300～400 s之間時(shí)，負(fù)載壓力會(huì)達(dá)到最大，即40%～50%之間.另外，對(duì)于集群節(jié)點(diǎn)數(shù)量，模擬數(shù)量從1 000個(gè)逐漸增加到10 000個(gè)進(jìn)行實(shí)驗(yàn)測(cè)試.計(jì)算節(jié)點(diǎn)心跳匯報(bào)時(shí)間間隔至少設(shè)為3 s，并記錄每個(gè)心跳周期內(nèi)發(fā)送的消息數(shù)量以及接收到心跳回復(fù)消息數(shù)量.

資源監(jiān)控服務(wù)接收到計(jì)算節(jié)點(diǎn)的心跳信息后，完成1次交互.資源監(jiān)控服務(wù)將心跳信息進(jìn)一步過濾處理后，產(chǎn)生節(jié)點(diǎn)更新事件并通知調(diào)度器，調(diào)度器更新相應(yīng)的資源狀態(tài).隨著計(jì)算節(jié)點(diǎn)上正在運(yùn)行的容器數(shù)量的增加，每次心跳信息的數(shù)據(jù)量也相應(yīng)增大，資源監(jiān)控服務(wù)接收到的數(shù)據(jù)量也增大，資源監(jiān)控服務(wù)將使用更多的CPU資源以及內(nèi)存資源來處理這些數(shù)據(jù)，并且產(chǎn)生更多的調(diào)度器更新事件.由于調(diào)度器必須為每個(gè)更新事件進(jìn)行對(duì)應(yīng)的處理，所以調(diào)度負(fù)載加大.因此集群節(jié)點(diǎn)的管理規(guī)模取決于調(diào)度器對(duì)更新事件的處理效率.對(duì)于每一次心跳信息的處理，既包括資源監(jiān)控服務(wù)器的數(shù)據(jù)過濾也包括調(diào)度器過濾后的數(shù)據(jù)的處理.而資源監(jiān)控服務(wù)的處理效率以及調(diào)度器的處理效率，決定了整個(gè)集群資源管理的能力.資源監(jiān)控服務(wù)的心跳信息處理效率定義為h1=min(mi/ni)，而調(diào)度器對(duì)于節(jié)點(diǎn)資源更新事件的處理效率為h2=min(si/ni).其中ni為集群模擬節(jié)點(diǎn)在心跳時(shí)間間隔發(fā)送的心跳數(shù)量，mi為集群模擬節(jié)點(diǎn)心跳時(shí)間間隔內(nèi)收到來自資源監(jiān)控服務(wù)的心跳信息回復(fù)的數(shù)量，si為調(diào)度器心跳時(shí)間間隔內(nèi)處理的節(jié)點(diǎn)資源更新事件數(shù)量.

Fig. 5 Scalability bottleneck test圖5 可擴(kuò)展性瓶頸測(cè)試

為了對(duì)比改進(jìn)前后的效果，使用了YARN發(fā)布的2個(gè)版本與我們改進(jìn)后的版本進(jìn)行測(cè)試.圖5是YARN在不同集群規(guī)模下的心跳信息處理效率.圖5(a)是使用YARN的Hadoop-2.10.0版本獲得的數(shù)據(jù)；圖5(b)是YARN的Hadoop-3.1.0版本獲得的數(shù)據(jù)，Hadoop-3.1.0對(duì)Hadoop-2.10.0中的資源監(jiān)視等服務(wù)進(jìn)行了一定的優(yōu)化；圖5(c)是本文對(duì)YARN的Hadoop-3.1.0使用差分模型和環(huán)形監(jiān)控優(yōu)化后的資源管理系統(tǒng).對(duì)比看出，改進(jìn)后的YARN資源管理系統(tǒng)對(duì)于心跳信息的處理效率明顯高于原系統(tǒng).YARN原系統(tǒng)的心跳監(jiān)控服務(wù)大約在4 500個(gè)計(jì)算節(jié)點(diǎn)時(shí)，就出現(xiàn)性能下降；在4 000個(gè)節(jié)點(diǎn)時(shí)，調(diào)度器的更新事件處理只能達(dá)到90%左右.而本文優(yōu)化后的系統(tǒng)，心跳信息處理能夠達(dá)到8 000個(gè)計(jì)算節(jié)點(diǎn)，在7 500個(gè)計(jì)算節(jié)點(diǎn)處，才出現(xiàn)調(diào)度器更新事件的處理能力下降.我們知道，資源監(jiān)控服務(wù)以及調(diào)度器在同一節(jié)點(diǎn)運(yùn)行，心跳信息處理開銷增大，必然影響調(diào)度處理開銷，反之亦然.YARN的調(diào)度器每接收1個(gè)更新事件，便進(jìn)行1次資源的回收與分配操作.然而，當(dāng)資源監(jiān)控服務(wù)對(duì)于心跳信息處理出現(xiàn)過載時(shí)，更新事件就不能及時(shí)發(fā)送給調(diào)度器，這嚴(yán)重限制了調(diào)度器資源回收與分配的性能，因此在大規(guī)模集群管理下，更新事件驅(qū)動(dòng)的資源分配方式不太適用.而改進(jìn)后的系統(tǒng)，在計(jì)算節(jié)點(diǎn)通過容器狀態(tài)差分方式對(duì)心跳信息進(jìn)行預(yù)處理，減少了心跳數(shù)量以及心跳信息所帶來的數(shù)據(jù)量，進(jìn)而減少通信開銷，提高了資源監(jiān)控服務(wù)對(duì)于心跳信息的處理效率，使得資源監(jiān)控服務(wù)可以快速地將更新事件發(fā)送到調(diào)度器，使得調(diào)度器的處理性能有較大提升.另外，資源監(jiān)控服務(wù)對(duì)于心跳信息的處理效率影響調(diào)度器對(duì)于資源分配的公平性以及可用資源回收的及時(shí)性.總之，提升資源監(jiān)控服務(wù)性能可以進(jìn)一步提升調(diào)度器的性能，進(jìn)而提升集群管理規(guī)模.

當(dāng)集群管理規(guī)模為8 000個(gè)節(jié)點(diǎn)以上時(shí)，由于大規(guī)模的任務(wù)在模擬節(jié)點(diǎn)上隨機(jī)運(yùn)行，新啟動(dòng)的任務(wù)以及結(jié)束任務(wù)的數(shù)量不斷出現(xiàn)，導(dǎo)致大量的集群計(jì)算節(jié)點(diǎn)的心跳匯報(bào)信息不能被響應(yīng)，改進(jìn)后YARN系統(tǒng)的資源監(jiān)控服務(wù)達(dá)到了處理瓶頸.同時(shí)隨著集群節(jié)點(diǎn)規(guī)模的增大，YARN內(nèi)部多種狀態(tài)機(jī)制的轉(zhuǎn)化與管理使得各模塊交互事件增多，導(dǎo)致資源管理中的異步事件分派器下發(fā)能力限制，調(diào)度器對(duì)于節(jié)點(diǎn)更新事件的處理達(dá)到了瓶頸.因此，在心跳時(shí)間間隔為3 s時(shí)，改進(jìn)后YARN的管理集群規(guī)?？梢詳U(kuò)大到7 500個(gè)節(jié)點(diǎn)，系統(tǒng)亦可以正常地調(diào)度任務(wù).修改前的YARN在集群節(jié)點(diǎn)數(shù)量超過4 000個(gè)時(shí)，開始出現(xiàn)調(diào)度延遲的現(xiàn)象.改進(jìn)后的YARN資源管理系統(tǒng)的集群規(guī)模可以擴(kuò)大到原來的1.88倍.

3.2 調(diào)度器對(duì)于事件的處理時(shí)間測(cè)試

YARN調(diào)度器需要處理資源分配請(qǐng)求以及節(jié)點(diǎn)更新事件，這些操作分別由應(yīng)用程序管理服務(wù)與資源監(jiān)控服務(wù)引發(fā).在YARN的 SLS結(jié)構(gòu)中，為了獲得調(diào)度器的各方面性能，SLS將調(diào)度器進(jìn)行了一次封裝，即添加了一個(gè)構(gòu)件Scheduler wrapper.當(dāng)資源監(jiān)控服務(wù)處理完心跳信息后，調(diào)度器處理開始，同時(shí)通過異步事件分派隊(duì)列，將計(jì)算節(jié)點(diǎn)更新事件傳入Scheduler wrapper，開始計(jì)時(shí).當(dāng)調(diào)度處理結(jié)束后，再通過異步事件分派隊(duì)列，將調(diào)度結(jié)束消息傳入Scheduler wrapper，停止計(jì)時(shí).從處理開始到處理結(jié)束的時(shí)間段就是處理一次事件所消耗的時(shí)間.通過YARN的Metric性能統(tǒng)計(jì)工具，計(jì)算出處理相應(yīng)事件類型的平均耗時(shí).

圖6和圖7分別記錄了Hadoop-2.10.0，Hadoop-3.1.0以及改進(jìn)后的YARN對(duì)于節(jié)點(diǎn)更新事件的處理時(shí)間，以及響應(yīng)資源請(qǐng)求更新與分配的時(shí)間.通過記錄節(jié)點(diǎn)更新事件的處理時(shí)間，可以分析資源監(jiān)控服務(wù)對(duì)調(diào)度器處理性能的影響.同時(shí)，通過分析應(yīng)用程序管理服務(wù)的資源分配處理過程，可以得到調(diào)度器對(duì)應(yīng)用程序的資源分配請(qǐng)求的響應(yīng)時(shí)間.這些數(shù)據(jù)可以使我們進(jìn)一步分析應(yīng)用管理程序、調(diào)度器以及資源監(jiān)控服務(wù)之間的性能影響關(guān)系.

Fig. 6 Scheduler cost time on node update event圖6 調(diào)度器對(duì)于節(jié)點(diǎn)更新事件處理時(shí)間

圖6為7 500節(jié)點(diǎn)下調(diào)度器對(duì)于節(jié)點(diǎn)更新事件的處理時(shí)間記錄，可以看出改進(jìn)后YARN系統(tǒng)的調(diào)度器運(yùn)行時(shí)間與預(yù)計(jì)時(shí)間相符合，即在690 s內(nèi)完成整個(gè)模擬過程.而Hadoop-2.10.0，Hadoop-3.1.0版本的YARN系統(tǒng)，在模擬過程中調(diào)度器的運(yùn)行時(shí)間均出現(xiàn)一定程度的延遲.另外，在模擬運(yùn)行過程中，調(diào)度器對(duì)于事件處理的平均時(shí)間明顯高于改進(jìn)后的YARN系統(tǒng).其最主要原因是，改進(jìn)后的YARN系統(tǒng)的資源監(jiān)控服務(wù)可以及時(shí)響應(yīng)集群計(jì)算節(jié)點(diǎn)的心跳信息并高效地處理，系統(tǒng)未出現(xiàn)過載現(xiàn)象，改善了調(diào)度器的更新事件的處理能力.

Fig. 7 Scheduler cost time on processing update requests from application master service圖7 調(diào)度器對(duì)應(yīng)用程序管理服務(wù)的更新請(qǐng)求處理時(shí)間

從圖7可以看出，改進(jìn)后的系統(tǒng)能較快地更新資源，大大提高了資源分配請(qǐng)求的更新速度.其主要原因是，當(dāng)YARN的資源監(jiān)控服務(wù)對(duì)于心跳信息的處理變得緩慢時(shí)，會(huì)導(dǎo)致節(jié)點(diǎn)資源更新的延遲，使得應(yīng)用程序?qū)τ诒敬钨Y源分配請(qǐng)求所獲取資源不能達(dá)到要求，導(dǎo)致應(yīng)用程序不斷地向應(yīng)用程序管理服務(wù)發(fā)送資源分配請(qǐng)求，增大了資源請(qǐng)求更新的頻率.在2次調(diào)度之間數(shù)據(jù)本地化，優(yōu)先級(jí)等因素可能發(fā)生變化，調(diào)度器需要重新進(jìn)行資源分配，進(jìn)一步加重調(diào)度器負(fù)載壓力.因此，資源監(jiān)控服務(wù)心跳信息的處理效率直接影響了資源的回收，進(jìn)一步影響了資源分配效率，導(dǎo)致調(diào)度器在性能方面受到了一定的影響.

3.3 系統(tǒng)性能整體測(cè)試

為了測(cè)試系統(tǒng)繁忙程度，本文將CPU使用率作為參考指標(biāo).本節(jié)CPU使用率特指在用戶態(tài)下的CPU使用率.圖8給出了系統(tǒng)在維護(hù)不同集群規(guī)模期間的CPU平均使用率.從圖8可以看出，在6 000節(jié)點(diǎn)之前，各系統(tǒng)的CPU平均使用率隨著集群管理規(guī)模擴(kuò)大呈現(xiàn)升高趨勢(shì).由于改進(jìn)后的YARN系統(tǒng)的資源監(jiān)控服務(wù)通過接收少量的關(guān)鍵心跳信息來管理大規(guī)模集群，使得CPU平均使用率相比原系統(tǒng)會(huì)低一些.對(duì)于改進(jìn)前的YARN系統(tǒng)，當(dāng)集群規(guī)模進(jìn)一步擴(kuò)大以及負(fù)載壓力的提高，集群節(jié)點(diǎn)持續(xù)地發(fā)送大批心跳信息導(dǎo)致資源監(jiān)控服務(wù)過載，因而處理效率更加緩慢.由于心跳信息無法被及時(shí)處理，模擬計(jì)算節(jié)點(diǎn)會(huì)長(zhǎng)時(shí)間等待心跳信息的回復(fù)消息，從而導(dǎo)致模擬節(jié)點(diǎn)無法正常發(fā)送心跳消息，因此其模擬節(jié)點(diǎn)上的CPU平均使用率從7 000節(jié)點(diǎn)開始明顯下降.相反，由于改進(jìn)后的YARN系統(tǒng)的資源監(jiān)控模塊對(duì)于心跳信息的處理效率提高，因此可以響應(yīng)更多的心跳，其模擬節(jié)點(diǎn)不會(huì)出現(xiàn)長(zhǎng)時(shí)間等待心跳回復(fù)事件，相比之下CPU平均使用率較高，但當(dāng)節(jié)點(diǎn)數(shù)量超過8 000后其處理能力達(dá)到瓶頸.

Fig. 8 CPU average usage under different cluster sizes圖8 不同集群規(guī)模下CPU平均使用率對(duì)比圖

3.4 節(jié)點(diǎn)宕機(jī)情況匯報(bào)性能測(cè)試

為了驗(yàn)證改進(jìn)后資源管理系統(tǒng)對(duì)于節(jié)點(diǎn)宕機(jī)情況的處理性能，本文在節(jié)點(diǎn)模擬過程中增加基于環(huán)形監(jiān)視的節(jié)點(diǎn)狀態(tài)監(jiān)控功能.對(duì)于節(jié)點(diǎn)自身以及其后繼節(jié)點(diǎn)在同一臺(tái)物理機(jī)器的場(chǎng)合，則直接調(diào)用函數(shù)來更新狀態(tài)事件；對(duì)于節(jié)點(diǎn)自身與后繼節(jié)點(diǎn)不在同一臺(tái)物理機(jī)器的場(chǎng)合，則需要與另一臺(tái)機(jī)器建立通信連接，然后進(jìn)行狀態(tài)事件的發(fā)送與更新.圖9給出宕機(jī)時(shí)的測(cè)試結(jié)果.測(cè)試過程中，模擬節(jié)點(diǎn)數(shù)量為7 500個(gè)，從整個(gè)模擬集群節(jié)中隨機(jī)選擇5%的模擬節(jié)點(diǎn)，在運(yùn)行了400 s后停止匯報(bào)心跳功能，同時(shí)停止向監(jiān)控節(jié)點(diǎn)匯報(bào)自己的生存狀態(tài)，用來模擬節(jié)點(diǎn)宕機(jī)情況.在該運(yùn)行過程中，通過Metric性能統(tǒng)計(jì)工具，記錄了節(jié)點(diǎn)移除事件.

Fig.9 Comparison of the numbers of removed nodes圖9 節(jié)點(diǎn)移除數(shù)量對(duì)比

從圖9結(jié)果可以看出，對(duì)于Hadoop-2.10.0與Hadoop-3.1.0版本的YARN系統(tǒng)，發(fā)現(xiàn)大量的額外節(jié)點(diǎn)被移除.分析原因后發(fā)現(xiàn)，由于節(jié)點(diǎn)存活檢測(cè)時(shí)間設(shè)置過小，隨著在后續(xù)過程中心跳信息帶來的負(fù)載量增大，心跳信息處理的延時(shí)增加，導(dǎo)致越來越多的節(jié)點(diǎn)被誤認(rèn)為宕機(jī)狀態(tài)而被移除.由于大量的節(jié)點(diǎn)被移除，使得調(diào)度器需要對(duì)該部分資源回收，同時(shí)對(duì)移除節(jié)點(diǎn)上的任務(wù)需要重新分配資源，進(jìn)一步加大了調(diào)度器負(fù)載，使得任務(wù)的運(yùn)行被延遲.然而設(shè)置時(shí)間間隔太大，其宕機(jī)監(jiān)控效果將會(huì)不敏感.

對(duì)于改進(jìn)后的YARN系統(tǒng)，集群計(jì)算節(jié)點(diǎn)的存活狀態(tài)監(jiān)控由計(jì)算節(jié)點(diǎn)來實(shí)施，每個(gè)節(jié)點(diǎn)只監(jiān)控它的前驅(qū)節(jié)點(diǎn)，只有當(dāng)計(jì)算節(jié)點(diǎn)向資源監(jiān)控服務(wù)匯報(bào)某個(gè)節(jié)點(diǎn)宕機(jī)時(shí)，資源監(jiān)控服務(wù)才會(huì)將相應(yīng)節(jié)點(diǎn)移除，并通知調(diào)度器進(jìn)行資源的更新與任務(wù)的回收，因此上述情況不存在.同時(shí)，由于計(jì)算節(jié)點(diǎn)提前對(duì)心跳數(shù)據(jù)過濾，只有計(jì)算節(jié)點(diǎn)真正出現(xiàn)宕機(jī)時(shí)，才向資源監(jiān)控服務(wù)匯報(bào)，從而減少了資源監(jiān)控服務(wù)處理消息的數(shù)量，使得集群管理器的資源監(jiān)控服務(wù)負(fù)荷降低.因此，改進(jìn)后的YARN能夠改善集群系統(tǒng)的可擴(kuò)展性.

4 總 結(jié)

資源管理系統(tǒng)處理心跳信息的效率影響系統(tǒng)的可擴(kuò)展性，因此提高系統(tǒng)運(yùn)行效率，加快資源狀態(tài)視圖的更新，可以緩解調(diào)度器不能及時(shí)處理更新事件而導(dǎo)致的延遲等問題.通過資源管理器的資源監(jiān)控服務(wù)功能的分解，將心跳信息的過濾功能轉(zhuǎn)移到計(jì)算節(jié)點(diǎn)的方式，改變嚴(yán)格的周期性心跳匯報(bào)機(jī)制，最終減輕資源管理器的負(fù)載壓力，提高了集中式資源管理系統(tǒng)的可擴(kuò)展性.事實(shí)上，集中式的心跳處理依舊會(huì)成為瓶頸.隨著集群規(guī)模的擴(kuò)展和狀態(tài)的規(guī)模進(jìn)一步擴(kuò)大，集群的資源狀態(tài)的存儲(chǔ)必須使用分布式數(shù)據(jù)儲(chǔ)存機(jī)制來保證可用性和低延遲.