基于虛擬化的火箭測發控軟件冗余技術

呂躍鵬 劉俊陽 楊 喆

北京航天自動控制研究所，北京100854

0 引言

運載火箭測發控軟件的主要任務是完成火箭的測試和發射任務，它具有流程控制、數據處理、分析判讀和人機交互等功能。測發控軟件大多采用分布式并行架構，即由業務軟件在網絡系統上分布運行，構成并行處理的軟件系統[1]。在故障發生時，這種非集中模式下軟件及其業務的遷移、恢復存在很多困難，在B/S架構下由后臺業務群集中實現冗余方案，能使冗余技術的實施更加靈活、便捷。同時，隨著某些火箭測發控系統對測試設備產品化、低成本、輕量化的發展要求，計算機資源和測控設備的配置越來越少[2-3]。為了更好地實現業務隔離、降低耦合、提高可靠性，需要在有限的計算機資源基礎上利用虛擬化技術實現關鍵業務和功能的冗余，更好地保障發射可靠性。虛擬化技術是通過軟件實現將計算機及物理設備軟件化，隱藏真實的計算機硬件，抽象出多個計算機系統軟硬件資源，這些資源相互獨立，為用戶提供隔離的操作接口和交互功能。由于虛擬化具有很好的可移植性、容錯性，特別是其中輕量級虛擬化容器技術的應用，能夠更加完善測發控軟件冗余技術的實現，同時又在很大程度上保持了原有軟件的實時性。

本文提出的基于虛擬化的測發控軟件前后端業務的冗余技術，為提高虛擬化環境下測發控軟件的可靠性，提供了一條有效途徑。

1 測發控軟件業務虛擬化技術的實現

測發控軟件按業務可以劃分成控制域和交互域2個業務域，同時存在一個獨立的數據庫系統，每個業務域又是多個業務(功能)的集合。控制域包括流程控制通信業務容器和協議處理業務容器。交互域包括前后端交互業務容器、數據處理業務容器。控制域是軟件系統的核心業務，用于解析操作請求并控制設備完成測試發射任務，以主從冗余方式熱備工作。交互域用于獲取、解析采集的數據，提供可視化服務和數據存儲功能。數據庫用于記錄兩個域間包括交互數據、操作數據在內的全部信息[4]。

測發控軟件以業務功能為單元，部署到虛擬化容器(下文簡稱容器)上，多個相同業務的容器相互配合構成虛擬化業務域，形成對業務的主備冗余。測發控軟件虛擬化平臺的組成如圖1所示。

圖1 虛擬化測發控平臺架構圖

本文建立適合于測發控軟件的虛擬化平臺，前后端交互業務容器采用tomcat 作為業務容器基礎鏡像，并整合交互域中的前后端交互業務(自研的WEB服務端軟件)，打包成新鏡像，以容器的形式進行部署。控制域和交互域中數據處理業務容器，都是基于linux作為基礎鏡像，并更新網絡、通信、java等相關工具包和依賴庫，重新整合打包成新鏡像，以多個主備容器的方式運行在虛擬化平臺上[5]。

前后端交互業務容器配置文件Dockerfile主要內容如下：

# Dockerfile

FROM mywebserver:v2

ADD MyComMidDocker_war.war/usr/local/tomcat/webapps/

