城轨信号系统云平台RAM指标分析

2021-02-11张德明

铁道通信信号 2021年12期

徐伟，张德明，宋欣

目前，城市轨道交通行业正在加速转型，从10年前的单线建设进入到线网建设，从运营地铁到经营地铁，从功能出行到智能出行。信息化建设也已进入到大规模开发和应用阶段，云计算、大数据等新一代信息技术在城市轨道交通行业逐渐得到广泛应用。为推动我国“互联网+城市轨道交通”战略，遵循《中国城市轨道交通智慧城轨发展纲要》，2021年中国城市轨道交通协会发布了《城市轨道交通云平台构建技术规范》。本文针对云平台和信号系统ATS深度融合涉及的RAM指标进行计算分析，为信号系统上云提供依据，对推动城市轨道交通行业信号系统数字化、智慧化转型升级具有重要意义。

1 云平台

云平台定义：设置在数据中心内的云计算平台，部署了各种计算、网络、存储、安全资源，可提供各种云计算服务的能力，具有统一的资源、安全、服务等平台管理软件。

城市轨道交通云平台兼顾了计算和数据存储处理，其特征如下。

1）硬件管理对使用者和管理者高度抽象，云计算分布式的资源向用户隐藏了实现细节，并最终以整体的形式呈现给用户。用户只需具备网络条件，即可通过客户端来访问平台资源。

2）基础设施的能力具备高度的弹性，可以根据需要进行动态扩展和配置。

3）能划分独立资源池。根据需求来动态地划分或释放不同的物理和虚拟资源。

4）资源可计量。云平台通过计量的方法对存储、计算、宽度、网络、用户资源进行自动控制和优化，监测资源的使用情况，并向用户提供报告。

按照轨道交通行业规定，轨道交通列车运行控制系统需在故障-安全环境中运行，对实时计算和网络安全的要求很高。传统ATS架构属于单机和网络的组合，对单机、操作系统、网络、业务软件都是透明可控的。而云平台由于存在虚拟机管理中间层，对消息链路、单机、操作系统都进行了高度封装，无法判别系统性能和通信延时的影响程度，虚拟化软件叠加硬件造成不可控因素较多，使得用户使用云平台时，为逻辑复杂性感到担忧，需要对云平台的开发进行规范。

2 规范要求

目前，城市轨道交通安全可靠性技术标准，主要参考欧洲电工标准化委员会（CENELEC）制定的铁路安全相关标准：EN50126，定义了整个铁路系统的安全性、可靠性［1］；EN50128，定义了子系统软件部分的安全完整性［2］；EN50129，定义了整个系统及硬件部分的安全性、可靠性［3］；EN50159，定义了通信系统的安全完整性等级。另外，IEC 61508，给出了确定安全完整性等级的方法。

安全完整性等级（SIL）为安全功能提供相对降低风险的级别，或用于指定降低风险的目标级别。安全完整性是定量元素和非定量元素的组合体。定量元素一般与硬件有关，如随机失效。非定量元素则与软件有关，如技术条件、文件、程序等失效。SIL置信度是根据多个定量和非定量因素结合确定的，在基于IEC 61508的功能安全标准中，定义了4个SIL［4］。

安全评估的目的就是在限定条件下，判断信号系统的功能安全性实现程度。为了评估这个实现程度，将其分为2点证明：①设计有安全功能（能够有效防护可预见的危险）；②安全功能可用性高（在设定的条件下）。在SIL等级定义中，通常关注安全功能可用性［6］。

在《城市轨道交通CBTC信号系统—ATS子系统规范》（CZJS/T 0030—2015）中，ATS系统安全性要求为SIL2级［5］。为了实现安全性等级，需要底层设备硬件、软件满足相应的RAM要求。ATS系统一直使用商品现货作为硬件载体，是首个能验证上云的系统。在软件开发中，遵循SIL2级安全完整性开发流程和开发方法［7］。其系统RAM要求满足下列规定：①系统可用性应不低于99.98%；②MTBF（平均无故障工作时间）应大于3500 h；③MTTR（平均修理时间）应不大于45 min。

3 ATS结构

3.1 传统结构

传统ATS结构分为控制中心和车站2级，主要包括服务器子系统（COM）、操作子系统（HMI）、计划子系统（Schedule）、接口子系统（ITF）。传统ATS总体结构组成见图1。

