協(xié)同設計(Collaborative Design)是指在計算機的支持下，各成員圍繞一個設計對象，各自承擔相應部分的設計任務，并行交互地進行設計工作，最終得到符合要求的設計結(jié)果的設計[1]。網(wǎng)格的出現(xiàn)為協(xié)同設計帶來了嶄新的解決思路。借助于網(wǎng)格研究的基礎(chǔ)設施以及Globus聯(lián)盟推出的網(wǎng)格既定標準GT3(Globus Toolkit 3)，可以為制造業(yè)網(wǎng)絡設計提供極為方便的底層支撐，為快速建立一個健壯的設計平臺提供保證，GMCD[4]就是這樣一個設計平臺。本文將首先分析網(wǎng)格環(huán)境中任務調(diào)度的模型，然后基于協(xié)同設計環(huán)境的特殊性，以GMCD為框架，建立一種實用的任務調(diào)度模型。


1 網(wǎng)格任務調(diào)度模型

　　網(wǎng)格環(huán)境中資源管理結(jié)構(gòu)模型有分層模型、抽象所有者模型、計算市場(經(jīng)濟)模型和混合模型。GMCD框架是以Globus為基礎(chǔ)的，而Globus的資源管理結(jié)構(gòu)模型則是層次的。因此，本節(jié)著重討論分層模型中的網(wǎng)格調(diào)度。

1.1 網(wǎng)格任務調(diào)度的相關(guān)組件及功能

　　在分層的資源管理結(jié)構(gòu)模型中，資源管理與調(diào)度是多級的，每個資源有自己的調(diào)度子系統(tǒng)，用戶只需把作業(yè)提交給資源請求代理，而代理后有多少資源提供者，以及該作業(yè)分配哪個資源，對于用戶來說都是透明的。資源提供者可以是單個PC機，可以是單個集群或多個集群，也可以是某個組織的一個中小型局域網(wǎng)。它們都有一個共同點，即都有一個管理者——局部資源管理器。單個PC機本身就是一個管理者；而集群和局域網(wǎng)，一般都有一臺服務器專職管理集群/局域網(wǎng)中的各結(jié)點。用戶作業(yè)在資源請求代理上進行一級調(diào)度，在局部資源管理器上進行二級調(diào)度，如果下面存在更多的集群或局域網(wǎng)，則存在三級、四級等多級調(diào)度。

　　在網(wǎng)格任務調(diào)度中有兩個非常重要的組件，分別是資源請求代理和資源管理器，它們在任務調(diào)度過程中分別進行一級和二級(多級)調(diào)度。其他與任務調(diào)度有關(guān)的組件還有網(wǎng)格工作站點以及負責聯(lián)系的組件[3]：

　　(1)資源請求代理

　　它是整個網(wǎng)格的資源管理者，負責接收用戶任務，根據(jù)其特點發(fā)送給域資源管理器，動態(tài)監(jiān)視任務的運行情況，根據(jù)需要將結(jié)果提交給用戶或進行再調(diào)度。主要功能有：

　?、賹Ψ仗峁┓教峁┳怨δ埽ζ浼尤牒屯顺龅葎幼鬟M行控制。
　　②建立網(wǎng)格資源信息庫并周期性地刷新，對全局資源進行統(tǒng)一管理和分配。
　　③接收用戶提交的作業(yè)，并根據(jù)作業(yè)類型和要求(如資源的類型和數(shù)量等)形成作業(yè)調(diào)度參數(shù)。
　?、芨鶕?jù)作業(yè)調(diào)度參數(shù)調(diào)度作業(yè)，分派資源，并隨時監(jiān)視作業(yè)的執(zhí)行情況。
　?、萑糇鳂I(yè)執(zhí)行有誤，則對其進行再調(diào)度，保證用戶作業(yè)的安全運行。

　　(2)域資源管理器

　　它是域內(nèi)資源管理和動態(tài)調(diào)度的中心，負責本域工作的創(chuàng)建、屬性的收集、接收從資源請求代理提交的任務并根據(jù)其特點進行處理機的分配。主要功能有：

　?、俦O(jiān)聽從本域結(jié)點發(fā)送來的信息，建立域成員信息資料庫并周期性刷新。
　?、谥芷谛缘亟邮沼少Y源請求代理提交的作業(yè)，并判斷其可行性，建立本域的任務隊列。
　?、蹚娜蝿贞犃兄羞x取作業(yè)，根據(jù)提交的參數(shù)和資源情況合理地分配作業(yè)。
　?、軐⒆鳂I(yè)執(zhí)行情況定時返回給資源請求代理，維持與上級數(shù)據(jù)庫的一致性。
　?、荼O(jiān)視各組員執(zhí)行狀況，根據(jù)情況進行作業(yè)調(diào)整(域內(nèi)調(diào)整或再調(diào)度)。
　　⑥確保用戶作業(yè)的安全運行，將結(jié)果通知資源請求代理并直接返還給用戶。

