卫星导航系统双工热备技术研究

刘晓萍 刘利 曹纪东 胡湘华 黄双临 胡光明

北京环球应用开发中心 北京 100094

0 前言

为提高软件运行的可靠性，通常采用的方法是将软件分别部署在两台或多台计算机上，利用专用双工软件构成双工系统或计算机集群系统，在单台计算机出现故障时，双工软件进行故障判断并进行切换，以保障软件能够不间断运行。群机冗余是提高计算机系统可靠性的有效途径。在工程实现中，双机热备是性能价格比最理想的方案，被广泛应用在航天、军事、金融等关键任务领域。

实现双工热备有两种选择，一种是采购目前市场上销售的商用双工热备软件(如RoseHA等)，另一种是自行设计开发。比较典型的商用双机容错系统，如Compaq Trucluster系统、HP双机双控容错系统、LEGATO Co-Standby Server系统、SteelEye LifeKeeper系统和Rose HA系统等，其关键结构均采用双机系统的热备方式，在通过高速网络或磁盘阵列进行互联的基础上，实现基于磁盘镜像或磁盘阵列的软硬件容错系统，提供通用的可靠性解决方案。但是，这些系统的故障检测时间比较长(根据应用和故障类型的不同，时间有所不同)：通过实际应用和测试，当系统出现故障时，双机切换时间都在10秒级、甚至数分钟，从而导致系统处理的“断流”现象。商用的双工热备软件不是针对我们这种高实时的应用开发的，其实时性较低，切换时间较长。

因此，针对卫星导航定位系统这种对实时性、可靠性要求高，需要不间断进行数据处理的关键任务系统，如何保证双机容错系统的强实时性、高可靠性和服务“不断流”，是其中的关键技术难点。

1 方案设计

在卫星导航系统中，由于系统的可靠性要求很高，必然需要利用双工技术来保障系统的连续运行。但是由于卫星导航系统数据处理量大、实时性要求高，所以对专用双工切换软件提出了更高的要求。

服务器的故障可能由各种原因引起，如硬件设备故障、操作系统故障、业务软件故障等等。为了达到系统的可用性和可靠性指标，商用软件这显然是不能满足要求的，我们采用双机自行开发的冗余互为热备容错方案。

1.1 硬件组成

双机热备系统的硬件组成如图1所示。两台服务器通过两条专用连接进行互连。专用连接用于传输服务器的心跳信息，以及双机交互信息(特征码、双机切换请求和应答以及在系统恢复时传送恢复计算所需的数据)。

图1 双机热备的系统组成

服务器心跳信息和双机间交互信息的数据量不大，但实时性要求高，因此双机专用连接需要选用带宽高、延迟小的产品。千兆以太网和基于InfiniBand标准的主机通道适配器（HCA）都具有带宽高、延迟小的特点。但由于InfiniBand HCA的带宽更高、延迟更小(数据如表1所示)，并且占用的CPU资源更少，因此作为首选。同时，可以采用两条千兆以太网连接作为备份链路，当InfiniBand HCA发生故障时切换使用以太网线发送心跳信息和双机交互信息。

表1 千兆以太网与InfiniBand HCA性能比较

针对系统的数据库应用需求，结合数据库集群的双机热备系统如图2所示。数据库集群可以采用Oracle 10g的RAC(Real Application Cluster)软件及Oracle Cluster Ready软件等，使用共享磁盘阵列进行数据存储。系统正常工作状态下，两台服务器同时接收并处理待存档的数据，由主机负责数据入库、数据备案及向外提供数据服务等工作，由数据库集群负责数据库本身负载均衡。当主机出现故障时，所有任务由备机独立承担，实现数据服务的连续运行。因为两台服务器共享同一数据库，因此在故障时能保证入库数据的一致性。

图2 结合数据库集群的双机热备系统组成

1.2 软件设计

在双机热备工作模式下，两台配置相同的服务器构成一个机组，一台为主机，另一台为备机(如图 3所示)。双机运行相同的软件，使用相同的参数配置，接收相同的数据，进行相同的数据处理，Oracle数据库集群负责数据库本身负载均衡。但只有主机才能输出计算结果，备机不向外输出。主机故障后，备机接替主机的工作成为新主机，独立承担所有实时任务，实现数据服务的连续运行，主机切出并在修复后切入成为新备机。备机故障后，主机状态不发生改变，备机切出并在修复后切入。

图3 双机热备软件组成

1.2.1 状态切换

在主机发生故障的情况下，双机热备系统自动切换原副机为主机，接替原主机完成任务。当故障机修复后，可重新加入双机系统。

在副机发生故障的情况下，主机仍维持主机状态，其处理不受影响，继续完成任务，双机热备软件将告警，但不发生切换。当副机修复后，可重新加入双机系统。

状态切换策略可通过状态管理进行设置。

1.2.2 实时性

双机热备方案的实时性由两部分构成：故障检测的实时性和状态切换的实时性。单机故障的情况很多，归纳起来有三种：服务器硬件故障，网络设备故障以及应用软件故障。

