容錯中間件[1-2]是一個可為開發者提供分布式應用容錯支持的開發平臺。容錯中間件將容錯邏輯從應用邏輯中分離出來,為容錯應用開發提供框架支持,簡化業務應用開發,同時使開發過程變得清晰。目前,容錯中間件的研究和實現主要是基于分布對象。國外主要產品有:基于JavaRMI的Arjuna系統,FilterFresh系統等;基于DCOM的COMERA系統;基于CORBA的OGS系統,Enteral系統等。國內方面主要有國防科學技術大學研發的分布應用容錯計算平臺StarFT。
中間件包括平臺功能,自身具有自治性、自主性、隔離性、社會化、激發性、主動性、并發性、認識能力等特性,是近似于Agent的結構,因此利用Agent來建立容錯中間件是一個不錯的選擇。
失效檢測[3]與恢復是實現容錯的核心問題。檢測到失效是容錯恢復的前提,因此,失效檢測是實現容錯不可或缺的一部分。失效恢復是容錯的目標,也是容錯技術提高系統效率的關鍵所在。
本文在分析介紹Agent[4]和多Agent系統[5-9]之后,給出了容錯中間件中的失效檢測模型和恢復策略,最后討論了基于JADE[10-12]的系統實現。
1 相關技術
1.1 Agent的定義及其結構
Agent(代理)概念起源于人工智能領域,是指用于模仿人類能力的自主實體,駐留在某一環境下能持續、自主地發揮作用。Agent的基本結構如圖1所示。
Agent一般具有自主性、反應性、交互性、協作性、主動性和智能性等特性。但在實際的系統中,Agent并不能保證具有以上的全部特性。
1.2 多Agent系統
多Agent系統是由多個Agent組成的一個社會整體,不同的Agent可以控制或影響環境的不同部分,多個Agent可以通過Agent通信語言進行交互,分工合作,實現更為復雜、單個Agent無法解決的問題。多Agent系統可以有效地解決數據、控制具有分布性的問題,并能提高系統的效率和魯棒性。
1.3 容錯技術
使得系統在部分節點失效或是部分對象崩潰的情況下仍能正常運行并得到預期結果的技術稱為容錯技術。軟件容錯借鑒硬件容錯的成功經驗,經常采用冗余技術進行處理。軟件容錯方法主要有錯誤回卷恢復、恢復塊、N版本軟件。
錯誤回卷恢復主要分為兩大類:基于檢查點的錯誤回卷恢復、基于日志的錯誤回卷恢復。基于檢查點的錯誤回卷恢復的核心思想是任務執行過程中設置檢查點,發現失效時不需要從頭開始運行,而是直接從最后一個成功執行的檢查點往下執行。基于日志的錯誤回卷恢復則是在判斷失效發生后,利用發生失效前最近的檢查點和日志信息完全重新運行作業的過程。
恢復塊的主要思想是:系統被劃分成若干恢復塊,整個系統由這些恢復塊組成。每個塊包含一個首要執行模塊和一些替換模塊。若首要執行模塊輸出結果驗收失敗,則調用第二個模塊;若再次失敗,則繼續調用另外的替換模塊。重復該操作,直到所有模塊均被調用,或超出時間限制。
N版本軟件的方法與硬件容錯的NMR方法類似。N(N》=2)個以不同方式實現的功能相同的模塊同時執行,由表決器判定正確的結果,作為模塊的結果。
2 失效檢測
2.1 失效檢測模型
本文設計的失效檢測系統主要由兩部分組成:局部檢測Agent,LDA(Local Detector Agent)和全局檢測Agent,GDA(Global Detector Agent)。LDA駐留在各節點,負責所駐留節點中實體的檢測工作;GDA負責各LDA及其所駐留節點的檢測工作。設計的檢測模型如圖2所示。
各部分詳細描述如下:
檢測對象:需要進行檢測的實體,可以是一個應用程序對象、也可以是一個進程、甚至是一個Agent;任何檢測對象在啟動時均需向LDA注冊。
LDA:每個工作中的節點均駐留有一個專屬的LDA,負責所屬節點中檢測對象的檢測及在發現失效時給出通告;任何LDA必須成功注冊到GDA后才能開始工作。
GDA:整個系統只有一個GDA,GDA駐留在主控節點,主要負責對各LDA的失效檢測、分類及通告的工作。
失效處理器:接收來自LDA或GDA的失效通告,對失效進行處理。
2.2 局部檢測Agent
LDA必須成功注冊到GDA后才能開始工作,若注冊失敗,允許重啟,當重啟次數超過設定閾值(比如3次)則給出警告,提請系統管理員介入,查看是否LDA程序出現錯誤。
任何檢測對象在啟動時都需要向該節點所屬LDA注冊,LDA根據各檢測對象的注冊信息建立并維護檢測對象及其狀態等信息的狀態表。流程如圖3所示。
LDA定時對狀態表中各檢測對象執行失效檢測算法,然后更新狀態表,并在發現失效對象時通告失效處理器。執行流程如圖4所示。
失效檢測主要有兩種模式:心跳模式,或稱“推”模式;輪詢模式,或稱“拉”模式。“推”模式的思想是:被檢測實體定時向檢測器發送心跳信息,檢測器在一段設定的時間內沒收到心跳信息,則判定實體失效;“拉”模式則為:檢測器定時向被檢測實體發送詢問信息,被檢測實體應答檢測器以申明自己未失效,檢測器在發出詢問后一段設定的時間內沒收到應答,則判定實體失效。
本文采用的測試模式是“拉”模式,在一個檢測間隔里完成對所有檢測對象的詢問及應答的接收或失效的判斷。如果檢測間隔太短,將無法正確處理對所有對象的檢測;而如果檢測間隔太長,則無法及時發現失效。因此,檢測間隔的設定需要一個綜合的折中考慮。
2.3 全局檢測Agent
整個系統只有一個GDA,GDA駐留在主控節點,主要負責對各LDA及其所在節點的失效檢測工作。如LDA維護檢測對象的狀態信息表一般,GDA根據各LDA注冊信息創建并維護針對LDA的狀態信息表。由于GDA與LDA一般駐留在不同節點,檢測時需要進行遠程通信,當發現LDA失效,需要進一步識別失效類型。主要失效類型有:LDA失效;通信失效;LDA所在節點失效。
3 失效恢復
3.1 恢復策略
本文主要采取的恢復策略是REDO策略,即檢測對象失效時,由失效處理器根據接收到的失效通告重啟該對象。在此基礎上針對一些比較特殊的檢測對象,執行更為符合其需求的恢復方法。
對于大數據量處理的對象,其執行可能涉及成千上萬的數據庫記錄,如果只是簡單的REDO,則已經處理過的記錄將會全部被再次處理,造成性能的重大浪費。因此,可以建立該對象的執行日志,維護該對象成功處理的記錄條數或是序號;當該對象需要被恢復時,根據執行日志直接從最后成功處理的記錄往下執行,也就是對該對象進行定點恢復。采用定點恢復將大大的提高系統的性能,避免大量時間的浪費。
對于在同一節點多次失效的對象,則可以考慮在另外的節點重新啟動,稱為對該對象的異機恢復。
3.2 定點恢復、異機恢復
定點恢復很重要的一個方面是恢復點的記錄,本文采用的是建立執行日志的方式。對于大量數據庫記錄處理的對象,假設需要處理1 000條記錄,每10條記錄設置一個恢復點,即當成功執行第10、20、30、……、1 000條記錄時,執行日志將產生一行日志信息表示該條記錄以及其之前的記錄已成功執行。若對象在執行第901至910條記錄時失效,恢復該對象時根據執行日志最后一行信息可以知道第900條以及之前的記錄已成功執行,于是,可以直接從第901條記錄開始處理,而不是從第1條記錄開始。由此可見,運用定點恢復可以避免大量無謂的時間浪費,很大程度上提高系統的性能。
一個對象在同一個節點失效次數超過設定閾值(比如4次),無論是該節點機器兼容性問題還是資源搶占問題,單純的在本機上的REDO已經不能解決問題。因此,可以考慮對該對象進行異機恢復,在另一個節點重啟該對象。
對于只采取REDO恢復策略的對象,只需要在選定的節點上啟動該對象,并在注冊信息里修改該對象所在地址即可實現異機恢復。
對于已運用定點恢復策略的對象,異機恢復時可以不考慮其已執行情況,簡單地在另一個節點重啟;也可以結合異機恢復與定點恢復,將該對象執行日志復制到選定的節點,實現在異機上的定點恢復。
4 系統實現
4.1 基于JADE的系統實現
JADE中,任何Agent必須向AMS注冊[11]。因此,對于檢測對象是Agent的情形,其主要注冊信息可由AMS獲取,負責檢測該Agent的LDA或者GDA只需記錄該Agent的標識及其狀態。
系統實現的各Agent按照職能不同分別駐留在主控節點和各計算節點上。主要有駐留在主控節點的容錯Agent(FTA,Fault Tolerant Agent)、日志收集Agent(LCA,Log Collector Agent);駐留在各計算節點的局部檢測Agent(LDA,Local Detector Agent)、日志Agent(LA,Log Agent)、恢復Agent(RA,Recovery Agent);檢測對象為在各計算節點上提供服務的計算Agent(CA,Compute Agent)。各Agent相互關系如圖5所示。
各Agent詳細功能如下所述:
LDA:負責CA、LA、RA的檢測工作。發現LA或CA失效時向RA發出本機恢復請求;必要時向FTA發出CA異機恢復請求;負責RA的本機恢復工作。(本文設定檢測間隔為1 000 ms)
FTA:負責LDA、LCA的檢測工作。發現LDA失效時向其所在節點的RA發出LDA恢復請求;接收來自LDA的CA異機恢復請求并將該請求轉發到合適的節點;負責LCA的恢復工作。另外,FTA還負責LDA所在主機的檢測及通報工作。
RA:接收來自LDA的本機恢復請求,并按照請求恢復本機的LA或CA;接收來自FTA的LDA恢復請求,并按照請求恢復本機上的LDA;接收來自FTA的CA異機恢復請求,并在本機上啟動指定的CA,實現異機恢復;必要時對CA進行定點恢復。
CA:計算能力提供者,屬于業務系統,本文所設計容錯系統的服務對象。
LA:本機日志記錄器;負責本機上各Agent運行情況的記錄,并將必要的信息發送給日志收集器LCA;負責用于定點恢復CA所必須的CA執行日志的創建及維護。
LCA:日志收集器;負責收集各節點的日志信息(CA執行日志不在收集范圍內);負責記錄FTA的運行情況。
分析上述Agent詳細功能,RA即為前述檢測模型中的失效處理器(主要處理策略是REDO,即重新啟動);LDA除去本機檢測工作外,還負擔了一部分失效處理器的工作(RA的恢復);FTA主要表現為前述模型中的全局檢測器GDA,此外,也負擔了一部分失效處理器的工作(LCA的恢復;LDA恢復請求、CA異機恢復請求的轉發)。
4.2 容錯Agent
容錯Agent(FTA)在系統中起著極其重要的作用,負責全局檢測工作與恢復請求的調度。為檢測各LDA,FTA需要維護一張記錄LDA信息的狀態表。由于LDA作為一個Agent,其主要信息均可從AMS獲取,FTA實際需要維護的信息僅僅是LDA標識(AID)及LDA狀態(是否正常)。本文選用HashMap作為記錄LDA狀態信息的數據結構,key-value對分別記錄LDA標識及LDA狀態。
定義一個TickerBehaviour負責周期性的更新LDA狀態表和LDA的失效判斷與處理工作。周期設定為1 000 ms。LDA失效判斷與處理算法如下描述:
(1)從AMS獲取Agent描述信息AMSAgentDescription;
(2)遍歷LDA狀態表,與AMSAgentDescription進行比對,更新狀態表;
(3)若所有LDA狀態均為true,則算法結束;否則,轉到(4);
(4)對狀態為false的LDA,通過AMSAgentDescription找尋與該LDA同節點的恢復Agent(RA);若該RA存在,則轉到(5);若不存在,則ping該節點地址,然后轉到(6);
(5)標識失效類型為LDA失效并請求該RA恢復其節點所屬LDA,然后轉到(7);
(6)若ping該節點有響應,則標識失效類型為節點系統失效并給出警告;若無響應,則標識失效類型為節點主機失效并給出警告;
(7)若全部狀態為false的LDA均處理完畢,則算法結束;否則,取下一個狀態為false的LDA,然后轉到(4)。
5 實驗結果
系統主控節點的計算機配置如下:Windows 7(32位)操作系統;Intel(R)Core(TM)i3-2120 CPU@3.30 GHz;4 GB內存。
系統計算節點(3臺)的計算機配置如下:Windows 7(32位)操作系統;Intel(R)Core(TM)2 Quad CPU Q8400@2.66GHz 2.67GHz;4.00 GB內存。
5.1 系統測試
臺風預報系統[13]中的相似路徑計算是一個分布式、多Agent的計算過程,其計算節點的失效將導致整體計算結果的不可靠,故為其提供容錯是必要的。在此背景下,本文以在臺風預報系統中提供相似路徑計算服務的計算Agent為系統檢測對象,對系統進行功能和性能上的測試。主控和各計算節點啟動、各功能Agent加載后,可在主控節點RMA控制界面查看詳細信息。
Main_Container(主容器)包含維持JADE平臺功能的3個服務:ams、df和rma;masterContainer(主控節點容器)包含3個Agent:容錯Agent(FTA)、日志收集Agent(LCA)和主控Agent(MA),MA屬于臺風預報系統的業務處理Agent,主要負責計算任務的分發,不是本文研究重點,故不進行詳細敘述;之后是3個computeContainer(計算節點容器),每個computeContainer里包含有計算Agent(CA)、局部檢測Agent(LDA)、日志Agent(LA)、恢復Agent(RA)以及負載平衡Agent(LBA),LBA負責計算各計算節點的負載值和計算能力值,為MA分發任務和FTA申請異機恢復時選擇節點提供參考。為方便操作,特制定Agent命名規則如下:(XXXXAgent)_(IP)_(端口號)。如:
recoverAgent_218.193.124.101_1013@Softlab-C-PC:1099/JADE
其中,“@”之前為本文系統指定的Agent名,“@”之后則為JADE平臺自動添加的標識。
5.2 結論
經過比較大量的測試,各Agent本機恢復均可在1 s內完成;異機恢復花費時間較長,在2 s到3 s之間。系統功能和性能上均符合本文前述內容的要求。由此印證本文提出的兩層失效檢測模型和改進行的REDO恢復策略真實可行。
Agent所表現出來的自主性、反應性、交互性、協作性、主動性和智能性等特性,為構建容錯中間件提供了一種新的技術途徑。采用兩層的失效檢測模型,局部檢測Agent與全局檢測Agent等多Agent分工合作,能夠較好地協作完成失效檢測的工作。定點恢復的采用大大的提高了系統的效率。基于多Agent的容錯中間件融合了Agent技術、容錯技術與中間件技術,能夠為分布式容錯應用開發提供框架支持,提供自主的、協作的失效檢測和恢復服務,簡化業務應用開發過程,提高系統的效率和魯棒性。
編輯:jq
-
人工智能
+關注
關注
1791文章
47294瀏覽量
238578 -
MAS
+關注
關注
0文章
16瀏覽量
10684 -
失效檢測
+關注
關注
0文章
4瀏覽量
5857
發布評論請先 登錄
相關推薦
評論