地鐵視頻監(jiān)控系統(tǒng)云平臺承載方案淺析*

王 鵬

(1.中鐵第一勘察設(shè)計院集團有限公司， 710043， 西安; 2.軌道交通工程信息化國家重點實驗室(中鐵一院)， 710043， 西安∥高級工程師)

0 引言

隨著中國城市軌道交通協(xié)會《中國城市軌道交通智慧城軌發(fā)展綱要》的發(fā)布，各城市軌道交通公司的智慧地鐵建設(shè)相繼進入高峰期。城市軌道交通云平臺作為智慧地鐵建設(shè)的基礎(chǔ)，得到了大規(guī)模的推廣。根據(jù)各城市地鐵的建設(shè)需求和建設(shè)思路，提出以下3種城市軌道交通云平臺的實施方案[1]：

1) 中心集中云平臺+站段級后備云節(jié)點：站段級后備云節(jié)點是中心集中云的一部分，只有虛擬化功能，不具備完整的計算能力。云節(jié)點為云桌面及各業(yè)務(wù)系統(tǒng)提供降級運行所需的虛擬化資源[2]。

2) 分布式邊緣云：具備完整的計算能力，既可以獨立于中心集中云運行，也可以實現(xiàn)中心集中云的統(tǒng)一管理。

3) 中心集中云平臺+站段級傳統(tǒng)物理機：該方案僅中心業(yè)務(wù)系統(tǒng)云化；而站段級維持各業(yè)務(wù)系統(tǒng)的傳統(tǒng)架構(gòu)，即非虛擬化方案。

將地鐵CCTV(視頻監(jiān)控)系統(tǒng)計算和存儲資源進行云化，是繼傳統(tǒng)視頻服務(wù)器+IP SAN(存儲局域網(wǎng)絡(luò))方案、流直存方案后的主流設(shè)計思路。與傳統(tǒng)架構(gòu)相比，基于云計算的CCTV系統(tǒng)不單獨設(shè)置通用服務(wù)器，而是設(shè)置CCTV業(yè)務(wù)計算資源池和存儲資源池。做云化的目的是為了硬件資源共享，提高硬件資源的利用率和系統(tǒng)的穩(wěn)定性，即在硬件資源池的基礎(chǔ)上，實現(xiàn)可漂移和可彈性伸縮的虛擬機或容器，一旦硬件出現(xiàn)故障，實現(xiàn)虛擬機或容器在資源池里自動遷移的目的。地鐵CCTV系統(tǒng)的云化有兩種方式：一是建設(shè)CCTV專業(yè)云，二是融合承載于服務(wù)多個系統(tǒng)的城市軌道交通云平臺。

目前,主流安防設(shè)備廠商自身可實現(xiàn)CCTV系統(tǒng)的深度虛擬化，即通過云存儲、云直存等方式實現(xiàn)類PaaS(平臺即服務(wù))層的視頻監(jiān)視專業(yè)云[3]。另外，CCTV系統(tǒng)亦可部署于城市軌道交通云平臺，即將傳統(tǒng)的系統(tǒng)架構(gòu)進行軟、硬件解耦后，部署系統(tǒng)軟件于城市軌道交通云平臺提供的虛擬機上。

本文著重從兩個角度分析基于城市軌道交通云平臺的CCTV系統(tǒng)設(shè)計方案中存在的重點和難點，即分析該系統(tǒng)集中部署于中心集中云平臺時災備降級應(yīng)用場景能否實現(xiàn)，以及該系統(tǒng)分散部署于分布式邊緣云時的優(yōu)缺點。

1 CCTV系統(tǒng)集中部署于中心集中云平臺方案分析

該方案是將全線所有站段級CCTV系統(tǒng)的計算及90 d存儲資源全部集中設(shè)置于中心集中云平臺，而站段僅僅提供少量的備份存儲。CCTV系統(tǒng)與其他系統(tǒng)間的接口僅在中心級實現(xiàn)。城市軌道交通云平臺除提供CCTV系統(tǒng)所需的計算、存儲、網(wǎng)絡(luò)資源外,還應(yīng)提供相應(yīng)的數(shù)據(jù)保護功能,如備份、容災服務(wù)，以期將傳統(tǒng)IT(信息技術(shù))模式下復雜的技術(shù)方案封裝為對用戶更加友好的云服務(wù)[4]。

1.1 中心集中云平臺內(nèi)的資源遷移需求

從硬件層面資源部署角度而言，中心集中云平臺與站段云分別部署，且均提供IaaS(基礎(chǔ)設(shè)施即服務(wù))層服務(wù)，如圖1所示。