　　(3)網(wǎng)格工作結(jié)點

　　它是任務執(zhí)行的基本單位，一旦申請加入資源提供方，便由域資源管理器直接調(diào)度和由資源請求代理間接調(diào)度。主要功能有：

　?、傧蛏霞壒芾砥魈岢錾暾垼埱蠹尤胭Y源提供方。
　?、谑占窘Y(jié)點的狀態(tài)和負載信息，并周期性地提交給域資源管理器。
　　③產(chǎn)生服務進程，隨時接收上級管理器提交的任務并執(zhí)行。

　　(4)負責聯(lián)系的組件

　　鑒于各實體間的聯(lián)系比較多，可將其分為作業(yè)提交和資源匯報兩部分。

　?、僮鳂I(yè)提交部分

　　用戶向資源請求代理提交作業(yè)任務；資源請求代理根據(jù)用戶參數(shù)將作業(yè)轉(zhuǎn)交給域資源管理器；域資源管理器根據(jù)各結(jié)點負載情況分派作業(yè)給合適的資源工作結(jié)點，任務執(zhí)行完畢后保存作業(yè)結(jié)果；域資源管理器直接將結(jié)果返回給用戶。

　?、谫Y源匯報部分

　　它完成如下任務：網(wǎng)格工作結(jié)點向域資源管理器提供各結(jié)點的狀態(tài)和負載情況；域資源管理器將該域的負載信息匯總并送給資源請求代理供查詢和管理結(jié)點；域資源管理器周期性地刷新資源請求代理中的作業(yè)狀態(tài)；工作結(jié)點執(zhí)行完畢。

1.2 網(wǎng)格任務調(diào)度的過程

　　用戶利用提交程序?qū)⒆鳂I(yè)任務和要求的環(huán)境屬性(如資源類型和數(shù)量等)提交給資源請求代理，資源請求代理分析環(huán)境屬性形成參數(shù)文件，根據(jù)任務性質(zhì)、通信狀況和各資源負載情況進行粗粒度調(diào)度，尋求最佳分配方案將作業(yè)及參數(shù)文件提交給選中的域資源管理器。當域資源管理器接收到新任務或調(diào)度周期到來時，新任務被賦予任務優(yōu)先級插入作業(yè)隊列。守護進程從結(jié)點機列表中獲取該域內(nèi)所有資源負載情況，同時更新資源請求代理上全局數(shù)據(jù)庫中相關(guān)的信息表。確定已經(jīng)到達該域的任務的優(yōu)先級，每次選取一個任務分配合適的資源。相應地，守護進程派生出相應的作業(yè)線程，周期性地監(jiān)視該作業(yè)的執(zhí)行狀態(tài)，并向上一級(資源請求代理)匯報，以便進行全局管理與調(diào)度(或用戶查詢)。當任務途中異常中斷或執(zhí)行性能比預期要差時，資源請求代理可進行再次調(diào)度，重新安排其他資源；而當任務完成時，資源請求代理會要求域資源管理器直接將作業(yè)結(jié)果返還給用戶。


2 GMCD中的任務調(diào)度機制

　　由于網(wǎng)格協(xié)同設計環(huán)境的特殊性，網(wǎng)格協(xié)同設計環(huán)境中的任務調(diào)度模型和通用的網(wǎng)格調(diào)度模型相比也具有特殊性?，F(xiàn)以GMCD構(gòu)架為例，討論網(wǎng)格協(xié)同設計中的任務調(diào)度機制。

　　GMCD系統(tǒng)體系結(jié)構(gòu)由底而上可分為四層，即設計知識單元DKU(Design Knowledge Units)[4]、網(wǎng)格中間件、設計中間件和應用層，如圖1所示。

　　DKU及互聯(lián)網(wǎng)絡組成了GMCD的底層支持結(jié)構(gòu)。DKU是Internet上的具有設計能力的組織或機構(gòu)，它們在某一類產(chǎn)品或零部件研發(fā)上具有先進的設計技術(shù)和生產(chǎn)能力。在DKU內(nèi)部存在設計知識數(shù)據(jù)庫、局域網(wǎng)和設計工具(集)。它們之間通過Internet或?qū)Ｓ酶咚倬W(wǎng)連通。在設計過程中，各個DKU之間具有平等關(guān)系，各自負責所獲得任務的運行，相對來說是獨立的。

　　用戶在應用層通過Portal將任務提交給設計中間件。設計中間件將由Portal提交的設計任務分解為可以被DKU執(zhí)行的子任務。分解過程如下。

