邓烨飞
(北京全路通信信号就设计院集团有限公司,北京 100070)
新基建贯穿智慧经济时代,有力支撑国内经济的长期稳定发展。近年来,云平台成为铁路行业新型通信基础设施的重要组成部分,为智能铁路的宏大目标提供数字底座。铁路通信云通过将计算、存储、网络、应用运行平台和软件等资源集中起来形成共享的资源池,以可度量的方式按需动态分配相应资源,提供服务。
云化规模增扩,伴之而来的是对铁路通信云的持续性、稳定性、可靠性需求的不断提升,铁路通信云不仅需要稳定可靠地运行,同时需要具备快速恢复能力——系统因不可抗力等原因停止工作时,数据业务仍能保持连续性。铁路通信云对容灾方案的需求从定时发起走向实时备份、从人工干预走向自动部署,已经成为一个研究重点。
容灾是指在距离较远的异址建立功能相同的系统,系统之间可以完成数据备份迁移和应用业务切换。当一方系统因意外停止工作时,另外一方系统可以完全恢复数据或接管功能,使该系统继续正常运行,实现数据和业务的“连续性”。
根据系统的保护程度,容灾系统分为数据级容灾、应用级容灾和业务级容灾。数据级容灾强调数据的备份和恢复,通过建立异地数据系统对本地系统关键数据实时/ 定时复制,保证数据不丢失;应用级容灾在数据级容灾的基础上再复制应用处理能力,建立一套包括数据备份系统、备用数据处理系统和备用网络系统等的备用支撑系统,提高业务连续性;业务级容灾是最高级别的灾备建设,在以上两个等级的灾备基础上,还需要考虑到通信信息系统之外的业务因素,包括备用办公场所和办公人员等。
衡量容灾系统的主要指标有:复原点目标(Recovery Point Objective,RPO),指当业务中断时最后一次备份数据所对应时间点,体现了能容忍的最大数据丢失量;复原时间目标 (Recovery Time Objective,RTO) ,指能够允许的服务中断时间长度。如图1 所示。
图1 RPO和RTO指标定义Fig.1 RPO & RTO indicator definition
灾备模式包括以下类型。
1)生产/灾备中心(Active-Standby)
生产中心提供生产管理、运营维护等业务系统主用服务,灾备中心提供冷备或者热备服务,当生产中心出现故障时,可以切换至灾备中心,这种模式技术方案复杂度较低,通过生产/灾备中心的资源冗余部署来提高可靠可用性,两个中心之间业务系统的部署范围和层次存在差异,资源利用率和业务连续性较低。
2)双活控制中心(Active-Active)
生产中心和灾备中心同时运行所有的业务系统,其中一个中心发生故障时,另一个中心可持续提供服务。这种模式下同一业务流量根据策略均衡负载于两个中心,技术方案复杂度较高,优点是能够提供业务高连续性和高可用性,资源也可以得到充分的利用。
铁路通信云与现有通信网络相适应,结合中国国家铁路集团有限公司(简称国铁集团)-铁路局集团公司-站段的组织模式,在不同层级遵循多云、分布式架构。根据铁路通信业务特性要求,铁路通信云设立业务云、网管云和监测云,分别承载通信类业务和支撑类业务。
铁路通信云具有多云多域的特点,多云是指国铁集团和各铁路局集团公司采用统一的技术制式和建设标准分别建设通信云。“多域”是指铁路通信云的业务云、监测云和网管云可以根据各自承载的业务类型和需求,建设物理隔离的资源池。铁路通信云将采用云边协同的架构,不同业务应用场景可集中部署于核心数据中心(Data Center,DC)或下沉至网络边缘DC。在站段级节点按需部署边缘云,具有数据存储和计算能力,满足不同的转发、存储和时延等要求。
结合铁路通信云的总体架构,其容灾需求如下:
1)通信云为多云、分布式架构,不同业务在应用特征、资源部署、可靠性和云安全等方面有着差异性需求。容灾方案需密切结合通信云架构及业务类型,采用分布式、多样化的容灾手段。
2)通信网元虚拟化上云,通信云的处理性能应适应通信业务的低时延要求,5G 核心网、调度通信系统等与行车安全密切相关的系统部署在通信云上,应满足高可靠性要求,在容灾切换时,需要网络的不间断传输来保证应用的连续性。
铁路通信云分别设立业务云、网管云以及监测云。其中业务云的典型应用系统包括5G 核心网、多媒体调度、综合视频和会议电视等;监测云的典型应用系统包括电源及机房环境监控系统、光缆监测系统、接口监测系统、铁塔监测系统、漏缆监测系统和数据网流量监测系统等;网管云的典型应用系统包括各系统的网管。
结合通信运营维护的障碍管理需求,评估通信各系统RTO 和RPO,可将铁路通信的各业务系统分为核心业务、重要业务和一般业务。核心业务涉及铁路运营生产,其状态直接影响铁路运行,障碍恢复时间为分钟级;重要业务指铁路运营生产的配套业务系统、影响日常运维的支撑类业务系统等;一般业务中断发生后对铁路运行或日常运维无影响。其容灾等级划分如表1 所示。
表1 容灾等级划分Tab.1 Classification of disaster recovery capability levels
铁路通信云具有多云多域的特点,在此基础上,依照关键通信类业务和支撑类业务在业务应用模型、流量带宽需求、负荷分担方式、网络调度能力和系统安全可靠性等方面的差异性,可灵活选择不同的容灾方式。
铁路通信云可以采用“两地三中心”的灾备模式,即同城双活中心加异地灾备中心。架构如图2 所示。
图2 铁路通信云“两地三中心”架构Fig.2 The “two places and three centers” system architecture of railway communication cloud
同城双活中心考虑业务云上的5G-R、多媒体调度通信、会议系统等障碍恢复时间为分钟级的业务系统,特别是5G-R、多媒体调度通信与行车安全密切相关,实现业务级容灾。双活中心可按照国铁集团和各铁路局集团公司要求分别异地设置。考虑到站点间的监测、业务会话同步确认等的网络延迟数,加上数据同步双写的光纤/传输链路延迟,都或多或少会影响整体业务的处理性能,距离越远影响越明显。因此同城双活中心与主中心相距30 ~100 km 以内,同时也可以有效避免同址供电和小型地质灾害带来的不利影响。
异地灾备中心考虑业务云上的综合视频监控系统和应急通信系统的灾备,实现应用级容灾,可按照国铁集团和各铁路局集团公司需求分别设置;考虑网管云、监测云的灾备,实现应用级容灾或数据级容灾,设置地点可按照国铁集团和各铁路局集团公司需求分别设置,或根据维护单位设置及管理监测范围跨路局集中设置。异地灾备中心与主中心相距300 km 以上,不属于同一个电网、同一江河流域及地震带,有效避免大型地质灾害影响。
“两地三中心”兼顾灾难备份和高可用能力,差别性制定容灾备份策略,既满足实际需求,也可以避免过度保护。
铁路通信云采用云边协同的架构,这一架构不仅结合了铁路通信特有的线型广域分布特性,同时也更为贴合铁路下一代通信在本地侧对“高速率、大带宽、低时延”的传输需求。
边缘云的灾备方式目前主要采用中心云和边缘云的容灾备份,边缘云与中心云互为灾备,来确保数据的可用性和安全性。在这种传统结构中,当光纤/传输链路过长或者跨站点读写频率过高时,会存在数据延时,无法及时灾备的风险。这种情况下,可在相邻两处边缘云设置灾备端,进行异地容灾备份,快速实现边边数据安全备份,节省云端传输时间及长途链路的带宽资源,实现分布式架构云平台的高可靠性。
通信云两地三中心及中心至边缘云之间需要敏捷弹性的自动化、智能化网络,以保证端到端的业务快速无阻塞转发。其数据链路作为通讯介质,在要求高可用性和冗余度的同时,还需要保证通讯质量。
目前可充分利用既有光缆、光传送网(Optical Transport Network,OTN)承载网等资源,配置冗余且相互独立的物理隔离通道,在某一中心故障时实现快速切换。也可采用数据传输链路与集群心跳链路相分离的设置,提高可靠性。随着铁路通信网络智能化升级,云网协同不断推进及深化应用。未来可采用以软件定义广域网(Software-Defined Wide Area Network,SD-WAN)与基于IPv6 转发平面的段路由(Segment Routing over IPv6,SRv6)为代表的智能化网络隧道技术,传送链路灵活可调度,网络连接弹性且安全,从而实时高效地获得网络资源信息,实现动态的管理和快速的部署。
双活控制中心的建立会带来新的问题——脑裂现象,即双中心一体化的业务系统在业务中断或者响应时间高时,会分裂成两个独立的控制中心。脑裂现象导致两个控制中心内的应用、数据库或者操作系统同时抢占共享资源,造成数据不一致,产生重大影响。因此需要到位的监测技术,在国铁集团和各铁路局集团公司部署监管平台,有效监测链路质量参数(如光衰、抖动和带宽等)、双活中心操作系统、应用和数据库的超时参数等,及时做出合理决策,解决问题。
双活控制中心提升了冗余的容灾解决方案。本地硬件冗余方案升级为跨站点建设,无形中在系统架构中增添了不稳定的因素,降低了整体业务平台的可靠性。因此需要应用虚拟化安全、数据安全隔离和加密、安全中间件、数据备份与恢复等云计算安全关键技术,建立监管范围更大、力度更强的云安全管理。识别两地三中心重要资产的安全状态,对硬件设备、操作应用系统、网络的安全机制集中管控、协同防护。
国铁集团积极推进云计算等新一代信息技术与铁路通信系统的深度融合。铁路通信云是信息技术(Information Technology,IT)和通信技术(Communication Technology,CT)相融合的新架构,通信云的灾备方案也有着其独有的特性和模式。容灾方案是在网元虚拟化后,对网络安全可靠性的探索,是铁路通信云具备快速恢复能力,实现业务连续性和高可靠可用性的有效抓手。目前,铁路通信云仍处于起步阶段,铁路通信云的容灾方案是一项长期、复杂的系统工程,需要从技术实现、经济成本、运营模式多个方面综合考虑,建设过程循序渐进而非一蹴而就。随着相关标准的建立及容灾技术的发展,后续仍需进一步的研究。