張以利，楊萬扣

（1.南京工業(yè)職業(yè)技術學院 計算機與軟件學院，江蘇 南京210046；2.東南大學 自動化學院，江蘇 南京211189）

0 引 言

當前，云計算技術研究正方興未艾，多云共享技術研究已成為云計算研究的另一個重要發(fā)展方向［1］。agent技術也是近年來研究熱點之一，移動agent獨立于網(wǎng)絡傳輸層協(xié)議之外，適合于異構平臺的運行，有利于多平臺系統(tǒng)無縫集成?；谝苿觓gent的開放云聯(lián)盟 （open cloud computing federation based on mobile agent，CCFMA），借助于移動agent技術，進行多個云平臺的 “對接”，實現(xiàn) “海量”資源共享。提出云聯(lián)盟平臺計算任務分段及遷移機制 （computing tasks sectioning and moving scheme，CTSMS），研究計算任務帶權分段并以此進行位置部署，設計實現(xiàn)由分段機制產(chǎn)生的超量子任務段隨agent自適應遷移機制，并給出算法實現(xiàn)。使開放且異構的云聯(lián)盟平臺計算任務安全性和私密性有了保障，解決了用戶群峰值需求時巨量子任務段隨移動agent的遷移而帶來的云聯(lián)盟平臺節(jié)點負載均衡問題，從而使云服務提供商不必為可能出現(xiàn)的短時間峰值需求而投入額外成本。

1 構建基于移動agent的云聯(lián)盟平臺

基于移動agent的云聯(lián)盟平臺，借助移動agent技術，將多個云計算平臺進行松散結合，實現(xiàn)資源共享，具有開放性和異構性特點［2］，如圖1所示。

1.1 移動agent體系結構及其通信機制

移動agent具有主動性和智能性，適合在異構開放的網(wǎng)絡環(huán)境中提供中間件服務或應用服務。

定義1 CCFMA平臺移動agent模型

云聯(lián)盟平臺移動agent定義為五元組模型

ID標識云聯(lián)盟平臺移動agent唯一性，一個節(jié)點可以存在一個或多個agent，故ID由所在云控制域、任務管理器及本地序號共同組成。type是agent屬性，任務管理器據(jù)此屬性確定接收的數(shù)據(jù)包是一個agent。state標識agent當前工作狀態(tài)是否忙，currPara描述agent當前資源共享情況及歷史信息。policy是移動agent的任務策略屬性，agent根據(jù)自身情況及相關環(huán)境參數(shù)，確定是否進行遷移以及往何處遷移。

移動agent系統(tǒng)包括agent及其運行環(huán)境 （mobile agent environment，MAE）。移動agent在云聯(lián)盟平臺中的運行機制，如圖1所示。移動agent攜帶子任務段，由任務管理器調度并派遣，或者派到本云平臺agent運行環(huán)境，或者派往云聯(lián)盟內(nèi)其它云平臺。

移動agent采取 “黑板報”通信機制?！昂诎鍒蟆笔窃谌蝿展芾砥鲀?nèi)開辟一塊為全局共享的內(nèi)存區(qū)域，是任務管理器所轄區(qū)域內(nèi)agent及節(jié)點信息的 “目錄表”，每個agent主動向其所在任務管理器 “黑板”上 “張貼”或 “讀取”相關 “黑板報”信息，是移動agent行動決策的依據(jù)。

圖1 基于移動agent的云聯(lián)盟平臺

1.2 基于移動agent的云聯(lián)盟平臺的搭建

云聯(lián)盟平臺 （CCFMA）是由多個云平臺通過移動agent而實現(xiàn)松散聯(lián)合。每個云平臺有一個或多個云控制域，這是由其地理位置及管理策略因素決定的。例如，Google在許多國家和地區(qū)都有不同的云控制域。每個云控制域往往設計一個或多個任務管理器，用于管理其所轄區(qū)域［3］。

云聯(lián)盟平臺實行區(qū)域管理機制。在大規(guī)模的云聯(lián)盟平臺下，實現(xiàn)集中式管理是不現(xiàn)實的也是不可取的。任務管理器是云聯(lián)盟平臺的基本管理單位，是由高性能的物理機組建而成。負責派遣攜帶子任務段的移動agent到云聯(lián)盟平臺節(jié)點的虛擬機中運行，是移動agent的訪問入口。負責管理區(qū)域內(nèi)負載均衡、注冊和管理agent并提供索引及目錄服務等。同時與本云平臺以及其它云平臺任務管理器定期交換節(jié)點及負載相關信息，以便對本地發(fā)出的移動agent有效跟蹤并對其他區(qū)域以至其他云平臺派遣出的發(fā)往本地的移動agent進行高效管理。

