面向航天器大數據安全傳輸的發布/訂閱系統設計

覃潤楠, 彭曉東, 謝文明, 惠建江, 馮渭春, 姜加紅

(1. 中國科學院國家空間科學中心, 北京 100191; 2. 中國人民解放軍63921部隊, 北京 100094)

0 引 言

航天器在軌運行過程中所處的空間環境復雜多變,各種粒子輻射、電磁輻射、溫度交變等環境效應[1]會對航天器產生干擾影響,嚴重的會導致航天器故障,造成巨大損失,需采取有效手段準確、直觀地展示航天器在軌工況,及時發現隱患,進行故障預警,并在故障發生時快速定位以及實施故障預案,從而保障航天器長期在軌穩定運行。因此,開展航天器運行狀態綜合檢測和監視顯示技術研究有著迫切的需求[2],且具有較高的實用價值。

聚焦航天器在軌運行狀態監視離不開對航天器遙測參數、數傳圖像的分析,航天器試驗數據成為地面監視人員了解航天器運行狀態的主要依據[3]。隨著航天技術的飛速發展,航天器種類、試驗頻率、測量站點日益增多,越來越多的新型載荷得以搭載應用,導致航天器試驗數據數量急劇增加[4]。在航天器在軌狀態監視過程中,如何使用較少數量的服務器高效、可靠地接收、管理并實時統計分析海量試驗數據,從而準確表征航天器的運行情況,是地面監視人員所關心的熱點問題。

分布式云計算的出現和發展,使得海量數據的耗時處理能夠依托于計算能力有限的服務器集群,通過軟硬件資源的共享,按需分配給計算機和其他設備[5]。Hadoop 正是近年來得到廣泛應用的開源云計算平臺,由核心組件分布式文件系統(hadoop distributed file system, HDFS)與大數據計算引擎MapReduce,以及Pig、ZooKeeper、 HBase、Hive等多個子項目組成[6]。面對持續增長的海量航天器試驗數據,具備通用性、高可靠性、可伸縮等特性的Hadoop的引入無疑會為分析展示航天器在軌試驗過程帶來便捷。

然而,Hadoop雖具有高容錯性、批處理、PB量級大數據傳輸等優點,但無法滿足小文件的高效存儲、實時的多線程并發數據讀寫等應用需求,因此需考慮引入高并發的消息發布/訂閱系統。發布/訂閱系統的異步通訊范式能夠實現大規模分布式通訊傳輸應用[7]:數據發送方將消息內容發送至根據主題名稱區分的邏輯信道中,而數據接收方則自由訂閱自己感興趣的主題,并同步接收所有被發送到這些主題信道下的消息[8],具有多線程并發、松耦合及高可拓展的特性。當前,主流的發布/訂閱系統有基于主題的Kafka[9]、RabbitMQ[10]、RocketMQ[11]、ActiveMQ[12]等系統,以及基于內容[13]、基于渠道[14]、基于類型[15]的發布/訂閱模型系統。

關于云計算平臺與發布/訂閱系統的結合方面已有一部分研究工作[16-18],文獻[19]提出了一個整合Hadoop的發布/訂閱中間件,通過基于內容的匹配算法來分析訂閱意圖,從而更精準地發布內容給訂閱者。然而在實際應用中,考慮到Hadoop的大規模并行計算依賴于存儲在本地磁盤上的離線數據,無法滿足航天器在軌試驗數據的實時在線引接與處理分析顯示的應用需求,需通過其他云節點額外進行數據的實時交互處理。然而在云計算平臺中,各云節點的性能差異會導致數據不同步的現象。目前,已經產生了許多經典的節點選舉機制實現各節點的數據同步,例如Paxos消息一致性算法[20]、Raft優先級選舉機制[21]、拜占庭故障容錯(practical Byzantine fault tolerance, PBFT)[22]等。但這些算法因各自特性差異皆有不同程度的使用限制,其中Paxos 和 Raft 共識算法并未考慮系統中的拜占庭節點問題,而PBFT 算法的可擴展性較差等。