注：SSD為固態(tài)硬盤；NCC為線網(wǎng)指揮中心；SAS為串行連接接口硬盤；SATA為串行高級技術(shù)附件接口硬盤；OCC為運營控制中心；OTN為光傳送網(wǎng)。

該架構(gòu)下全線各站段產(chǎn)生的海量視頻、圖像需實時上傳并集中存儲于云數(shù)據(jù)中心，這將對線路傳輸網(wǎng)和線網(wǎng)骨干傳輸網(wǎng)的系統(tǒng)架構(gòu)及設(shè)備選型產(chǎn)生影響。

Btr=NstaCipcDcr/1 000

(1)

式中：

Btr——傳輸帶寬需求，Gbit/s；

Nsta——車站節(jié)點數(shù)量，座；

Cipc——單節(jié)點IPC(網(wǎng)絡(luò)攝像機)數(shù)量，路；

Dcr——IPC編碼速率，Mb/s。

根據(jù)地鐵CCTV系統(tǒng)100%覆蓋率的要求，單車站節(jié)點須設(shè)置不少于200路IPC。按1條常規(guī)線路20座車站節(jié)點的規(guī)模，以及H.265編碼格式4 Mbit/s碼流考慮，通過式(1)計算，僅視頻存儲就對傳輸網(wǎng)帶寬有16 Gbit/s以上的需求。

傳統(tǒng)二層網(wǎng)絡(luò)的所有網(wǎng)元位于同一個廣播域內(nèi)。隨著網(wǎng)絡(luò)節(jié)點數(shù)量增加，網(wǎng)絡(luò)穩(wěn)定性和安全性面臨巨大的壓力?？紤]到車站和云數(shù)據(jù)中心之間網(wǎng)絡(luò)的穩(wěn)定性和安全性，必須以三層組網(wǎng)。

從網(wǎng)絡(luò)層面而言，線網(wǎng)、線路通過三層路由打通數(shù)據(jù)通路。

地鐵CCTV系統(tǒng)入云后，為了保證虛擬機遷移過程中業(yè)務(wù)不中斷，需要保證虛擬機的IP(互聯(lián)網(wǎng)協(xié)議)地址、MAC(媒體存取控制)地址等參數(shù)保持不變，這就要求虛擬機遷移必須發(fā)生在一個二層網(wǎng)絡(luò)中，即中心云平臺與站段云節(jié)點必須都位于同一個大二層網(wǎng)絡(luò)中。

大二層網(wǎng)絡(luò)是為了解決數(shù)據(jù)中心的服務(wù)器虛擬化之后的虛擬機動態(tài)遷移這個特定需求而提出的。虛擬機遷移是一種資源管理技術(shù)，可將虛擬機從一個物理機遷移到另一個物理機。虛擬機遷移是當資源分配出現(xiàn)問題(如CPU(中央處理器)負載率過高，內(nèi)存不夠等)時觸發(fā)的處置策略，對于城市軌道交通云平臺而言是一個常態(tài)性的管理手段。

如果當云數(shù)據(jù)中心資源不足或者發(fā)生故障時，由于云數(shù)據(jù)中心和車站的硬件資源分開部署，且無法實現(xiàn)虛擬機平滑遷移的功能，則將無法將云數(shù)據(jù)中心的業(yè)務(wù)遷移到車站。綜上所述，當采用全線所有車站CCTV系統(tǒng)計算、存儲、平臺軟件等資源集中部署于控制中心集中云平臺的設(shè)計方案時，云數(shù)據(jù)中心的故障將導致全線CCTV系統(tǒng)癱瘓。

如圖2所示，解決該問題需要引入VxLAN(虛擬擴展局域網(wǎng))技術(shù)，通過增加1個UDP(用戶數(shù)據(jù)包協(xié)議)格式的外層數(shù)據(jù)隧道作為數(shù)據(jù)鏈路層，這樣可以在三層網(wǎng)絡(luò)的基礎(chǔ)上建立若干個二層網(wǎng)絡(luò)間的隧道，而原有數(shù)據(jù)報文內(nèi)容作為隧道數(shù)據(jù)凈荷加以傳輸，可實現(xiàn)跨區(qū)域的大二層網(wǎng)絡(luò)[5]。

圖2 VxLAN技術(shù)下的全線網(wǎng)大二層網(wǎng)絡(luò)通道Fig.2 Full line network large 2-layer passage under VxLAN technology

當前階段VxLAN網(wǎng)絡(luò)配置較為復雜，其技術(shù)體系還有待完善。考慮到成本，用戶一般只在數(shù)據(jù)中心范圍內(nèi)實施VxLAN技術(shù)方案。另外不同廠家的VxLAN交換機互聯(lián)互通還存在問題，因此，在地鐵線路之間、線路中心與車站之間統(tǒng)一部署VxLAN技術(shù)的難度和投資較大，虛擬機跨區(qū)域遷移功能的實現(xiàn)還有待時日。