任務管理器采用 “黑板報”的通信機制，節(jié)點和agent目錄表等重要信息都 “張貼”在位于其中的 “黑板”上，其他任務管理器可獲取此 “黑板報”以掌握平臺全局信息，便于決策之用。

云聯(lián)盟平臺的任務管理器接收到用戶任務以后，便根據(jù)松散耦合的原則及子任務重要程度對計算任務進行分解及子任務安全權重賦值，并按計算任務帶權分段算法對子任務鏈進行若干分段，任務管理器根據(jù)需要派遣若干移動agent，把這些子任務段 “加”到不同的移動agent中，再根據(jù)這些子任務段的重要程度，將這些agent指派到本地或其他云平臺的虛擬機運行環(huán)境中執(zhí)行［4］。

2 CCFMA平臺計算任務分段及遷移機制研究

2.1 CCFMA平臺計算任務帶權分段機制

目前，云計算平臺內(nèi)部安全性研究相對成熟了，部署在云平臺內(nèi)部計算任務是相對安全的。但是，由于云聯(lián)盟平臺是開放異構的平臺，各云平臺有著不同的安全機制和運行方式。如果用戶任務隨移動agent遷移到其它平臺上運行，其安全性和私密性得不到保證。惡意的節(jié)點可能窺探用戶任務的內(nèi)部邏輯，獲取程序實現(xiàn)目標，進而達到竊取目的［5］。為此，系統(tǒng)采用計算任務帶權分段機制。

定義2 CCFMA平臺子任務

云聯(lián)盟平臺子任務S定義為一個四元組

屬性i為計算任務T的序號，屬性j為Ti子任務Sj序號，屬性weigPriv為子任務所要求的安全權重，是體現(xiàn)子任務在任務Ti中重要程度的量，一般地，weigPriv值越大，其要求安全性級別越高，其在Ti中越重要。clouPosi為Sj部署位置，是一個布爾量，1為云平臺內(nèi)，0為其他平臺。

設計算任務Ti有M個子任務Sj，即T＝ （S1，S2，…，Sj，…，SM）（j∈ M），分別存放在agent集合A＝ （agent1，agent2，…，agentj，…，agentM）中 （j∈M）。Ti的第j個子任務記作，存放該子任務的agent記作。

首先，系統(tǒng)將計算任務按盡量降低子任務間耦合度原則分解子任務，并以其在整個任務中的重要程度賦以安全權值，權值大小表明該子任務要求安全程度高低。然后，提取子任務鏈中權值較大的 “重要點”，而將提取后剩下的子段按子任務前后鏈接及權值累加情況再次切分提取其中“關節(jié)點”，進而形成若干新子任務段。由于云平臺內(nèi)部安全性較好，故將這些 “重要點”和 “關節(jié)點”留在本云平臺執(zhí)行，而將其它子任務段由agent攜帶部署到其它云平臺上。最后，本云平臺任務管理器再將返回結果進行任務的“綜合”處理。這樣，其它平臺節(jié)點在執(zhí)行過程中，即使發(fā)現(xiàn)某段 “細節(jié)”也無法得到任務的關鍵部分和整體，無法實現(xiàn)對任務的協(xié)同攻擊，因而任務是安全的，保護了計算任務的私密性［6］。

系統(tǒng)先掃描子任務鏈Sj并將其所有元素位置屬性clouPosi置0，同時提取Sj中安全權重達到閾值threWeig的 “重要點”元素，并將其位置屬性置1，這樣，Sj第一次被截得到若干子任務段；再對這些子任務段進行二次掃描。掃描并累加首個子任務段元素，當累加值達到閾值時，提取該 “關節(jié)點”并將其位置屬性置1，繼續(xù)掃描其余元素，掃描時從零累加權值；照此方法，掃描其余子任務段。至此，二次掃描得到了若干 “重要點”、“關節(jié)點”以及次子任務段［7］。計算任務帶權分段算法如下。

算法1 計算任務帶權分段算法

先將賦值所有子任務位置屬性clouPosi＝0

該程序段反復迭代后，子任務鏈Sj（j∈M）就被截為若干 “重要點”“關鍵點”和次子任務段。cloudPosi值為1的子任務將部署在本云平臺，而其余次子任務段由于cloudPosi值為0而由移動agent攜帶部署到其它云平臺。

