高可用性系统设计之二：软件启动模式设定

在上一期中我们讲到了从硬件角度如何实现高可用性的系统设计，但这仅涉及到问题的一个方面，设计人员还必须充分考虑到软件对系统可用性的巨大影响，尤其是高可用系统设计时软件重启动模式的设定。

Chuck Hill

摩托罗拉计算机公司

chuck_hill@mcg.mot.com

只有考虑了所有能导致系统故障的因素,一个系统才是真正完整的高可用性系统。尽管对硬件行为的建模和预测机制有很深入的理解，但还有其它一些因素难以模型化和预测。对这部分的研究往往需要参考以前的记录，因为系统在启动的时候通常难以达到高可用性。以前的反馈信息和系统改进对于达到高可用性至关重要。

至今为止，软件造成的故障是系统故障的第二大因素，但是常常不能像硬件那样得到足够的重视。同时，软件的变化和升级极为频繁，这使得软件对系统稳定性的长期影响更加难以预测。随着系统对软件故障检测和管理依赖性的增强，软件问题日益受到重视。

图1的表格显示了各种故障因素的比例。系统故障总数近2/3源于硬件和软件故障，另外的1/3是由一些更难控制的因素引起的。由硬件和软件升级导致的系统稳定性问题是一个重要因素，而操作人员误操作引起的故障与自然灾难和人为破坏引起的故障一样，具有重要的统计意义。

冷重启、暖重启和热重启

软件在系统故障管理中占有重要地位。无论是由硬件还是由软件引发的系统故障，其持续时间长短取决于系统的重启动能力。如果系统采用热重启(hot restart)、暖重启(warm restart)或冷重启(cold restart)模式，故障管理中的处理方式将各不相同。重启模式受事件发生之时系统可用信息量的影响可用的信息越多，重启速度也就越快。

热重启的恢复时间最快，但也最难实现。在热重启模式下，应用程序保存系统当前运行的状态信息，并将该信息传送给备份部件，以实现快速恢复。应用程序要具备利用这些状态信息实现系统的重启动的能力。

热重启系统中同样需要在故障管理事件之前预先指定备份部件。这在2N系统中最为明显，因为该系统的部件与备份部件是一一对应的(见图2)。而在N+1系统中，热重启要求备份部件保存多个运行中部件的状态信息，因此备份部件就必须具有额外存储能力，否则就必须采用暖重启模式。

暖重启与热重启类似。在该模式下，应用程序保存系统当前运行的状态信息(见图3)。在执行故障管理时指定备份部件。备份部件需配置必要的应用程序和状态信息，这就增加了重启时间，但能降低备份部件的成本。在备份部件与现行部件不完全相同的系统中，更易实现暖重启。

冷重启(cold restart)是最易于实现的，但需要最长的重启动时间。冷重启意味着备份部件对故障部件的运行状态一无所知，备份部件只能从初始化状态开始。

实现冷重启几乎无须对系统应用程序作任何修改，由操作系统和服务程序实现高可用性软件的功能。但这是以系统更长的重启时间为代价，并丢失系统所有当前的运行状态信息。

各种重启模式所需的时间取决于系统及应用软件的实现方法。相对而言，如果热重启模式的时间为1X，那么暖重启的时间将会是2-3X，冷重启的时间将接近10-100X。在支持高可用性的系统软件和应用程序中，重启时间将要求为最短。

故障管理软件

良好的系统服务程序可减少应用程序为实现高可用性而做的大量工作，通过提供稳定的系统平台，即可实现高可用性。高可用性系统要求在系统的各个环节进行缜密的设计，高可用的软件基础结构起始于操作系统(OS)(见图4)。为实现小型PCI(CPCI)系统中部件的热拔插，操作系统必须支持设备驱动器的动态装载和卸载，并允许系统资源在这些驱动器中重新分配。这是实现系统修复和重构的最基本功能。

CPCI热拔插(也称为完全热拔插)提供了自动化程度更高的热拔插功能。完全热拔插的目的是改善系统的操作界面，高可用性要求操作界面必须尽可能灵活处理各种错误。完全热拔插使用一种称为ENUM的信号提醒系统取出或插入电路板，并允许系统自动实现资源的重新配置。完全热拔插支持在简单系统模型中使用非硬式驱动器。

使用硬式驱动器可达到更高程度的可用性，硬式驱动器能检测到下层硬件故障。硬式驱动器通过采用脱机和备份操作模式，使应用程序可采用更高级别的重启模式。这些模式为故障管理系统提供了诊断信息，因而对于高可用系统而言，驱动器是故障检测的第一层。