1.2 災備降級場景需求分析

1.2.1 中心集中云平臺故障

若中心集中云平臺出現(xiàn)大面積的硬件故障或資源不足的情況，各業(yè)務(wù)系統(tǒng)需要使用站段邊緣云節(jié)點的資源。如圖3所示，由于線路為非大二層網(wǎng)絡(luò)架構(gòu)，無法實現(xiàn)虛擬機遷移，因此各節(jié)點間的資源池無法拉通，其業(yè)務(wù)由控制中心降級至站段的應(yīng)用場景無法實現(xiàn)。

圖3 中心集中云平臺故障場景Fig.3 Central cloud platform failure scenarios

1.2.2 云數(shù)據(jù)通道/網(wǎng)絡(luò)故障

中心集中云平臺接入交換機與站段邊緣云節(jié)點的匯聚交換機時，一般通過線路級傳輸設(shè)備提供的若干個10 GE(萬兆位以太網(wǎng))通道相連。如圖4所示，若傳輸通道或云交換機發(fā)生故障，即使中心集中云與邊緣云由云管理平臺統(tǒng)一管控，網(wǎng)絡(luò)發(fā)生故障后亦無法做任何云管理操作，中心集中云與邊緣云上、下級業(yè)務(wù)亦無法遷移。

圖4 中心集中云數(shù)據(jù)通道中斷場景Fig.4 Cloud data passage interruption scenario

另外全線視頻集中在云數(shù)據(jù)中心存儲，雖實現(xiàn)了統(tǒng)一管理、集中運維，但降低了硬件采購成本，對傳輸系統(tǒng)的帶寬要求提升到了100 Gbit/s級別，導致其對網(wǎng)絡(luò)的依賴程度變高。

綜上所述，目前的地鐵通信網(wǎng)絡(luò)架構(gòu)設(shè)計無法實現(xiàn)中心集中云平臺災備降級方案。云數(shù)據(jù)中心與車站間的災備降級需通過VxLAN技術(shù)實現(xiàn)，即在各線網(wǎng)中心、線路中心、車站間搭建出大二層的網(wǎng)絡(luò)。另外，災備降級場景下的切換時延及數(shù)據(jù)保護機制，需要城市軌道交通云平臺與其承載的業(yè)務(wù)系統(tǒng)配合實現(xiàn)熱備倒換的功能。

2 站段級CCTV系統(tǒng)部署于邊緣云方案分析

該方案中站段級CCTV系統(tǒng)就近部署于本地的邊緣云，由邊緣云對硬件資源進行虛擬化。本地邊緣云可提供IaaS、PaaS及SaaS(軟件即服務(wù))。其優(yōu)點是為了避免災備場景下虛擬機跨區(qū)域遷移的問題。

2.1 邊緣云提供IaaS層服務(wù)

如圖5所示，由站段邊緣云節(jié)點IaaS層為CCTV系統(tǒng)提供在車站實時工作所需的計算、存儲、安全等IT資源服務(wù)。流媒體及控制服務(wù)器軟件直接部署在邊緣云IaaS層。CPU、內(nèi)存、存儲資源等資源配置須固定分配。

圖5 邊緣云提供IaaS層服務(wù)Fig.5 Edge cloud providing IaaS layer services

硬件虛擬化的優(yōu)勢是在硬件故障情況下CCTV業(yè)務(wù)可自動遷移。就當前階段而言，安防設(shè)備廠商將CCTV系統(tǒng)軟件部署到第三方城市軌道交通云平臺IaaS層上，上層流媒體控制業(yè)務(wù)在邊緣云硬件故障時無法感知到底層虛擬機的動態(tài)調(diào)度和遷移，從而無法實現(xiàn)CCTV業(yè)務(wù)的本地自動遷移。

CCTV業(yè)務(wù)匹配IaaS彈性調(diào)度的過程其實就是實現(xiàn)PaaS層服務(wù)的過程。安防設(shè)備廠商自有1套可實現(xiàn)自動遷移的專業(yè)云存儲解決方案，其實現(xiàn)機制是基于集群腳本調(diào)度的機制。該機制是在硬件上做輕量級虛擬化，配合集群調(diào)度手段，通過大量可能的虛擬機調(diào)度，將所有業(yè)務(wù)配置通過腳本完成，實現(xiàn)了類PaaS層的調(diào)度機制，以及實現(xiàn)了CCTV業(yè)務(wù)對底層虛擬機的遷移或彈性伸縮的感知。但這種方案由于內(nèi)部需要大量集群腳本配置綁定到所劃定好的、固定的虛擬機上，為軟、硬件于一體的解決方案，因此無法將軟件單獨解耦出來部署到通用的虛擬機上。換言之，將CCTV業(yè)務(wù)部署到站段邊緣云提供的通用虛擬機上的方式，會導致該業(yè)務(wù)使用的硬件資源被嚴格固定在指定的虛擬機上。