舉例計算任務帶權分段算法

設 T＝ （S1，S2，…，S11），threWeig＝5，S＝（weigPriv，clouPosi）

圖2 計算任務帶權分段算法示意圖

分析：第1次掃描由于安全權重值達到閾值5而提取6和10號兩個 “重要點”，如圖2（a）所示。第二次掃描由子任務安全權重累加值達到5而提取3和9號兩個 “關節(jié)點”，如圖2（b）所示。經(jīng)過二次掃描后剩下4個小子任務段，如圖2（c）所示。

2.2 CCFMA平臺移動agent自適應遷移機制

當遇到客戶群短時間峰值需求時，云平臺任務管理器會有大量的計算任務聚集，根據(jù)計算任務帶權分段算法，最后會得到很多 “重要點”、 “關節(jié)點”以及次子任務段。因此，在某些 “熱點”區(qū)域，可能會有超量子任務 “短暫”的 “扎堆”現(xiàn)象，出現(xiàn)云聯(lián)盟平臺負載不均衡問題。為此，系統(tǒng)采用移動agent自適應遷移機制。

定義3 CCFMA云節(jié)點間距離

云聯(lián)盟平臺中，設有兩節(jié)點nodep和nodek，其所在的實際物理節(jié)點為physp和physk，則兩云節(jié)點間距離［8］定義為

distPhysp，k為物理節(jié)點physp和physk間實際距離，該量影響網(wǎng)絡延遲和數(shù)據(jù)傳輸可靠性。bandAver為平臺物理節(jié)點平均帶寬，bandPhysp、bandPhysk為物理節(jié)點physp、physk的帶寬。云節(jié)點間距離，實際上是對節(jié)點帶寬、節(jié)點間實際距離及網(wǎng)路狀況等進行綜合反映，此處的節(jié)點也可以是虛擬節(jié)點。特別的，當兩節(jié)點 （虛擬節(jié)點）位于同一物理節(jié)點時，由于distPhsyp，k＝0，由式3得distNodep，k＝0。

定義4 CCFMA平臺鄰節(jié)點

云聯(lián)盟平臺鄰節(jié)點是指與節(jié)點nodei的節(jié)點間距離小于或等于預設值threDistNode的節(jié)點，記做neigNodej（j∈m）。nodei的鄰節(jié) 點 N＝ （neigNode1，neigNode2，…，neigNodej，…，neigNodem）（j∈ m）。關于nodei與neigNodej間距離計算方法，見式 （3）。

如果agenti發(fā)現(xiàn)其所在節(jié)點nodei的負載loadNodei超過閾值threLoad，就尋找其鄰節(jié)點中負載最小的節(jié)點neig－Nodej并與之比較，若該節(jié)點負載低于其所在節(jié)點，則agenti會自動遷移至這個負載最小的節(jié)點neigNodej。遷移后的agenti再以這個負載最小節(jié)點neigNodej為新 “據(jù)點”進行云節(jié)點間距離的計算，進而建立新的鄰節(jié)點集合，并將該 “據(jù)點”負載與閾值threLoad進行比較，尋找負載更輕的節(jié)點并繼續(xù)遷移。循環(huán)迭代此決策過程，直到agenti“跳”至負載低于閾值threLoad的節(jié)點［9］。否則，報告其所屬任務管理器：nodei局部區(qū)域超載，該區(qū)域就會暫時停止部署新任務。

這里的 “閾值threLoad”的設置很關鍵，直接影響到agent遷移路徑長短及用戶群峰值需求問題解決，如果設置過高，則agent會在某個 “熱點”節(jié)點上 “扎堆”，影響到峰值需求問題的解決，如果設置過低，則會使得agent為了尋找到低負載節(jié)點而不斷遷移，并最終向任務管理器報告區(qū)域超載假象。為了避免后一種情況頻繁發(fā)生，可設置agent“跳數(shù)”閾值，用來適當限定agent“跳數(shù)”。移動agent自適應遷移算法如下。

算法2 移動agent自適應遷移算法

輸入攜帶子任務的agenti

3 仿真實驗及性能分析

仿真實驗計算任務：通過房價相關數(shù)據(jù)統(tǒng)計近20年中國房價變化情況，進而分析今后20年中國房價變化趨勢。假設取25個 “代表省份”，每個省取20個 “代表城市”進行分析。

