地鐵視頻監控系統云平臺承載方案淺析*

王 鵬

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

0 引言

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

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

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

3) 中心集中云平臺+站段級傳統物理機：該方案僅中心業務系統云化；而站段級維持各業務系統的傳統架構，即非虛擬化方案。

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

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

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

1 CCTV系統集中部署于中心集中云平臺方案分析

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

1.1 中心集中云平臺內的資源遷移需求

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

注：SSD為固態硬盤；NCC為線網指揮中心；SAS為串行連接接口硬盤；SATA為串行高級技術附件接口硬盤；OCC為運營控制中心；OTN為光傳送網。

該架構下全線各站段產生的海量視頻、圖像需實時上傳并集中存儲于云數據中心，這將對線路傳輸網和線網骨干傳輸網的系統架構及設備選型產生影響。

Btr=NstaCipcDcr/1 000

(1)

式中：

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

Nsta——車站節點數量，座；

Cipc——單節點IPC(網絡攝像機)數量，路；

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

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

傳統二層網絡的所有網元位于同一個廣播域內。隨著網絡節點數量增加，網絡穩定性和安全性面臨巨大的壓力?？紤]到車站和云數據中心之間網絡的穩定性和安全性，必須以三層組網。

從網絡層面而言，線網、線路通過三層路由打通數據通路。

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

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

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

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

圖2 VxLAN技術下的全線網大二層網絡通道Fig.2 Full line network large 2-layer passage under VxLAN technology

當前階段VxLAN網絡配置較為復雜，其技術體系還有待完善?？紤]到成本，用戶一般只在數據中心范圍內實施VxLAN技術方案。另外不同廠家的VxLAN交換機互聯互通還存在問題，因此，在地鐵線路之間、線路中心與車站之間統一部署VxLAN技術的難度和投資較大，虛擬機跨區域遷移功能的實現還有待時日。

1.2 災備降級場景需求分析

1.2.1 中心集中云平臺故障

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

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

1.2.2 云數據通道/網絡故障

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

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

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

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

2 站段級CCTV系統部署于邊緣云方案分析

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

2.1 邊緣云提供IaaS層服務

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

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

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

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

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

2.2 邊緣云提供PaaS層服務

如圖6所示，由站段邊緣云節點提供CCTV系統在車站實時在線工作所需的計算和存儲資源，由邊緣云對硬件資源進行虛擬化并提供PaaS層服務。PaaS層提供業務系統的應用運行、開發環境及開發組件等平臺性服務[6]。

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

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

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

3 結語

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

隨著網絡虛擬化技術體系的不斷發展和完善，建議城市軌道交通云平臺采用VxLAN技術搭建線網及線路大二層網絡架構，并要求其外部服務網提供PaaS層服務，最終實現城市軌道交通云平臺與其承載的業務系統間深層次的融合。