摘  要： 分析了己有的調(diào)度機制和常用的任務(wù)調(diào)度算法，并在此基礎(chǔ)上設(shè)計了資源評價模型。將資源評價模型加入調(diào)度系統(tǒng)中，資源信息由評價模塊進行分析和評價，并提供給任務(wù)調(diào)度器，實現(xiàn)資源和任務(wù)的優(yōu)化匹配，提高了服務(wù)質(zhì)量（QoS）。
關(guān)鍵詞： 云計算；資源評價；模型

　近幾年來，隨著云計算技術(shù)的廣泛應(yīng)用以及電子商務(wù)、網(wǎng)絡(luò)社區(qū)、搜索服務(wù)等互聯(lián)網(wǎng)應(yīng)用的快速發(fā)展，人們對網(wǎng)絡(luò)服務(wù)和計算服務(wù)的需求迅速增加，對服務(wù)質(zhì)量的要求也在不斷提高。在傳統(tǒng)的商業(yè)模式下，用戶為了獲取某項服務(wù)，需要不斷升級硬件設(shè)備，本地安裝軟件、配置程序等。而如今，云計算作為一種新的計算模式，使得用戶可以通過任何電子終端或網(wǎng)絡(luò)瀏覽器，隨時隨地按照需要獲取服務(wù)，而不必考慮基礎(chǔ)設(shè)施的架構(gòu)、維護以及服務(wù)的實現(xiàn)細節(jié)等。云計算正逐漸被商品化，人們付出一定的費用來獲取所需的服務(wù)[1]，與水、電、煤氣及電話服務(wù)等類似。由于這種商業(yè)特性，用戶服務(wù)質(zhì)量的保障受到各大云服務(wù)提供商的重視，因而任務(wù)調(diào)度與資源分配問題也顯得格外重要。在己有的任務(wù)調(diào)度系統(tǒng)中，任務(wù)調(diào)度模塊與資源信息收集模塊往往緊密耦合，任務(wù)調(diào)度的選擇對象為所有節(jié)點的全部資源信息。任務(wù)調(diào)度器需要對收集到的所有節(jié)點的各類資源信息進行整理，并與任務(wù)進行匹配，以選擇最適宜的節(jié)點進行調(diào)度，對資源的評價功能多是集中在中心調(diào)度器中。在資源大規(guī)模性及動態(tài)性強的云計算環(huán)境下，這種機制給中心任務(wù)調(diào)度器帶來了很大的壓力，影響調(diào)度效率，并且對任務(wù)執(zhí)行效率、資源收費策略及系統(tǒng)利用率等缺乏綜合考慮。
針對上述特點，作者設(shè)計了資源評價模型，并將資源評價模型加入到調(diào)度系統(tǒng)中，資源信息由評價模塊進行分析和評價，將評價結(jié)果提供給任務(wù)調(diào)度器，實現(xiàn)資源和任務(wù)的優(yōu)化匹配，提高了服務(wù)質(zhì)量（QoS）。
1 模型體系結(jié)構(gòu)
　本模型基于Linux系統(tǒng)的分布式平臺上實現(xiàn)，采用無中心分布式管理模式，通過各節(jié)點的相互監(jiān)控實現(xiàn)服務(wù)和節(jié)點故障的檢測，并通過協(xié)商進行故障服務(wù)的接管。本模型設(shè)計結(jié)合資源評價的分布式調(diào)度模型，不存在中心評價與調(diào)度節(jié)點，各節(jié)點的地位作用是對等的，節(jié)點間需相互協(xié)商以完成資源評價與任務(wù)調(diào)度。每個節(jié)點都針對任務(wù)信息進行本地資源評價，并與其他候選調(diào)度節(jié)點進行比較及綜合評價，找到最優(yōu)節(jié)點，以決定是否將任務(wù)由本節(jié)點執(zhí)行。
　模型體系結(jié)構(gòu)如圖1所示，具體描述如下：
?。?）節(jié)點首先發(fā)現(xiàn)任務(wù)，作為任務(wù)源節(jié)點，將任務(wù)信息以廣播的形式發(fā)布在組群中，發(fā)起協(xié)商。
?。?）組群內(nèi)所有節(jié)點收到協(xié)商邀請，收集本地資源信息，針對任務(wù)需求進行本地資源評價，從而獲得任務(wù)分配到該節(jié)點的性能評估值，并將本地評估值在組群內(nèi)廣播。
?。?）各參與協(xié)商節(jié)點收集其他參與節(jié)點的本地評價信息，并根據(jù)任務(wù)調(diào)度目標，對包括本節(jié)點在內(nèi)的所有候選調(diào)度節(jié)點進行綜合評價，選出評估值最優(yōu)的節(jié)點；若最優(yōu)節(jié)點為本節(jié)點，則將任務(wù)在本地執(zhí)行，否則，放棄本次協(xié)商。

