APP下载

基于云平台的新一代智慧型 AFC系统方案应用研究

2022-04-16卢肖静

现代城市轨道交通 2022年4期
关键词:智慧型计算机系统车站

吕 欢,吴 松,郭 戈,卢肖静

(中铁电气化局集团有限公司,北京 100166)

1 引言

随着云技术的发展以及自动售检票(AFC)系统用户需求的提升,传统AFC系统工程建设中线路中心、车站服务器所采用的物理机模式因其资源利用率低、物理位置分散不便于维护和管理等缺点已不适用当前的系统需求。基于云计算的分布式处理系统,采用PC集群及开源的分布式数据库,可使硬件投资大幅下降。用户可根据业务负载情况动态调整虚拟机资源的使用情况,通过在线升级服务器配置,解决因客流增长引起的中央计算机/交易服务器和部分车站的计算机系统资源超载的现象,避免因大客流换乘站系统CPU长时间满负荷运转影响交易上传。

根据不同的需求建立数学模型,分析挖掘AFC系统有价值的信息,实现运维智能化、乘客服务便捷化是智慧型AFC系统的需求。AFC系统运行需要对大量的实时数据(客流数据、票卡及票库数据、设备状态数据、运营模式数据以及联机数据)进行计算分析。由于依托云技术的大数据平台可实现AFC系统的业务数据分析,因此基于云平台的新一代智慧型AFC系统的研究应用也是目前城市轨道交通建设关注的重点。

2 云平台结构概述

城轨云平台由中心级云平台和站段级云节点构成。中心级云平台按不同业务应用、大数据平台划分虚拟数据中心(VDC),通过逻辑隔离技术为各业务系统灵活计算、分配存储和网络资源。站段级云节点同样按相关业务应用划分VDC,为各业务系统提供资源。中心级云平台、站段级云节点统一规划、部署基础设施即服务(IaaS),根据应用需求适时部署平台即服务(PaaS)、软件即服务(SaaS)。

3 新一代智慧型 AFC 系统方案

3.1 新一代智慧型 AFC 系统需求分析

智慧型AFC系统除支持发售实体票卡外,也支持多种类的互联网票卡,如二维码票、人脸票、掌静脉票等。不同票种子系统的服务器虚拟机可以集成铺设,也可以单独铺设,但用户需要根据业务负载情况动态调整虚拟机数量。同时AFC系统需要根据客流情况调整虚拟机资源的使用,包括离线/在线调整虚拟CPU(vCPU)数量,离线/在线调整内存,离线添加/删除网卡,离线/在线挂载虚拟磁盘等。如某工程实例,在工程建设前期中央计算机/交易服务器虚拟机CPU及内存资源规划为8C/16G,大客流换乘站车站计算机系统服务器资源规划为4C/8G。新线开通后,由于客流量大,中央计算机/交易服务器和部分车站的计算机系统均发生资源超载现象,其中大客流换乘站的计算机系统CPU长时间满负荷运转,严重影响交易上传。因此运营结束后在线将中央计算机/交易服务器从8C/16G升级到16C/32G,将大客流换乘站计算机系统服务器从4C/8G升级到8C/16G,解决资源超载问题。

3.2 基于云平台的新一代智慧型 AFC 系统架构

基于云平台建设的智慧型AFC系统主要由云、管、端3部分组成。云是城轨云平台,管是云网络,端是用户APP、自动售票机、自动检票机等车站终端设备。云平台对AFC业务应用系统所涉及的计算、存储、网络及安全等资源进行统一规划、部署和管理。基于云平台建设的智慧型AFC系统将线网级的清分中心、互联网票务平台、多线路中心以及各车站计算机系统应用软件均部署于中心级云平台。不同于传统模式AFC系统与传输系统进行接口,智慧型AFC需与云平台网络进行接口,而专用的控制器、接入设备、终端设备等由AFC业务应用系统统一部署和管理。基于云平台的新一代智慧型AFC系统结构分为5层,架构图如图1所示。

图1 AFC系统云部署架构

3.3 基于云平台的新一代智慧型 AFC 系统方案

3.3.1 清分中心以及互联网票务平台上云方案

一个城市中的轨道交通一般包含多条线路,通常情况下分别由多个运营单位运营管理,而各线路之间又相互连接贯通,因此城市轨道交通清分中心及互联网票务平台部署于城轨云上则非常必要。在清分中心以及互联网票务平台上云方案中,清分中心以及互联网票务平台对云平台的资源需求如表1所示。

表1 清分中心以及互联网票务平台对云平台的资源需求

3.3.2 线路中心 AFC 系统业务上云方案

在线路中心AFC系统上云方案中,线路中央计算机系统(LC)虚拟机对云平台的资源需求如表2所示。线路中心AFC系统中的非云化设备(加密机、编码分拣机、打印机等)部署可采用独立组网方式,与中心级云平台的物理接口界面宜位于中心级云平台外部接入区交换机外侧。

