基于云計算技術的信號集中監測系統架構設計方案*

胡啟正 余立偉 謝智多

(1.中國鐵道科學研究院集團有限公司通信信號研究所,100081,北京; 2.國能朔黃鐵路發展有限責任公司,062350,滄州; 3.北京華鐵信息技術有限公司,100081,北京)

隨著《“十三五”國家信息化規劃》《交通運輸信息化“十三五”發展規劃》等文件對軌道交通行業信息化、標準化等要求的提出,為貫徹落實鐵路信息化建設的相關要求,中國國家鐵路集團有限公司印發《鐵路信息化總體規劃》,規范并指導“十三五”時期乃至更長一段時間內鐵路信息化的建設,以推進鐵路行業各系統信息化進程。以京張高鐵智能動車組和京雄高鐵智能運營信息化支撐關鍵技術研究項目為依托,我國已初步構建出智能鐵路技術體系[1],廣泛應用云計算、人工智能等新技術對鐵路基礎設施裝備的相關信息進行全面、科學、主動的檢測與監測,邁出了智能鐵路的關鍵一步。

鐵路信號集中監測系統經歷了從無到有、由弱到強的發展歷程,從最初只能對駝峰、區間設備進行監測,逐漸發展成為信號設備的綜合監測平臺。隨著監測范圍的不斷擴大、監測精度的逐步提高、監測功能的日益完善,對信號集中監測系統也提出了更高的要求,以期逐步實現信號設備智能運維的總體目標。對信號集中監測系統提出的要求有:①信號集中監測系統在對信號設備狀態進行監測的同時,還應具備故障診斷能力,實現自動分析采集接口數據功能;②當設備存在隱患時,信號集中監測系統能夠提前發現設備隱患[2];③當設備故障時,信號集中監測系統能夠診斷并定位故障范圍及故障原因。既有信號集中監測系統仍依賴于依靠大量人力在實體物理機上進行系統環境配置、應用軟件部署和網絡配置,存在耗時長、硬件資源未充分利用、部署靈活性受限、成本高等問題。目前,隨著云計算、大數據、人工智能等技術在鐵路系統內的應用推廣[3],原有系統架構和部署方案已經無法滿足智能化、信息化、智慧化發展的需求。將云平臺技術應用到鐵路信號集中監測系統中,充分整合多臺物理服務器的計算、存儲和網絡資源,在中心層面形成統一的資源池,進行集中調度分配與管理,可以靈活進行橫向、縱向擴展,在資源池內為不同業務需求靈活分配獨立的資源,提升硬件資源的利用率和管理效率,實現業務的快速部署。

隨著大數據、云計算、人工智能等技術在鐵路系統中的應用,鐵路信號集中監測系統作為鐵路電務維修方式由計劃修向狀態修演進的關鍵系統之一,要求系統除了具備一定的智能化和自動化的新業務能力外,還要求系統架構具備智能化、網絡化及數字化的特點,構建海量數據采集和分析的系統服務體系。本文針對信號集中監測系統的應用現狀,運用云計算技術的優勢,在實驗室中構建了基于云計算的信號集中監測系統架構,并采用服務等級協議對整體架構進行評價。本文研究可為信號集中監測系統向云遷移提供試驗基礎和技術指導。

1 基于云計算技術的信號集中監測系統

1.1 現狀分析

鐵路信號集中監測系統體系結構主要由兩部分構成:系統配置的層次結構和數據通信的網絡結構。監測系統的層次結構為三級四層結構,主要包含:鐵路總公司、鐵路局、電務段三級;鐵路總公司監測子系統、鐵路局電務監測子系統、電務段監測子系統、車站監測網四級。在具體的實施過程中,監測系統體系結構的具體劃分會根據電務部門維護和管理工作的實際需求進行調整。信號集中監測系統體系結構示意圖如圖1所示。由圖1可知,每臺物理服務器均承載一項獨立業務,若要滿足冗余性要求,則物理服務器的數量將更多。

注:TDCS為列車調度指揮系統;CTC為分散自律調度集中;TSRS為臨時限速服務器系統;RBC為無線閉塞中心;CBI為計算機聯鎖。

信號集中監測系統采用傳統信號集中監測系統的網絡架構,其示意圖如圖2所示。目前,傳統信號集中監測系統網絡架構主要面臨以下幾個方面的問題:

圖2 信號集中監測系統網絡架構示意圖

1) 業務系統耦合度高。業務系統軟件開發的耦合度過高,一旦其中某項功能升級,將會涉及其余多個模塊,新增或升級功能項可能導致多個業務重新部署。

2) 業務部署耗時長。①鐵路CSM(信號集中監測)系統按業務分別設立獨立的硬件基礎設施,例如:通信前置服務器、Web服務器和應用服務器等,各業務功能獨立運行在不同的服務器上,需要分別對不同物理服務器進行單獨的系統配置;②業務進行變動升級時,涉及多個物理服務器,操作便利性低。