图1 传统ATS总体结构组成

控制中心ITF是与其他非信号系统的接口；车站ITF是与联锁、ATO/ATP等信号系统的接口。车站和控制中心的数据通过COM实现交换。HMI、Schedule、ITF分别与COM进行信息交换。

硬件采用双机热备的有Schedule、COM和ITF等子系统。本文以传统ATS系统中的控制中心设备为例，说明在传统结构下的设备构成。传统ATS系统中心设备框架见图2。

图2 传统ATS系统中心设备框架

主用中心中，应用服务器、数据库服务器、外部接口服务器、通信服务器均为双套热备布置，调度操作站（HMI）、时刻表编辑工作站和运行图工作站等都是单机设置，所有设备通过100 Mb/s以太网接口连接［8］。

3.2 云平台结构

在云平台中，将所有服务器纳入云平台部署及管理，工作站采用云桌面的方式，充分利用云平台虚拟化技术，实现硬件资源利用最大化。云平台ATS系统结构见图3。

图3 云平台ATS系统结构

在云平台ATS结构中，为了达到CBTC核心业务系统对数据库高可用的要求，采用一主一备模式，包含主、备份节点服务器各2台，主、备用存储阵列各1台，全部使用交叉连接，并在管理交换机上配置数据分析平台和运维管理平台，所有工作站采用虚拟机方式提供云桌面支持。

传统ATS和云平台ATS的可靠性与成本比较见表1。

表1 传统ATS和云平台ATS的可靠性与成本比较

相对于传统结构，云平台结构基于开源云平台配置，采用通用的X86硬件结构，能够有效降低用户成本，节省了一次性投入成本和运维成本；利用开放型技术、松耦合架构，让用户有更多的自主选择性，摆脱了大厂设备的局限性和约束性，大大提升了系统设备的可维护性。

4 RAM分析

ATS上云后，使用新的云平台软硬件替代原有的硬件冗余方案，不会改变系统既有的安全功能。下面将从技术上分析云平台硬件和软件RAM（可靠性、可用性、可维修性）指标。

4.1 云平台硬件

云平台RAM指标应能够满足ATS业务系统的要求。针对信号系统设备，其随机失效完整性就是系统随机失效的概率，该值对ATS系统可用性指标影响较大。失效包括：工作模式、环境、磨损、过应力、应力降级等。这部分与硬件元器件损坏、软件失效、环境干扰相关，能够量化的是硬件失效率。传统降低硬件失效率的技术有双机备份、软件切换、功能组合等。

本文以主流云平台PAAS层中常见的VMware云平台管理程序为例，介绍其特有的虚拟分布式存储（vSAN），并进行可用性分析。

vSAN是专为虚拟机设计的极其简单的存储，具有速度快、恢复能力强、动态性优等优点，是针对超融合基础架构推出的一款存储解决方案，也是一个软件驱动的体系结构，可通过虚拟化的x86服务器实现计算、网络连接和共享存储。vSAN会池化与服务器连接的闪存设备和硬盘（HDD），以便为虚拟机创建一个富有弹性的高性能共享数据存储。

在可靠性和可用性方面，vSAN和传统存储一样，都是基于RAID方案。不同的是vSAN使用了纯软件RAID和容错失败策略（FTT）。FTT是存储对象可以容忍的主机故障数，可为每个虚拟机独立设定数据可用性指标。例如，对于只有1份数据（FTT=0），没有备份数据，数据可用性等于数据所在硬件可用性。通常，硬件可用性在99%范围内，即每年3.65天停机时间。设定更高的FTT策略，能有效降低不可用概率。当FTT=1时，即备份1份数据，数据可用性至少提高到99.99%；当FTT=2时（备份2份，一共3份），可用性提高到99.9999%。通常来说，对于FTT=n，必须有超过n个主机发生故障，数据才不可用。

总的来说，云平台特有的虚拟分布式存储设备的容错失败策略FTT，对云平台整体可用性的指标具有较大的影响。下面对整体云平台设备的MTBF进行计算。

对于硬件产品，定义故障概率的常用指标：AFR（年化故障率）和MT B F（平均无故障工作时间）。