服务器硬件故障可以细分为部件故障和整机故障。本方案采用心跳机制来检测整机故障。备机上的热备服务模块每隔10ms在两个专用连接上监测主机的心跳。当备机在50ms内收不到主机的应答时，认为主机已故障，备机就切换为主机，接管向外输出信息的任务。这样可以保证故障检测时间≤50ms。部件故障是通过系统监护模块检测的，通过定期对系统部件、进程的检测，可以获取各部件、进程的状态，检测周期定为30ms。系统监护模块判断故障的时间＜1ms，这样故障检测时间≤50ms。

网络设备故障会引起进程无法获得数据或发送数据，通过特征码机制，可以在＜50ms的周期里判断出接收数据失败，发送数据失败可以立即判断出来，加上重发超时，也可以保证检测时间≤50ms。

业务软件的故障包括软件崩溃、计算错误、CPU占用过高、内存占用过高、磁盘占用过高等。系统监护和业务管理通过定期握手、状态查询等手段，收集业务软件的状态信息，检测周期定为30ms。系统监护模块判断故障的时间＜1ms，这样故障检测时间≤50ms。

双机状态切换分两种情况：服务器整机故障被检测出来时，由备机的双机热备服务模块直接切换，并将双机状态通知业务管理，由于是本地调用，切换时间＜1ms；其它故障被检测出来时，由系统监护模块发送软硬件故障信息到相应的热备服务模块，延迟＜0.5ms，热备服务模块向备机的热备服务模块发送切换请求，并获得答复，延迟＜1ms，热备服务模块将双机状态通知业务管理执行信息输出切换，切换时间＜0.5ms。由于备机是一直正常运行，切换后数据直接发送，存在的延迟主要是因为在故障确认的期间，可能会有部分待发送数据因没有收到特征码而缓存在待发送队列，这时需要将其全部发送出去。信息处理平台的业务计算是数据驱动的，产生的数据量与接收的数据量在同一个数量级上，即每个分系统产生的数据小于10包/秒，因此，在50ms内产生的待发送数据不会大于10包，发送耗时＜10ms。

1.2.3 数据同步

为了减少系统对错误的响应时间，双机之间通讯采用InfiniBand高速通讯卡，通讯卡由PCI直接和总线通讯，可采用MPI库，比千兆以太网具备更高的带宽和更小的延迟，可以用于双机之间状态的一致性检查、同步以及消息的发送。

双机切换过程不可避免的引入延迟，在高实时、高可靠性系统中，必须保证系统服务的连续和完整，即不会因为切换引起数据的丢失。在本方案中，通过特征码机制来保证数据一致性。热备服务负责接收业务管理发送来的特征码并发送到对方。业务管理根据特征码，确认接收数据是否完整和发送数据是否成功。

当服务器切入时，重建计算环境需要一定的配置数据和累积一定时间的业务数据。为了保证切入的服务器的计算能尽快和主机保持同步，热备服务负责根据业务管理的需求来传送配置数据和业务数据，写入本机的动态数据区和静态数据区。

1.2.4 时间同步

在系统状态的保持和恢复过程中，时间同步是非常重要的，为此系统采用了专门硬件时钟(原子钟)为基准的时间信号，通过时频信号送达计算机，供计算机校准本地时钟，高精准的时钟为双工同步提供了很好的时间信号，可以为主备机切换和恢复提供精准的时间戳，给系统状态时间定位以及实时容错、快速恢复提供可能。

实时时钟和定时器能够提供极小的时间间隔来控制与调度任务和事件的执行和发生。系统实时时钟能提供微妙或纳秒级的时间分辨率，从而可以控制应用软件中的进程或线程在精确的时间间隔内激活运行。同时还可以利用实时时钟和定时器并结合采用信号机制，对应用软件中有关时间间隔要求严格的软件接口和程序进行控制。

2 双工切换测试情况

（1）模拟副机软件故障，杀死副机运行的某个进程，如数据接收进程RCV。

测试结果：主机正常工作。

（2）模拟主机硬件故障，杀死主机上运行的所有进程。

测试结果：副机双工进程报警：“未收到心跳信息，请检查”，同时自动将本机设为“主机”，并向对方发送含有夺权信息的心跳信息。

（3）模拟主机软件故障，杀死主机上运行的某个进程，如数据接收进程RCV。

测试结果：主机双工进程检测到本机软件故障，自动将本机设为“副机”，同时向原副机发送委托信息，副机收到心跳信息中有委托变换工作状态信息，将自己设为“主机”，完成一次主副切换；数据库中存储的数据内容完整。

3 结论

经过多次测试，该双工热备模块的可靠性和实时性都能满足系统的要求，能够在服务器发生软、硬件故障或收到来自系统监控程序的切换命令时，在要求时间内完成服务器的切换，保证系统连续正常工作，数据入库不中断。因此，这种双工热备策略在系统上的应用是成功的。

[1]曾碧卿,陈志刚.服务器集群系统研究[J].计算机应用研究.2004.

[2]王晋鹏,潘龙法,李降龙.LVS 集群中的动态反馈调度[J].计算机工程.2005.

[3]章文嵩.Linux服务器集群技术.[EB/OL].http://www. chinaitlab.com/www/special/juqun.asp.2006.