一种面向运载火箭测发控的虚拟化系统优化设计

马宗瑞，岳 玮，姚京红，张晨光

（1.北京宇航系统工程研究所，北京，100076；2.中国运载火箭技术研究院，北京，100076）

0 引言

地面测发控系统按照空间布局分为前端测控设备和后端地面测发控系统。前端测控设备主要负责将箭上设备的模拟量和状态量等数据发送至后端进行数据判读和处理，同时还需响应后端地面测发控系统发送的控制指令，并通过有线/无线信道传输至箭上电子设备从而实现对箭上设备的控制。后端地面测发控系统负责接收并处理前端测控设备发来的数据，将数据和状态通过测发控软件显示在测试人员面前。后端地面测发控系统主要设备包括网络交换机、计算服务器、工作站及测发控软件。在运载火箭的测试和发射过程中，测试人员通过操作后端地面测发控系统中的测控软件发出控制指令，指令从测控软件经工作站发出，通过网络交换机传输至前端测控设备，实现对箭上电气类产品控制和状态监测工作。

目前现役运载火箭后端地面测发控系统有如下特点：

a）设备物理分布不集中，各自独立维护，重复性劳动多，效率低；

b）重复设计建设工作多，成本高，未形成统一规范标准；

c）资源未实现共享，使用率低；

d）不能根据实际需要和业务变化动态调整资源和快速扩展，系统灵活性和可扩展性差；

e）系统单点多，容灾能力较差。目前主要通过冷备份关键单机实现故障隔离，在测试过程中如果设备出现异常，需要测试人员手动替换备份设备，并进行状态切换，部分切换会导致测试状态无法保持甚至中断火箭测试流程。

1 研究现状

运载火箭地面测发控系统起步于长征系列火箭地面电气系统，传统运载火箭地面测发控系统历经了从“近控”向“远控”的改变，并引入了总体网系统［1］。随着中国运载火箭技术领域产品自主可控要求的逐步提升，进口的交换设备和计算设备已经不能满足国产化要求，总体网系统逐渐开展国产化替代工作［2］。随着虚拟化技术的成熟并在民用市场的大规模普及，运载火箭地面测发控系统也将数据判读分析业务迁移至虚拟化平台中［3］，但仍未解决目前整个地面测发控系统不同专业的“烟囱式”重复建设问题。

2 面向运载火箭测发控的测控云设计

将后端地面测发控系统进行迁移改造，完成向“测控云”的转变，增强整个系统可管理性，提升计算资源利用率。改造内容主要涉及虚拟化云计算设计、虚拟化存储设计及虚拟桌面设计［4-6］。

2.1 虚拟化云计算设计

虚拟化云平台的主要功能是在运载火箭测试发射过程中提供业务软件运行所需要的平台系统，通过CPU虚拟化、内存虚拟化、设备I/O虚拟化实现在单一物理计算设备上运行多个虚拟系统。把应用程序对底层系统和硬件的依赖抽象出来，从而解除应用、操作系统和硬件的耦合关系，使得物理设备的差异性和兼容性与上层应用透明。不同虚拟系统之间相互隔离、互不影响，可以独立运行于不同的操作系统，并提供不同的应用服务。虚拟化云平台既包含硬件设备，也包含应用软件。硬件设备主要包括服务器、存储交换和磁盘阵列设备。应用软件主要包括虚拟化云系统、虚拟机操作系统。虚拟化云平台架构设计如图1所示。

图1 虚拟化云平台架构设计Fig.1 Virtualization platform architecture

虚拟化环境上的业务软件按照业务特点共分为四大类：响应及流转类软件，处理及存储类软件，监测及判读类软件和大数据应用类软件。业务软件特点如下：

a）响应及流转类软件：发出或响应指令信息、将未处理的业务数据从不同的数据源汇聚打包后转发至处理及存储类软件和大数据应用类软件并将处理后的业务数据转发给监测及判读软件，是测控云业务软件的交互中枢。该类软件只负责汇聚和转发业务数据，对数据进行分析的工作较少，故其占用CPU及内存等计算资源适中，但占用较多的通信带宽。由于该类软件是数据传输的中枢，并且与发射流程大量耦合，故其如果发生故障将直接影响火箭的测试，所以需要采取一定的热备措施。