　　GMCD任務分解分為兩層。任務以XML(eXtensible Markup Language)文件形式被提交后，首先會由資源請求代理轉(zhuǎn)交給自稱能完成該任務的域，然后在域控制管理器內(nèi)被首次分解，分解的原則是可執(zhí)行原則。對于已經(jīng)進入域控制管理器的任務，應用分解智能體根據(jù)知識庫內(nèi)的知識，將其分解為可以被DKU執(zhí)行的任務。知識庫內(nèi)保留了該域內(nèi)所有DKU的功能申明。域內(nèi)任務分解(高層分解)的目標是把任務分解為可以被DKU執(zhí)行的子任務，低層任務分解在DKU內(nèi)進行，其目標是把子任務分解為可以被DKU中服務器執(zhí)行的底層操作。由于設計工作的特殊性，DKU分布通常不均勻，能完成有關(guān)聯(lián)或相似性設計任務的DKU通常在一個或幾個域內(nèi)。如果被提交的設計任務沒有合適的域可以執(zhí)行，則還要在高層分解之前加入一層手工分解或由資源請求代理分解。也就是說，可以把任務返還給用戶，由用戶根據(jù)一定的設計知識對設計任務實行手工分解，也可以由資源請求代理根據(jù)域的功能自述分解為可以被域執(zhí)行的子任務。域資源管理器和DKU的關(guān)系如圖2所示。

　子任務在DKU內(nèi)被重新解析為可以被服務器執(zhí)行的底層任務，然后由DKU調(diào)度到各個服務器上去執(zhí)行。

　　高層分解和低層分解在失敗時都回溯。

　　分解后的任務由域調(diào)度器調(diào)度到合適的DKU上去執(zhí)行。GMCD的任務映射分為三個層次。資源請求代理保留了每個域的功能自述副本。任務通過Portal提交后，根據(jù)域的功能自述，被轉(zhuǎn)交給能完成該任務的域；然后在域內(nèi)分解再由域調(diào)度器進行二次映射，二次調(diào)度的目的是把分解后的子任務映射到合適的DKU上去；在DKU內(nèi)的調(diào)度是第三次映射，這次調(diào)度的目的是把解析子任務后得到的底層任務映射到合適的服務器上去。本文所關(guān)注的是第二次調(diào)度，也就是分解以后的任務如何由域調(diào)度器調(diào)度到DKU上。在第二次調(diào)度中，由于設計任務的特殊性，一組相似或相關(guān)任務通常會在一個時間段內(nèi)陸續(xù)到達。


3 資源預留的引入

　　資源預留是網(wǎng)格系統(tǒng)中一個十分必要的機制，因為資源預留可以保證任務在開始執(zhí)行時獲得必要的資源，從而提高網(wǎng)格系統(tǒng)的QoS。因此，資源預留的提出，從一開始就得到了廣泛的認可，在目前網(wǎng)格系統(tǒng)的調(diào)度模塊中已經(jīng)被廣泛采用。在協(xié)同設計過程中，每個設計任務，特別是其中某些大任務的執(zhí)行直接影響設計任務完成的時間，在本文中引入了資源預留機制，以便為其中的大任務提供動態(tài)預留資源[5]，進而提高協(xié)同設計的效率。

　　下面討論引入資源預留的網(wǎng)格協(xié)同設計任務調(diào)度模型。

　　網(wǎng)格協(xié)同設計任務執(zhí)行的框架分為三個層次：由底而上依次為資源層、資源管理控制層和應用(用戶)層。資源層是可以進行設計的實體DKU或者其他必要的資源，接受資源管理控制層的管理。應用層負責用戶任務的提交和結(jié)果的反饋。資源管理控制層可以抽象為一個資源管理器，在控制管理器內(nèi)設置了負責任務映射和資源預留請求的模塊。

　　網(wǎng)格協(xié)同設計任務調(diào)度系統(tǒng)模型示意圖如圖3所示。

　在圖3中，在設計應用層和資源管理器之間省略了一個資源請求代理層。這是因為假定任務已經(jīng)由資源請求代理指定為由該域完成。在這個域中，有多種系統(tǒng)資源，主要考慮計算資源和存儲資源，在預留資源時既可能要預留計算資源也可能要預留存儲資源及其他資源。當調(diào)度系統(tǒng)有預留的需求時，就通過創(chuàng)建預留操作向資源預留請求處理模塊提出預留請求。資源信息由資源發(fā)現(xiàn)和資源監(jiān)控提供。

　　在該任務調(diào)度系統(tǒng)模型中，任務執(zhí)行的大致流程如下：用戶通過網(wǎng)格門戶Portal將任務提交給資源請求代理；資源請求代理將任務分配給可以執(zhí)行該任務的域，必要時可以先對任務進行分解；在域內(nèi)任務被分解并被調(diào)度到具體的資源上去執(zhí)行。任務執(zhí)行的結(jié)果由資源逐層向上返回給用戶，任務執(zhí)行的狀態(tài)監(jiān)控由資源監(jiān)控模塊負責。

　　在本文中，首先分析了網(wǎng)格任務調(diào)度模型，然后基于網(wǎng)格協(xié)同設計環(huán)境的特殊性，以GMCD為構(gòu)架，分析了網(wǎng)格協(xié)同設計中任務分解和任務執(zhí)行的過程，引入了資源預留機制，建立了網(wǎng)格協(xié)同設計環(huán)境中的任務調(diào)度模型。