本文通過借鑒國內外主流的發布/訂閱系統,綜合考慮當前選舉同步機制的局限性,設計了一種面向航天器多源異構試驗數據傳輸、管理、緩存的分布式大數據發布/訂閱系統(big-data publish/subscribe system, BPSS),實現了基于消息一致性的動態選舉算法從而保障大數據的傳輸效率與安全。同時,在大型航天器數管實驗任務中對BPSS的性能進行實驗,驗證了其具備數據交互響應迅速、海量多源異構數據高吞吐穩定性等特點,能夠穩定、實時表征航天器運行狀態,便于地面監視人員進行有效的故障處置,為航天任務保駕護航。

本文按如下結構組織:第1節介紹當前國內外研究現狀,引出航天器在軌試驗數據全生命周期管理過程中所面臨的問題;第2節提出BPSS架構,并介紹其架構設計;第3節提出并介紹基于消息一致性的動態選舉算法;第4節依托航天器數管實驗任務進行BPSS性能驗證,根據實驗數據分析實驗結果;最后給出本文的結論。

1 BPSS系統架構設計

1.1 總體架構設計

BPSS系統為5層分布式架構,包含控制中心層、數據發布層、數據訂閱層、數據處理層、數據緩存層,總體架構如圖1所示。其中,控制中心層對云平臺的全部云節點實現主從調控,采用基于消息一致性的動態選舉算法推選主控節點,并通過動態彈性擴容策略增加從節點資源來完成大規模發布/訂閱任務。對于任意主從節點均設有以下4層架構:數據發布層將數據推送至數據映射區,通過水位線和檢查點記錄數據偏移量,保證數據發布順序性;數據訂閱層根據數據映射區的主題分區拉取數據,通過訂閱偏移量保證數據拉取順序性,同時各節點的數據映射區通過消息一致性通訊算法實現與主控節點的數據同步;數據處理層對數據映射區進行鏡像備份,形成帶索引的源數據存儲塊,保證數據計算分析效率;數據緩存層完成數據安全入庫存儲,實現內存級高吞吐與強容錯性。

1.2 控制中臺架構設計

BPSS系統的控制中心層在云平臺上實現控制中臺架構,包含調度器節點、主控節點、多個從節點,如圖2所示。

控制中臺通過基于消息一致性的動態選舉算法對全部云節點實現主從調控,在主控節點由于意外進程中斷或意外死機停止工作后在選舉區中發起選舉。整個選舉過程主要由選舉器和管理器共同完成,其中選舉器負責接收選票和發送選票,管理器負責主從節點之間的選舉通信和從節點票數的傳遞。如某個從節點票箱中的票數達到半數以上,則由該從節點接替主控節點工作。

圖1 BPSS總體架構設計圖Fig.1 Overall architecture design diagram of BPSS

對于故障節點采用動態彈性擴容策略重新賦能,該節點要求的資源將借助心跳機制傳遞到全局資源控制模塊,同時監視器通過訂閱心跳來監控集群狀況,隨后觸發縱向擴容,彈性伸縮模塊創建新的資源節點,并保存至擴容隊列。最后,容器編排工具接收到創建新節點的指令后,在擴容隊列中讀取該節點信息并新建節點,當新節點創建完成后, 則將擴容隊列中的相應節點移除。

1.3 發布/訂閱架構設計

在BPSS系統的任意主從節點上均實現發布/訂閱架構,包含發布者節點、訂閱者節點,以及數據映射區,如圖3所示。

發布者節點的設計由主線程和發送線程兩個線程協調組成。在主線程中由用戶創建數據,之后通過攔截器、序列化器和分區器將數據緩存到數據累加器的隊列尾部,以便發送線程可以批量發送,進而減少網絡傳輸的資源消耗以提升性能。發送線程負責從數據累加器的雙端隊列頭部獲取消息,并通過響應器將其發送到數據映射區。

訂閱者節點能夠加入訂閱組,負責根據水位線訂閱數據映射區中的數據主題,拉取數據后保存訂閱偏移量,如圖4所示。其中,水位線用于定義數據可見性,即用來標識哪些數據能夠被訂閱者節點拉取。訂閱偏移量是訂閱者節點拉取下一條數據的位移值,因此介于水位線和訂閱偏移量之間的數據就屬于可以被拉取的數據內容。

