基于LKJ信息系统跨平台及安全性研究与应用
2021-05-27阳亦斌欧盛芬
阳亦斌,杨 将,欧盛芬
(湖南中车时代通信信号有限公司,长沙 410119)
1 概述
随着2018年国家《网络安全法》,2019年底《信息安全技术网络安全等级保护基本要求》的正式实施,在中国制造向中国智造转型的关键期,“国产、自主可控”已成为我国信息技术产业发展的时代标志,中国国家铁路集团有限公司(以下简称“国铁集团”)以及下属18个铁路局集团有限公司将信息系统网络安全提升到前所未有的高度。为落实《中共中国铁路总公司党组关于进一步加强铁路网络安全和信息化工作的通知》(铁总党[2019]28号)的要求,由国铁集团信息公司牵头,联合中华人民共和国公安部、中国铁道科学研究院集团有限公司测评中心,2019年7月对全路3 896个信息系统进行网络安全等级保护定级。按照《国铁集团工电部关于做好工电信息系统整改相关工作的通知》(工电综技电[2019]132号)的要求,全路各铁路局集团有限公司对信息应用系统开展全面安全性整改。
LKJ信息系统具体包含LKJ设备运行监测管理系统、LKJ数据无线换装系统、电务车载设备生产管理平台、调车防护等系统。其中LKJ设备运行监测管理系统和LKJ数据无线换装系统已被定级为信息安全等级保护第三级,各系统主要采用国外X86服务器,闭源Windows操作系统平台,数据库采用Oracle系列版本,消息中间件采用IBM MQ,整个业务系统体系基本搭建在国外的平台基础之上。
2 可行性替代分析
目前LKJ信息系统主要采用Windows服务器、IBM MQ中间件、Oracle数据库等国外的技术和产品,因此需从操作系统、数据库、消息中间件、业务系统等层面进行全面安全可控跨平台移植。原始系统技术选型分析示意如图1所示。
2.1 操作系统
图1 原始系统技术选型分析示意图Fig.1 Analysis diagram of original system technology selection
LKJ信息系统对操作系统的应用要求主要体现在安全性、稳定性、兼容性、易用性和可维护性方面。Linux作为运行在全球数据中心服务器、大型计算机、超级计算机上的开源操作系统,应用广泛,可满足LKJ信息系统应用要求。Linux发行版本多,本文主要对主流Linux版本分支,结合应用需求进行对比分析。具体对比如表1所示。
表1 Linux版本分支对比表Tab.1 Comparison table of Linux revision branch
从表1中看出,Rhel、CentOS、Debian适用于服务器,稳定性和兼容性是其追求的主要目标,其内核版本的更新频率较低;Fedora、Ubuntu、优麒麟、Deepin主要应用于个人办公桌面,稳定性要求不高,追求功能的新颖性。综合本次业务需求,采用CentOS 8.x作为数据库、消息中间件、通信子系统、业务子系统的操作系统承载平台,并在CentOS基础上进行优化定制和安全加固。
2.2 数据库
Mysql被公认为是最流行的开源关系型数据库,PostgreSQL被公认为是最先进的开源关系型数据库,是Oracle的“开源版数据库”。目前既有LKJ信息系统采用Oracle数据库,PostgreSQL、Mysql数据库均能满足替代要求,重点从语法对数据库移植复杂度、工作量和成本进行分析。具体对比如表2、3所示。
PostgreSQL、Mysql、Qracle、Ms sql server等数据库语法结构差异较小,差异主要来源于数据库提供的功能、数据库字段类型、系统提供的函数。PostgreSQL在数据移植难度、数据完整性、大数据量操作、密集运算、重型负载方面的表现都要好于 Mysql数据库和 Ms sql server,因此采用PostgreSQL数据库。
2.3 消息中间件
消息中间件是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等功能,属于分布式系统架构中的一个重要组件。
表2 数据类型对比表Tab.2 Comparison table of data type
表3 语法函数对比表Tab.3 Comparison table of syntax functions
目前开源的消息中间件种类较多,常见的有ActiveMQ、RabbitMQ、Kafka、Rocketmq、ZeroMQ等产品。根据LKJ信息系统业务的需要,对中间件进行定制、调优、改进、固化。具体对比如表4所示。
综上从消息中间件在持久化、可靠性(消息)、性能、易用性(使用难度)等多个维度进行了对比分析,单纯从吞吐量和TPS角度分析,Kafka、Memcacheq、ZeroMQ性能较好,经过测试,Kafaka在单台服务器上处理小消息时TPS能够达到100 W/S,在同等条件下RabbitMQ的吞吐量只有Kafka的1/10至1/5之间,但RabbitMQ在使用RAM模式时,其性能较高。Rocketmq和ActiveMQ的性能居于其间,约几十万条每秒。基于目前实际LKJ信息系统需求,并综合性能考虑,Kafaka更具有优势。
表4 中间件对比表Tab.4 Comparison table of middleware
2.4 车地平台化通信
根据LKJ信息系统跨平台设计总体要求,实现高并发、高稳定车地平台化通信,支持TCP和UDP协议,支持IPV4和IPV6网络协议,支持车地通信协议的用户自定义,且基于国产或开源操作系统。
Epoll是Linux下多路复用IO接口Select/Poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下系统CPU利用率。在获取事件时,无需遍历整个被侦听的描述符集,只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合。Epoll除了提供Select/Poll那种IO事件的电平触发(Level Triggered)外,还提供了边沿触发(Edge Triggered),使得用户空间程序有可能缓存IO状态,减少Epoll_Wait/Epoll_Pwait的调用,提高应用程序效率。综合考虑采用基于开源的Epoll第三方通信库进行设计完成替代。
3 跨平台设计与实现
3.1 系统架构
LKJ信息系统由操作系统、数据库、消息中间件、及各个子系统等组成。LKJ信息系统跨平台总体系统架构示意如图2所示。
对本方案中涉及到的关键信息进行分层,总体可以分为车载设备、车地传输层(通信子系统)、数据分发层(消息中间件:Kafka)、数据处理层、数据存储层(数据库:PostgreSQL)、应用服务层、终端应用层,以及操作系统承载层(操作系统:Linux CentOS 8.x 平台操作系统 )。
3.2 技术架构
LKJ信息系统跨平台技术架构示意如图3所示。
根据LKJ信息系统跨平台设计总体要求,所有子系统均进行跨平台设计,兼容Linux和Windows平台。各个子系统均使用标准的C/C++语言和STL标准模板库,避免使用与系统相关的API接口;使用PostgreSQL数据库,均支持在Linux平台和Windows平台上部署,具有良好的跨平台部署能力;使用Kafka消息中间件,在业界比较常用且有大量实践案例,API支持多种语言,支持Windows和Linux双平台。系统采用Reactor网络编程模型,利用Reactor实例、多路复用器、事件处理器以及事件源四个核心组件,引入开源高性能事件驱动I/O库,进行平台通用模块框架设计,实现对Linux CentOS/Windows Server操作系统平台的兼容。
图2 总体系统架构示意图Fig.2 Overall system architecture
图3 技术架构示意图Fig.3 Technical architecture
3.3 平台化通信设计
根据对LKJ信息系统通信子系统性能分析,影响高并发、高性能的主要技术瓶颈在网络IO的快速收发、业务包的高速处理和转发。
通过网络IO模型的选型,使用复杂度O(1)的Epoll模型,在网络IO层面实现快速的网络吞吐,为了充分使用SMP多核的并发处理优势,在包的解析处理和转发层面,通信子系统使用可配置数量的业务线程池技术,避免线程频繁的创建和销毁,并充分利用硬件多核资源,以应对在多终端大并发连接情况下对通信数据包的高效处理。
在通信子系统内部,按照消息流向,可以架构为消息收发(Epoll)、消息处理(工作线程池)、消息分发(内部消息中间件处理)这3个流程。
通信子系统基础架构示意如图4所示。
图4 通信子系统基础架构示意图Fig.4 Communication subsystem infrastructure
3.4 操作系统设计
目前LKJ信息系统采用国外Windows操作系统平台,通过前期可行性替代研究,同时考虑对Kafka消息中间件、PostgreSQL数据库版本的支持,通过定制化的Linux操作系统平台,是实现操作系统安全可控的有效替换方案。CentOS是基于Linux 平台的操作系统,其内核kernel代码全部安全可控,可定制成具有高性能、高可用、高可靠和高易用等特征,支持多核、双态、多进程,可用于业务功能复杂、扩展性、稳定性、安全性较高的综合业务,满足业务对系统的实时性需求,同时支持QT应用或Web应用开发,并支持运行上层桌面,方便集成应用组件。操作系统软件架构示意如图5所示。
图5 操作系统软件架构示意图Fig.5 Operating system software architecture
3.5 数据库设计
通过对业务场景的需求分析以及数据库软件技术选型,LKJ信息系统跨平台选用PostgreSQL12(64位)数据库作为系统架构的数据库系统。
1)数据库接口机设计
在需要入库的业务和数据库之间,建立一层缓存机制,避免大量数据入库时PostgreSQL数据库处理不过来导致阻塞,影响查询等业务;接口机会汇聚多个入库请求,批量进行入库提交,以极大的提供入库的效率;在PostgreSQL数据库发生异常时,接口机会将入库数据缓存到文件中,当数据库上线时,再将数据插入至数据库中,提高系统整体的容灾能力。
为保证接口机数据高速写入,数据缓存采用内存缓存和磁盘文件相结合的方式。接口机的数据先写入到内存中,当小块数据缓存到较大数据量时,再调用接口批量写入到磁盘文件中,通过内存缓存累积成大块IO写入文件,来提高写入磁盘的效率。
入库数据流示意如图6所示。
图6 入库数据流示意图Fig.6 Inbound data flow
2)PostgreSQL数据库优化
LKJ信息系统跨平台设计需完成既有基于Oracle数据库的脚本移植(包括数据结构、字段类型、字段长度)、数据库内置存储过程触发器定时任务的移植,客户端访问数据库语句的代码移植,数据库的优化遵循由“硬”及“软”的方式进行调优。
数据库调优主要考虑LKJ信息系统单表海量数据,为确保操作数据的效率,对数据库进行分表分区设计,提升数据库的并发访问能力,避免单台数据库服务器成为瓶颈。按照日期对主表进行水平拆分,以一日一表的原则建立表结构相同的虚拟主表,按照每5 s 1 000条实时数据的量来进行计算,日表数据量约172.8万条。为避免主表拆分后对用户查询数据带来的额外开销,数据库设计时提供存储过程调用,用户操作主表,将查询语句提交给存储过程,存储过程根据传入的时间及条件,返回翻译后的查询、修改、删除等语句供业务系统调用,用户不再关注数据存放在哪张虚拟主表中。
数据库虚拟主表示意如图7所示。
图7 数据库虚拟主表示意图Fig.7 Database virtual main table
3)PostgreSQL数据库可靠性设计
双机热备,以主备两台数据库为基础构建高可用框架,提升整套数据系统的稳定性、数据安全性和性能,双机方案基于ROSE HA框架进行部署。ROSE负责数据库双机的资源管理层和消息传递,负责仲裁指定谁双机中的活动节点、IP地址的转移、本地资源管理系统、双机的心跳信息(heartbeat),以及负责数据库服务的启动、停止和状态查看。
数据同步,主数据库A对外提供读写,将数据同步至从数据库B,从数据库B不断从主数据库A接收到数据并入库,主从数据同步基于时间点的备份(简称PITR),其中把数据库变动日志记录WAL日志传送到另外一台服务器上有两种方式,WAL日志归档(base-file)和流复制(streaming replication)。
数据库异常及恢复,当数据库双机处于正常运行状态时,浮动IP位于数据库主数据库A上,客户端数据采集器通过浮动IP连接到A的接口机,数据由A进行缓存并入库,客户端通过该IP地址进行数据库连接和操作。从数据库B异常时,不影响数据库A的正常工作,待数据库B恢复后,继续进行数据的同步;主数据库A异常时,双机软件会将浮动IP切换到从数据库B,从数据库B上的数据接口机接收外部传入的数据并缓存到本地文件中,此时数据并不入库,只提供数据的读取操作,不提供数据的修改、删除、插入操作。待主数据库A修复后,双机软件将切回至主数据库A,此时主数据库接口机主动将从数据库B缓存的本地数据文件拷贝至主数据库A,由主数据库A上的入库接口机进行入库操作,以保证数据的完整性。
4 结束语
鉴于目前国内外形势,结合《信息安全技术网络安全等级保护基本要求》,本文采用基于国产或开源的操作系统、数据库、消息中间件等对LKJ信息系统进行跨平台设计、转型给出具体替代方案。通过部署与试用,所设计的替代方案满足LKJ信息系统工程化应用所需的安全性、可靠性及其他各项性能指标要求,有效保障了既有LKJ信息系统应用的平稳过渡,为今后在轨道交通领域信息系统自主化设计提供了具体思路。