摘要:為了提高分布應用的健壯性,通常需要開發人員編寫相應的容錯代碼。現有的CORBA構件模型通過定義構件的端口特征,以組裝的方式實現代碼的二進制級復用,它使用戶能夠快速開發和部署分布應用。在此基礎上,如何在構件模型下快速靈活地建立容錯應用成為一個令人關注的話題。通過設計構件模型下的容錯體系結構,提供了快速靈活開發容錯應用的機制,并提出了解決兩種失效類型的容錯策略和算法。
關鍵詞:分布構件;容錯;策略
中圖分類號:TP311.52文獻標志碼:A
文章編號:1001-3695(2007)12-0134-03
隨著分布式應用的發展,CORBA作為一種成熟的中間件技術,具有跨操作系統、跨平臺、跨語言等強大的互操作性,但其復雜性成為它在企業中應用的主要障礙。分布構件技術以降低中間件平臺的復雜性、支持分布式企業應用和代碼的二進制重用[1,2]為目標,已成為中間件技術的主要發展方向。1997年6月,CORBA平臺上的構件模型(CORBA component model,CCM )被正式提入OMG組織的研究日程,OMG組織發布了CCM的RFP;2002年6月,CCM正式成為CORBA 3.0規范的一部分。在此期間,許多大學和組織均對CORBA構件技術進行了研究,并開發出了相應的原型平臺,如OpenCCM[3,4]、MicoCCM[5]、K2-CCM、EJCCM等。CORBA構件模型作為一種企業計算中間件還需要具備高可用性,因此,如何在CORBA構件模型上建立高可用的系統成為一個重要的課題。20世紀90年代,許多大學設計和實現了基于CORBA平臺的容錯系統。例如Piranha[6]系統通過在ORB中使用組通信機制提供冗余對象的服務;Eternal[7]系統通過使用截取器(interceptor)來實現容錯;容錯CORBA規范[8]通過在一個IOR中封裝多個profile提供primary-backup容錯策略。但是,如何充分利用CORBA構件模型的優勢,靈活、快速地建立一個容錯系統的研究還很少。
本文從分析構件模型的優勢入手,闡述了在分布構件模型下快速建立容錯系統的主要思想。在此基礎上提出了AARC(assembly architecture based on replicated component)容錯體系結構,詳細地描述了如何在AARC結構上建立容錯應用。最后給出了該結構下的四種實用的容錯算法。
1AARC體系結構
分布構件技術將一個應用劃分為構件和容器兩部分。其中構件是應用的業務邏輯,容器提供了應用的運行和管理環境。容器概念的引入為應用服務器對象的容錯策略和機制提供了良好的空間。基于構件平臺的容錯策略和機制的實現應當使構件的開發者不必編寫與容錯相關的代碼就可以選擇多種容錯策略,并按照要求生成各種容錯代碼。這樣,CCM用戶就可以快速地開發容錯應用,并聲明他需要使用的由容器提供的容錯策略。
基于上述思想,筆者提出了一種基于CCM平臺的容錯體系結構。為方便建模首先給出相關定義。
定義1管理域Domain=∪ni=0ComponentServeri。應用涉及的構件服務器構成一個管理域。
定義2構件服務器ComponentServer={〈Container,Component〉i|0≤i<n|}。構件服務器由多個容器和構件的序偶組成。
定義3容器Container={Policyi|0≤i<n}。容器管理了相應構件的各種運行時策略。
定義4組裝件Assembly={Componenti,Connectionjk|0≤i, j,k<n}。組裝件由一系列構件以及它們之間的連接構成。構件的組裝是CCM代碼復用的集中體現。
組裝件是構成用戶應用的基石,建立具有容錯功能的組裝件可以增強應用的可用性。因此,在筆者的CCM系統中定義了與容錯相關的策略集FPolicie。其中FPolicies={fail-silent,LMRT-fail-silent,Byzantine,FPoliciesContainer,LMRT-Byzantine}。
定義5容錯構件ReplicatedComponent={Agent,Componenti|0≤i<n,Componentj=Componentk,0≤j,k<n}。
2AARC的容錯研究
在AARC中,利用冗余的構件來提高組裝件的可用性對CCM的調用機制提出了新的要求。對于處理Byzantine類型的失效需要同時將請求發送到多個冗余的構件中才能發現這種失效并進行恢復。因此,需要將一個同步的請求分解為多個異步請求來達到多個請求并行執行的目的。文獻[7]中使用了CORBA的異步消息調用機制來完成請求的并行激發。但是,CORBA的異步調用機制由ORB內核提供,應答處理對象由ORB管理,這樣很難將一個冗余的請求與多個應答對應起來。基于異步消息的冗余機制需要內核的支持,這會影響系統的互操作性。
筆者提出了一個基于one way調用和構件事件端口的容錯機制。首先引入一個特殊的構件稱做代理構件,它負責接收其他構件發送過來的調用請求,并將請求同時發送給多個冗余的服務構件以達到多個冗余請求的并行執行。代理構件還負責收集所有的應答并進行過濾,最后將正確的結果返回給調用者構件。例如下面的構件描述構成組裝件的一部分。組裝件中的其他構件會使用math構件的the_comp刻面來進行對數運算。
interface Compute {
double ln(in long val);
};
component Maths {
privodes Compute the_comp;
};
通過一個特殊的容錯構件編譯器,筆者將這個構件描述映射為一個容錯的IDL 3.0的描述。映射后的構件描述如下:
eventtype Ret_Compute_ln {
public CORBA::Cookie cookie;
public double ret;
factory create(in CORBA::Cookie id, in long ret);
};
interface Compute {
oneway void ln(in CORBA::Cookie id, in long val);
};
component Maths {
privodes Compute the_comp;
publishes Ret_Compute_ln
the_ Ret_Compute_ln;
};
此外還要為該容錯版本的構件映射一個代理構件的描述,代理構件封裝了容錯邏輯的細節。其描述如下:
eventtype Ret_Compute_ln {
public CORBA::Cookie cookie;
public double ret;
factory create(in CORBA::Cookie id, in long ret);
};
interface Compute {
double ln(in CORBA::Cookie id, in long val);
};
component Maths {
privodes Compute the_comp;
consumes Ret_Compute_ln
the_ Ret_Compute_ln;
};
容錯應用的開發者只需要按照通常方式描述一個構件,并通過容錯工具為構件生成容錯的IDL 3.0映射和為容錯構件生成構件實現的包裝類,來簡化和加速容錯應用的開發。在代理構件的生成代碼中,容錯工具為構件的各種策略均生成了相應的代碼。容錯構件在部署和組裝后就可以從容器中獲取相應的容錯策略來執行相應的容錯算法。
3AARC的容錯算法
本節討論代理構件針對上述四種容錯策略提供的容錯算法。為了方便算法描述,本文進行如下定義:
a)容錯構件由n個副本構成,它們刻面的引用分別為 refi。其中0≤i<n。
b)容錯構件的客戶請求為request,代理構件的應答為reply。
c)每一個構件的副本應答為replyi。其中0≤i<n。
此外,算法中還需要一個同步變量,它由event標志。
3.1針對fail-silence失效的容錯算法
Fail-silence失效也稱做fail-stop失效。當一個構件不能工作時,該構件不會對相應的請求給出應答。針對這種失效,筆者提出了相應的溫備份算法FSR(fail-silence recovery)。FSR算法如下:
input request, replicated components group
G={refi|0≤i output reply for each replicated component refi∈G create Event send request to refi wait Event if has no system exception then reply ← replyi return reply end if end for throw exception 相應的代理構件接收應答算法RR(reply receive)如下: input notification service event, Event output replyi if no exception received then replyi←retrieve reply form notification service event set Event else exceptioni←system exception set Event end if 算法FSR和RR共同完成單個構件的fail-silence失效恢復。之所以稱為溫備份是由于處于備份狀態的構件,通常情況下在一次調用中不接收和處理請求,只有在主構件失效時才參加到處理請求的任務中。該算法可以處理多個構件副本發生fail-silence失效的情況。其中失效的同類構件副本書不能大于n-1;否則算法拋出構件失效異常。 3.2減少fail-silence失效的平均恢復時間 LMRT-fail-silence容錯策略針對fail-silence失效提供了一種最小平均恢復時間的容錯算法LMRT-FSR(least mean recovery time-Fail-silence recovery),其描述如下: input request, replicated components group G={refi| 0≤ i output reply for each replicated component refi ,refj∈G create Event send request to refi send request to refj wait Event if replyi is not 1 then reply←replyi else if replyj is not 1 reply←replyj end if if reply is not 1 then return reply end if end for throw exception 相應的代理構件接收應答的算法也使用上述RR算法。算法LMRT-FSR和RR 結合使用,通過同時將請求發送給兩個構件副本的熱備份方法進行容錯。處理請求的兩個構件副本在本次請求中稱為活躍構件。處理請求的兩個副本中,只要有一個給出應答,代理構件就可以將應答返回給實際的調用者。LMRT-FSR算法在一個活躍構件副本fail-silence失效時仍然能夠繼續工作,并且它的平均恢復時間t≈0。這是通過花費額外的計算資源得到的。實際應用中,可以根據應用的需求擴大活躍備份構件的數目。 3.3針對Byzantine失效的容錯算法 通常在軟件中,常見的失效除了fail-silence外,還可能發生Byzantine失效。當一個構件發生Byzantine失效時,它不會發生任何異常,也不會拒絕請求。相反,它會針對其請求偶然地給出一個錯誤的應答,構件的使用者很難發現構件的失效。上述FSR和LMRT-FSR算法不能解決Byzantine失效帶來的問題。針對前面定義的Byzantine策略,設計了一個恢復Byzantine失效的容錯算法BR,其描述如下: input request, replicated components group G={refi| 0≤i output reply for each replicated component refi ,refj∈G create Event1 create Event2 send request to refi send request to refj wait Event1 wait Event2 if has no exception then if replyi equals replyj then reply←replyi return reply end if end if end for throw exception 算法BR與RR一起可以發現和恢復Byzantine失效的構件請求。BR通過比較來自兩個活躍構件副本的應答來發現Byzantine失效。一旦發生失效,則重新執行處理過程。BR算法與LMRT-Fail-silence算法相比,使用了等量的計算資源。盡管帶來了額外的應答處理開銷,但是它卻能夠發現和恢復更高級的失效類型。 3.4降低Byzantine失效容錯算法的恢復時間 為了達到更少的平均恢復時間,構件平臺提供了一種LMRT-Byzantine策略。這種策略供構件的部署者使用,通過它聲明在失效管理中使用LMRT-BR容錯算法。LMRT-BR算法如下: input request, replicated components group G={refi|0≤i output reply for each replicated component refi,refj,refk∈G create Event1, Event2, Event3 send request to refi send request to refj send request to refk wait Event1, Event2,Event3 if has no more than one exception then if replyi equals replyj then reply←replyi return reply else if replyj equals replyk then reply ← replyj return reply else if replyk equals replyi then reply ← replyk return reply end if end if end for throw exception 對應LMRT-BR的應答處理算法同RR算法。它通過增加一次請求中活躍副本的個數達到減少平均恢復時間的目的。只要有至少兩個副本給出應答,并且應答的結果相同就可以認為執行成功。這樣,不僅在最多只有一個活躍構件發生Byzantine失效的情況恢復了正確的應答,而且平均恢復時間t≈0。這極大地提高了系統的可用性。實際應用中,可以通過修改和配置算法的參數對多個活躍構件發生Byzantine失效的情況進行恢復。 4結束語 本文提出了一個在分布構件模型下快速建立容錯應用的AARC體系結構。以對數計算構件的例子闡述了該模型下,通過IDL描述隱式地將構件普通定義轉換為容錯定義的方法。使用構件的事件端口,在將一個同步請求分解為多個異步請求的基礎上,給出四種高可用的容錯算法,并對它們的特點進行了詳細的分析。在進一步研究中,將這些容錯結構和算法與負載均衡綜合考慮,從而推動CCM構件技術逐步走向實用和成熟。 參考文獻: [1]EDDON G,EDDON H.Inside distributed COM[M].Redmond,WA:Microsoft Press,1998. [2]BOX D.Essential COM[M].Mass:Addison-Wesley,1998. [3]MARVIE R,MERLE P. CORBA component model: discussion and use with OpenCCM[EB/OL].[2006].http://corbaweb.lifl.fr/OpenCCM/CCM.html. [4]MERLE P. OpenCCM[C]//Proc of the 1st Object Web Conference.Paris: [s.n.],2001:30-31. [5]The MICO CORBA component project[EB/OL].[2006].http://www.fpx.de/MicoCCM. [6]MAFFIES S. Piranha: a CORBA tool for high availability[J].IEEE Computer, 1997,30(4): 59-66. [7]NARASIMHAN P,MOUSER L E,MELLIAR-Smith P M.Exploiting the Internet inter-ORB protocol to provide CORBA with fault-tolerance[C]//Proc of the 3rd USENIX Conference on object-Oriented Technologies and Systems(COOTS). Oregon:[s.n.],1997. [8]OMG. Fault tolerant CORBA specification v1.0[S].2000. “本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”