此外,為保證數據映射區的數據安全與處理實時性,BPSS在數據處理層實現基于檢查點的數據鏡像備份,整體設計思路如圖5所示。其中,檢查點的含義是當某次鏡像備份完成后,緩存當前的備份進度。因此,當批量數據寫入時,遇到檢查點后將重新建立新的鏡像文件,同時會在這個鏡像文件文件頭中添加索引,并合并為帶索引的源數據存儲塊,既可以保證緩存效率,同時也能在系統故障或服務器斷電時快速恢復數據。

圖2 控制中臺架構設計圖Fig.2 Control center architecture design diagram

圖3 發布/訂閱架構設計圖Fig.3 Publish/subscribe architecture design diagram

圖4 訂閱偏移量示意圖Fig.4 Schematic diagram of subscribe offset

圖5 數據鏡像備份模式設計圖Fig.5 Design diagram of data mirroring backup mode

2 基于消息一致性的動態選舉算法

2.1 算法總體描述

BPSS的控制中臺為同步云節點之間的數據狀態,引入心跳檢測機制周期性地檢測各節點的工作情況。當前心跳檢測協議有很多種,例如加速心跳協議[23]、多機系統心跳檢測機制[24]、自適應心跳檢測[25]等,但心跳檢測協議大多都存在節點異常后的不可恢復性,以及主控節點單點失效導致恢復延誤的問題[26]。常見的解決節點異常的方法是雙機容錯技術[27],在主控節點故障時用備份機對故障主控節點的工作進行平滑接管,但降低了分布式系統的靈活性,于是針對雙機容錯技術的缺陷產生了選舉機制[28-30]。當某個從節點檢測到主控節點故障時,該從節點需發起一個選舉過程,并要求其他從節點全部參加,共同選舉出一個新的從節點接替主控節點工作。

然而,在實際工程應用中發現了選舉機制的諸多問題,例如云節點越多,選舉機制的執行時間就越長,以及有新節點頻繁加入集群后可能重新引起一次選舉,導致主控節點不斷變換,系統可用性大幅降低。同時,由于各節點間的性能差異,數據同步程度不一致,選舉后會出現數據丟失的現象。為改進上述問題,本文設計了一種基于消息一致性的動態選舉算法,能夠對參加選舉的節點數量進行動態調控,通過動態彈性擴容策略為故障節點再次賦能,同時基于消息一致性通訊策略同步各節點數據狀態,其偽代碼如算法1所示。