子任務分解如下：各 “代表城市”房價情況有500個子任務，各 “代表省份”房價情況有25個子任務，中國房價情況及變化趨勢有1個子任務。

實驗軟硬件及參數(shù)設置：使用云平臺A和云平臺B仿真云聯(lián)盟平臺，A、B兩云平臺的軟硬件配置相同。任務管理器task manager各1臺，主機pc各40臺，系統(tǒng) WindowsXP，云平臺 Hadoop，agent平臺IKV＋＋Grasshopper，開發(fā)語言和工具為java和Eclipse3.3。任務管理器功能和結構由程序事先產(chǎn)生，其余節(jié)點處理能力相同。

計算任務按低耦合原則分解子任務526個。按安全權重值賦予3個子任務類別：A類 “中國房價情況及變化趨勢”1個，安全權重最高：weigPriv＝15，B類 “代表省份”25，安全權重較高：weigPriv＝10，而C類 “代表城市”500個，weigPriv＝1。安全權重閾值設置threWeig＝10，移動agent的 “跳數(shù)”閾值設置threStep＝15。

3.1 計算任務帶權分段機制有效性分析

容易得出A類和B類子任務由于其安全權重都達到10而首輪掃描即被 “選中”為 “重要點”。500個子任務由于其安全權重較低，經(jīng)過第二次掃描后，將被分成若干子任務段。10個子任務的權重累計和才達到10，因而第10個才被提取為 “關節(jié)點”，以此類推。這526個子任務共提取“重要點”26個，提取 “關節(jié)點”50個，共被截50個次子任務段。

這些 “重要點”和 “關節(jié)點”的位置屬性cloudPosi置1，即這些子任務留在本云平臺執(zhí)行，而50個子任務段則由任務管理器派遣移動agent攜帶到云聯(lián)盟內(nèi)其它平臺執(zhí)行。

實例分析：實例任務的 “代表省份房價情況”和 “中國房價情況及變化趨勢”都是分析結論部分，當然是整個計算任務重要部分，而按照分段機制，這26個子任務均部署在本云平臺上執(zhí)行，其安全性當然會得到保障。500個子任務 “代表城市房價情況”盡管大部分被移動agent攜帶到云聯(lián)盟內(nèi)其它云平臺上執(zhí)行，其安全性及私密性同樣可以保證。因為，按照分段機制這500個子任務經(jīng)過二次掃描被分割50段，并且每連續(xù)的10個子任務中第10個 （即“關節(jié)點”）就要被 “提取”出來，并留在本云平臺中執(zhí)行，并且它們是安全權重累加值未達到權重閾值，其在全局任務中占據(jù)的重要程度較低。也就是說，送到云聯(lián)盟內(nèi)其它云平臺上執(zhí)行的子任務不是連續(xù)的，且在全局中的重要性較低，“惡意”節(jié)點即使得到子任務代碼并進行分析，也無法分析到全局性的任務。

由此可見，CCFMA平臺計算任務帶權分段機制及其算法是有效的。

3.2 移動agent自適應遷移機制有效性驗證

仿真實驗中，設用戶向云平臺A的任務管理器提交任務。計算任務共分解526個子任務，其中有26個 “重要點”和50個 “關節(jié)點”部署在云平臺A，而50個子任務段則由云平臺A任務管理器派遣移動agent攜帶到云平臺B執(zhí)行，按移動agent自適應遷移機制運行。

對比實驗中，攜帶子任務段的移動agent被派遣到云平臺B的某位置后，僅受任務管理器調度而被動移動，自身不會隨環(huán)境變化而自適應遷移。其它條件與仿真實驗完全相同。

定義5 總體標準偏差

總體標準偏差 （overall standard deviation，OSD），以給定的樣本作為總體來求標準偏差，是一個用來反映樣本總體相對于樣本平均值的離散程度的量。此處用來反映各節(jié)點負載相對于平臺平均負載的離散程度［10］

式中：xi——節(jié)點nodei負載，——平臺節(jié)點負載平均值，n——節(jié)點數(shù)量。

從任務管理器派遣的移動agent開始移動后，每隔500s記錄一次節(jié)點負載數(shù)據(jù)。各節(jié)點負載總體標準偏差隨時間變化情況，如圖3所示。

圖3 各節(jié)點負載總體標準偏差隨時間變化情況