3) 建設和運用成本高。①為滿足系統的穩定性和隔離性要求,通常特定功能的應用程序會配屬獨立的物理服務器,且物理服務器的配置資源按應用程序峰值運行需求進行購置,單臺服務器計算資源利用率低;②磁盤陣列的使用僅用作應用服務器和數據庫服務器,其他服務器均使用各自獨立的硬盤資源進行存儲,存儲資源分散,系統對磁盤陣列的利用率不高。

4) 可擴展性較差。①分散獨立設置的CSM系統基礎設施無法對閑置資源進行整合,造成一定程度的資源浪費;②面對業務量驟增,為滿足隔離性要求,無法在原有基礎設施上進行業務模塊擴展。

5) 系統運維管理工作難度大。信號集中監測中心子系統可容納多臺物理服務器,運維人員無法對物理服務器上各應用業務進行綜合管理,現場存在故障處置不及時的問題。

1.2 基于云計算技術的系統架構設計方案

云計算平臺應提供云計算基礎設施資源服務,包括IaaS(基礎設施即服務)、PaaS(平臺即服務)和SaaS(軟件即服務)[4]。IaaS通過虛擬化技術、軟件定義存儲和軟件定義網絡技術,整合通用的物理服務器、存儲設備和網絡設備組成共享資源池,為應用系統提供需要的計算、存儲和網絡資源。PaaS根據應用系統需求,提供共性的、開放的、可管理的服務能力,通過開放接口或SDK(軟件開發工具包)向應用系統提供服務。SaaS提供經營管理和用戶生產所需要的軟件服務。

云平臺部署方式如下:①私有云平臺——企業購置基礎設施,并部署面向企業內部的服務;②公有云平臺——由云服務商建設基礎設施,企業購買相應服務;③混合云平臺——上述兩種方式均包含的一種部署方式。

結合鐵路安全生產相關要求,基于云平臺的鐵路信號集中監測系統部署方式應當選擇鐵路專用內部網絡在管轄范圍內構建私有云平臺,在保證數據安全可靠的同時,還保障了基礎設施的可控性?；谠破脚_的信號集中監測系統架構如圖3所示。

圖3 基于云平臺的信號集中監測系統架構示意圖

基于云平臺的信號集中監測系統主要分為:

1) 數據采集層,主要由信號集中監測系統的車站采集設備和中心外部系統接口組成,是CSM系統的重要數據源。

2) 云平臺資源層,主要由物理資源和虛擬資源池組成,其中硬件資源必須選用支持虛擬化技術的服務器、存儲設備和網絡設備。云平臺資源層主要實現過程為:①在物理服務器上安裝VMware ESXi軟件,在硬件資源上構建虛擬機監視器Hypervisor,完成服務器的IP(互聯網協議)配置,并在此基礎上進行嵌入式安裝vCenter虛擬機,將所有ESXi宿主機納入vCenter數據中心進行集中管理;②將磁盤陣列以FC(網狀通道)協議接入ESXi服務器,構建共享存儲資源池;③運用vCenter軟件定義通信鏈路功能,按業務需求對虛擬標準交換機的端口進行邏輯劃分,構建出業務網和管理網,形成動態調整的整體網絡資源。形成統一的計算資源池、網絡資源池和存儲資源池,不僅能夠實現對平臺資源的統一調度,為云平臺服務層提供基礎資源,還能簡化外部設備,提升現場人員的管理效率。管理服務器能對宿主機和虛擬機進行統一資產管理和集群管理[5]。

3) 云平臺服務層,主要負責承載信號集中監測系統的中心業務,實現中心分析、管理、報警等功能。云平臺服務層的主要實現過程為:①信號集中監測系統中心設備統一從虛擬資源池中進行資源劃分,構建相互協作的虛擬機,各虛擬機之間通過虛擬標準交換機實現對轄管終端、數據庫服務器、通信前置服務器的數據轉發[6];②在云平臺的基礎上,采用自動化部署將業務模塊部署到各對應的虛擬機上;③數據存儲包含關系數據庫和大數據存儲方式,可實現管轄范圍內車站監測數據的全生命周期存儲,為智能診斷、數據分析提供數據支撐。

4) 交互層,主要負責為用戶和運維人員提供B/S(瀏覽器/服務器模式)或C/S(客戶端/服務器模式)架構的展示界面,能夠高效展示系統的總體資源利用率和動態資源調度發生率。

1.3 關鍵技術

1.3.1 分布式架構

監測系統中心前置軟件及中心應用軟件采用分布式結構進行開發,前后端分離部署,并借鑒SOA(面向服務的架構)設計模式,將中心前置作為通信服務總線,便于統一控制業務流向及協議格式,能夠使監測業務實現內部流程標準化,并能夠應對未來多變的接入場景。各模塊之間松耦合,根據應用場景靈活選擇部署,模塊間除了部分業務有關聯性外,各程序運行互不干擾,以降低故障傳遞性。