ADD TomcatLib/* /usr/local/tomcat/lib/

CMD ["catalina.sh", "run"]

控制域或交互域數據處理業務容器的LINUX容器配置文件Dockerfile主要內容如下：

#Dockerfile

FROM ubuntu:latest

……

COPY FlowControl ～/DockerImage/

WORKDIR ～/DockerImage/

CMD ["./FlowControl"]

通過上述方法對基礎鏡像進行包裝，擴充鏡像中的庫和工具的支持，從而可以通過研制的鏡像來形成測發控軟件后端業務的容器群，達到容器間相互冗余的目的[6]。

2 控制域冗余技術的研究

控制域包括了流程控制業務容器和協議處理業務容器。流程控制業務用于驅動測試流程，通過向協議處理業務發出命令消息，實現控制和測試協議，并同現場設備進行交互。

協議處理業務是依據數據幀格式協議解析流程控制業務的命令消息，并依據數據協議將命令消息轉發給箭上或者地面設備，控制設備執行。

流程控制業務和協議處理業務部署在多個虛擬化容器中，相同業務的不同容器形成主從冗余。本文對主份施行熱備方式的業務冗余策略，對備份施行冷備方式的容器冗余策略。熱備份方式主要通過心跳和業務通信等狀態信息判斷業務的健康狀況，并實時切換主從業務。冷備份方式主要通過監控充當備份角色的業務載體容器本身的健康狀況，判斷故障和重新啟動備份容器。即業務容器啟動后管理模塊定期發送HTTP請求到容器，等待容器響應；一旦等待時間超時，則將判斷容器故障，依據配置信息對問題容器進行重啟，以保持從容器的原有數量。下面主要對熱備方式進行論述。

2.1 控制域的冗余技術

2.1.1 流程控制業務的冗余技術

流程控制業務容器在測試開始時提供主、從2種狀態的選擇，其中一臺流程控制業務容器運行主機狀態程序，其它流程控制業務容器運行從機狀態程序。流程控制業務主機控制流程，從機容器充當監聽角色，并接收主機狀態程序發來的測試狀態信息。主機狀態控制整個測試發控流程，并將當前的工作狀態通知從機狀態程序，使運行在2個容器上的測發控程序同步熱備運行。當運行主機狀態的容器發生故障時，如“心跳”停止、通信中斷等，運行從機狀態的流程控制業務容器可通過前端的流程控制頁面人為切換為主機狀態，接管流程控制工作，而原運行主機狀態的流程控制業務容器，可視故障狀況人為決定是否重新初始化進入從機狀態工作。

2.1.2 協議處理業務的冗余技術

協議處理業務容器也采用主從冗余方案，1個時刻僅有1個控制域容器能夠控制執行設備協議處理業務，協議處理業務容器將完全自主實現較為復雜的冗余策略；

1)流程控制業務容器向協議處理業務主從容器均發送指令，協議處理業務主從容器均回復確認幀；

2)協議處理業務由當班容器執行動作，執行完成后，向流程控制業務主從容器均上報執行結果(若收到指令時是協議處理業務主容器當班，在執行動作期間發生了主從切換，則由協議處理業務從容器回復執行結果)；

3)協議處理業務容器采集到的模擬量、狀態量等，通過組播方式向交互域中數據處理業務容器發送；

4)協議處理業務主容器向協議處理業務從容器發送心跳信息，心跳信息中包含協議處理業務主容器狀態，協議處理業務從容器若一段時間未收到心跳信息，或者心跳信息顯示主容器狀態異常，則進行自動切換到最先啟動的從容器；

5)流程控制業務容器可以通過主從切換指令強制切換協議處理業務容器的當班狀態；

2.2 主要數據流和數據結構

控制域的數據流如圖2所示，其中包括了流程控制業務容器主從間通信、協議處理業務容器主從間通信，以及兩個域之間的通信方式。

流程控制業務容器數據流圖，如圖3所示。

流程控制業務主容器在啟動時可以選擇主從狀態，運行處于主狀態時，通過和協議處理業務的通信，控制包括PLC、PXI、LXI、測試計算機等設備終端，執行測試及發射控制任務。同時，流程控制業務主容器將測試項目、步序、數據等信息發送給控制域從容器，供從容器跟蹤當前的測試進程，當發生切換時能無縫接續。

圖2 控制域冗余通信方式圖

圖3 流程控制業務容器數據流圖

協議處理業務容器主從數據流圖，如圖4所示。

協議處理業務主容器啟動后，接收流程控制業務容器發送的設備控制命令、等待設備回令或數據并發送給流程控制業務容器，同時接收對設備的點采和頻采數據消息并轉發給交互域。主從容器間進行心跳檢測，多個從容器發現主心跳信息異常時切換主容器，由健康的從容器接續運行。

控制域冗余數據結構分3類：

1)流程控制業務主從容器間

流程控制業務主從容器間通信內容統稱為測試狀態信息，主要包含了命令、回令響應和消息通告3種數據消息格式。命令消息包括了測試項目通告命令(TestConfCMD)、查詢控制命令(CtrSearchCMD)、回令響應消息(RespMsg)；測試通告消息只包含測試狀態通告消息(TestStatusMsg)。

測試項目通告命令(TestConfCMD)用于主容器和從容器保持數據一致性。消息內容包含對應測試編號、測試項目代碼、測試項目名稱、測試項目步驟和測試數據。測試編號是選擇的測試項目號；測試項目代碼是測試項目號對應的名稱代碼；測試項目名稱是測試項目號對應的名稱；測試項目步驟為測試項目對應的流程步編號；測試數據為測試過程中點采的數據，包括了數據名稱、數據的實測值、該項數據的閾值。

查詢控制命令消息(CtrSearchCMD)是主容器向從容器發送，查詢從響應主的命令任務，包含ID號和命令參數2種數據。ID號是當前需要給從容器發送的控制命令，共有3種命令，分別是清空命令、主從容器切換命令、主查詢從容器是否允許切換命令；命令參數為3種命令的操作內容，清空命令對應的清空流程列表的操作命令消息；切換命令對應的切換與否的命令消息；查詢命令對應的切換允許的回應狀態命令消息。

圖4 協議處理業務容器數據流圖

回令響應消息(RespMsg)用于從設備回復主設備確認命令，包含命令ID和命令回復確認標志。命令ID為主設備的控制命令ID號；命令回復確認為獲取命令后的應答狀態碼。

測試狀態通告消息(TestStatusMsg)是主從間通信保持當前測試狀態一致，同時在切換后不影響整個流程的一種措施，包含測試步序號和運行狀態。測試步序號為當前測試項目及當前測試步驟編號，運行狀態為當前流程運行狀態信息。

2)協議處理業務主從容器間

協議處理業務主從容器間使用心跳信息進行通信，通信標識為DHeartMsg，用于判斷當前主容器是否工作正常。

心跳信息(DHeartMsg)僅包含了主機的在位信息。

3)控制域內

控制域內通信是在流程控制業務容器和協議處理業務容器之間進行的，通信內容為冗余控制命令，名稱為CMDMsg。流程控制業務容器將控制命令發送給協議處理業務容器，后者通過設備號封裝對應的數據幀，和真實設備進行通信。

控制命令(CMDMsg)包含接受控制命令的設備ID號和具體命令消息。設備ID號為接受控制命令的設備號，命令消息為對設備操作的命令內容。

3 交互域冗余技術研究

交互域是人員操作交互的業務集合，包括人機交互業務、前后端交互業務容器、數據處理業務容器。人機交互業務與前后端交互業務容器采用B/S架構設計。人機交互業務運行在前端瀏覽器上，前后端交互業務容器提供后端與對前端的服務。

人機交互業務由數據交互頁面和流程控制頁面構成。前者顯示內容來自數據處理業務容器處理解析后的點采和頻采設備數據，再經可視化處理后呈現在頁面上，供工作人員觀察分析；后者提供可視化操作，使得用戶能夠通過簡單的操作即可和虛擬化平臺及真實設備進行交互。前后端交互業務容器支持與人機交互業務中的多種頁面進行通信，解析來自頁面的請求信息和數據，并將解析完成的命令發送給控制域的流程控制業務容器進行處理，數據參數訂閱信息發送給數據處理業務容器。數據處理業務容器負責建立和連接數據庫，存儲數據，同時解析來自控制域協議處理業務容器對設備的頻采數據，并依據訂閱信息進行發布。

3.1 交互域的冗余技術

交互域的冗余技術體現在頁面故障恢復和登陸安全性2個方面。頁面故障需要恢復時，只需重新訪問前后端交互業務容器IP和端口號即可，登陸安全性措施是為保證流程控制頁面控制權的唯一性。

流程控制頁面在故障恢復時，需要2個部分的信息，即心跳信息和頁面操作記錄。流程控制頁面正常運行時，每100ms發送給后端交互業務容器1次心跳信息，超過1s后端交互業務容器未收到心跳信息，則判斷頁面故障退出，重新啟動頁面；頁面操作記錄用于存儲對頁面的操作痕跡，并更新數據庫中的操作記錄表。

數據交互頁面的故障恢復技術，依賴心跳信息和參數選項記錄。心跳信息同流程控制頁面的心跳信息記錄，參數選項記錄用于記錄交互頁面訂閱的數據參數，虛擬化平臺依據訂閱信息定期發布更新數據，并在交互頁面進行顯示。

登陸安全性針對控制頁面，出于對設備控制功能和安全性的需求，必須保證同一時刻有且僅有1個控制頁面可以操作，避免多個用戶同時登陸流程控制頁面以及后登陸用戶可以替換先登陸用戶。流程控制頁面登陸安全性技術，在前后端交互業務容器中實現。前后端交互業務容器需要將頁面登陸信息作記錄，并在記錄中更新流程控制頁面在位個數。

3.2 主要數據流和數據結構

交互域的通信方式圖和數據流圖分別如圖5和圖6所示，其中包括了前端2種頁面和前后端交互業務的通信、前后端交互業務容器和數據處理業務容器的通信，以及數據處理業務和數據庫的通信。

圖5 交互域冗余通信方式圖

圖6 交互域數據流圖

交互域的通信使用B/S模式的Ajax請求響應模式，頁面通過json將數據發送給前后端交互業務容器，并響應業務容器返回的數據。

數據處理業務容器和數據庫間通信數據統稱為解析數據；數據處理業務容器和協議處理業務容器間通信數據統稱為原始數據。

交互域冗余技術使用的數據結構有：

1)流程控制頁面通信數據結構

請求響應數據中用于流程控制頁面和后端通信的消息包括心跳信息(CPHeartMsg)和頁面操作記錄(CPOptMsg)2種。

心跳信息(CPHeartMsg)用于判斷流程控制頁面或交互頁面是否正常，內容包含頁面編號和頁面重啟標志位。頁面編號為流程控制或交互頁面編號；頁面重啟標志位，用于區分頁面因故障關閉或正常關閉。

頁面操作記錄(CPOptMsg)用于傳遞給數據庫保存頁面交互的所有操作，內容包含流程名稱、流程步和流程運行狀態。其中，流程步為當前流程運行對應的步序號；流程運行狀態標識當前流程運行狀態為全流程運行、單步運行或終止運行。

2)數據交互頁面通信數據結構

請求響應數據中用于數據交互頁面和后端通信的消息包括心跳信息(VPHeartMsg)和參數選項(VPParaMsg)，心跳信息數據結構定義同1)。

參數選項(VPParaMsg)記錄交互頁面編號和交互頁面訂閱的參數數據集合。

3)數據庫表數據結構

數據庫包括登陸信息表、流程狀態表、存儲數據表、前端交互操作表在內的4種數據表。

登錄頁面信息數據庫主要包含網頁類型標識碼、網頁類型、交互頁面和流程控制頁面的數量信息。如表1所示。

表1 登陸頁面信息表

表2用于記錄設備點采和頻采后解析完成的數據，及數據對應的上下限值，更新數據值，保證數據的有效性。

表2 存儲數據表

交互操作表(表3)用于記錄對頁面的操作記錄，為還原頁面狀態提供參考。依據頁面布局將頁面可分為多個區域，頁面操作后立即更新對應區域號的數值。

表3 交互操作記錄表

流程狀態表(表4)用于記錄流程運行狀態，流程名編號為測試項目的編號；流程步號用于記錄流程運行步序號；流程狀態中0x00表示開始全部流程、0x01表示單步運行流程、0x02表示停止流程運行。

表4 流程狀態表

4 實驗

本文對冗余技術方案的主要冗余功能和性能進行實驗驗證。

4.1 從容器健康檢查和故障恢復

容器級健康狀態檢查工作包括：管理模塊和容器進行HTTP請求響應通信，定期檢查容器是否有反饋，設置超時響應時間(2s)，超過后，則認為容器已經失效，需要重新啟動容器。業務容器健康監測配置文件偽代碼如下所示：

Master.yaml文件如下：

apiVersion: v1

kind: Pod

metadata:

labels: myweblive

name: weblive

spec:

……

livenessProbe：

httpGet:

path:/_status/healthz

port: 80

initialDelaySeconds: 15

timeoutSeconds: 2

容器發生故障并重啟運行，效果如圖7和圖8所示。

圖7 容器狀態異常

圖8 容器重新啟動成功

容器因故障退出后，可以自動重新啟動，當主業務容器發生故障重啟，從業務容器接替主容器開始工作，主容器重啟后成為從容器，執行監聽任務。

通過容器自身的健康檢查和自動重啟功能，能夠自主對容器重啟，無需手動重啟。

4.2 冗余切換時間性能分析

為了驗證容器在業務冗余中的性能，將同樣的業務分別部署在物理機和虛擬化容器上，重點比對冗余切換業務在2種平臺上的運行性能。

實驗環境軟硬件參數如表5所示，

表5 實驗軟硬件環境

a)業務啟動時間性能差異分析

重啟物理機和業務容器，比對兩者成功業務啟動的時間如圖9所示。

圖9 物理機和容器業務成功啟動時間比對

如圖9中的對比，業務在容器平臺啟動的時間略低于物理機平臺，差值一般在0.5s內。

b)業務冗余切換性能分析

業務容器間心跳信息的通信，等待超過200ms，即切換主從業務。

如圖10所示，2種業務平臺主業務切換為從業務并接替工作的時間，相差為數十微秒量級。

通過冗余的功能和性能試驗，可以發現業務冗余在虛擬化容器平臺上的性能低于真實物理機，但是兩者差距在可接受范圍內。同時，容器在隔離性、封裝性和遷移性上都有較好的優勢，可以彌補性能上的不足。

圖10 物理機和容器業務主從切換延遲

5 結束語

本文研究并提出了測發控軟件在虛擬化平臺上的冗余技術，提出了具體的實現方案，實驗證明能更好地滿足地面測發控軟件的可靠性和健壯性需求，為提高發射可靠性提供了有利保障。