例如：固态硬盘Intel 3710，AF R为0.44%。常用的希捷600 G硬盘（型号为ST600MM0009），M T B F为2×106h，A FR为0.44%［9］。企业级硬盘和固态硬盘A F R从0.44%～0.87%。主流商用X86服务器的M T B F一般大于50万h（故障率低于1.7%/年），也有一些达到了100万h（故障率为0.87%/年）。假设2台服务器同时发生故障（取故障率0.88%/年），其A F R故障率为

上述结果意味着每10000台服务器每年可能会有0.7744台发生故障，满足ATS系统要求的最低故障率250.2857%/年（MTB F≥3500 h）。

其他设备包括机架、主机、控制器的可用性都可从供应商处获得。比如，常用的商用服务器产品，华为OceanStor5000系列融合存储主机可靠性规格：方案级可靠性99.9999%，MTB F为106h，M T T R为2 h［10］。该设备的可用性为。在实际工程中，还需要考虑机架、控制器、SSD/HDD等其他设备的故障，这些都可从供应商处获取企业级硬件设备的可用性指标。例如常用的单点设备的故障概率，机架为0.99998，SSD为0.99998，主机为0.9998，缓存为0.99998。在上述所有器件部署于虚拟分布式存储中时，无拷贝保护（FTT=0），总的组合概率为（机架）0.99998×（SSD）0.99998×（缓存）0.99998×（主机）0.9998≈0.99974，意味着每年仍有（1-0.99974）×365×24≈2.28 h会停机。

在上述计算中，完全依赖厂家提供的设备数据，并使用了最严苛的计算。在现场环境中，为了保守起见，只取到每个设备的最后一个9，再次计算，（机架）0.9999×（SSD）0.9999×（缓存）0.9999×（主机）0.999≈0.9987，意味着每年仍有11.39 h会停机。对于ATS系统应用，仍然无法接受。

为了提高设备可用性，需要使用容错失败策略。假设FTT=1，有一个备份数据，即如果2个数据都不可用，设备才会停机，在此条件下再计算不可用概率，（1-0.9987）2=0.000001689，对应可用性概率是0.999998。可以看到，在FTT=1下，可用性从2个9提高到5个9，呈现出指数级增长的趋势。

总的来说，通常1台虚拟机包含多个硬、软件对象，假设有10个对象，每个对象可用性为0.999991，这整体的可用性为0.99999110=0.99991。即虚拟机可用性从单机的5个9降低到4个9。为了提高可用性，在FTT=2的情况下（3个副本），如果要宕机，需要3个副本同时宕机，再算一遍，(1-0.9987)3=0.000000002197，数据可用性为1-0.000000002197=0.999999997803，提升到8个9，这样就达到了足够可用的等级了。

通过上述计算，可以总结出硬件设备的可用性随着数据保护策略FTT的增加，呈现指数级增长。数据保护策略的使用提高了云服务整体硬件可用性指标，为应用可用性提供了有力技术支撑。

参考传统ATS系统可用性要求99.98%，即每年有0.02%×365×24×60=105.12 min的宕机时间。在整体设备可用性最不利（0.9987）的情况下，当FTT=1时，云平台整个系统可用性计算结果为0.999998，远超要求的99.98%。

通过前面的计算有效性分析，证明了云平台硬件架构作为新的ATS系统架构满足可靠性和可用性使用要求。

4.2 云平台软件

大部分云平台的底层仍然使用虚拟机平台，主机硬件和软件故障造成的影响与可用性有最直接的关系。以最常见的VMware软件为例，当出现硬件和软件故障时，云平台软件通过虚拟机中容错机制（FT）和高可用性（HA）来保证不宕机，提高了系统的可维护性。

4.2.1 容错机制（FT）

大多数任务可以使用虚拟机容错机制。容错机制通过创建和维护一个辅助虚拟机，来确保主虚拟机的连续可用性。该虚拟机与主虚拟机相同，且在发生故障时可随时切换。工作时，主虚拟机会持续复制到辅助虚拟机，以便辅助虚拟机可以随时接管工作，此外主虚拟机和辅助虚拟机会持续监控彼此的状态以维护FT可用。如果主虚拟机故障，系统将会执行故障切换，立即启用辅助虚拟机以替换主虚拟机，并自动重新建立其他FT冗余。如果运行辅助虚拟机的主机发生故障，则该主机立即会被新的FT替换。总之，在任一情况下，都不会遭遇服务中断和数据丢失的情况。

