通过有效的故障管理提高系统可靠性

对电信运营商服务质量问题的关注以前仅限于通信系统供应商，而现在扩展到整个通信设备制造商。运营商提供服务需要高可靠产品，这类产品对故障应具有容错能力，能够在不中断服务的条件下进行维护和升级。本文介绍如何利用有效的故障管理来提高系统可靠性，使其达到“五个九”质量水平。

电信业中的高可靠性又称为高可用性(High Availability)，它是一种分类，一般在通信业中用于运营商系统，表示系统具有99.999%正常运行时间(即所谓的五个九)，或者说每年的停机时间小于315秒(平均每天不到1秒)。

系统可用性可按下式计算：

可用性=MTTF/(MTTF+MTTR)

其中MTTF为平均无故障时间，MTTR为平均修复时间。

根据该关系式可得出一些有趣的特性。从数学上讲，为了提高可用性，我们可以或者增加MTTF，或者降低MTTR。把MTTF增加N倍和把MTTR降低成1/N是一样的，但如果我们进一步看一下公式，就能发现将MTTR降低50%(MTTR变成0.5MTTR)要比将MTTF增加50%(MTTF变成1.5MTTF)更好，而对这两个参量来讲，还有其它更重要的系统特性。下面用一些简化的假设来看一个系统实例。

假设一个系统由N个部件组成，每个部件的MTTF都相同，记为MTTF_comp，其中部件的失效相互之间独立，且不具有记忆性(即与以前的失效无关)，同时每个部件的MTTR也一样,那末系统MTTF为：

MTTF_system=MTTF_comp/N

假设有100个不同的部件，则系统的可用性为：

可用性=(MTTF_comp/100)/((MTTF_comp/100)+MTTR)

如果每个部件都具有五个九的质量，即

MTTF_comp=99,999·MTTR

带入公式可得：

可用性=0.999001，或者说是三个九的可用性。

所以要想使系统达到HA或者五个九的质量，那么每个部件就必须具有七个九的可用性。这是一个简化的说明，但我们可以看到，MTTF是系统每个部件的函数，并且系统MTTF大致与系统中独立的部件数成反比。当部件数目增大时，提高一个部件的MTTF_comp对整个MTTF_system影响不大(图1)。

MTTR一般随系统的复杂性(如系统部件数)增加而增加，但对于好的设计来讲，MTTR并不直接与部件数成正比(图2)。如果我们能基本独立地对每个部件进行修复，那么MTTR应该是最长系统部件(或部件组)修复时间的函数。所以这就是真正的目标，即找出一个能显示该MTTR模型的设计方法，从而得到较高系统可用性。我们可以构想一个数量较少的修复操作(每一次为一个MTTR)，这种操作能满足绝大多数部件失效情况，这样整个问题就变得便于管理了。

此外MTTF基本上是一个很难用任何分析手段计算得到的数字，软件质量的提高一般只需投入更多时间和资金，或者用更好的工具就可以了，但通常硬件质量方面任何大的改进(如MTTF)需要投入巨资。另一方面，MTTR可以确切计算出来，只需付出相对很低且可以估计的费用就能获得一个数量级的改进。

为做到这一点，多数HA系统设计人员都定义一小类修复操作，使之满足所有部件失效情况。就像我们将要看到的那样，在系统中设计冗余部件减少MTTR是一种很有效的方法，可以避免与系统中多个部件都成函数关系的MTTF降低，但这并不表示对MTTF的考虑不重要，有一些通用部件设计技术常常用来提高系统MTTF水平。

错误、故障与失效

在我们讨论修复之前，必须首先清楚地了解是什么原因需要我们进行修复，这里将介绍三个概念，即错误、故障和失效。错误是一个可以观察到的状态，指一个值或者一个响应偏离了真实或正确值；故障定义为一个引起错误的交互系统或部件失效；失效也是一种状态，指系统或交互部件所观察到的反应偏离了规定的方向。

故障会引起错误，从而导致失效，但错误也可能在错误状态检测范围内得到修正。此外，故障还会引起一个新的故障，这个故障再引起另一个错误，并继续下去。二者的主要区别在于错误是可以观察的，而故障是观察不到的。如果可能，我们可以通过修正错误来尝试“修复”故障，但在大部分场合却无法做到。为了解这一点，我们需要看一下系统产生的错误类型。

