王 鹏

(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层服务，最终实现城市轨道交通云平台与其承载的业务系统间深层次的融合。