表2 单线路LC系统虚拟机的资源需求

3.3.3 车站级 AFC 系统业务上云方案

(1)车站级AFC系统业务上云方案。站段云节点主要有4种实施方案:方案一,仅AFC中央业务系统部署于中央级云平台,车站业务按传统方案设置;方案二,AFC车站业务系统部署于中央级云平台,站段云节点设置降级服务器,车站与中心网络断开的情况下,由站段云节点降级服务器支持AFC系统降级运营;方案三,AFC车站级业务部署于站段云节点,站段云节点设置边缘计算服务器;方案四,AFC车站业务系统部署于中央级云平台,站段云节点不设置服务器。

(2)方案比选。方案一,AFC中心系统由云平台安全生产网承载,规模较小,车站相关业务系统未上云,技术方案较成熟,但未完全达到资源整合的目的;方案二,站段云节点仅在降级的情况下使用,虽然可靠性较高,但造成一定的资源浪费;方案三,站段云节点设置云节点服务器,承载AFC业务车站级系统,不改变原AFC系统架构,基于云-管-端的架构,实现边缘计算,数据上传的功能;方案四,相对方案三总体节约计算资源,但车站缺少降级服务,对传输网络的可靠性要求极高。经过以上比选可知,目前AFC业务上云采用方案三最为安全可靠、经济合理。

(3)车站计算机系统(SC)虚拟机对云平台的资源需求如表3所示。

表3 SC虚拟机对云平台的资源需求

(4)车站AFC系统的非云化设备部署方案。车站AFC系统的非云化部署设备宜采用独立组网方式,与车站级云平台的物理接口界面宜位于车站级云节点汇聚交换机外侧。车站服务器云化以后,紧急控制器通过串口连接服务器的传统方式就不适用当前的接入模式,需进行改进。改进方案有以下2种:方案一,通过串口延长线连接车控室AFC监控工作站进行紧急模式反馈;方案二,定制开发带网口的紧急控制器连接AFC三层交换机,通过网络进行紧急模式反馈。从上述方案描述中可见,方案一会增加潜在故障点,可靠性较差,因此在工程实践中推荐采用方案二。

3.3.4 云桌面系统方案

云桌面系统按照AFC系统业务应用需求为AFC系统提供控制中心以及车站的云桌面服务。云桌面以服务器虚拟化为基础,允许多个用户桌面以虚拟机的形式独立运行。AFC系统云桌面工作站与其他业务系统同时共享CPU、内存、网络连接和存储器等底层物理硬件资源,并可避免受到由其他业务系统用户活动所造成的应用程序崩溃和操作系统故障的影响。在云桌面系统方案中AFC云桌面工作站虚拟机的资源需求如表4所示。

表4 AFC云桌面工作站虚拟机的资源需求

3.3.5 网络安全等级保护方案

云平台按照安全等级保护三级(简称“等保三级”)建设,并统一提供底层病毒防护。中心级云平台在各业务系统之间部署云内防火墙,其中安全策略由AFC根据开放的端口类型决定。在安全生产网内部部署入侵检测设备,用于云平台的统一入侵检测,并具备检测到恶意代码可报警功能;最外层部署流量探针,用于探测业务系统的异常流量。同时配备网络审计设备,统一对云平台各业务系统流量做网络审计。

基于云平台部署的AFC系统要满足网络安全等保三级的要求,需从以下几个方面进行安全防护。

在通信网络安全防护方面,由于云平台统一对各业务系统流量做网络审计,AFC系统侧则不再单独配置针对通信网络安全的防护设备。同时需保证AFC系统网络与其他专业网络之间的相互隔离。

在区域边界安全防护方面,AFC系统须设置运维审计(堡垒机)、日志审计设备。AFC系统控制中心具备网络安全控制、审计等功能,与云网络通过物理防火墙进行隔离。AFC系统车站设备同样通过物理防火墙与云网络进行隔离。车站物理防火墙需具备入侵防御功能,一旦检测到恶意代码,会自动进行丢弃。

AFC系统网络设备等保方案是在车站及车辆段、控制中心(2台主备)部署防火墙,在控制中心设置安全服务器,部署安全管理平台、运维审计、日志审计、漏洞扫描、数据库审计、防病毒软件。同时需对车站终端设备进行必要的安全加固。其中控制中心网络安全设备配置有3种方案:方案一,采用服务器+软件的模式,该模式可移植性好,可扩展性强,软件灵活度强;方案二,采用一体机模式,该模式方便,但可扩展性差;方案三,采用分体设备,该模式投资较大。基于以上比选,推荐选择服务器+软件方案部署控制中心网络安全设备。

管理中心安全防护主要通过网络管理系统、综合安全管理平台等机制实现安全防护。AFC系统网络等保方案设置安全管理平台,通过平台对安全设备进行统一管理。AFC系统网络安全防护系统构成如图2所示。