因此，邊緣云提供IaaS層服務(wù)的同時，并將CCTV業(yè)務(wù)直接部署到虛擬機上，可實現(xiàn)CCTV系統(tǒng)基本的使用功能，但要求虛擬機必須按業(yè)務(wù)進行固定分配。此時云集中平臺自身具備的虛擬機遷移和彈性的好處不復存在。此種云化效果，既增加了服務(wù)器(增加了“虛機管理系統(tǒng)”、“應(yīng)用操作系統(tǒng)Guest OS”、“中間件”等軟件層級)的開銷，又增加了系統(tǒng)運行的厚度和不穩(wěn)定性。這樣邊緣云IaaS層帶來的虛擬機彈性伸縮及遷移性優(yōu)勢丟失，底層硬件云化亦失去其價值。

2.2 邊緣云提供PaaS層服務(wù)

如圖6所示，由站段邊緣云節(jié)點提供CCTV系統(tǒng)在車站實時在線工作所需的計算和存儲資源，由邊緣云對硬件資源進行虛擬化并提供PaaS層服務(wù)。PaaS層提供業(yè)務(wù)系統(tǒng)的應(yīng)用運行、開發(fā)環(huán)境及開發(fā)組件等平臺性服務(wù)[6]。

圖6 邊緣云提供PaaS層服務(wù)Fig.6 Edge cloud providing PaaS layer services

CCTV流媒體控制業(yè)務(wù)本身具備實時動態(tài)變化的特性，即CCTV業(yè)務(wù)的云化不僅是基礎(chǔ)硬件資源層的云化，還要有支持硬件資源云化的CCTV平臺層同步匹配CCTV業(yè)務(wù)，從而構(gòu)建出基礎(chǔ)硬件資源層和平臺層均云化的CCTV云監(jiān)控系統(tǒng)。增加PaaS層服務(wù)后流媒體業(yè)務(wù)不必配置到某個固定的虛擬機上，而是通過PaaS層統(tǒng)一對接端口資源池，實現(xiàn)流媒體與后臺云平臺層之間的動態(tài)端口調(diào)度和遷移，最終實現(xiàn)流媒體業(yè)務(wù)的云化。

PaaS層的應(yīng)用還處于起步階段，邏輯結(jié)構(gòu)非常復雜[7]?？紤]到建設(shè)成本，PaaS層方案適合30萬路以上的IPC接入的管理/運營中心場景。對于單個地鐵站段200～500路IPC的接入場景，PaaS層的實現(xiàn)將導致系統(tǒng)過于復雜和龐大、費效比過低。據(jù)調(diào)研，目前地鐵CCTV系統(tǒng)直接部署在通用城市軌道交通云平臺上，且完全實現(xiàn)CCTV資源云化調(diào)度的案例，只有省級公安廳“雪亮工程”CCTV平臺。其接入IPC的量級達百萬路級別，即CCTV系統(tǒng)的深度虛擬化需要匹配PaaS層服務(wù)。單獨就站段級邊緣云而言，PaaS層虛擬化的代價太大。目前，從應(yīng)用的靈活性、部署的便捷性及運維的簡便性考慮，傳統(tǒng)的物理機部署方式更合適。該模式亦是城市軌道交通云平臺技術(shù)得到充分應(yīng)用驗證前的妥協(xié)方案[8]。

3 結(jié)語

在當前國內(nèi)主要城市軌道交通云平臺項目僅提供IaaS服務(wù)的前提下，根據(jù)CCTV系統(tǒng)流媒體控制業(yè)務(wù)的特點，結(jié)合災備降級場景下虛擬機遷移的需求，以及現(xiàn)有城市軌道交通云架構(gòu)對于CCTV業(yè)務(wù)遷移的支持能力等進行分析，推薦采用分布式邊緣云方案或中心集中云平臺+站段級傳統(tǒng)物理機方案來實現(xiàn)地鐵CCTV系統(tǒng)的虛擬化。

隨著網(wǎng)絡(luò)虛擬化技術(shù)體系的不斷發(fā)展和完善，建議城市軌道交通云平臺采用VxLAN技術(shù)搭建線網(wǎng)及線路大二層網(wǎng)絡(luò)架構(gòu)，并要求其外部服務(wù)網(wǎng)提供PaaS層服務(wù)，最終實現(xiàn)城市軌道交通云平臺與其承載的業(yè)務(wù)系統(tǒng)間深層次的融合。