容错机制的响应完全自动化，保护操作系统中运行的所有关键任务，而无需进行特别标定。当基础架构出现故障时，不会造成停机和数据丢失，不会中断原有TCP连接。FT会自动部署在群集中的2台独立的物理服务器上，只有这2台服务器同时发生故障，FT才会失效。通过前面计算获知，2台服务器同时故障的可能性为0.007744%，这是一个非常小的概率。

典型FT用例：需要始终保持可用的应用程序，尤其是具有长时间客户端连接的应用程序，在硬件故障期间保持这些连接；不能通过其他方式实现群集功能的自定义应用程序；可以通过自定义群集方案提供高可用性，但方案太复杂，很难进行配置和维护。这些FT的情况，非常符合轨道交通ATS应用软件的运行环境要求。

启动FT的必备条件：群集中至少有2台物理服务器，至少有1个共享存储卷，FT要求至少有独立的10 Gb/s网络，25/40/100 Gb/s网络将更好，通常受服务器和网络性能资源限制，FT仅支持创建一份辅助虚拟机。

FT就绪时间长短取决于硬件和网络性能，通常包含以下因素：虚拟机的内存大小，虚拟机的存储大小（如果主虚拟机和辅助虚拟机位于不同的存储上），用于FT日志记录的网络带宽大小。

FT复刻的最主要限制因素仍然是磁盘性能。以磁盘I/O的性能为例，对网络I/O和磁盘I/O进行对比，取性能较低的一方作为计算的依据。一般来说，共享存储的磁盘I/O约为200 MB/s。

假设虚拟机的配置为32 GB内存、500 GB存储，以FT网络10 Gb/s为例，计算初始FT就绪时间。

仅考虑网络I/O的就绪时间=（32 GB+500 GB）/（10 Gb/s/8）=425.6 s

仅考虑共享磁盘I/O的就绪时间=（32 GB+500 GB）/200 MB/s=2660 s

可以看出，在采用共享磁盘下，FT的性能制约仍取决于磁盘I/O性能，配置更高I/O的SSD盘或接口能极大缩短FT的复刻准备时间和启动性能。

ATS的系统要求可维护时间≤45 min，从上面的计算可以得出，在FT已开启的情况下，切换时间可忽略。即使在最不利情况（普通SATA共享存储），重新开启FT，复刻数据需2660 s（44 min），也能够满足ATS可维护时间要求。

为了分散风险，架构设计中通常在一个群集设置多台主机，分配2个独立的共享存储，或者vSAN。让所有的主机都可以访问这2个共享存储或者vSAN。vSAN可采用多个副本（FTT）来保障数据不丢失，进一步降低了数据丢失的风险。

4.2.2 高可用性（HA）

HA运行机制是监控群集中的主机及虚拟机，通过配置合适的策略，当群集中的主机或虚拟机发生故障时，可以自动到其他主机上重新启动，最大限度保证重要服务不中断。这也正是将多台主机添加到一个群集管理的目的，可以统一管理及使用这些高级HA特性。

主机的故障类型包括：物理硬件故障或电源等原因导致的主机停止运行；主机网络中断导致的主机与网络隔离；主机跨网络分区导致连接不上副机。

在主机发生故障时，HA将尝试在任一指定的主机上重新启动其虚拟机；如果不行，则HA会尝试在群集内的其他主机上重新启动虚拟机。为了避免因故障间隔时间、最短正常运行时间监测信息等非瞬态错误而反复重置虚拟机，HA可以设置监控敏感度。HA通过在主机出现故障时重新启动虚拟机来为虚拟机提供基本级别的保护，相比FT，HA提供了更高级别的可用性。在HA的帮助下，典型的ATS设备硬件、网络故障、系统死机等，都能够通过重启系统来恢复应用服务，其可维护时间仅取决于软件系统重启时间。

以上所述都是针对主机计划外停机和灾难的保护，对于计划内的停机维护，虚拟机软件也提供了较完善的保护机制。比如vMotion方法，通过主动备份的方式，实现迁移过程中服务不中断。云平台RAM计算中，通过数据保护策略和群集管理，能明显降低云平台系统的随机失效概率，各项RAM指标均超过现有ATS系统规定要求。