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

王 鵬

(1.中鐵第一勘察設(shè)計(jì)院集團(tuán)有限公司， 710043， 西安; 2.軌道交通工程信息化國(guó)家重點(diǎn)實(shí)驗(yàn)室(中鐵一院)， 710043， 西安∥高級(jí)工程師)

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

Btr=NstaCipcDcr/1 000

(1)

式中：

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

Nsta——車(chē)站節(jié)點(diǎn)數(shù)量，座；

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

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

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

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

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

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

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

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

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

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

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

1.2 災(zāi)備降級(jí)場(chǎng)景需求分析

1.2.1 中心集中云平臺(tái)故障

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

圖3 中心集中云平臺(tái)故障場(chǎng)景Fig.3 Central cloud platform failure scenarios

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 結(jié)語(yǔ)

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

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