图2 AFC系统网络安全系统构成图

4 基于云平台的新一代智慧型 AFC 系统验证

4.1 AFC系统软件部署方案

AFC系统中的线路中央计算机系统部署2台应用 /交易服务器、2台数据库服务器、2台通信服务器、1 台存储设备,并全部部署于中央级云平台上。每个车站设置1台车站计算机系统服务器,部署于站段级云平台上。

基于云平台的AFC软件部署步骤为:第一步,开通操作员账号、部署系统、部署应用服务;第二步,部署中央计算机、车站计算机软件。

云平台中央计算机系统及车站计算机系统部署步骤包括虚拟机创建、操作系统部署、基础软件部署、中央计算机软件部署、系统应用软件(操作系统、软件工具开发包、消息队列、数据库、网络时间协议(NTP)、AFC应用程序等)部署。其中线路中央计算机系统/车站计算机系统(LCSC)服务器虚拟机部署操作系统(centos7.7、JDK1.8 、mysql5.7.29、rabbitmq3.8.2),云桌面工作站部署操作系统(windows10、chrome、navicat)。实际工程中整个部署周期大概需要10天。

4.2 AFC 系统软件测试方案

软件测试通常在软件部署完成后10天内完成在线测试,测试内容包括中央计算机系统、车站计算机系统的业务测试、功能测试和性能测试。一般情况下,先采用1个中央计算机系统,2个样板站的模式进行初步部署测试,其后随着其余各车站的陆续开通,跟随建设进度逐步进行测试。

4.2.1 中央计算机系统测试内容及目的

中央计算机系统的测试内容主要包括业务测试、功能测试及性能测试,具体测试内容及目的如下所述。

(1)中央计算机数据库服务器高可用集群测试为验证中央计算机数据库高可用集群是否可以正常安装并正常切换。

(2)外部FTP服务器上传、下载功能测试旨在验证中央计算机服务器是否能够从外部FTP服务器上传、下载文件。

(3)数据库备份、恢复测试的目的是为验证数据库是否能够正常备份和恢复。

(4)中央计算机系统与外部系统接口测试中,首先中央计算机系统开启对外部系统的接口,其次在外部接口模拟机上利用Modbus TCP Client软件读取中央计算机系统提供的数据,从而验证中央计算机系统与对外部系统的接口性能。

(5)时钟同步测试通过开启各服务器云桌面的时间同步客户端,测试客户端与外部时间源的同步功能。

(6)云平台虚拟机管理测试通过云管理平台查看虚拟机状态,并实现快照及快照恢复。

(7)云平台桌面终端系统安装测试,该测试旨在验证在云平台桌面终端上能够正确部署windows10 操作系统及相关软件。

(8)中央计算机系统软件功能测试通过部署并启动中央计算机系统软件,利用客户端验证中央计算机系统软件是否正常运行。

(9)中央计算机系统性能测试通过模拟全线车站计算机系统同时访问中央计算机系统的场景,查看中央计算机系统相关服务器的性能。

4.2.2 车站计算机服务器操作系统及相关服务部署测试

(1)SC系统软件功能测试旨在验证在车站计算机服务器上是否能够正确部署操作系统及相关服务。

(2)车站计算机系统性能测试。以车站终端设备(SLE)最多、客流量最大的换乘站为例,测试该站全部SLE设备发起向车站计算机系统的访问请求,验证车站计算机系统服务器性能。

(3)云平台的网络性能测试。利用网络测试软件测试云平台主机间的网络性能。

5 结束语

基于云平台部署的智慧型AFC系统可根据业务需求在线调整服务器虚拟机数量,根据客流状态调整虚拟机资源配置,相较传统AFC可减少服务器投资及运维费用,有利于新增票种子系统的部署。本文通过探讨清分中心、互联网票务平台、线路中心、车站计算机系统基于云平台的部署方案,并经过多方案比选,推荐清分中心、互联网票务平台、线路中心部署于中央级云平台,车站计算机系统部署于车站接点云的方案为基于云平台智慧型AFC系统部署的最佳方案。该方案既可满足智慧型AFC系统用户的需求,又能满足在中心与车站网络断开的情况下,实现车站降级服务。除此以外本文还探讨智慧型AFC系统中非云设备上云以后的改进方案、网络安全等级保护方案及系统验证方案,为后期基于云平台智慧型AFC系统部署提供一些工程经验。

猜你喜欢

智慧型计算机系统车站
基于智慧教室功能建构及其建设思考
车站一角
上海“十四五”大力发展智慧型基础教育
做一位智慧型班主任
控制
IBM推出可与人类“辩论”的计算机系统
在北京,一个车站的治理有多难
计算机组成与结构课程教学的探讨与实践
计算机系统变革性研究的四个问题
地铁车站