一般来讲错误有两类。第一类是定义明确的错误，其原因(故障)非常清楚，结果也是已知且确定的，并在一定范围内。这类错误一般是可以修正的，只要处置得当，不会引起失效。第二类错误本质上是一种瞬态错误，一般很少发生，通常没有重复性和再生性，与时序或过载效应相关。据研究显示，成熟系统中后一类瞬态错误要明显多于确定性错误，数量之比约为100比1。对于这种错误，我们通常不能用修正的方法进行修复，达到防止失效的目的，这是因为我们常常不能准确找出造成这种错误的故障。有时也能够从错误推断出故障，但大多数情况下做不到这一点，因为找不到线索，所以我们一般通过对错误造成的(或将造成的)失效进行恢复，从而达到修复的目的。更通常的做法是从失效源头处进行恢复，即从故障开始。

如上所述，大多数故障是不能修正的，因此故障恢复操作比错误修正更受到HA设计的重视。错误是能观察到的，我们必须首先了解错误检测所扮演的角色。

大多数设计人员都很熟悉各式各样错误检测技术，包括硬件、软件、内部的、外部的、后台正确性检查等等。在任何可靠系统中，都应该尽可能开发使用这些技术，但事实是有大量不同的错误类型必须进行检测，而且每一种都有与其相关的分支。

除此以外，同一种或几个相关故障可能会引起几乎同时发生的多个错误，如果处置不当还会引起其它错误或故障。回想一下我们常常不能判定故障的确切性质，即意味着在大多数场合下不能用检测错误的软件就地进行错误处理，因为错误处理软件自身也会遭到破坏。在HA系统中，我们要将风险减少到最小，所以如果能找到故障或者用适当的修复操作进行处理的话，错误事件应尽可能传到系统最高级。因此必须要有一个通用工具，可以将检测到的错误递交给它以进行处理，这就是“故障管理器”

故障管理

对于有些类型的错误，我们能够有效地隔离或者判断出故障源，但就像我们已看到的那样多数错误这样做会很困难或者不可能，所以此时我们只能试图把故障围在一个范围内，将其影响限制在局部，防止引发更多故障和失效而造成进一步损害，而且即使我们已经判断出故障范围限定状况，仍要准确收集必须修复的软件或硬件单元。为了使所有这些工作衔接起来，需要有一个统一的故障处置或管理方法，以获得成功的HA系统设计。HA系统对故障管理的总体要求包括：

·隔离：将故障源隔离在具体的硬件或软件单元中。注意这不是一定都可以做得到的，一般来讲隔离硬件故障比隔离软件故障相对要容易一些，然而许多研究表明，在大多成熟系统中软件故障数量要超出硬件故障，比例为6比1。所以软件故障要普遍得多，并且很难将它进行隔离和处理。

·围堵：防止故障造成进一步损害。

·局部处理：判断故障的范围，如哪个硬件和软件会受到影响。

·识别：判断故障的类型，以此判定需要进行的修复操作，可以是修正，也有可能进行恢复。

故障管理的任务是提供一个全面的框架，以便有效管理修复工作。故障修复设计需要一个参考框架，针对不同类型故障列出必要的响应，有两类主要修复操作，即避免和修正。故障避免表示在故障引起失效前将其修复。该技术实例包括数据结构的预防性维护，如受损数据结构的后台审计和挽救装置，以及系统状态的一致性检查，如修复不一致状态(同样也是使用审计和挽救装置)等。虽然这些方法可以改进MTTF而值得一做，但它们通常基于一种试探性方法，很难达到好的效果。

故障修正

故障修正表示在错误引起失效后对其进行修复，该修复操作定义了系统的MTTR。修正技术也包括两类，分别是屏蔽和恢复。

故障产生可修正错误时可以使用屏蔽技术，将失效影响从系统中充分屏蔽掉。这个方法使用冗余或者替代信息贮备，或者用一些自带的修正程序，像误差修正码之类。N次复用冗余硬件结构支持这种修正形式。

当误差是不可修正或不可屏蔽时，可以使用恢复技术。由于失效已经暴露出来，因此我们可从它的影响中进行恢复，而恢复又有两种形式：前向恢复和后向恢复。