2 模型功能與模塊劃分
2.1 系統(tǒng)功能模塊
　本實驗室已有的基于Linux的分布式平臺，主要提供容錯及故障接管功能，通過核心態(tài)心跳檢測機制進行節(jié)點間的監(jiān)控，接管故障節(jié)點，重啟失效任務(wù)，如圖2所示。資源監(jiān)控模塊負責對系統(tǒng)計算資源、存儲資源、網(wǎng)絡(luò)資源以及負載信息的收集；任務(wù)監(jiān)控模塊負責對任務(wù)的監(jiān)控，以及對新任務(wù)的獲??；心跳檢測模塊是系統(tǒng)進行故障監(jiān)測的核心模塊，它實現(xiàn)在系統(tǒng)核心態(tài)，通過定時發(fā)布心跳信息進行節(jié)點間的相互監(jiān)控；用戶模塊接收用戶輸入?yún)?shù)，以及向用戶顯示系統(tǒng)狀態(tài)等；中心控制模塊是系統(tǒng)的核心模塊，負責系統(tǒng)各模塊間的消息傳遞，根據(jù)資源信息、任務(wù)信息、用戶信息以及故障信息進行任務(wù)調(diào)度和故障接管等。

　本文重點描述資源評價模型（即處于中心控制模塊中），結(jié)合任務(wù)信息、資源信息及節(jié)點故障信息對各節(jié)點執(zhí)行任務(wù)的適宜程度進行評估，將評估結(jié)果提供給任務(wù)調(diào)度子模塊，作為任務(wù)調(diào)度的依據(jù)。
2.2 評價模塊及消息流程
　本模型是針對任務(wù)調(diào)度的資源評價模型，其核心功能是資源評價，包括本地評價和綜合評價。根據(jù)功能對資源評價模塊進行劃分，如圖3所示。

　系統(tǒng)采用分布式架構(gòu)，每個節(jié)點都包含相同的模塊，采用消息驅(qū)動機制。消息包括4種：（1）MSG_TASK表示新任務(wù)消息；（2）MSG_HELP表示失效任務(wù)接管信息；（3）MSG_ASSESS表示本地評價信息；（4）MSG_FITNESS表示最終評價結(jié)果。
　根據(jù)消息類型及其攜帶的不同參數(shù)，確定消息的處理方式。消息傳遞流程如圖4所示。任務(wù)信息由心跳檢測模塊通過MSG_HELP消息或任務(wù)監(jiān)控模塊通過MSG_TASK消息發(fā)布，分別表示失效任務(wù)接管和新任務(wù)調(diào)度。消息形式為（task_id，task_infor），表示任務(wù)標識號和任務(wù)信息。評價模塊收到任務(wù)信息，設(shè)置該task_id的ITIMER_REAL定時器；本地評價模塊執(zhí)行Self_assess（），并將評價信息通過消息MSG_ASSESS（task_id，node_id，assessment）發(fā)送；綜合評價模塊處理接收到的所有節(jié)點的MSG_ASSESS消息，將該評價信息加入到候選節(jié)點列表candidate_list中；在定時器到了指定時間后執(zhí)行Final_ssess（），對包括本節(jié)點在內(nèi)的所有節(jié)點進行綜合評價；并發(fā)送最終評價結(jié)果MSG_RESULT（tasKid，result），同時忽略此后收到的該task_id的MSG_ASSESS。主要結(jié)構(gòu)如下。
　receive（message）；
　switch（message.msg--type）
　{  //根據(jù)消息類型判斷
　Ease MSG_TASK：
　Ease MSG_HELP：
　Sef_assess（）；  //本地評價
　Send_assess（）；  //發(fā)送本地評價信息
　Case MSG_ASSESS：
　Addto_candidate_list（）；  //將節(jié)點加入候選節(jié)點列表
　Final_assess（）；  //綜合評價
　Send_result（）；  //發(fā)送最終評價結(jié)果
　Case MSG_RESULT：
　sched_task（）； //調(diào)度模塊根據(jù)評價結(jié)果執(zhí)行任務(wù)調(diào)度
　}