兩組實驗在各節(jié)點負載均衡方面的比較。由圖3可以看出，CTSMS實驗數(shù)據(jù)線總體標準方差下降速度比對比實驗要來得快，隨后很快穩(wěn)定下來，而對比實驗在開始的時候還不很穩(wěn)定。這是由于仿真實驗設計使用移動agent自適應遷移機制，攜帶子任務的移動agent被派遣到云平臺B后，會根據(jù)所在節(jié)點及周圍節(jié)點負載情況進行決策，按預設負載閾值尋找低負載節(jié)點并自動遷移。而對比實驗中移動agent自身不會隨環(huán)境變化而自適應遷移，僅靠任務管理器來分配，所以下降速度較慢，并且在任務執(zhí)行的初期表現(xiàn)出一定的隨機性。

4 結束語

基于移動agent的云聯(lián)盟平臺 （CCFMA），借助移動agent技術，實現(xiàn)多個云計算平臺的 “對接”。采用計算任務分段及遷移機制，研究計算任務帶權分段并以此進行位置部署，設計實現(xiàn)由分段機制產(chǎn)生的超量子任務段隨agent自適應遷移機制，并給出算法實現(xiàn)。。使開放且異構的云聯(lián)盟平臺計算任務安全性有了保障，解決了用戶群峰值需求時超量子任務段隨移動agent遷移而帶來節(jié)點負載均衡問題，從而使云服務提供商 （CSP）不必為可能出現(xiàn)的短時間用戶群峰值需求而投入額外成本。

［1］LIU Xiaoqian.Research on data center structure and scheduling mechanism in cloud computing ［D］.Hefei：University of Science and Technology of China，2011 （in Chinese）. ［劉曉茜.云計算數(shù)據(jù)中心結構及其調度機制研究 ［D］.合肥：中國科學技術大學，2011.］

［2］XU Xiaolong，CHENG Chunling，XIONG Jingyi，et al.Mobile agent－based secure task partitioning and allocation algorithm for cloud ＆client computing［J］.Transactions of Beijing Institute of Technology，2011，31 （8）：922－926 （in Chinese）. ［徐小龍，程春玲，熊婧夷，等.一種基于移動Agent的云端計算任務安全分割與分配算法 ［J］.北京理工大學學報，2011，31（8）：922－926.］

［3］LI Jing，HAN Qiyun.Resource cooperative discovery model in virtual computing systems ［J］.Computer Engineering，2012，38 （10）：48－50 （in Chinese）.［李靜，韓起云.虛擬計算系統(tǒng)中資源協(xié)同發(fā)現(xiàn)模型 ［J］.計算機工程，2012，38 （10）：48－50.］

［4］ Mell J，Grance T.The NIST definition of cloud computing［EB／OL］.［2011－10－20］.http：／／csrc.nist.gov／publications／drafts／800－145／Draft－SP－800－145＿cloud－definition.pdf.

［5］LIU Fan，YANG Ming.Ciphertext policy attribute based encryption scheme for cloud storage ［J］.Application Research of Computers，2012，29 （4）：1452－1456 （in Chinese）. ［劉帆，楊明.一種用于云存儲的密文策略屬性基加密方案 ［J］.計算機應用研究，2012，29 （4）：1452－1456.］

［6］Iosup A，Ostermann S，Yigitbasi M N.Performance analysis of cloud computing services for many－tasks scientific computing［J］.IEEE Trans.on Parallel and Distributed System，2011，22 （6）：931－945.

［7］Boss G，Malladi P.Cloud computing ［EB／OL］.［2011－10－20］.http：／／www.jbm.com／developerworkers／websphere／zones／hipods／.

［8］ZHANG Zehua.Research on model and key realization issues of cloud computing federation ［D］.Kunming：Yunnan University，2010（in Chinese）.［張澤華.云計算聯(lián)盟建模及實現(xiàn)的關鍵技術研究 ［D］.昆明：云南大學，2010.］

［9］SHEN Lijun，LIU Li，LU Rui，et al.Task scheduling in cloud computing based on improved immune evolutionary algorithm［J］.Computer Engineering，2012，38 （9）：208－210 （in Chinese）.［申麗君，劉麗，陸銳，等.基于改進免疫進化算法的云計算任務調度 ［J］.計算機工程，2012，38 （9）：208－210.］

［10］CHENG Miao，CHEN Huaping.Weblog mining based on Hadoop［J］.Computer Engineering，2011，37 （11）：37－39 （in Chinese）. ［程苗，陳華平.基于Hadoop的 Web日志挖掘［J］.計算機工程，2011，37 （11）：37－39.］