论地铁供电综合监控系统异构服务器并列运行试点改造应用

1 项目背景与改造必要性

本次试点选取了我司某条运营将近10 年的地铁线路。其 ISCS 核心采用两台HP-UX 系列小型机（IA 架构）构成冗余机组，运行Oracle 数据库，负责全线供电系统及环境设备的监控。

改造的必要性主要体现在硬件风险较高，服务器临期服役，硬盘、电源模块、内存条故障频发，最后一次采购的同型号备件价格高达原价的数倍。 系统性能濒临瓶颈，随着新增车站和设备的接入，实时数据点表数量激增，原有系统处理能力接近极限， 应延迟加剧。技术壁垒及限制，HP-UX 系统运维知识体系陈旧，年轻工程师掌握困难，且与当前主流的开源技术栈脱节，维护成本高企。

改造目标是将系统迁移至基于x86 架构平台，采用Windows Server 操作系统与Oracle 数据库，构建新的高可用系统。为实现“业务无感知”的平滑过渡，项目设定了为期3 个月的异构系统并列运行期。

2 异构并列运行的核心难点分析

异构并列运行绝非简单的两台服务器同时开机，其背后是两种截然不同的技术生态的融合与对抗，难点层出不穷。

2.1 硬件架构与操作系统层面的异构性

这是最根本的差异。UNIX（HP-UX）基于IA 架构，而新系统基于x86 架构，两者在指令集、内存管理、I/O 处理机制上存在天壤之别。这导致在HU-UX 上优化的内核参数、内存分配策略无法直接套用于 WindowsServer 并列运行期间，需保证两套系统性能均处于良好状态，但针对新系统的调优可能会影响与旧系统的同步效率，反之亦然。驱动与兼容性存在问题，新服务器上的高速网卡、HBA 卡、磁盘阵列控制器等需要与现有的存储网络（SAN）和网络环境兼容，并确保在Windows Server 下有稳定高效的驱动程序。

2.2 数据库系统与数据同步的极致挑战

数据是 ISCS 的灵魂，保证新旧两套数据库数据的实时性、一致性和完整性是并列运行成功的生命线。从HP-UX 到 Windows Server 属于跨大版本、跨操作系统的同步，Oracle 自身的 Data Guard、GoldenGate 等工具虽支持异构，但配置极其复杂。同步延迟与冲突需解决，地铁ISCS 数据流具有高并发、实时性的特点。并列运行时，任何一方的数据写入都需近乎实时地同步到另一方。网络波动、系统负载都可能导致同步延迟（Lag）。一旦出现延迟，在短时间内可能产生大量数据堆积。更棘手的是，如果在延迟期间，两套系统对同一个关键数据点（如“远程合闸”命令）进行了相反的写操作，将引发致命的数据冲突，如何自动、安全地解决冲突是巨大挑战。数据类型与字符集可能存在差异，不同版本的Oracle 在数据类型支持上可能有细微差别，操作系统不同的字符集设置也可能导致数据同步时出现乱码问题。

2.3 应用中间件与接口适配的艰巨性

ISCS 并非只有数据库，还包括大量的应用服务（如实时服务、历史服务、报警服务）。改造新旧服务器之间存在接口兼容性，这些服务通常通过API、OPC、TCP/IP Socket 等方式与下位系统（如供电专业的 PSCADA、变电所综合自动化系统）通信。必须确保新系统上的应用服务能够与旧有接口兼容，任何微小的差异都可能导致数据采集失败。保持服务不间断与状态同步，对于有状态的服务，如何保证在从旧系统切换到新系统时，客户端的会话不中断，状态信息不丢失，需要应用层开发商深度配合改造。

3 解决方案与实践策略

针对上述难点，我们制定了“数据驱动、热备运行、全面测试、快速回退”的方针，并采取了以下具体策略：

3.1 架构设计阶段

调整数据主副节点方案：经过严格POC 测试，我们采取修改系统主副架构的方案避免异构间存在的问题。原站级服务器作为主服务与下层设备进行数据交互，控制中心总服务器作为副本与主服务器进行数据同步，调整为中心总服务器与站级服务器均作为主服务器获取通讯管理机数据。尽量避免不同版本数据库同步引发冲突。

制定热备运行测试方案，我们制定了详细的并列运行测试计划：首先将服务器并行安装于机柜，通过切换网络连接的方式开展测试与恢复，对历史查询、报表生成等业务功能开始测试；其次将各系统数据进行测试验证，在充分验证后，在运营天窗期进行的最终切换。

3.2 技术实施阶段

深入的数据比对与校验：在同步开启后，我们自主研发了数据比对脚本，数据接入前对新旧两套数据库中的关键表进行 checksum 校验，确保数据一致性。与客户端开发商合作，修改SCADA 人机界面软件的连接配置，使其改变相关主副服务关系，同时改变管理机数据流向与支持节点列表。模拟对点与压力测试：在线路每日停运后，切换测试服务器环境，模拟各互联系统遥信遥测遥控数据，进行抽样对点测试，同时对各种故障情况（网络中断、服务器宕机等）测试冗余服务器稳定性和切换流程的可靠性，并记录了详细的恢复时间目标（RTO）。

3.3 运维保障阶段

制定详尽的标准作业程序，编写了从日常检查、同步状态确认到故障应急处理、系统回退等全套操作手册。并组织维护人员进行多次培训和实战演练，确保人人熟悉流程。确立明确的回退机制，在任何阶段，如果新系统出现无法快速解决的严重故障，我们都设计了“一键式”回退方案：将客户端连接强制切回旧系统，确保运营安全永远是第一位的。

4 试点应用效果与总结

本次改造的价值在于成功验证了异构并列运行模式在地铁关键系统中的可行性，为行业提供了宝贵的实践经验。消除了原有系统的技术风险和安全漏洞，提升系统性能，降低系统能耗，为未来线网扩展预留了空间。降低了全生命周期成本，x86 服务器和开源 Windows Server 系统的采购与维护成本大幅低于传统 UNIX 架构。锻炼了技术队伍，维护工程师掌握了新一代的运维技术栈，提升了应对复杂技术挑战的能力。

总结而言，地铁综合监控系统异构服务器更新改造是一项复杂的系统工程，其核心难点在于如何在异构环境下保障数据的实时一致性与业务的高可用性。成功的关键在于：前期充分的方案论证和POC 测试、中期对数据同步环节的精细把控、以及后期周密的运维监控和应急准备。本次试点不仅是一次设备更新，更是一次对管理模式、技术能力和协作流程的全面升级，对推动地铁行业数字化转型具有积极的示范意义。

参考文献

[1]王建国,李志刚.城市轨道交通综合监控系统[M].北京:中国铁道出版社,2018.

[2]Oracle Corporation.Oracle GoldenGate Concepts and Administration Guide[Z].202

[3] 刘明, 张涛. 基于异构数据库同步的电力 SCADA 系统升级方案研究[J]. 电力系统保护与控制,2020,48(10):156-162.

[4]赵宇,陈星,高锋.地铁信号系统冗余切换与数据一致性研究[J].都市快轨交通,2022,35(1):89-94.