網(wǎng)格協(xié)同設計環(huán)境中的任務(wù)調度機制
協(xié)同設計(Collaborative Design)是指在計算機的支持下,各成員圍繞一個(gè)設計對象,各自承擔相應部分的設計任務(wù),并行交互地進(jìn)行設計工作,最終得到符合要求的設計結果的設計[1]。網(wǎng)格的出現為協(xié)同設計帶來(lái)了嶄新的解決思路。借助于網(wǎng)格研究的基礎設施以及Globus聯(lián)盟推出的網(wǎng)格既定標準GT3(Globus Toolkit 3),可以為制造業(yè)網(wǎng)絡(luò )設計提供極為方便的底層支撐,為快速建立一個(gè)健壯的設計平臺提供保證,GMCD[4]就是這樣一個(gè)設計平臺。本文將首先分析網(wǎng)格環(huán)境中任務(wù)調度的模型,然后基于協(xié)同設計環(huán)境的特殊性,以GMCD為框架,建立一種實(shí)用的任務(wù)調度模型。
1 網(wǎng)格任務(wù)調度模型
網(wǎng)格環(huán)境中資源管理結構模型有分層模型、抽象所有者模型、計算市場(chǎng)(經(jīng)濟)模型和混合模型。GMCD框架是以Globus為基礎的,而Globus的資源管理結構模型則是層次的。因此,本節著(zhù)重討論分層模型中的網(wǎng)格調度。
1.1 網(wǎng)格任務(wù)調度的相關(guān)組件及功能
在分層的資源管理結構模型中,資源管理與調度是多級的,每個(gè)資源有自己的調度子系統,用戶(hù)只需把作業(yè)提交給資源請求代理,而代理后有多少資源提供者,以及該作業(yè)分配哪個(gè)資源,對于用戶(hù)來(lái)說(shuō)都是透明的。資源提供者可以是單個(gè)PC機,可以是單個(gè)集群或多個(gè)集群,也可以是某個(gè)組織的一個(gè)中小型局域網(wǎng)。它們都有一個(gè)共同點(diǎn),即都有一個(gè)管理者——局部資源管理器。單個(gè)PC機本身就是一個(gè)管理者;而集群和局域網(wǎng),一般都有一臺服務(wù)器專(zhuān)職管理集群/局域網(wǎng)中的各結點(diǎn)。用戶(hù)作業(yè)在資源請求代理上進(jìn)行一級調度,在局部資源管理器上進(jìn)行二級調度,如果下面存在更多的集群或局域網(wǎng),則存在三級、四級等多級調度。
在網(wǎng)格任務(wù)調度中有兩個(gè)非常重要的組件,分別是資源請求代理和資源管理器,它們在任務(wù)調度過(guò)程中分別進(jìn)行一級和二級(多級)調度。其他與任務(wù)調度有關(guān)的組件還有網(wǎng)格工作站點(diǎn)以及負責聯(lián)系的組件[3]:
(1)資源請求代理
它是整個(gè)網(wǎng)格的資源管理者,負責接收用戶(hù)任務(wù),根據其特點(diǎn)發(fā)送給域資源管理器,動(dòng)態(tài)監視任務(wù)的運行情況,根據需要將結果提交給用戶(hù)或進(jìn)行再調度。主要功能有:
?、賹Ψ?wù)提供方提供注冊功能,并對其加入和退出等動(dòng)作進(jìn)行控制。
?、诮⒕W(wǎng)格資源信息庫并周期性地刷新,對全局資源進(jìn)行統一管理和分配。
?、劢邮沼脩?hù)提交的作業(yè),并根據作業(yè)類(lèi)型和要求(如資源的類(lèi)型和數量等)形成作業(yè)調度參數。
?、芨鶕鳂I(yè)調度參數調度作業(yè),分派資源,并隨時(shí)監視作業(yè)的執行情況。
?、萑糇鳂I(yè)執行有誤,則對其進(jìn)行再調度,保證用戶(hù)作業(yè)的安全運行。
(2)域資源管理器
它是域內資源管理和動(dòng)態(tài)調度的中心,負責本域工作的創(chuàng )建、屬性的收集、接收從資源請求代理提交的任務(wù)并根據其特點(diǎn)進(jìn)行處理機的分配。主要功能有:
?、俦O聽(tīng)從本域結點(diǎn)發(fā)送來(lái)的信息,建立域成員信息資料庫并周期性刷新。
?、谥芷谛缘亟邮沼少Y源請求代理提交的作業(yè),并判斷其可行性,建立本域的任務(wù)隊列。
?、蹚娜蝿?wù)隊列中選取作業(yè),根據提交的參數和資源情況合理地分配作業(yè)。
?、軐⒆鳂I(yè)執行情況定時(shí)返回給資源請求代理,維持與上級數據庫的一致性。
?、荼O視各組員執行狀況,根據情況進(jìn)行作業(yè)調整(域內調整或再調度)。
?、薮_保用戶(hù)作業(yè)的安全運行,將結果通知資源請求代理并直接返還給用戶(hù)。
(3)網(wǎng)格工作結點(diǎn)
它是任務(wù)執行的基本單位,一旦申請加入資源提供方,便由域資源管理器直接調度和由資源請求代理間接調度。主要功能有:
?、傧蛏霞壒芾砥魈岢錾暾?,請求加入資源提供方。
?、谑占窘Y點(diǎn)的狀態(tài)和負載信息,并周期性地提交給域資源管理器。
?、郛a(chǎn)生服務(wù)進(jìn)程,隨時(shí)接收上級管理器提交的任務(wù)并執行。
(4)負責聯(lián)系的組件
鑒于各實(shí)體間的聯(lián)系比較多,可將其分為作業(yè)提交和資源匯報兩部分。
?、僮鳂I(yè)提交部分
用戶(hù)向資源請求代理提交作業(yè)任務(wù);資源請求代理根據用戶(hù)參數將作業(yè)轉交給域資源管理器;域資源管理器根據各結點(diǎn)負載情況分派作業(yè)給合適的資源工作結點(diǎn),任務(wù)執行完畢后保存作業(yè)結果;域資源管理器直接將結果返回給用戶(hù)。
?、谫Y源匯報部分
它完成如下任務(wù):網(wǎng)格工作結點(diǎn)向域資源管理器提供各結點(diǎn)的狀態(tài)和負載情況;域資源管理器將該域的負載信息匯總并送給資源請求代理供查詢(xún)和管理結點(diǎn);域資源管理器周期性地刷新資源請求代理中的作業(yè)狀態(tài);工作結點(diǎn)執行完畢。
1.2 網(wǎng)格任務(wù)調度的過(guò)程
用戶(hù)利用提交程序將作業(yè)任務(wù)和要求的環(huán)境屬性(如資源類(lèi)型和數量等)提交給資源請求代理,資源請求代理分析環(huán)境屬性形成參數文件,根據任務(wù)性質(zhì)、通信狀況和各資源負載情況進(jìn)行粗粒度調度,尋求最佳分配方案將作業(yè)及參數文件提交給選中的域資源管理器。當域資源管理器接收到新任務(wù)或調度周期到來(lái)時(shí),新任務(wù)被賦予任務(wù)優(yōu)先級插入作業(yè)隊列。守護進(jìn)程從結點(diǎn)機列表中獲取該域內所有資源負載情況,同時(shí)更新資源請求代理上全局數據庫中相關(guān)的信息表。確定已經(jīng)到達該域的任務(wù)的優(yōu)先級,每次選取一個(gè)任務(wù)分配合適的資源。相應地,守護進(jìn)程派生出相應的作業(yè)線(xiàn)程,周期性地監視該作業(yè)的執行狀態(tài),并向上一級(資源請求代理)匯報,以便進(jìn)行全局管理與調度(或用戶(hù)查詢(xún))。當任務(wù)途中異常中斷或執行性能比預期要差時(shí),資源請求代理可進(jìn)行再次調度,重新安排其他資源;而當任務(wù)完成時(shí),資源請求代理會(huì )要求域資源管理器直接將作業(yè)結果返還給用戶(hù)。
2 GMCD中的任務(wù)調度機制
由于網(wǎng)格協(xié)同設計環(huán)境的特殊性,網(wǎng)格協(xié)同設計環(huán)境中的任務(wù)調度模型和通用的網(wǎng)格調度模型相比也具有特殊性?,F以GMCD構架為例,討論網(wǎng)格協(xié)同設計中的任務(wù)調度機制。
GMCD系統體系結構由底而上可分為四層,即設計知識單元DKU(Design Knowledge Units)[4]、網(wǎng)格中間件、設計中間件和應用層,如圖1所示。
DKU及互聯(lián)網(wǎng)絡(luò )組成了GMCD的底層支持結構。DKU是Internet上的具有設計能力的組織或機構,它們在某一類(lèi)產(chǎn)品或零部件研發(fā)上具有先進(jìn)的設計技術(shù)和生產(chǎn)能力。在DKU內部存在設計知識數據庫、局域網(wǎng)和設計工具(集)。它們之間通過(guò)Internet或專(zhuān)用高速網(wǎng)連通。在設計過(guò)程中,各個(gè)DKU之間具有平等關(guān)系,各自負責所獲得任務(wù)的運行,相對來(lái)說(shuō)是獨立的。
用戶(hù)在應用層通過(guò)Portal將任務(wù)提交給設計中間件。設計中間件將由Portal提交的設計任務(wù)分解為可以被DKU執行的子任務(wù)。分解過(guò)程如下。
GMCD任務(wù)分解分為兩層。任務(wù)以XML(eXtensible Markup Language)文件形式被提交后,首先會(huì )由資源請求代理轉交給自稱(chēng)能完成該任務(wù)的域,然后在域控制管理器內被首次分解,分解的原則是可執行原則。對于已經(jīng)進(jìn)入域控制管理器的任務(wù),應用分解智能體根據知識庫內的知識,將其分解為可以被DKU執行的任務(wù)。知識庫內保留了該域內所有DKU的功能申明。域內任務(wù)分解(高層分解)的目標是把任務(wù)分解為可以被DKU執行的子任務(wù),低層任務(wù)分解在DKU內進(jìn)行,其目標是把子任務(wù)分解為可以被DKU中服務(wù)器執行的底層操作。由于設計工作的特殊性,DKU分布通常不均勻,能完成有關(guān)聯(lián)或相似性設計任務(wù)的DKU通常在一個(gè)或幾個(gè)域內。如果被提交的設計任務(wù)沒(méi)有合適的域可以執行,則還要在高層分解之前加入一層手工分解或由資源請求代理分解。也就是說(shuō),可以把任務(wù)返還給用戶(hù),由用戶(hù)根據一定的設計知識對設計任務(wù)實(shí)行手工分解,也可以由資源請求代理根據域的功能自述分解為可以被域執行的子任務(wù)。域資源管理器和DKU的關(guān)系如圖2所示。
子任務(wù)在DKU內被重新解析為可以被服務(wù)器執行的底層任務(wù),然后由DKU調度到各個(gè)服務(wù)器上去執行。
高層分解和低層分解在失敗時(shí)都回溯。
分解后的任務(wù)由域調度器調度到合適的DKU上去執行。GMCD的任務(wù)映射分為三個(gè)層次。資源請求代理保留了每個(gè)域的功能自述副本。任務(wù)通過(guò)Portal提交后,根據域的功能自述,被轉交給能完成該任務(wù)的域;然后在域內分解再由域調度器進(jìn)行二次映射,二次調度的目的是把分解后的子任務(wù)映射到合適的DKU上去;在DKU內的調度是第三次映射,這次調度的目的是把解析子任務(wù)后得到的底層任務(wù)映射到合適的服務(wù)器上去。本文所關(guān)注的是第二次調度,也就是分解以后的任務(wù)如何由域調度器調度到DKU上。在第二次調度中,由于設計任務(wù)的特殊性,一組相似或相關(guān)任務(wù)通常會(huì )在一個(gè)時(shí)間段內陸續到達。
3 資源預留的引入
資源預留是網(wǎng)格系統中一個(gè)十分必要的機制,因為資源預留可以保證任務(wù)在開(kāi)始執行時(shí)獲得必要的資源,從而提高網(wǎng)格系統的QoS。因此,資源預留的提出,從一開(kāi)始就得到了廣泛的認可,在目前網(wǎng)格系統的調度模塊中已經(jīng)被廣泛采用。在協(xié)同設計過(guò)程中,每個(gè)設計任務(wù),特別是其中某些大任務(wù)的執行直接影響設計任務(wù)完成的時(shí)間,在本文中引入了資源預留機制,以便為其中的大任務(wù)提供動(dòng)態(tài)預留資源[5],進(jìn)而提高協(xié)同設計的效率。
下面討論引入資源預留的網(wǎng)格協(xié)同設計任務(wù)調度模型。
網(wǎng)格協(xié)同設計任務(wù)執行的框架分為三個(gè)層次:由底而上依次為資源層、資源管理控制層和應用(用戶(hù))層。資源層是可以進(jìn)行設計的實(shí)體DKU或者其他必要的資源,接受資源管理控制層的管理。應用層負責用戶(hù)任務(wù)的提交和結果的反饋。資源管理控制層可以抽象為一個(gè)資源管理器,在控制管理器內設置了負責任務(wù)映射和資源預留請求的模塊。
網(wǎng)格協(xié)同設計任務(wù)調度系統模型示意圖如圖3所示。
在圖3中,在設計應用層和資源管理器之間省略了一個(gè)資源請求代理層。這是因為假定任務(wù)已經(jīng)由資源請求代理指定為由該域完成。在這個(gè)域中,有多種系統資源,主要考慮計算資源和存儲資源,在預留資源時(shí)既可能要預留計算資源也可能要預留存儲資源及其他資源。當調度系統有預留的需求時(shí),就通過(guò)創(chuàng )建預留操作向資源預留請求處理模塊提出預留請求。資源信息由資源發(fā)現和資源監控提供。
在該任務(wù)調度系統模型中,任務(wù)執行的大致流程如下:用戶(hù)通過(guò)網(wǎng)格門(mén)戶(hù)Portal將任務(wù)提交給資源請求代理;資源請求代理將任務(wù)分配給可以執行該任務(wù)的域,必要時(shí)可以先對任務(wù)進(jìn)行分解;在域內任務(wù)被分解并被調度到具體的資源上去執行。任務(wù)執行的結果由資源逐層向上返回給用戶(hù),任務(wù)執行的狀態(tài)監控由資源監控模塊負責。
在本文中,首先分析了網(wǎng)格任務(wù)調度模型,然后基于網(wǎng)格協(xié)同設計環(huán)境的特殊性,以GMCD為構架,分析了網(wǎng)格協(xié)同設計中任務(wù)分解和任務(wù)執行的過(guò)程,引入了資源預留機制,建立了網(wǎng)格協(xié)同設計環(huán)境中的任務(wù)調度模型。
評論