面向铁路私有云的铁路信号集中监测系统迁移方案研究

李坤妃

(北京市自动化工程学校，北京 100101)

1 概述

随着高速铁路的快速发展，中国国家铁路集团有限公司更加注重经济效益、运营效率和服务水平。云计算、大数据、物联网等新兴技术的快速发展，结合铁路发展的实际运营维护需求，急需建立弹性计算能力强、共享度高、资源灵活调配、按需分配的基础性支撑平台——铁路私有云平台，并将既有的铁路业务信息系统迁移到云平台上，从而提高铁路基础设施的利用率，促进铁路业务系统之间的互联互通，支撑铁路业务快速发展，充分挖掘铁路数据潜在的价值，最终在保障铁路运输安全运行的前提下，达到提高企业经济效益的目的。

与其他行业信息系统向云平台迁移不同的是，铁路部分业务系统除融合了自身的生产功能还具备一部分监测功能，信号集中监测系统则是铁路信号系统的专职监测系统，具备一定的复杂性，对云计算、云存储、云安全提出更高级的要求。目前铁路信号集中监测系统，普遍存在管理层级多，部署分散，现场设备型号和厂家繁多，部分硬件资源短缺或者利用率低的情况，从而影响信号系统的监测和电务人员的运维保障工作，而信号集中监测系统属于保障铁路正常运营的系统，是不容故障和卡顿的，这就需要一个足够稳定和流畅的系统环境满足不断增加的业务质量需求。

结合当前信号集中监测发展近况，具备上云条件的是铁路局集团公司/电务段层信号集中监测子系统，本文就以铁路局集团公司/电务段层信号集中监测子系统为研究对象，铁路私有云平台为研究平台，进行系统的迁移方案研究。

2 铁路信号集中监测系统发展演进

信号集中监测系统是监测信号设备状态、发现信号设备隐患、诊断分析信号设备故障原因、实现信号子系统接口信息安全监督、辅助和指导现场维修及故障处理，提高电务系统设备运用质量和维护水平的重要信号设备。

信号集中监测系统是信号设备的集中监测和智能诊断分析平台，通过全面汇集地面信号设备、车载信号设备等相关设备的运行状态和监测数据，实现信号设备健康状态及维护信息的集中存储、安全监督、智能诊断、综合分析功能。其监测范围包括联锁、闭塞、列控中心、TDCS/CTC、RBC、TSRS、信号安全数据网、DMS、LMD、机车信号远程监测、驼峰、电源屏、计轴、区间综合监控等信号设备和子系统。其他信号子系统新增自诊断设备应通过信息接口方式纳入监测系统，其监测内容、接口方式、通信要求等应符合中国国家铁路集团有限公司相关技术条件要求。

信号集中监测系统层次结构为“三级三层”结构。“三级”为中国国家铁路集团有限公司级、铁路局集团公司级、站段级。“三层”为中国国家铁路集团有限公司层监测子系统、铁路局集团公司/电务段层监测子系统、车站层监测子系统。“三级三层”结构如图1 所示。集中监测系统应按局集团公司建设信号集中监测中心，系统层次结构如图2 所示。

图1 “三级三层”结构Fig.1 "Three-level three-tier" Structure

3 铁路信号集中监测系统向云平台迁移的需求

3.1 迁移方案的适用范围

结合当前信号集中监测演讲发展情况，具备上云条件的是铁路局集团公司/电务段层信号集中监测子系统。铁路局集团公司/电务段层信号集中监测子系统功能应涵盖通信前置服务器功能、应用服务器功能、综合分析服务器功能、数据库服务器功能、网管服务器功能、WEB 服务器功能、防病毒服务器功能、时间服务器功能、接口服务器功能、维护工作站功能。

图2 系统层次结构Fig.2 System hierarchical structure

铁路局集团公司/电务段层集中监测子系统配置计算资源设备、存储设备、网络设备、网络安全设备、电源设备、防雷设备、维护工作站；计算资源设备包括：通信前置服务器、应用服务器、综合分析服务器、数据库服务器、网管服务器、WEB 服务器、防病毒服务器、时间服务器、接口服务器等。

3.2 云平台资源需求

针对铁路局集团公司/电务段层集中监测子系统上云的需求（目前只考虑计算、存储、网络需求，信息安全、可靠性等用户需求不在本文中论述），大致梳理对于云平台的资源需求如下。

1) 存储设备

监测系统的存储设备，采用统一存储系统，配置冗余RAID 控制器，512 GB 缓存，存储容量为 300 TB，支持扩展到3 PB 裸容量。

2) 服务器资源

监测系统的应用及计算服务统一由计算资源池提供，部署在云平台的冗余信号及电务生产管理云平台需求及架构，虚拟机不应在同一台物理机。提供的服务至少包括以下内容。

a. 数据库服务器

数据库服务器2 套，至少16 个CPU 核，主频不低于4.2 GHz，内存容量不小于256 GB。

b. 应用服务器、综合分析服务器