拓扑管理

系统拓扑结构的管理是高可用性系统基本架构的底层，系统拓扑结构的管理系统负责没有管理人员在场时器件的隔离。系统拓扑管理的重配置也有助于提高系统的稳定性。

CPCI通过高可用系统模式实现了这种拓扑管理能力。系统中热拔插控制器能使单个电路板在软件控制下断电或重启。

开放结构系统的拓扑管理需要灵活性。从OEM通信系统设备供应商的角度看，最终应用的有效载荷往往由下一个增值整合器(value added integrator)加以补充。系统的拓扑结构是动态的，因此拓扑管理相应地也应该具有灵活性。拓扑管理必须由用户可以访问的数据库来驱动。对设计优良的拓扑管理器来说，其系统底层架构对用户不透明，用户不必关心其具体的实现方法。

故障及事件自动管理

以上所述的所有软件都具有控制基础系统部件的基本能力。这种软件基本结构可跟支持系统修复和重构的硬件基本结构相媲美。为达到高可用(即99.999%正常运行时间)，故障管理过程必须完全自动化，因为依靠操作员来管理系统将会花费很长的时间。

完全自动化管理系统的基础是事件/故障管理器。软件或硬件升级这样的事件，以及硬件或软件故障引发的事件，从管理的角度来说本质上都是相同的，都产生了改变系统运行状态，然后回复到稳定状态的动作。

由于系统拓扑结构具有灵活性，事件管理器也必须具有像系统拓扑结构一样的灵活性。事件管理器必须能接收来自系统整合器规定的程序指令，一个设计良好的事件管理器为用户提供了易于详细说明程序的界面。

高级业务

校验点(checkpointing)和“心跳”(heartbeat)服务功能结合分布式处理环境(DPE)实现了工作/备份操作，这些功能使应用程序能够实现更高级的重启模式。点校验为应用程序提供了保存状态的方法，而“心跳”功能使工作设备和备份设备保持同步，并用作检测校验点处理故障的一种方法。

DPF抽象了来自应用程序的系统配置。在拓扑管理器的协同工作下，用户应用程序无需了解诸如备份设备在何处等系统实际配置情况。

事件管理器与拓扑管理器及DPF共同将系统事件从应用层中隐去，因某个器件故障引发的拓扑结构变化可通过逻辑映射到其它设备来处理。

另一个提高系统效率的重要功能是诊断控制。事件管理器利用诊断信息来确定故障部件，通信平台通常要求实时部件故障判断的准确率达到95%。

由于工作/备份系统中的设备具有某种状态，可利用诊断管理器为设备的正常状态作正确诊断。诊断管理器与拓扑管理器及事件管理器共同判断设备是否在期望的状态下工作。

以上所描述的所有基本结构仍不能产生5个9(99.999%)的高可用性系统。先前5个9系统的高可用预算中，每年为系统升级分配了1分钟时间，软件在线升级必须满足这个要求。软件在线升级需要采用具有上述所有基本结构部件特性的工作/备份应用程序模型。

由于系统很少独立工作，系统的最后部分通常是一个网络管理接口。故障管理器采用分层实现时呈最佳状态，因此这种结构通常能达到最佳效果。

第三方软件

高可用性技术很快从主要的电信设备提供商的专用平台转变为开放架构的平台。另外，实现高可用性所需的开放软件也日益普遍。

这些软件部分来源于开发高可用性操作系统的供应商。许多供应商致力于这方面的研究，但还没有任何新产品发布，这种局面有望在2001年大有改观。当前一些操作系统声称具有高可用性，却仅局限于2N系统应用中。另一种选择是将支持基本业务的操作系统和可以工作在各种操作系统下的第三方故障管理软件结合起来。尽管一些产品可实现大部分所需的软件功能，用户仍然需要为目标平台的管理开发相应的程序。

适当的软件基本结构与适当的硬件基本结构对于高可用性而言同样重要。只有将许多精工细做的部件适当地集成，才能确保高可用性。另外，了解系统高可用性必须满足的要求也同等重要。

要获得更高的可用性，需要付出相应的代价。采用正确的系统体系结构、重启模式和软件基本结构可得到性价比最好的系统。系统集成商和平台供应商应共同致力于开发所有的必要软件，实现期望的高可用性。

作者简介：

Chuck Hill是摩托罗拉计算机公司电信业务部门的系统设计人员。他在开发容错和高可用性系统方面有6年的工作经验。Chuck还参加了多个PICMG委员会，包括热拔插分会和冗余系统插槽分会。