b）处理及存储类软件：接收数据源和响应及流转类软件发送的指令信息和业务数据，将业务数据进行解码、分析和重组后经响应及流转类软件转发给监测及判读软件，并将部分数据存储在本地。该类软件需要对大量的源码数据进行解析，并按照规定的协议进行处理，同时源码数据和处理后的数据都需要存储在磁盘中，故其占用较多的CPU、内存及磁盘容量等计算资源。处理及存储类软件虽然参与火箭测试流程，但若其出现故障并不会直接导致流程中止，故只对处理及存储类软件采取冷备措施。

c）监测及判读类软件：从响应及流转类软件获取需要实时监测及测试后判读的数据供判读人员直接使用。该类软件只负责将测试数据进行显示，不承担数据分析或者流转的工作，所以其占用较少的CPU、内存、磁盘以及网络资源。由于监测及判读类软件均为服务器-客户端（Client-Server）架构，并且不会直接导致火箭测试流程发生中止，故只对监测及判读类软件的服务端和部分客户端进行冷备。

d）大数据应用类软件：从响应及流转类软件实时获取测试数据，并异步开展数据包络分析和深度挖掘。该类软件承担大量的数据分析工作，占用较多的CPU、内存以及磁盘等计算资源。若该软件出现故障，不会直接导致流程中止，故只对大数据应用类软件采取冷备措施。

综合考虑上述资源分配和热备冗余要求，形成以下虚拟化资源分配原则，如表1所示。其中响应及流转类软件需要在不同物理机进行热备，处理及存储类软件、监测及判读类软件以及大数据应用类软件需要在不同物理机进行冷备。

表1 虚拟化资源分配原则Tab.1 Virtualization resource allocation principles

2.2 虚拟化存储设计

针对虚拟化系统的存储设计，重点关注设计存储数据的高安全性和持续可用性，通过多种技术手段保证共享存储中留存的虚拟机数据无丢失、无差错。测控业务对数据的存储速率、系统冗余性都有较高要求。采用集中式存储，可以为虚拟化平台提供低时延的存储服务，并且对于使用者维护门槛低，更适用于发射场环境。

2.3 虚拟桌面设计

虚拟化存储环境中涉及到服务器主机总线适配器（Host Bus Adapter）卡、存储交换机和磁盘阵列三大部分，其核心应用是虚拟机通过存储局域网络访问存储设备，实现数据共享读写。虚拟化存储架构逻辑如图2所示。

图2 虚拟化共享存储网络逻辑架构Fig.2 Virtualization storage area network logical architecture

磁盘阵列设计采用双活双控、多链路、磁盘容错的冗余设计。虚拟化服务器可通过8条等价路径与磁盘阵列主（或备）控制器之间实现高速I/O 访问，任意线路、控制器甚至整机的故障均不会造成虚拟机数据读写的失败。磁盘阵列内的硬盘系统配置RAID5加全局独立热备盘容错模式，最大可支持2块硬盘故障情况下的虚拟机数据可用，并可保证在少量硬盘故障情况下磁盘系统的自愈能力。

在此存储网络架构基础上，系统可以在单发HBA模块故障、存储交换故障、磁盘阵列硬盘故障、磁盘阵列控制器故障、磁盘阵列机箱故障模式下确保存储业务可靠运行。

桌面虚拟化依赖于服务器虚拟化，在数据中心的服务器上进行服务器虚拟化，生成大量独立的桌面操作系统（虚拟机或者虚拟服务器），同时根据专有的高性能桌面传输协议发送给终端设备。用户可通过简易的终端设备实现对虚拟化系统中虚拟机和虚拟服务器的控制和访问。

针对后端地面测发控系统，重点关注设计瘦客户机的持续连接能力和设备快速替换能力，通过多种技术手段保证虚拟桌面操作的连接性以及快速重连。

虚拟桌面的连接涉及到虚拟桌面连接服务器和瘦客户机两大部分，其中的关键环节是虚拟桌面连接服务器和虚拟化管理平台的冗余对接，保证瘦客户机按需连接至指定的虚拟桌面（虚拟机）。具体设计如图3所示。