当故障产生一个可恢复错误时可以使用前向恢复，我们通过构建新的“正确”状态以便从失效中恢复，只需在部件或作为整体的系统中采用少量中断。前向恢复的一个例子是在响应中产生否定确认或者超时情况时重新发送信息，这是一种简单的技术。

后向恢复表示基本上没有合适的方法可以修正误差，这样就产生了失效，所以恢复的过程就是返回到以前已知的正确状态，并且从这一点出发重新开始运行。

在HA系统中，故障修复最普遍的形式往往是后向恢复。就像我们在前面分析中看到的那样，发生在系统中的大多数故障我们都不能准确识别，这样造成损害的范围就不能被任何分析手段所确定，所以就不清楚要修复什么。即使能确切判定出故障，屏蔽和前向修复操作通常也难以实施或进行，因此很多错误处理的最安全方法是假定不可挽救的错误己经产生，然后有目的地舍弃被故障影响的部件，再恢复被舍弃部件在最后无错误或正确状态中所提供的服务。

后向恢复有两种基本模型，分别是重起动和复制(或冗余)。重起动表示失效的部件被重新起动，它也意味着重新加载部件软件。复制或冗余表示系统里有失效部件的复制品，所以失效后我们可以切换至冗余部件。这里的“部件”可以表示处理节点内的软件系统，也可以表示处理节点本身，或者甚至是多个节点。执行这些操作所需的时间随“失效节点”定义而变化，并且反映在MTTR中。粗略地讲，每种类型恢复所需的MTTR可以排列如下(为简单起见我们不考虑多部件情况)：

·处理节点重起动(或者重新自举)：最高级MTTR

·软件子系统/部件重起动：次高级MTTR(在有些场合可以接近或低于下一个)

·处理中节点切换：再次级MTTR(在有些场合可以接近或高于上一个)

·软件子系统/部件的切换：最低级MTTR

注意在有些场合，切换严格地讲不能看作是后向恢复操作，而可认为是一个屏蔽故障的误差修正，例如一个服务器部件失效并转换至替代服务器可以不涉及以前状态的恢复，然而这要假定复制服务器和失效的工作服务器必须精确同步，对大多数系统来讲这是很罕见的情况，但确实也有。

重起动一般是一种很难处理的操作，因为它涉及到要取消/删除失效的部件以及完全重新初始化部件至之前的已知状态。有时如果发生重大硬件故障，这样做将完全不可行；而如果是软件部分受到破坏，则需要全部重新加载，这通常又很费时间。但如果设计正确，有时重起动也是一种有效的技术。不过复制或者冗余大大减小了在一个点上发生毁灭性失效的可能性，而正是这种失效需要采取重起动。

所以总的来讲，使用冗余部件进行切换操作是一种较好的恢复方法。成功切换的关键是要制订一个可靠的计划，对部件每个一致性状态进行定点检查，这样可能的话失效部件就能完全恢复，或者复制部件能恢复到最后己知时刻的一致性状态。故只要有可能，失效部件仍然需要重起动，此时所用时间并不重要。

但这样产生了另外一个问题，即当谈论一个部件失效时，我们如何能够确认这一故障不会破坏其他部件呢？

恢复域概念

恢复域对任何HA系统设计来讲都是至关紧要的，上面故障管理部分己经间接谈到了这一点，就在故障管理的两个任务即错误围堵和局部处理中。HA系统设计所有方面都必须对故障净范围及需要精确恢复的内容予以判定，正确的恢复操作中，所有表示部件最后已知一致性状态的信息必须预先知道，而代表这一切的集合，包括部件、硬件和软件统称为故障恢复域，所以恢复域定义了故障的围堵和局部处理特性。

对于恢复域概念，我们必须精心设计和执行。幸运的是，在软件设计方面对于这一点已有一些指导原则，这将在稍后进行讨论。恢复域另外一个重要考虑因素涉及到修复时间。总的来讲，一个给定故障的恢复域越小，故障恢复的MTTR就越低，而与使用的恢复技术无关，因此这就成为一个重要的设计目标

故障容错结构

