摘 要: 分析了己有的調度機制和常用的任務調度算法,并在此基礎上設計了資源評價模型,。將資源評價模型加入調度系統(tǒng)中,,資源信息由評價模塊進行分析和評價,,并提供給任務調度器,,實現資源和任務的優(yōu)化匹配,提高了服務質量(QoS),。
關鍵詞: 云計算,;資源評價;模型
近幾年來,,隨著云計算技術的廣泛應用以及電子商務,、網絡社區(qū)、搜索服務等互聯(lián)網應用的快速發(fā)展,,人們對網絡服務和計算服務的需求迅速增加,,對服務質量的要求也在不斷提高,。在傳統(tǒng)的商業(yè)模式下,用戶為了獲取某項服務,,需要不斷升級硬件設備,,本地安裝軟件、配置程序等,。而如今,,云計算作為一種新的計算模式,使得用戶可以通過任何電子終端或網絡瀏覽器,,隨時隨地按照需要獲取服務,,而不必考慮基礎設施的架構、維護以及服務的實現細節(jié)等,。云計算正逐漸被商品化,,人們付出一定的費用來獲取所需的服務[1],與水,、電,、煤氣及電話服務等類似。由于這種商業(yè)特性,,用戶服務質量的保障受到各大云服務提供商的重視,,因而任務調度與資源分配問題也顯得格外重要。在己有的任務調度系統(tǒng)中,,任務調度模塊與資源信息收集模塊往往緊密耦合,,任務調度的選擇對象為所有節(jié)點的全部資源信息。任務調度器需要對收集到的所有節(jié)點的各類資源信息進行整理,,并與任務進行匹配,,以選擇最適宜的節(jié)點進行調度,對資源的評價功能多是集中在中心調度器中,。在資源大規(guī)模性及動態(tài)性強的云計算環(huán)境下,,這種機制給中心任務調度器帶來了很大的壓力,影響調度效率,,并且對任務執(zhí)行效率,、資源收費策略及系統(tǒng)利用率等缺乏綜合考慮。
針對上述特點,,作者設計了資源評價模型,,并將資源評價模型加入到調度系統(tǒng)中,資源信息由評價模塊進行分析和評價,,將評價結果提供給任務調度器,,實現資源和任務的優(yōu)化匹配,提高了服務質量(QoS),。
1 模型體系結構
本模型基于Linux系統(tǒng)的分布式平臺上實現,,采用無中心分布式管理模式,,通過各節(jié)點的相互監(jiān)控實現服務和節(jié)點故障的檢測,并通過協(xié)商進行故障服務的接管,。本模型設計結合資源評價的分布式調度模型,,不存在中心評價與調度節(jié)點,各節(jié)點的地位作用是對等的,,節(jié)點間需相互協(xié)商以完成資源評價與任務調度,。每個節(jié)點都針對任務信息進行本地資源評價,并與其他候選調度節(jié)點進行比較及綜合評價,,找到最優(yōu)節(jié)點,,以決定是否將任務由本節(jié)點執(zhí)行。
模型體系結構如圖1所示,,具體描述如下:
?。?)節(jié)點首先發(fā)現任務,作為任務源節(jié)點,,將任務信息以廣播的形式發(fā)布在組群中,,發(fā)起協(xié)商。
?。?)組群內所有節(jié)點收到協(xié)商邀請,,收集本地資源信息,針對任務需求進行本地資源評價,,從而獲得任務分配到該節(jié)點的性能評估值,,并將本地評估值在組群內廣播。
?。?)各參與協(xié)商節(jié)點收集其他參與節(jié)點的本地評價信息,,并根據任務調度目標,對包括本節(jié)點在內的所有候選調度節(jié)點進行綜合評價,,選出評估值最優(yōu)的節(jié)點,;若最優(yōu)節(jié)點為本節(jié)點,則將任務在本地執(zhí)行,,否則,,放棄本次協(xié)商。
2 模型功能與模塊劃分
2.1 系統(tǒng)功能模塊
本實驗室已有的基于Linux的分布式平臺,,主要提供容錯及故障接管功能,,通過核心態(tài)心跳檢測機制進行節(jié)點間的監(jiān)控,,接管故障節(jié)點,,重啟失效任務,如圖2所示,。資源監(jiān)控模塊負責對系統(tǒng)計算資源,、存儲資源,、網絡資源以及負載信息的收集;任務監(jiān)控模塊負責對任務的監(jiān)控,,以及對新任務的獲?。恍奶鴻z測模塊是系統(tǒng)進行故障監(jiān)測的核心模塊,,它實現在系統(tǒng)核心態(tài),,通過定時發(fā)布心跳信息進行節(jié)點間的相互監(jiān)控;用戶模塊接收用戶輸入參數,,以及向用戶顯示系統(tǒng)狀態(tài)等,;中心控制模塊是系統(tǒng)的核心模塊,負責系統(tǒng)各模塊間的消息傳遞,,根據資源信息,、任務信息、用戶信息以及故障信息進行任務調度和故障接管等,。
本文重點描述資源評價模型(即處于中心控制模塊中),,結合任務信息、資源信息及節(jié)點故障信息對各節(jié)點執(zhí)行任務的適宜程度進行評估,,將評估結果提供給任務調度子模塊,,作為任務調度的依據。
2.2 評價模塊及消息流程
本模型是針對任務調度的資源評價模型,,其核心功能是資源評價,,包括本地評價和綜合評價。根據功能對資源評價模塊進行劃分,,如圖3所示,。
系統(tǒng)采用分布式架構,每個節(jié)點都包含相同的模塊,,采用消息驅動機制,。消息包括4種:(1)MSG_TASK表示新任務消息;(2)MSG_HELP表示失效任務接管信息,;(3)MSG_ASSESS表示本地評價信息,;(4)MSG_FITNESS表示最終評價結果。
根據消息類型及其攜帶的不同參數,,確定消息的處理方式,。消息傳遞流程如圖4所示。任務信息由心跳檢測模塊通過MSG_HELP消息或任務監(jiān)控模塊通過MSG_TASK消息發(fā)布,,分別表示失效任務接管和新任務調度,。消息形式為(task_id,task_infor),表示任務標識號和任務信息,。評價模塊收到任務信息,,設置該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é)點在內的所有節(jié)點進行綜合評價,;并發(fā)送最終評價結果MSG_RESULT(tasKid,result),,同時忽略此后收到的該task_id的MSG_ASSESS,。主要結構如下。
receive(message),;
switch(message.msg--type)
{ //根據消息類型判斷
Ease MSG_TASK:
Ease MSG_HELP:
Sef_assess(),; //本地評價
Send_assess(); //發(fā)送本地評價信息
Case MSG_ASSESS:
Addto_candidate_list(),; //將節(jié)點加入候選節(jié)點列表
Final_assess(),; //綜合評價
Send_result(); //發(fā)送最終評價結果
Case MSG_RESULT:
sched_task(),; //調度模塊根據評價結果執(zhí)行任務調度
}
2.3 任務信息參數化
該子模塊負責把任務信息進行抽象,,得到評價所需的參數化任務描述,需輸出的信息包括任務的客觀屬性和用戶的QoS需求,。對于任務客觀屬性信息,,可通過任務長度、數據文件大小等抽象出任務對各類資源的需求量Rq以及限制條件,。
任務主觀描述信息建立在對用戶QoS需求的分析上,,而用戶往往只能提供定性的需求信息,模型無法將其作為參數直接使用,。然而要求用戶提供定量的QoS描述不適合云計算這種面向服務的商業(yè)計算模式,。因此,本模型需要考慮將QoS參數由定性轉化為定量描述,,本文運用云理論模型[2-3]將用戶QoS描述參數化,,作為評價模型輸入的定量值。
2.4 資源信息參數化
資源信息參數化主要對本節(jié)點資源的屬性信息進行抽象和整理,。資源信息由資源監(jiān)控模塊提供,,包括所有與任務執(zhí)行性能、時間及費用等相關的因素,可分為靜態(tài)屬性和動態(tài)屬性信息,。資源的靜態(tài)信息指節(jié)點的硬件信息,,如計算速度,、內存大小,、數據存儲容量及網絡帶寬等。資源動態(tài)信息需要定時收集,,其中包括CPU隊列長度,、內存使用率、硬盤利用率,、網絡負載及延遲等,。
本實驗室對資源動態(tài)監(jiān)控方面的研究主要實現在基于Linux系統(tǒng)的平臺上,使用shell命令虛擬內存統(tǒng)計(vmstat)可以對系統(tǒng)的CPU利用率,、虛擬內存使用情況及進程進行監(jiān)視,,統(tǒng)計系統(tǒng)的整體使用情況;此外,,使用iostat命令還可以監(jiān)視磁盤及I/O使用情況,。資源的整體狀態(tài)是動態(tài)變化的,上述信息需定時統(tǒng)計,,為資源的分析評價提供依據,。將收集到的資源信息保存在文件nodeinfor.txt中,并定時更新,。
針對本文分布式環(huán)境的特點,,采用招投標模型的方法進行價格制定和服務協(xié)商。任務源節(jié)點首先發(fā)布招標信息,;資源提供者通過對本地資源的評估,,提供資源信息和報價,進行投標,;使用者根據一定的評價策略選擇最適合的資源,。
2.5 故障率檢測
系統(tǒng)采用心跳機制實現節(jié)點間相互監(jiān)控,通過定時發(fā)送心跳消息檢測其他節(jié)點的狀態(tài),,記錄各節(jié)點的故障信息,,從而得到各節(jié)點的故障率。本實驗室在心跳機制方面己進行了相關研究,,為提高心跳檢測的實時性,,一方面,減少心跳包發(fā)送的延遲,,將心跳協(xié)議實現在Linux系統(tǒng)內核態(tài),,使得心跳包的發(fā)送不受系統(tǒng)協(xié)議棧和應用層任務切換的影響[4-5];另一方面,減少心跳包傳輸的延遲,,設計并實現了基于實時以太網的心跳協(xié)議,,通過硬實時通信協(xié)議TTEP(Time-Triggered Ethernet Protocol)來保證心跳協(xié)議數據包傳輸的實時性,避免了以太網中數據包擁塞導致的心跳包傳輸延遲,,提高檢測的準確率[6],。
2.6 本地評價與綜合評價
本地評價和綜合評價是資源評價模塊的核心。本地評價模塊負責處理MSG_HELP以及MSG_TASK消息,,形式為(task_id,,task_infor),并執(zhí)行self_assess(),。結合參數化的資源信息及task_infor計算本地評價值,,將消息MSG_ASSESS(task_id,node_id,,assessment)進行廣播,。
消息MSG_ASSESS由綜合評價模塊處理,將該節(jié)點及其評價信息加入候選節(jié)點列表candidate_list中,,數據結構為:
struct candidate_list{
int task_id,; //任務標識
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é)點可靠性
}
為了保證及時評價和調度,責任節(jié)點在發(fā)布任務信息時設置定時器,,給定一個時間間隔,。該計數隨著實際時間而減少,當時間間隔減為0時,,綜合評價器執(zhí)行final_assess(),,對候選節(jié)點列表中的節(jié)點進行綜合評價。本模型采用ITIMER_REAL定時器,,如下所示:
void init_time(){ //定時器初始化
struct itimerval value,;
value.it_value.tv_sec=1; //設定執(zhí)行任務的時間間隔
value.it_value.tv_usec=0,;
value.it_interval=value.it_value,; //設定初始時間計數
setitimer(ITIMER_REAL,&value,,NULL),;
//設置計時器ITIMER_REAL
}
void init_sigaction(void){ //建立信號處理機制
struct sigaction tact,;
tact.sa_handler=final_assess;
//收到信號后執(zhí)行綜合評價函數
tact.sa_flags=0,;
sigemptyset(&tact.sa_mask),; //初始化信號集
sigaction(SIGALRM,&tact,,NULL),;
//建立信號處理機制
}
在發(fā)布任務信息時調用ini_time()函數將定時器初始化,規(guī)定時間間隔后定時器發(fā)送SIGALRM信號,,綜合評價函數final_assess()被觸發(fā)執(zhí)行,。
本文對資源評價模型的體系結構進行了詳細描述,,并介紹了其中的功能和模塊劃分,,以及對每個模塊中所采用的關鍵問題和技術進行了描述并給出了解決辦法。資源評價模型主要用于對獨立任務的調度,,尚存在一些不足和需要改進地方,,在以后的研究中將作進一步探討并改進。
參考文獻
[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)紅.云計算-實現概念計算的方法[J].東南大學學報,2003,,33(4):502-506.
[3] 胡亮,,胡德斌,孫葉萌,,等.計算網格中經濟模型的應用策略[J].吉林大學學報,,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.