图3 虚拟桌面架构Fig.3 Virtual desktop architecture

虚拟桌面连接服务器的冗余设计：连接服务器以虚拟机的形式部署在虚拟化服务器集群中，可同时受到集群虚拟机高可用（High Available，HA）功能、虚拟机快照功能的双重保护。连接服务器与虚拟化管理软件的同步数据是通过其虚拟管理地址（Virtual Internet Protocol，VIP）实现的，任何一台虚拟化管理软件及其所在服务器发生故障时，连接服务器仍然可以保持与虚拟管理地址的联通，保持对虚拟桌面运行环境的有效管理。

a）连接服务器以虚拟机形式部署，受到集群HA和快照功能的双重保护；

b）连接服务器与虚拟化管理软件的VIP 地址连接，单点故障时可保持连接。

瘦终端的冗余设计：瘦客户机是轻量化的终端设备，仅通过运行虚拟桌面连接程序（调用虚拟桌面连接协议）访问虚拟桌面连接服务器，并利用连接服务器的重定向功能连接指定的虚拟机。其关键的冗余设计主要涉及主/备双网卡接入网络，从而始终能够保持与连接服务器以及服务器虚拟化平台的连接。瘦客户机配置主/备双网卡，可保持与连接服务器和虚拟化平台的连接。

3 运载火箭后端地面测发控系统关键技术研究

针对影响火箭测试发射的后端地面测发控系统故障模式，将影响火箭发射流程正常进行的主要故障模式确定为虚拟化云平台软硬件故障及测控业务软件故障，并针对此两类模式进行冗余设计实现对测控云的优化改进。

3.1 虚拟化云平台冗余设计

a）服务器在整机、部件两个方面提供冗余设计。借助服务器集群技术实现针对整机的冗余，通过设置主/备双管理节点工作模式实现高可靠性设计，由数据库的底层同步机制实现虚拟化管理数据的一致性操作。借助虚拟化平台软件的主/备配置模式实现部件级的故障倒换，实现针对网卡、HBA卡的冗余。

b）存储在设备、线路两方面提供冗余设计。采用两台存储交换机、双台磁盘阵列（阵列控制器采用冗余设计、硬盘资源采用RAID-6 冗余容错设计）构建SAN 存储环境。以存储交换机为中心构建叠加的双星型链路拓扑，配合存储多路径技术实现服务器至磁盘阵列的多条等价存储路径冗余。采用双活双控技术可以将控制器和阵列背板机箱由单控状态变为冗余热备状态，当一个控制器发生故障时另一个控制器可以实时接管状态继续工作。采用独立磁盘冗余阵列（Redundant Array of Independent Disks，RAID）模式可以实现存储性能和数据安全的兼顾的方案，并且可以接受RAID 成员组中至多2 块硬盘故障不影响数据的完整性和实时可用性。

c）采用虚拟机高可用技术和容错（Fault Tolerance，FT）技术以提高虚拟化云系统中虚拟机的可靠性。安装了操作系统的虚拟机是测控软件运行的重要载体，当虚拟机或其操作系统发生故障时，测控软件也会受到相应的影响。

虚拟机高可用技术是虚拟化云系统通过定时心跳监测包检测运行在云系统上层的虚拟机的工作状态，当心跳监测出现异常后，虚拟化云系统会自动将故障虚拟机迁移到另一个正常的物理服务器上重启，迁移所需的时间为分钟级。

容错技术是指两个虚拟机之间实时高可用，不同于HA，容错的目的是保证业务的连续性，为所配置容错的虚拟机建立一个“影子”备份虚拟机，两个虚拟机之间内存是实时同步的，即保持镜像状态，当主机接管主机的业务及功能，其切换所需时间为秒级。容错占用较大的网络和计算资源，但是其切换时间更短，虚拟机高可用占用的资源少，但是迁移所需的时间较长，故会造成较长时间的业务中断，将运行测控软件的虚拟机按照重要度进行分类，重要或者实时性要求高的虚拟机可配置容错，以后期数据处理和实时性要求低的虚拟机配置高可用，实现所有虚拟机均具备无人干预的自恢复能力。