1.3.2 集群模式

為了提高分布式結構中單節點軟件的高可用性及并行處理能力,中心前置軟件、中心應用軟件均采用集群模式,并支持在線橫向擴展。集群模式具備以下重要機制:

1) 高可用性。當集群中部分節點失效后,能夠正常提供集群服務,由Zookeeper應用程序協調機制,進行業務遷移。

2) 橫向擴展。集群通過在Zookeeper應用程序上注冊節點信息,集群中的主控節點負責監控節點變化,在節點發生變化時,推送原數據到其他節點及中心通信組件,各節點根據通知進行相應的策略調整。

3) 負載均衡。根據業務量的大小動態均衡各節點業務處理量,在保障負載均衡的同時,提高整體并發能力和響應速度。

1.3.3 自動化部署

在云平臺上,業務系統部署對象從物理服務器轉變為虛擬機,當面對業務量大的場景時,人工進行業務部署將面臨低效率窘境。為了簡化部署流程,提升部署效率,采用Java與Shell混合編程的方式實現業務部署的自動化。自動化部署選項主要包含初始化節點、新增節點和刪除節點。

業務自動化部署程序主要由配置文件讀取、文件分發和進程操作三個腳本組成?；玖鞒虨槌绦蛲ㄟ^讀取配置文件,獲取待部署機器的相關信息,包括IP信息、部署業務信息及登錄賬戶密碼等,然后調用分發腳本對目標機器進行業務程序拷貝,最后通過用戶的選擇對業務程序進行相關進程操作,實現業務自動化部署。以初始化節點為例,其自動部署流程如圖4所示。

圖4 初始化節點自動部署流程圖

自動化部署的操作界面主要通過Java語言內嵌tomcat程序啟動DeployWEB包,其主要負責展示和交互數據,并處理主體業務邏輯。配置文件的讀取主要通過shell腳本調用ConfigFile函數實現數據庫配置文件庫表的讀取。文件分發腳本主要是由except和scp命令來實現遠程登錄和文件拷貝。進程操作過程主要是由watchDogDeploy.sh和KillOrDeleteObj.sh腳本實現。

2 方案應用及評價指標

實驗室環境配置8 TiB磁盤陣列、6臺32核256 GiB內存服務器、2臺光纖交換機、1臺三層交換機構建基于云平臺的鐵路信號集中監測系統,其網絡架構如圖5所示。

注:VM為虛擬機。

虛擬機采用64位CentOS 7操作系統,每臺配置4個虛擬網卡,分別用于業務網及管理網,通過在業務網部署的一臺虛擬機運行自動化部署工具對業務網內虛擬機下發命令,以實現業務系統自動化部署。

自動化部署業務和人工部署業務耗時對比如圖6所示。測試方式為同一個人分別采用兩種方式進行系統部署,共重復5次,部署時間取均值。

圖6 自動化部署與人工部署業務耗時對比

采用SLA(服務等級協議)對云平臺進行質量評估,評估原則主要有以下幾個方面:

1) 可用性。在所需要的資源得到保證的前提下,云計算服務提供者能夠在規定的條件下,在給定的時間間隔內,依據云服務SLA向用戶提供相應云計算服務的能力。

2) 可靠性。在面臨網絡環境的動態不確定性、服務交互通信可靠性改變、服務遭遇惡意攻擊拒絕、服務基礎設施故障等問題時,其服務質量是否能夠得到保障的評估指標。

3) 效率性。服務的及時響應性、服務互動溝通機制、服務投訴解決率、計算資源配置及時性及虛擬機遷移時間[7]。

4) 可維護性。例如平均故障維修時間、擴展性、兼容性。

結合CSM業務特點,提出如下服務質量評價指標:

1) IaaS的SLA參數主要包括虛擬機和服務器,以及用戶需求的響應時間等,如表1所示。

表1 IaaS的SLA參數及說明

2) PaaS的SLA參數主要包括云服務平臺和平臺環境的相關參數,包括平臺的整合能力和可擴展性等,如表2所示。

表2 PaaS的SLA參數及說明

3) 依托實驗室搭建條件,并結合CSM業務需求,對IaaS進行服務質量測評,測評結果如表3所示。

表3 IaaS的服務質量測評結果

3 結語

云計算技術充分利用了現有的硬件基礎,不僅節約了鐵路各系統的建設成本,還將對既有分散的各系統體系結構和部署服務模式產生積極影響。作為鐵路電務設備監測及管理的重要系統之一,基于云平臺的鐵路信號集中監測系統對系統資源進行了優化配置,其部署靈活性、性能穩定性及可靠性均有顯著提升。

基于云平臺的鐵路信號集中監測系統架構研究,符合鐵路信息化、智能化的發展理念,能夠支撐鐵路電務系統大數據分析功能,對于推進信號設備的修程、修制及改革具有重要的意義。