应用服务器2 套、综合分析服务器2 套，至少32 个CPU 核、主频不低于2.0 GHz，内存容量不低于128 GB。

c. 通信前置服务器、网管服务器、WEB 服务器

通信前置服务器2 套、网管服务器、接口服务器、WEB 服务器，至少8 个CPU 核、主频不低于2.0 GHz，内存容量不低于32 GB。

d. 接口服务器组

每接口设置1 台接口服务器，每台至少8 个CPU 核、主频不低于2.0 GHz，内存容量不低于32 GB。

e. 时间服务器、防病毒服务器

时间服务器、防病毒服务器至少4 个CPU 核、主频不低于2.0 GHz，内存容量不低于16 GB。

4 铁路信号集中监测系统总体迁移方案

4.1 云平台技术架构设计

1）逻辑架构设计

通过对底层服务器、存储服务器虚拟化聚合部署，形成虚拟化资源池，利用海量数据存储系统，配合云计算资源管理层和资源服务层，实现对铁路私有云基础架构的平台层服务，为云计算中心提供云计算服务和良好的基础平台，并且具备很高的自适应和扩展性。铁路私有云计算平台硬件基础逻辑架构如图3 所示。

2）物理架构设计

图3 铁路私有云平台逻辑架构Fig.3 Logical architecture of railway private cloud platform

利用虚拟化技术将服务、存储、计算、网络构建为虚拟资源池，实现在单一物理服务器上运行多个虚拟服务器（虚拟机），把信号集中监测系统业务应用对于底层的系统和硬件的依赖抽象出来，从而解除应用与操作系统和硬件的耦合关系，使物理设备的差异性、兼容性对上层应用透明，使不同的虚拟机之间相互隔离，互不影响，从而实现同时运行不同操作系统，并提供不同的服务。利用分布式技术构建铁路信号大数据处理集群，将大量服务器计算存储节点整合成统一的计算存储集群，为铁路信号集中监测系统海量的业务信息，监测数据（开关量、模拟量、接口数据）以及后续可能开放的音频数据和视频图像数据的处理提供超强的计算能力和超大的存储空间，突破传统模式带来的发展瓶颈问题。

4.2 总体迁移方案

在借鉴其他行业信息化系统向云平台迁移经验的基础上，结合铁路信号集中监测系统的特点，定制了一套系统总体迁移方案。本迁移方案分为6 个阶段，分别为：需求调研、评估与分析阶段，迁移方案设计阶段，虚拟化环境准备阶段，业务应用迁移阶段，迁移后测试验证阶段和迁移后业务割接阶段。总体迁移方案如图4 所示。

1）需求调研、评估与分析阶段

在需求调研，评估与分析阶段，应确定用户的需求，迁移系统的范围和目标，利用调查问卷、系统评估工具（MAP）和访谈等评估形式，对集中监测系统系统进行评估，分析和汇总用户需求和系统需求，形成调研报告和评估分析报告。

2）迁移方案设计阶段

图4 应用系统迁移方案Fig.4 Migration solution of application system

在迁移方案设计阶段，针对待迁移系统范围内的物理服务器进行虚拟化适用性分析，设计迁移场景和云平台架构方案。在云平台方案设计的基础上，进行资源竞争设计、迁移顺序、迁移方法等内容的设计，形成总体迁移方案。

3) 虚拟化环境准备阶段

在虚拟化环境准备阶段，应判断现有的铁路私有云平台环境是否能容纳被迁移的所有对象、所有业务应用，以及检查计算资源、存储资源、网络资源以及数据库资源等，建立迁移所需的环境准备，如虚拟机、虚拟化网络等。

4) 业务应用迁移阶段

在集中监测系统业务应用迁移阶段，应根据既定的迁移方案严格的执行应用系统迁移，将物理机的应用系统移植到虚拟机内，有工具自动迁移和手工部署两种方式，应对系统迁移失败制定详尽的回退方案。

5) 迁移后测试验证阶段

对迁移到铁路私有云平台上的集中监测系统进行功能性测试、性能测试和稳定性测试，并进行应用验证，以便预先排除隐患，使应用系统成功的运行在云平台环境下。

6) 迁移后业务割接阶段

制定割接方案，依照割接方案进行割接操作，割接完成后进入割接后观察期，通过割接验收后将原系统下线。

5 结束语

通过对铁路局集团公司/电务段层信号集中监测子系统的需求调研实践，详细阐述信号集中监测系统面向铁路私有云平台的整体架构、迁移实施方案的整体步骤和策略要点，构建基于铁路私有云计算平台环境下的信号集中监测系统新平台。新系统借鉴其他行业应用云计算平台的成熟经验，并依托铁路私有欲的独特优势和特点，将信号集中监测系统整合到私有云平台环境下。系统应用模型在实验室环境下分别运行1 个月、3 个月后，根据详细的测试记录和迁移后的分析报告，证明信号集中监测系统向私有云平台的迁移方案安全、可靠，高效，并为后期的铁路监测检测系统向云平台迁移，提供智能化服务打好了坚实的基础。