3.2 测发流程冗余设计

运载火箭测发流程主要依托于测发控软件实现。测发控软件主要用于测试人员在后端对运载火箭前端或者箭上设备实现加断电或数据采集控制。测发控软件分为服务端与客户端，服务端和客户端是共同提供测发控业务服务的。服务端主要负责处理前端发送来的数据，并响应客户端发送的指令同时将状态发送给客户端进行显示。客户端主要提供可实现人机交互的界面，将界面的响应发送给服务端进行处理，同时接收服务端发来的状态及数据，将其显示在界面上。测发控软件服务端和客户端均包含主从模式，且默认客户端均连接主服务端。软件模块信息流见图4。

图4 测发控软件模块信息流Fig.4 Test launch and control system software information flow

当主服务端异常时客户端主动切断与主服务端的连接，并连接副服务端继续工作。传统的测发控软件虽然也设置了主从模式，但是主从的切换需要手动实现，这依赖于测试人员现场状态的判断和操作。面向后端测发控系统无人值守等需求，采用以心跳数据包为判断基准的测发控软件自动主从切换设计。测发控软件主服务端与从服务端每固定周期发送心跳数据包。当超过指定时间未收到对方发送的心跳数据包，则认为对端出现异常或已经关闭，此时从服务端自动切换为主机状态。目前主要面向于服务端程序失去响应或异常关闭、服务端所在虚拟机网络中断或失去响应、服务端所在物理节点异常宕机或网络中断等故障模式。采用这种设计以后，测发控软件根据自身或者运行环境的状态可以自行对状态进行判断，并执行无人干预的主从切换动作，实现测发流程的冗余。

4 运载火箭后端地面测发控系统关键技术验证

针对虚拟化云平台和测发流程冗余改进设计试验验证技术的有效性和准确性，在集群交换机上通过千兆网口和万兆网口连接4台国产品牌计算服务器，在每台服务器上安装国产虚拟化系统，其中服务器A和服务器B安装虚拟化管理软件。虚拟化管理信息通过服务器的千兆网络流转，测发控业务数据通过服务器的万兆网络实现交互。配置双活存储系统，将服务器与国产品牌的磁盘阵列通过存储交换设备交叉互联。将国产品牌的瘦客户机与集群交换机通过网线链接，在虚拟化系统中部署云桌面软件。其中在服务器A上配置虚拟机A和虚拟机B，在服务器B上配置虚拟机C和虚拟机D，每个虚拟机均安装国产Linux操作系统，虚拟机A、C分别部署软件主服务端和从服务端软件，虚拟机B、D分别部署主客户端和从客户端软件，最终完成全国产品牌国产技术的虚拟化验证系统的搭建。

4.1 虚拟化云平台冗余验证试验

4.1.1 试验过程及结果

a）服务器集群冗余测试。断开集群内单台物理服务器（即服务器A）供电模拟服务器异常掉电故障，检查云平台软件运行是否异常，检查其他服务器工作状态，试验结果如表2所示。

表2 服务器集群冗余测试结果Tab.2 The test result of server cluster redundancy

b）存储双活双控冗余测试。通过向虚拟机操作系统内传输大文件增加磁盘读写性能负载，在此过程中执行下述操作：1）断开磁盘阵列A 供电模拟磁盘阵列A 异常宕机，检查使用共享存储的虚拟机操作系统是否工作正常，记录虚拟机磁盘读写交互延迟时间；2）断开存储交换机A 供电模拟存储交换机A 异常宕机，检查使用共享存储的虚拟机操作系统是否工作正常，记录虚拟机磁盘读写交互延迟时间；3）抽出磁盘阵列B 上的一块硬盘模拟磁盘阵列硬盘出现故障，检查使用共享存储的虚拟机操作系统是否工作正常，记录虚拟机磁盘读写交互延迟时间。试验结果如表3所示。

表3 存储冗余测试结果Tab.3 The test result of storage redundancy

虚拟机高可用测试及容错测试。将云平台服务器A中的虚拟机A配置成容错模式，“影子”虚拟机设置在服务器B上，将虚拟机B配置成高可用模式，将虚拟机B的迁移节点配置为服务器B。将两台虚拟机正常启动后，断开服务器A的供电，记录虚拟机A和B发生的现象，通过向虚拟机A和虚拟机B发出命令监测操作系统服务和网络中断的时间。