2.3 任務(wù)信息參數(shù)化
　該子模塊負責把任務(wù)信息進行抽象，得到評價所需的參數(shù)化任務(wù)描述，需輸出的信息包括任務(wù)的客觀屬性和用戶的QoS需求。對于任務(wù)客觀屬性信息，可通過任務(wù)長度、數(shù)據(jù)文件大小等抽象出任務(wù)對各類資源的需求量Rq以及限制條件。
　任務(wù)主觀描述信息建立在對用戶QoS需求的分析上，而用戶往往只能提供定性的需求信息，模型無法將其作為參數(shù)直接使用。然而要求用戶提供定量的QoS描述不適合云計算這種面向服務(wù)的商業(yè)計算模式。因此，本模型需要考慮將QoS參數(shù)由定性轉(zhuǎn)化為定量描述，本文運用云理論模型[2-3]將用戶QoS描述參數(shù)化，作為評價模型輸入的定量值。
2.4 資源信息參數(shù)化
　資源信息參數(shù)化主要對本節(jié)點資源的屬性信息進行抽象和整理。資源信息由資源監(jiān)控模塊提供，包括所有與任務(wù)執(zhí)行性能、時間及費用等相關(guān)的因素，可分為靜態(tài)屬性和動態(tài)屬性信息。資源的靜態(tài)信息指節(jié)點的硬件信息，如計算速度、內(nèi)存大小、數(shù)據(jù)存儲容量及網(wǎng)絡(luò)帶寬等。資源動態(tài)信息需要定時收集，其中包括CPU隊列長度、內(nèi)存使用率、硬盤利用率、網(wǎng)絡(luò)負載及延遲等。
　本實驗室對資源動態(tài)監(jiān)控方面的研究主要實現(xiàn)在基于Linux系統(tǒng)的平臺上，使用shell命令虛擬內(nèi)存統(tǒng)計（vmstat）可以對系統(tǒng)的CPU利用率、虛擬內(nèi)存使用情況及進程進行監(jiān)視，統(tǒng)計系統(tǒng)的整體使用情況；此外，使用iostat命令還可以監(jiān)視磁盤及I/O使用情況。資源的整體狀態(tài)是動態(tài)變化的，上述信息需定時統(tǒng)計，為資源的分析評價提供依據(jù)。將收集到的資源信息保存在文件nodeinfor.txt中，并定時更新。
針對本文分布式環(huán)境的特點，采用招投標模型的方法進行價格制定和服務(wù)協(xié)商。任務(wù)源節(jié)點首先發(fā)布招標信息；資源提供者通過對本地資源的評估，提供資源信息和報價，進行投標；使用者根據(jù)一定的評價策略選擇最適合的資源。
2.5 故障率檢測
　系統(tǒng)采用心跳機制實現(xiàn)節(jié)點間相互監(jiān)控，通過定時發(fā)送心跳消息檢測其他節(jié)點的狀態(tài)，記錄各節(jié)點的故障信息，從而得到各節(jié)點的故障率。本實驗室在心跳機制方面己進行了相關(guān)研究，為提高心跳檢測的實時性，一方面，減少心跳包發(fā)送的延遲，將心跳協(xié)議實現(xiàn)在Linux系統(tǒng)內(nèi)核態(tài)，使得心跳包的發(fā)送不受系統(tǒng)協(xié)議棧和應(yīng)用層任務(wù)切換的影響[4-5]；另一方面，減少心跳包傳輸?shù)难舆t，設(shè)計并實現(xiàn)了基于實時以太網(wǎng)的心跳協(xié)議，通過硬實時通信協(xié)議TTEP（Time-Triggered Ethernet Protocol）來保證心跳協(xié)議數(shù)據(jù)包傳輸?shù)膶崟r性，避免了以太網(wǎng)中數(shù)據(jù)包擁塞導(dǎo)致的心跳包傳輸延遲，提高檢測的準確率[6]。
2.6 本地評價與綜合評價
　本地評價和綜合評價是資源評價模塊的核心。本地評價模塊負責處理MSG_HELP以及MSG_TASK消息，形式為（task_id，task_infor），并執(zhí)行self_assess（）。結(jié)合參數(shù)化的資源信息及task_infor計算本地評價值，將消息MSG_ASSESS（task_id，node_id，assessment）進行廣播。
　消息MSG_ASSESS由綜合評價模塊處理，將該節(jié)點及其評價信息加入候選節(jié)點列表candidate_list中，數(shù)據(jù)結(jié)構(gòu)為：
struct candidate_list{
int task_id；  //任務(wù)標識
struct assess_node list[MAXNODENUM]；
//參與評價的節(jié)點列表
}
struct assess_node{  //參與評價的節(jié)點信息
int node_id；  //節(jié)點標識
double load；  //節(jié)點負載
double exe_time；  //節(jié)點估計完成時間
double cost；   //所需費用
double stability；   //節(jié)點可靠性
}
　為了保證及時評價和調(diào)度，責任節(jié)點在發(fā)布任務(wù)信息時設(shè)置定時器，給定一個時間間隔。該計數(shù)隨著實際時間而減少，當時間間隔減為0時，綜合評價器執(zhí)行final_assess（），對候選節(jié)點列表中的節(jié)點進行綜合評價。本模型采用ITIMER_REAL定時器，如下所示：
void init_time（）{  //定時器初始化
struct itimerval value；
value.it_value.tv_sec=1；  //設(shè)定執(zhí)行任務(wù)的時間間隔
value.it_value.tv_usec=0；
value.it_interval=value.it_value；  //設(shè)定初始時間計數(shù)
setitimer（ITIMER_REAL，&value，NULL）；  
//設(shè)置計時器ITIMER_REAL
}
void init_sigaction（void）{  //建立信號處理機制
struct sigaction tact；
tact.sa_handler=final_assess；  
//收到信號后執(zhí)行綜合評價函數(shù)
tact.sa_flags=0；
sigemptyset（&tact.sa_mask）；  //初始化信號集
sigaction（SIGALRM，&tact，NULL）；
//建立信號處理機制
}
　在發(fā)布任務(wù)信息時調(diào)用ini_time（）函數(shù)將定時器初始化，規(guī)定時間間隔后定時器發(fā)送SIGALRM信號，綜合評價函數(shù)final_assess（）被觸發(fā)執(zhí)行。
　本文對資源評價模型的體系結(jié)構(gòu)進行了詳細描述，并介紹了其中的功能和模塊劃分，以及對每個模塊中所采用的關(guān)鍵問題和技術(shù)進行了描述并給出了解決辦法。資源評價模型主要用于對獨立任務(wù)的調(diào)度，尚存在一些不足和需要改進地方，在以后的研究中將作進一步探討并改進。
參考文獻
[1] RAJKUMAR B， CHEE S Y， VENUGOPALA S， et al.Cloud computing and emerging IT platforms： vision， hype，and reality for delivering computing as the 5th utility[J].Future Generation Computer Systems，2009，25（6）：599-616.
[2] 尹國定，衛(wèi)紅.云計算-實現(xiàn)概念計算的方法[J].東南大學(xué)學(xué)報，2003，33（4）：502-506.
[3] 胡亮，胡德斌，孫葉萌，等.計算網(wǎng)格中經(jīng)濟模型的應(yīng)用策略[J].吉林大學(xué)學(xué)報，2009，47（2）：306-311.
[4] Wang Zhanjie， Li Xiao. A new real-time heartbeat failure detector[C]. 4th International Conference on Wireless Communications， Networking and Mobile Computing， 2008：1-3.
[5] Wang Zhanjie， He Kai， Wang Hailong. A safety-critical peal-time network protocol[C]. 2008 IEEE International Conference on Granular Computing，2008：312-315.
[6] Wang Zhanjie， Chen Wen， Wang Hailong. Improvement on real-time capability of heartbeat mechanism[C]. International Conference on Advanced Measurement and Test， 2010：938-942.