呂躍鵬 劉俊陽 楊 喆
北京航天自動控制研究所,北京100854
運(yùn)載火箭測發(fā)控軟件的主要任務(wù)是完成火箭的測試和發(fā)射任務(wù),它具有流程控制、數(shù)據(jù)處理、分析判讀和人機(jī)交互等功能。測發(fā)控軟件大多采用分布式并行架構(gòu),即由業(yè)務(wù)軟件在網(wǎng)絡(luò)系統(tǒng)上分布運(yùn)行,構(gòu)成并行處理的軟件系統(tǒng)[1]。在故障發(fā)生時,這種非集中模式下軟件及其業(yè)務(wù)的遷移、恢復(fù)存在很多困難,在B/S架構(gòu)下由后臺業(yè)務(wù)群集中實(shí)現(xiàn)冗余方案,能使冗余技術(shù)的實(shí)施更加靈活、便捷。同時,隨著某些火箭測發(fā)控系統(tǒng)對測試設(shè)備產(chǎn)品化、低成本、輕量化的發(fā)展要求,計(jì)算機(jī)資源和測控設(shè)備的配置越來越少[2-3]。為了更好地實(shí)現(xiàn)業(yè)務(wù)隔離、降低耦合、提高可靠性,需要在有限的計(jì)算機(jī)資源基礎(chǔ)上利用虛擬化技術(shù)實(shí)現(xiàn)關(guān)鍵業(yè)務(wù)和功能的冗余,更好地保障發(fā)射可靠性。虛擬化技術(shù)是通過軟件實(shí)現(xiàn)將計(jì)算機(jī)及物理設(shè)備軟件化,隱藏真實(shí)的計(jì)算機(jī)硬件,抽象出多個計(jì)算機(jī)系統(tǒng)軟硬件資源,這些資源相互獨(dú)立,為用戶提供隔離的操作接口和交互功能。由于虛擬化具有很好的可移植性、容錯性,特別是其中輕量級虛擬化容器技術(shù)的應(yīng)用,能夠更加完善測發(fā)控軟件冗余技術(shù)的實(shí)現(xiàn),同時又在很大程度上保持了原有軟件的實(shí)時性。
本文提出的基于虛擬化的測發(fā)控軟件前后端業(yè)務(wù)的冗余技術(shù),為提高虛擬化環(huán)境下測發(fā)控軟件的可靠性,提供了一條有效途徑。
測發(fā)控軟件按業(yè)務(wù)可以劃分成控制域和交互域2個業(yè)務(wù)域,同時存在一個獨(dú)立的數(shù)據(jù)庫系統(tǒng),每個業(yè)務(wù)域又是多個業(yè)務(wù)(功能)的集合??刂朴虬鞒炭刂仆ㄐ艠I(yè)務(wù)容器和協(xié)議處理業(yè)務(wù)容器。交互域包括前后端交互業(yè)務(wù)容器、數(shù)據(jù)處理業(yè)務(wù)容器。控制域是軟件系統(tǒng)的核心業(yè)務(wù),用于解析操作請求并控制設(shè)備完成測試發(fā)射任務(wù),以主從冗余方式熱備工作。交互域用于獲取、解析采集的數(shù)據(jù),提供可視化服務(wù)和數(shù)據(jù)存儲功能。數(shù)據(jù)庫用于記錄兩個域間包括交互數(shù)據(jù)、操作數(shù)據(jù)在內(nèi)的全部信息[4]。
測發(fā)控軟件以業(yè)務(wù)功能為單元,部署到虛擬化容器(下文簡稱容器)上,多個相同業(yè)務(wù)的容器相互配合構(gòu)成虛擬化業(yè)務(wù)域,形成對業(yè)務(wù)的主備冗余。測發(fā)控軟件虛擬化平臺的組成如圖1所示。
圖1 虛擬化測發(fā)控平臺架構(gòu)圖
本文建立適合于測發(fā)控軟件的虛擬化平臺,前后端交互業(yè)務(wù)容器采用tomcat 作為業(yè)務(wù)容器基礎(chǔ)鏡像,并整合交互域中的前后端交互業(yè)務(wù)(自研的WEB服務(wù)端軟件),打包成新鏡像,以容器的形式進(jìn)行部署??刂朴蚝徒换ビ蛑袛?shù)據(jù)處理業(yè)務(wù)容器,都是基于linux作為基礎(chǔ)鏡像,并更新網(wǎng)絡(luò)、通信、java等相關(guān)工具包和依賴庫,重新整合打包成新鏡像,以多個主備容器的方式運(yùn)行在虛擬化平臺上[5]。
前后端交互業(yè)務(wù)容器配置文件Dockerfile主要內(nèi)容如下:
# Dockerfile
FROM mywebserver:v2
ADD MyComMidDocker_war.war/usr/local/tomcat/webapps/
ADD TomcatLib/* /usr/local/tomcat/lib/
CMD ["catalina.sh", "run"]
控制域或交互域數(shù)據(jù)處理業(yè)務(wù)容器的LINUX容器配置文件Dockerfile主要內(nèi)容如下:
#Dockerfile
FROM ubuntu:latest
……
COPY FlowControl ~/DockerImage/
WORKDIR ~/DockerImage/
CMD ["./FlowControl"]
通過上述方法對基礎(chǔ)鏡像進(jìn)行包裝,擴(kuò)充鏡像中的庫和工具的支持,從而可以通過研制的鏡像來形成測發(fā)控軟件后端業(yè)務(wù)的容器群,達(dá)到容器間相互冗余的目的[6]。
控制域包括了流程控制業(yè)務(wù)容器和協(xié)議處理業(yè)務(wù)容器。流程控制業(yè)務(wù)用于驅(qū)動測試流程,通過向協(xié)議處理業(yè)務(wù)發(fā)出命令消息,實(shí)現(xiàn)控制和測試協(xié)議,并同現(xiàn)場設(shè)備進(jìn)行交互。
協(xié)議處理業(yè)務(wù)是依據(jù)數(shù)據(jù)幀格式協(xié)議解析流程控制業(yè)務(wù)的命令消息,并依據(jù)數(shù)據(jù)協(xié)議將命令消息轉(zhuǎn)發(fā)給箭上或者地面設(shè)備,控制設(shè)備執(zhí)行。
流程控制業(yè)務(wù)和協(xié)議處理業(yè)務(wù)部署在多個虛擬化容器中,相同業(yè)務(wù)的不同容器形成主從冗余。本文對主份施行熱備方式的業(yè)務(wù)冗余策略,對備份施行冷備方式的容器冗余策略。熱備份方式主要通過心跳和業(yè)務(wù)通信等狀態(tài)信息判斷業(yè)務(wù)的健康狀況,并實(shí)時切換主從業(yè)務(wù)。冷備份方式主要通過監(jiān)控充當(dāng)備份角色的業(yè)務(wù)載體容器本身的健康狀況,判斷故障和重新啟動備份容器。即業(yè)務(wù)容器啟動后管理模塊定期發(fā)送HTTP請求到容器,等待容器響應(yīng);一旦等待時間超時,則將判斷容器故障,依據(jù)配置信息對問題容器進(jìn)行重啟,以保持從容器的原有數(shù)量。下面主要對熱備方式進(jìn)行論述。
2.1.1 流程控制業(yè)務(wù)的冗余技術(shù)
流程控制業(yè)務(wù)容器在測試開始時提供主、從2種狀態(tài)的選擇,其中一臺流程控制業(yè)務(wù)容器運(yùn)行主機(jī)狀態(tài)程序,其它流程控制業(yè)務(wù)容器運(yùn)行從機(jī)狀態(tài)程序。流程控制業(yè)務(wù)主機(jī)控制流程,從機(jī)容器充當(dāng)監(jiān)聽角色,并接收主機(jī)狀態(tài)程序發(fā)來的測試狀態(tài)信息。主機(jī)狀態(tài)控制整個測試發(fā)控流程,并將當(dāng)前的工作狀態(tài)通知從機(jī)狀態(tài)程序,使運(yùn)行在2個容器上的測發(fā)控程序同步熱備運(yùn)行。當(dāng)運(yùn)行主機(jī)狀態(tài)的容器發(fā)生故障時,如“心跳”停止、通信中斷等,運(yùn)行從機(jī)狀態(tài)的流程控制業(yè)務(wù)容器可通過前端的流程控制頁面人為切換為主機(jī)狀態(tài),接管流程控制工作,而原運(yùn)行主機(jī)狀態(tài)的流程控制業(yè)務(wù)容器,可視故障狀況人為決定是否重新初始化進(jìn)入從機(jī)狀態(tài)工作。
2.1.2 協(xié)議處理業(yè)務(wù)的冗余技術(shù)
協(xié)議處理業(yè)務(wù)容器也采用主從冗余方案,1個時刻僅有1個控制域容器能夠控制執(zhí)行設(shè)備協(xié)議處理業(yè)務(wù),協(xié)議處理業(yè)務(wù)容器將完全自主實(shí)現(xiàn)較為復(fù)雜的冗余策略;
1)流程控制業(yè)務(wù)容器向協(xié)議處理業(yè)務(wù)主從容器均發(fā)送指令,協(xié)議處理業(yè)務(wù)主從容器均回復(fù)確認(rèn)幀;
2)協(xié)議處理業(yè)務(wù)由當(dāng)班容器執(zhí)行動作,執(zhí)行完成后,向流程控制業(yè)務(wù)主從容器均上報(bào)執(zhí)行結(jié)果(若收到指令時是協(xié)議處理業(yè)務(wù)主容器當(dāng)班,在執(zhí)行動作期間發(fā)生了主從切換,則由協(xié)議處理業(yè)務(wù)從容器回復(fù)執(zhí)行結(jié)果);
3)協(xié)議處理業(yè)務(wù)容器采集到的模擬量、狀態(tài)量等,通過組播方式向交互域中數(shù)據(jù)處理業(yè)務(wù)容器發(fā)送;
4)協(xié)議處理業(yè)務(wù)主容器向協(xié)議處理業(yè)務(wù)從容器發(fā)送心跳信息,心跳信息中包含協(xié)議處理業(yè)務(wù)主容器狀態(tài),協(xié)議處理業(yè)務(wù)從容器若一段時間未收到心跳信息,或者心跳信息顯示主容器狀態(tài)異常,則進(jìn)行自動切換到最先啟動的從容器;
5)流程控制業(yè)務(wù)容器可以通過主從切換指令強(qiáng)制切換協(xié)議處理業(yè)務(wù)容器的當(dāng)班狀態(tài);
控制域的數(shù)據(jù)流如圖2所示,其中包括了流程控制業(yè)務(wù)容器主從間通信、協(xié)議處理業(yè)務(wù)容器主從間通信,以及兩個域之間的通信方式。
流程控制業(yè)務(wù)容器數(shù)據(jù)流圖,如圖3所示。
流程控制業(yè)務(wù)主容器在啟動時可以選擇主從狀態(tài),運(yùn)行處于主狀態(tài)時,通過和協(xié)議處理業(yè)務(wù)的通信,控制包括PLC、PXI、LXI、測試計(jì)算機(jī)等設(shè)備終端,執(zhí)行測試及發(fā)射控制任務(wù)。同時,流程控制業(yè)務(wù)主容器將測試項(xiàng)目、步序、數(shù)據(jù)等信息發(fā)送給控制域從容器,供從容器跟蹤當(dāng)前的測試進(jìn)程,當(dāng)發(fā)生切換時能無縫接續(xù)。
圖2 控制域冗余通信方式圖
圖3 流程控制業(yè)務(wù)容器數(shù)據(jù)流圖
協(xié)議處理業(yè)務(wù)容器主從數(shù)據(jù)流圖,如圖4所示。
協(xié)議處理業(yè)務(wù)主容器啟動后,接收流程控制業(yè)務(wù)容器發(fā)送的設(shè)備控制命令、等待設(shè)備回令或數(shù)據(jù)并發(fā)送給流程控制業(yè)務(wù)容器,同時接收對設(shè)備的點(diǎn)采和頻采數(shù)據(jù)消息并轉(zhuǎn)發(fā)給交互域。主從容器間進(jìn)行心跳檢測,多個從容器發(fā)現(xiàn)主心跳信息異常時切換主容器,由健康的從容器接續(xù)運(yùn)行。
控制域冗余數(shù)據(jù)結(jié)構(gòu)分3類:
1)流程控制業(yè)務(wù)主從容器間
流程控制業(yè)務(wù)主從容器間通信內(nèi)容統(tǒng)稱為測試狀態(tài)信息,主要包含了命令、回令響應(yīng)和消息通告3種數(shù)據(jù)消息格式。命令消息包括了測試項(xiàng)目通告命令(TestConfCMD)、查詢控制命令(CtrSearchCMD)、回令響應(yīng)消息(RespMsg);測試通告消息只包含測試狀態(tài)通告消息(TestStatusMsg)。
測試項(xiàng)目通告命令(TestConfCMD)用于主容器和從容器保持?jǐn)?shù)據(jù)一致性。消息內(nèi)容包含對應(yīng)測試編號、測試項(xiàng)目代碼、測試項(xiàng)目名稱、測試項(xiàng)目步驟和測試數(shù)據(jù)。測試編號是選擇的測試項(xiàng)目號;測試項(xiàng)目代碼是測試項(xiàng)目號對應(yīng)的名稱代碼;測試項(xiàng)目名稱是測試項(xiàng)目號對應(yīng)的名稱;測試項(xiàng)目步驟為測試項(xiàng)目對應(yīng)的流程步編號;測試數(shù)據(jù)為測試過程中點(diǎn)采的數(shù)據(jù),包括了數(shù)據(jù)名稱、數(shù)據(jù)的實(shí)測值、該項(xiàng)數(shù)據(jù)的閾值。
查詢控制命令消息(CtrSearchCMD)是主容器向從容器發(fā)送,查詢從響應(yīng)主的命令任務(wù),包含ID號和命令參數(shù)2種數(shù)據(jù)。ID號是當(dāng)前需要給從容器發(fā)送的控制命令,共有3種命令,分別是清空命令、主從容器切換命令、主查詢從容器是否允許切換命令;命令參數(shù)為3種命令的操作內(nèi)容,清空命令對應(yīng)的清空流程列表的操作命令消息;切換命令對應(yīng)的切換與否的命令消息;查詢命令對應(yīng)的切換允許的回應(yīng)狀態(tài)命令消息。
圖4 協(xié)議處理業(yè)務(wù)容器數(shù)據(jù)流圖
回令響應(yīng)消息(RespMsg)用于從設(shè)備回復(fù)主設(shè)備確認(rèn)命令,包含命令I(lǐng)D和命令回復(fù)確認(rèn)標(biāo)志。命令I(lǐng)D為主設(shè)備的控制命令I(lǐng)D號;命令回復(fù)確認(rèn)為獲取命令后的應(yīng)答狀態(tài)碼。
測試狀態(tài)通告消息(TestStatusMsg)是主從間通信保持當(dāng)前測試狀態(tài)一致,同時在切換后不影響整個流程的一種措施,包含測試步序號和運(yùn)行狀態(tài)。測試步序號為當(dāng)前測試項(xiàng)目及當(dāng)前測試步驟編號,運(yùn)行狀態(tài)為當(dāng)前流程運(yùn)行狀態(tài)信息。
2)協(xié)議處理業(yè)務(wù)主從容器間
協(xié)議處理業(yè)務(wù)主從容器間使用心跳信息進(jìn)行通信,通信標(biāo)識為DHeartMsg,用于判斷當(dāng)前主容器是否工作正常。
心跳信息(DHeartMsg)僅包含了主機(jī)的在位信息。
3)控制域內(nèi)
控制域內(nèi)通信是在流程控制業(yè)務(wù)容器和協(xié)議處理業(yè)務(wù)容器之間進(jìn)行的,通信內(nèi)容為冗余控制命令,名稱為CMDMsg。流程控制業(yè)務(wù)容器將控制命令發(fā)送給協(xié)議處理業(yè)務(wù)容器,后者通過設(shè)備號封裝對應(yīng)的數(shù)據(jù)幀,和真實(shí)設(shè)備進(jìn)行通信。
控制命令(CMDMsg)包含接受控制命令的設(shè)備ID號和具體命令消息。設(shè)備ID號為接受控制命令的設(shè)備號,命令消息為對設(shè)備操作的命令內(nèi)容。
交互域是人員操作交互的業(yè)務(wù)集合,包括人機(jī)交互業(yè)務(wù)、前后端交互業(yè)務(wù)容器、數(shù)據(jù)處理業(yè)務(wù)容器。人機(jī)交互業(yè)務(wù)與前后端交互業(yè)務(wù)容器采用B/S架構(gòu)設(shè)計(jì)。人機(jī)交互業(yè)務(wù)運(yùn)行在前端瀏覽器上,前后端交互業(yè)務(wù)容器提供后端與對前端的服務(wù)。
人機(jī)交互業(yè)務(wù)由數(shù)據(jù)交互頁面和流程控制頁面構(gòu)成。前者顯示內(nèi)容來自數(shù)據(jù)處理業(yè)務(wù)容器處理解析后的點(diǎn)采和頻采設(shè)備數(shù)據(jù),再經(jīng)可視化處理后呈現(xiàn)在頁面上,供工作人員觀察分析;后者提供可視化操作,使得用戶能夠通過簡單的操作即可和虛擬化平臺及真實(shí)設(shè)備進(jìn)行交互。前后端交互業(yè)務(wù)容器支持與人機(jī)交互業(yè)務(wù)中的多種頁面進(jìn)行通信,解析來自頁面的請求信息和數(shù)據(jù),并將解析完成的命令發(fā)送給控制域的流程控制業(yè)務(wù)容器進(jìn)行處理,數(shù)據(jù)參數(shù)訂閱信息發(fā)送給數(shù)據(jù)處理業(yè)務(wù)容器。數(shù)據(jù)處理業(yè)務(wù)容器負(fù)責(zé)建立和連接數(shù)據(jù)庫,存儲數(shù)據(jù),同時解析來自控制域協(xié)議處理業(yè)務(wù)容器對設(shè)備的頻采數(shù)據(jù),并依據(jù)訂閱信息進(jìn)行發(fā)布。
交互域的冗余技術(shù)體現(xiàn)在頁面故障恢復(fù)和登陸安全性2個方面。頁面故障需要恢復(fù)時,只需重新訪問前后端交互業(yè)務(wù)容器IP和端口號即可,登陸安全性措施是為保證流程控制頁面控制權(quán)的唯一性。
流程控制頁面在故障恢復(fù)時,需要2個部分的信息,即心跳信息和頁面操作記錄。流程控制頁面正常運(yùn)行時,每100ms發(fā)送給后端交互業(yè)務(wù)容器1次心跳信息,超過1s后端交互業(yè)務(wù)容器未收到心跳信息,則判斷頁面故障退出,重新啟動頁面;頁面操作記錄用于存儲對頁面的操作痕跡,并更新數(shù)據(jù)庫中的操作記錄表。
數(shù)據(jù)交互頁面的故障恢復(fù)技術(shù),依賴心跳信息和參數(shù)選項(xiàng)記錄。心跳信息同流程控制頁面的心跳信息記錄,參數(shù)選項(xiàng)記錄用于記錄交互頁面訂閱的數(shù)據(jù)參數(shù),虛擬化平臺依據(jù)訂閱信息定期發(fā)布更新數(shù)據(jù),并在交互頁面進(jìn)行顯示。
登陸安全性針對控制頁面,出于對設(shè)備控制功能和安全性的需求,必須保證同一時刻有且僅有1個控制頁面可以操作,避免多個用戶同時登陸流程控制頁面以及后登陸用戶可以替換先登陸用戶。流程控制頁面登陸安全性技術(shù),在前后端交互業(yè)務(wù)容器中實(shí)現(xiàn)。前后端交互業(yè)務(wù)容器需要將頁面登陸信息作記錄,并在記錄中更新流程控制頁面在位個數(shù)。
交互域的通信方式圖和數(shù)據(jù)流圖分別如圖5和圖6所示,其中包括了前端2種頁面和前后端交互業(yè)務(wù)的通信、前后端交互業(yè)務(wù)容器和數(shù)據(jù)處理業(yè)務(wù)容器的通信,以及數(shù)據(jù)處理業(yè)務(wù)和數(shù)據(jù)庫的通信。
圖5 交互域冗余通信方式圖
圖6 交互域數(shù)據(jù)流圖
交互域的通信使用B/S模式的Ajax請求響應(yīng)模式,頁面通過json將數(shù)據(jù)發(fā)送給前后端交互業(yè)務(wù)容器,并響應(yīng)業(yè)務(wù)容器返回的數(shù)據(jù)。
數(shù)據(jù)處理業(yè)務(wù)容器和數(shù)據(jù)庫間通信數(shù)據(jù)統(tǒng)稱為解析數(shù)據(jù);數(shù)據(jù)處理業(yè)務(wù)容器和協(xié)議處理業(yè)務(wù)容器間通信數(shù)據(jù)統(tǒng)稱為原始數(shù)據(jù)。
交互域冗余技術(shù)使用的數(shù)據(jù)結(jié)構(gòu)有:
1)流程控制頁面通信數(shù)據(jù)結(jié)構(gòu)
請求響應(yīng)數(shù)據(jù)中用于流程控制頁面和后端通信的消息包括心跳信息(CPHeartMsg)和頁面操作記錄(CPOptMsg)2種。
心跳信息(CPHeartMsg)用于判斷流程控制頁面或交互頁面是否正常,內(nèi)容包含頁面編號和頁面重啟標(biāo)志位。頁面編號為流程控制或交互頁面編號;頁面重啟標(biāo)志位,用于區(qū)分頁面因故障關(guān)閉或正常關(guān)閉。
頁面操作記錄(CPOptMsg)用于傳遞給數(shù)據(jù)庫保存頁面交互的所有操作,內(nèi)容包含流程名稱、流程步和流程運(yùn)行狀態(tài)。其中,流程步為當(dāng)前流程運(yùn)行對應(yīng)的步序號;流程運(yùn)行狀態(tài)標(biāo)識當(dāng)前流程運(yùn)行狀態(tài)為全流程運(yùn)行、單步運(yùn)行或終止運(yùn)行。
2)數(shù)據(jù)交互頁面通信數(shù)據(jù)結(jié)構(gòu)
請求響應(yīng)數(shù)據(jù)中用于數(shù)據(jù)交互頁面和后端通信的消息包括心跳信息(VPHeartMsg)和參數(shù)選項(xiàng)(VPParaMsg),心跳信息數(shù)據(jù)結(jié)構(gòu)定義同1)。
參數(shù)選項(xiàng)(VPParaMsg)記錄交互頁面編號和交互頁面訂閱的參數(shù)數(shù)據(jù)集合。
3)數(shù)據(jù)庫表數(shù)據(jù)結(jié)構(gòu)
數(shù)據(jù)庫包括登陸信息表、流程狀態(tài)表、存儲數(shù)據(jù)表、前端交互操作表在內(nèi)的4種數(shù)據(jù)表。
登錄頁面信息數(shù)據(jù)庫主要包含網(wǎng)頁類型標(biāo)識碼、網(wǎng)頁類型、交互頁面和流程控制頁面的數(shù)量信息。如表1所示。
表1 登陸頁面信息表
表2用于記錄設(shè)備點(diǎn)采和頻采后解析完成的數(shù)據(jù),及數(shù)據(jù)對應(yīng)的上下限值,更新數(shù)據(jù)值,保證數(shù)據(jù)的有效性。
表2 存儲數(shù)據(jù)表
交互操作表(表3)用于記錄對頁面的操作記錄,為還原頁面狀態(tài)提供參考。依據(jù)頁面布局將頁面可分為多個區(qū)域,頁面操作后立即更新對應(yīng)區(qū)域號的數(shù)值。
表3 交互操作記錄表
流程狀態(tài)表(表4)用于記錄流程運(yùn)行狀態(tài),流程名編號為測試項(xiàng)目的編號;流程步號用于記錄流程運(yùn)行步序號;流程狀態(tài)中0x00表示開始全部流程、0x01表示單步運(yùn)行流程、0x02表示停止流程運(yùn)行。
表4 流程狀態(tài)表
本文對冗余技術(shù)方案的主要冗余功能和性能進(jìn)行實(shí)驗(yàn)驗(yàn)證。
容器級健康狀態(tài)檢查工作包括:管理模塊和容器進(jìn)行HTTP請求響應(yīng)通信,定期檢查容器是否有反饋,設(shè)置超時響應(yīng)時間(2s),超過后,則認(rèn)為容器已經(jīng)失效,需要重新啟動容器。業(yè)務(wù)容器健康監(jiān)測配置文件偽代碼如下所示:
Master.yaml文件如下:
apiVersion: v1
kind: Pod
metadata:
labels: myweblive
name: weblive
spec:
……
livenessProbe:
httpGet:
path:/_status/healthz
port: 80
initialDelaySeconds: 15
timeoutSeconds: 2
容器發(fā)生故障并重啟運(yùn)行,效果如圖7和圖8所示。
圖7 容器狀態(tài)異常
圖8 容器重新啟動成功
容器因故障退出后,可以自動重新啟動,當(dāng)主業(yè)務(wù)容器發(fā)生故障重啟,從業(yè)務(wù)容器接替主容器開始工作,主容器重啟后成為從容器,執(zhí)行監(jiān)聽任務(wù)。
通過容器自身的健康檢查和自動重啟功能,能夠自主對容器重啟,無需手動重啟。
為了驗(yàn)證容器在業(yè)務(wù)冗余中的性能,將同樣的業(yè)務(wù)分別部署在物理機(jī)和虛擬化容器上,重點(diǎn)比對冗余切換業(yè)務(wù)在2種平臺上的運(yùn)行性能。
實(shí)驗(yàn)環(huán)境軟硬件參數(shù)如表5所示,
表5 實(shí)驗(yàn)軟硬件環(huán)境
a)業(yè)務(wù)啟動時間性能差異分析
重啟物理機(jī)和業(yè)務(wù)容器,比對兩者成功業(yè)務(wù)啟動的時間如圖9所示。
圖9 物理機(jī)和容器業(yè)務(wù)成功啟動時間比對
如圖9中的對比,業(yè)務(wù)在容器平臺啟動的時間略低于物理機(jī)平臺,差值一般在0.5s內(nèi)。
b)業(yè)務(wù)冗余切換性能分析
業(yè)務(wù)容器間心跳信息的通信,等待超過200ms,即切換主從業(yè)務(wù)。
如圖10所示,2種業(yè)務(wù)平臺主業(yè)務(wù)切換為從業(yè)務(wù)并接替工作的時間,相差為數(shù)十微秒量級。
通過冗余的功能和性能試驗(yàn),可以發(fā)現(xiàn)業(yè)務(wù)冗余在虛擬化容器平臺上的性能低于真實(shí)物理機(jī),但是兩者差距在可接受范圍內(nèi)。同時,容器在隔離性、封裝性和遷移性上都有較好的優(yōu)勢,可以彌補(bǔ)性能上的不足。
圖10 物理機(jī)和容器業(yè)務(wù)主從切換延遲
本文研究并提出了測發(fā)控軟件在虛擬化平臺上的冗余技術(shù),提出了具體的實(shí)現(xiàn)方案,實(shí)驗(yàn)證明能更好地滿足地面測發(fā)控軟件的可靠性和健壯性需求,為提高發(fā)射可靠性提供了有利保障。