经试验，当断开服务器A供电后，运行于服务器B中虚拟机A的“影子”虚拟机切换为当班状态，直接接管虚拟机A 的实时状态，切换时间为3 s。同时虚拟机B从服务器A按照高可用策略自动迁移至服务器B后重新启动，期间全程无人干预，迁移时间总计约5 min（不同操作系统迁移时间存在差异）。

4.1.2 小 结

采用虚拟化云、服务器集群、存储双活双控及虚拟机高可用和容错技术对原有的“烟囱式”建设的地面测发控系统进行整合优化，并重点针对系统的容错能力和自愈能力进行了改进。采用虚拟化云技术将现有的计算资源进行融合并重新划分，地面测发控系统计算资源得到更合理的分配。

通过试验验证，采用服务器集群和虚拟机高可用技术后，整个测发控系统的容错能力显著提高，当其中一台承载云平台的服务器出现宕机等异常现象时，云平台不会因为一台设备故障而发生崩溃，并且运行在故障服务器上的重要虚拟机业务可通过容错技术得到快速迁移，业务受影响时间小于5 s，其他虚拟机业务可通过高可用技术提高自身自愈能力，减少人为干预和切换需要的时间。

采用存储双控双活技术，在模块级和整机级不同维度下均消除了地面测发控系统数据存储的单点故障，最大程度地确保地面测发控数据的完整性，保证存储设备一度故障下，测发控数据不会因故障发生丢失错误的情况。

4.2 测发流程冗余验证试验

4.2.1 试验过程及结果

在虚拟化云平台故障自恢复验证试验环境的基础上，还原系统状态。

通过在虚拟机操作系统中输入相应指令可操作系统强制崩溃，操作系统网络将失效，分别对虚拟机A～D执行该操作，可分别模拟操作系统发生故障导致测控软件受影响的情况，分别观察测控软件主服务端、备服务端、主客户端、备客户端的现象，观察测控软件是否能够继续工作，验证测发流程冗余设计是否正确有效。试验结果如表4所示。

表4 测发流程冗余测试结果Tab.4 The test result of test launch and control flow path redundancy

4.2.2 小 结

对现有的测控软件的主从切换策略进行优化，引入心跳监测实现了测发流程的冗余。在虚拟机A～D分别部署了主服务端、从服务端、主客户端和从客户端测控软件，通过输入指令使得虚拟机强制崩溃，来等效模拟测控软件受系统故障影响的情况，测试结果表明，无论哪个虚拟机及虚拟机上运行的软件发生异常，测控软件的运行均未受到影响，其中当运行主客户端的虚拟机发生异常时，主客户端随操作系统崩溃而无法使用，需要切换至备份客户端即虚拟机D继续工作，但测控业务服务不会发生中断。

5 结束语

为解决液体运载火箭后端地面测发控系统容错能力有限，自愈能力差的问题，同时消除现有各系统独立“烟囱式”建设的现象，应用虚拟化云的解决方案替换掉原系统独立计算独立存储的方案，同时采用服务器集群、存储双控双活、虚拟机高可用和容错及测发流程冗余等技术对现液体运载火箭后端地面测发控系统进行优化升级。以某型液体运载火箭后端地面测发控设备优化升级结果为例。在实施此优化前，后端地面测发控每个电气系统平均配置3台计算存储用服务器、1台冷备份服务器，3台高性能工作站、1台冷备份工作站，5台浏览判读计算机，总计约12台服务器、12台工作站、15 台计算机，总计约40 台计算设备，并且均未实现全国产化要求。在实施虚拟化改造后，服务器从原来的12台优化至6台，27台工作站和计算机减配为15台瘦客户机，整体设备规模减半，不再需要额外配套冷备份产品，并且满足了国产化需求。优化后的液体运载火箭后端地面测发控系统的虚拟化平台计算容错能力、存储冗余能力和业务软件的健壮性均有较大幅度提高，系统单点故障得到消除，能够满足现今液体运载火箭对地面测发控系统的要求。