这里的篇幅不允许对故障容错结构进行展开讨论，但有些概念还是要介绍一下。总体来讲，有三种处理器系统结构在HA系统设计中得到广泛使用，分别是冗余对、簇和N次复用。

冗余对是装载有相同软件的两个处理器，但两者并不是平行运行。一个在当前使用，另一个作为备用，当正在使用的处理器出故障时将其替代。为做到这一点，常用修复机制是用带切换的后向恢复操作，因为当正在使用的处理器出现故障时，备用处理器可能不与之保持完全同步，这样就必须进行更新，或者在执行切换操作时将其带入与系统其余部分一致的状态。很明显，当冗余对发生切换时，故障的恢复域就是处理器域。注意冗余对切换经常因为软件错误而不是硬件或处理器失效而产生，回想一下就知道这是因为重新自举或重起动节点经常要花费太多时间，所以冗余处理器不只用于硬件失效。这种用于恢复的复制使用最为广泛，从概念上讲也最容易处理。

簇是指一组处理器，它们之间松散耦合并直接相连，但电气上是隔离的。所有处理器并不执行同一个软件，相反，系统软件子系统即使不是全部也有大部分复制在簇的某处。这种结构可以在软件子系统一级最好地利用切换恢复机制，此时恢复域是一个子系统。如果做得好，该结构可利用子系统切换操作较低的MTTR，而得到非常高可用性的方案。如果服务分区良好，并且在簇内复制了足够的次数，这种结构还能够支持处理器域失效，有时比冗余对效果更好，但是它复杂性高，成本也高。

N次复用指安排N个处理器，这里N大或等于2，为保证完整性，也在这里介绍一下。每个处理器并行执行相同的代码，并使用相同的接口或通信器件。

它的概念是对于所有系统输出，如果存在分歧则用一个仲裁动作来决定使用那一个输出。如N大或等于3，将使用一个表决机构，本质上讲是通过屏蔽故障进行修正的一种形式，而不是恢复。如果N等于2，则通常N次复用对停止工作，而是进行一些恢复操作，也许是转换到一个备用的N次复用对上，以便用在更完善的冗余对结构形式中。出于费用上的考虑，N次复用大多用在对安全性要求很高的系统中，像运输和大型工厂工艺控制系统，这些场合发生失效将是灾难性的。

故障管理要求可通过软件特定单元以及特定的设计实践和原则来满足，到目前为止，我们一直把注意力放在框架上,协助了解HA系统的故障容错本质和一般使用技术，我们也看了一些硬件故障容错的高级特性，现在可以得出关于软件HA系统设计方面更实用的结论。下面是有关这种设计的一些原则和要求。

改进软件系统整体可靠性从而改进MTTF的最佳方法之一是遵循简单化概念。人们很早就知道将系统分解成许多小模块会得到比大模块更好、更可靠的结果，系统复杂性将随规模大小成指数增加。同样的论点也可用在使用的编程模板或模型中，就像通过使用应用编程接口(API)所表现的那样。将模板和API数量限定在很小数量能得到更可靠的代码，这也可以应用到操作系统API和它们支持的编程模板中。

软件分离

我们己经看到HA系统设计中故障管理的两个重要目标是围堵和局部处理，就是说将故障的影响限定在一定范围，并将受到影响和需要修复软件部分精确控制在局部地方。为做到这一点，设计人员应将所有软件子系统组织成分离的恢复域，这些域相互之间在物理上和逻辑上是分离的，物理上使用存贮保护(MMU)，而在逻辑上避免共享数据。恢复域子系统分解得越细，就越能够利用低MTTR的优点进行恢复操作。

子系统之间的所有通信应该使用干净透明的接口，这样每个子系统的状态是完全自限定的。我们也非常希望每个子系统有属于自己的代码/信号源，减少或避免通用或共享代码/信号源。如果想有一个符合HA的系统，对于便利和性能方面的考虑就不能超越分离原则。

虽然后向恢复是最流行和成功的方法，但它对设计和操作环境(包括操作系统)有一些特殊要求，包括：

·检查点(保存系统/子系统状态)：这样在恢复操作中可以回复之前的状态。有许多设计模型和模板可用于这一技术，这里我们不对其进行评估，关键是系统的状态数据必须存在于恢复域的外面，保证不会因故障受到破坏。除此之外，该数据中心库必须本身是复制或冗余的，以便从单点失效中得到保护，再根据恢复结构和方法的不同，很方便地从系统其它处理单元进行访问。