算法 1 基于消息一致性的動態選舉算法Maser Mode (){ Qi(i=1,2,…,N) {initialize -> sort; while (true) ∥檢查選舉區與等待區節點數量; { if (選舉區數量超限) ∥閾值n Qn{->進入等待區; } else if (等待區數量超限) Qn{->進入選舉區; } }

Heartbeats Detect () ∥心跳檢測 { Timer->∥設置定時器 { ∥組播發送消息至各節點 Multicast (Qi, message); if (Ack loss); ∥未收到從節點心跳回復 { ∥節點故障,不再向該節點發送檢測包 AutoScale Mode();∥動態彈性擴容策略 Qi(i=正常節點) ; } } } ∥end of heartbeats thread Message Response () ∥執行選舉消息響應 { Qi{ if (發起選舉的節點 優先級高于自己) { Multicast (讓位信息); ∥讀取讓位信息應答 if (Ack->響應超過半數) { Qi 被選舉為主控節點; Consistent Mode ();∥消息一致性通訊策略 } } else { Multicast (結束選舉信息); } }} ∥end of master mode thread

由算法1可知,基于消息一致性的動態選舉算法首先將所有節點進行優先級排列,并根據當前集群規模進行閾值設置,閾值之上劃分為選舉區,閾值之下劃分為等待區。只有位于選舉區的從節點才有資格參加主控節點的選舉,選舉結束后參加過選舉的從節點其優先級會進一步調高,盡可能保證主控節點性能為集群中的最優節點。同時,閾值也會根據實際情況動態調整:當選舉區的從節點數量過多時將選舉區內優先級最低的節點下放至等待區,同樣當等待區從節點數量過多時,將等待區內優先級最高的從節點升級至選舉區。此外,對于故障節點通過動態擴容將其替換為新創建的節點,針對新加入集群的節點或故障恢復節點直接將其置為等待區,降低節點加入集群時進行選舉的次數。在主控節點由于意外進程中斷或意外死機停止工作后在選舉區中發起選舉,如某個從節點中的票數達到半數以上,則由該從節點接替主控節點工作,并進行各節點間消息一致性判讀。

2.2 消息一致性通訊策略

基于消息一致性的動態選舉算法中的消息一致性策略偽代碼如算法2所示,每個節點中需記錄主控節點變更次數的紀元信息,紀元信息初始值為0,每當主控節點變更一次,紀元信息值就會加1,即增設版本號,下標m表示主控節點。同時,每個節點中需記錄消息偏移量,用于同步當前紀元信息下寫入第一條消息時的偏移坐標。從節點以固定頻率向主控節點請求數據同步,并當節點狀態更替時比對各自節點消息偏移量的位置進行數據截斷或補齊操作,以此保護各節點的數據完整性。

算法 2 消息一致性通訊策略Consistent Mode (){ Qi(i=1,2,…,N)Qm; initialize, Timer->∥設置定時器 { ∥單播發送消息至主控節點請求同步 Multicast(Qi(i=1,2,…,N), message); if(Qi宕機重啟) { message->數據截斷或補齊; } if(Qi選舉為Qm) { 紀元信息+=1; 消息偏移量+=number(message); } }}

2.3 動態彈性擴容策略

基于消息一致性的動態選舉算法中的動態彈性擴容策略偽代碼如算法3所示,設置擴容隊列暫存當前故障節點,根據每一個故障節點的故障類型設定節點類型type,如果擴容隊列中包含該節點類型,則繼續迭代查找下一個故障節點,否則將該節點類型加入至擴容隊列中。通過擴容隊列的設置,降低新節點的創建時間,同時防止為同一個故障節點創建過多新節點。

算法 3 動態彈性擴容策略AutoScale Mode (){ for each i∈N do type=Pending Qi->node_type if Expanding Q.contains (type) continue else create new node putin Expanding Q end}

3 實驗與結果

3.1 實驗環境準備

BPSS在大型航天器數管實驗任務中進行了實地測試,其硬件部署圖如圖6所示。采用云平臺虛擬節點集群、分布式云存儲設備,以及國產操作系統與數據庫搭建大容量數據交換環境。

圖6 硬件環境部署Fig.6 Hardware environment deployment

3.2 實驗結果分析

面向航天器在軌運行監視中測控遙測、數傳遙測、數傳圖像、遙控指令等多源數據傳輸、交互、顯示需求,設計了大數據訂閱吞吐性能、大數據傳輸性能兩類實驗,共同驗證BPSS的實際性能。

3.2.1 大數據訂閱吞吐性能實驗

首先采用不同量級的航天器在軌傳輸數據包進行數據發布(單體為1 M),對比BPSS與當前國內外主流開源發布/訂閱系統(例如Kafka、ActiveMQ、RabbitMQ、RocketMQ)的消息訂閱響應時延。數據內容包括星地與星間通信的測控遙測、數傳遙測、數傳圖像、操控指令等,數據類型包括json、txt、jpeg、xml等。

消息訂閱響應時延指數數據發布后直到訂閱獲得全部數據所消耗的時間,如下所示:

Tdelay=Tsubscribe-Tpublish

(1)

式中:Tdelay為消息訂閱響應時延;Tsubscribe表示數據訂閱時間戳;Tpublish為數據發布時間戳。

實驗結果如表1所示,可知在不同量級的數據傳輸過程中,數據訂閱響應時延與訂閱數據量呈現正相關關系。BPSS消息訂閱平均響應時延為0.05 s,其他發布/訂閱系統如Kafka、ActiveMQ、RabbitMQ、RocketMQ的消息訂閱平均響應時延分別為28.64 s、0.07 s、0.14 s、0.11 s,相比而言BPSS具有更快的消息訂閱響應速率。

表1 不同發布/訂閱系統響應時延對比Table 1 Different publish/subscribe system response delay comparison

之后分別采用單體大小為1 M、10 M、100 M的航天器在軌傳輸數據包,測試數據單體大小以及數據類型是否會對發布/訂閱系統的訂閱速率產生影響,實驗結果如圖7所示。分析可知,在發布/訂閱系統中,數據訂閱響應時延與訂閱數據的單體大小呈正相關關系。同時,相較于其他數據類型,各發布/訂閱系統對于jpeg圖像類型數據的訂閱響應時延都是最長的。但相比于其他的發布/訂閱系統,BPSS對各類多源異構數據的響應速率差異化最小。

圖7 不同數據包下各發布/訂閱系統的響應時延Fig.7 Response delay of each publish/subscribe system under different data packets

最后,對系統的數據吞吐能力進行分析,定義系統數據吞吐能力計算如下所示:

(2)

式中:Numsubscribe表示在數據持續發布的條件下訂閱到的數據量統計;t表示訂閱這些數據所花費的時間,單位為s。

實驗采用單體為1 M的航天器在軌傳輸數據包,按照1 000包/秒的固有數據發送頻率持續發布5 min,測試BPSS與Kafka、ActiveMQ、RabbitMQ等發布/訂閱系統的吞吐性能,相關實驗結果如圖8所示?？芍?吞吐能力越高Tps值越大,且曲線走勢越平穩,因此BPSS在各發布/訂閱系統中具備較好的吞吐性能。同時結合表1分析可知,消息訂閱響應時延與發布/訂閱系統的大數據吞吐性能成反比,消息訂閱響應時延越長其系統吞吐性能越差。

圖8 不同發布/訂閱系統吞吐性能比對Fig.8 Camparison of throughput performance between different publish/subscribe systems

3.2.2 大數據傳輸安全性能實驗

首先,對比BPSS中基于消息一致性的動態選舉算法與當前國內外主流選舉算法(例如Paxos、Raft、PBFT等算法)的性能差異。在5個云節點分別采用不同算法進行100次主控節點選舉并統計結果分布,實驗結果如圖9所示。

圖9 不同主控節點選舉機制性能比對Fig.9 Performance comparison of election mechanism for different master nodes

分析可知Paxos、Raft、PBFT等算法選舉出來的主控節點在各個節點上都有所分布,即集群中的任意節點都有機會當選為領導者節點。而BPSS中基于消息一致性的動態選舉算法使得優先級最高的節點(云節點1)大概率保持為主控節點,能夠有效減少選舉次數并提高選舉效率,同時避免集群節點數量變更引起網絡拓撲結構頻繁變化進而導致系統可用性降低的問題。

之后采用單體為1 M的航天器在軌傳輸數據包,并對每包數據進行自增編號后按照1包/秒的頻率進行發布,分別統計持續訂閱1 h、6 h、12 h、24 h(平均每小時傳輸數據量為3.52 GB)不同時長下的訂閱數據編號缺失情況與數據內容完整度,測試發布/訂閱系統數據傳輸性能。

實驗指標采取數據傳輸丟幀率Rf與數據破損率Rd,指標定義如下所示:

(3)

(4)

式中:T表示向各云節點發布的數據量;L表示各云節點訂閱后丟失的數據量;D表示各云節點訂閱到的數據量。實驗結果如表5所示。

表5 不同發布/訂閱系統傳輸數據完整性比對Table 5 Data transmission performance comparison of different publish/subscribe systems %

結果表明,單日吞吐量達到80 GB左右的量級時,BPSS數據傳輸丟幀率控制在0.025%,數據破損率控制在0.018%,且在單日各時刻內BPSS對于數據傳輸的丟幀與破損情況基本保持穩定,具備大數據穩定性傳輸優勢。

4 結束語

本文設計了一種面向航天器多源異構試驗數據傳輸、管理的BPSS,對云節點實現主從調控與彈性擴容,并通過基于消息一致性的動態選舉算法完成大規模發布/訂閱任務,實現高效、安全的航天器試驗數據傳輸通信,為航天器試驗任務全生命周期實時監測、運行工況健康檢測提供重要支撐。實驗圍繞大型航天器數管實驗任務中高吞吐量的數據收發處理任務,結果表明BPSS有效優化了數據發布/訂閱響應速度,尤其提升海量數據傳輸安全性與存儲一致性,具備數據響應迅速、高吞吐穩定性高等優勢。未來工作中,作者將進一步優化BPSS在云環境下更長周期的穩定處理性能。