·源回收：后向恢复需要将错误的恢复域消灭掉，这意味着域内的程序或任务要终止。返回、回收或者清理所有错误子系统拥有或分配的源是非常必要的，并且极为重要，否则该域将不能正确地重起动，或者系统将受到源泄漏的危害并随时间推迟而引起其它故障。通常操作系统会对这一点提供一些帮助，应该特别将这点看作实时操作系统(RTOS)的一个优点。

状况/事件监控

监督或者状况/事件监控要求已在错误检测中进行了介绍，但带故障和后向错误恢复的系统软件部件也会在任何时间停止提供服务，而可能引出这种要求。换言之，我们需要看到故障和失效的另一面，即那些与现在己经失效的部件有关系的其它部件，当部件失效时，与其进行通信的应用必须可靠地通知到。例如一个服务器应用需要知道什么时候客户死机，以释放掉服务器中已分配的资源，另外还要知道如果有需要的话什么时候进行切换。应用本身不应该做这些工作，相反，操作环境或操作系统本身应提供一个服务自动发出这些通知。这项要求也应在整个网络实施。

通信情况

在子系统级使用切换方法进行后向恢复的结果之一是要有用于通信透明的方案，在簇系统结构中尤其如此。所谓透明表示需要用 (失效部件的)复制部件切换通信时，不必精确地“知道”复制部件在哪里，可以是在同一处理单元中，或者也可以是在网络的另外单元中，但所使用的通信方案必须是相同的。此外，至所有复制服务的路径地址必须事先知道，且这一要求常常需由操作环境或操作系统来解决。

由于故障种类形形色色，性质也各有所异，错误处理或者更准确地讲故障管理不应在最低水平如检测错误代码中进行。在应用代码空间从系统实体(像RTOS)中处理故障返回一般来讲不是一个好方法，将错误“扔”到一些集中的故障管理应用中要更好一些，可以帮助限定故障并得到一致性修复策略。将错误处理器或故障管理器部件与系统及每个定义恢复域连起来是一个很好的做法(图3)。

对于后向恢复，特别重要的是部件不应是恢复域本身的一部分，因为我们必须假定整个恢复域都受到破坏。该方法的另一个优点是从应用中将分离出来的错误或故障处理代码送入集中位置可得到更简单的代码模块，并且像我们已看到的那样，简化本身在HA系统设计中就是一个优点。从本质上讲，这个部分属于操作环境的一部分，操作系统本身在这一方面能够提供的任何帮助都很有用。

另外一个在子系统部件级从后向恢复中引出的要求是这些部件的动态配置能力。失效的部件最后必须重新起动，因此本身必须动态配置到运行环境中，从而与系统其余部分重新建立通信及运行。应该避免所有或大部分对软件部件实行的静态配置，如果部件需要动态加载的话这一点特别重要。单个部件动态加载虽然并不严格要求为故障容错系统，但这常常能对恢复提供有用的帮助，并且可用在许多系统中，这在现场升级或维护中特别有用。我们没有特别强调现场升级或维护，但仍应使用同样的规则。当现场系统进行升级或维护时，系统一些部分可以从服务中脱开进行升级或修复，此时应尽量把范围缩到最小以避免影响MTTR。单个软件部件的动态配置能力需要得到来自操作环境的直接支持，因为它还包括了通信方面的内容。

本文结论

在了解HA系统要求中，我们看到了一些高级框架，包括HA系统的定义、故障性质、故障检测问题和它们的影响，以及修复的含意和各种修复方法与硬件结构的内容，所有这些都有助于清楚地定义什么方法重要和为什么重要。我们也从这个框架中引出实现HA系统的一些有用设计原则和要求，其中大多数都直接与操作环境或操作系统的服务和特性有关，这些环境或系统我们并没有详细讨论(这是另外一个题目)。但设计人员如能按照对商用操作系统和中间件方案的选择来仔细检查这些要求，他们将从中获益，目前有许多这样的方案存在并且都各不相同。

作者：Michael Christofferson

产品市场经理

OSE Systems Inc

Email: mikec@enea.com