通过有效的故障管理提高系统可靠性
来源:电子工程专辑 作者: 时间:2003-04-29 00:27
摘要:对电信运营商服务质量问题的关注以前仅限于通信系统供应商,而现在扩展到整个通信设备制造商。运营商提供服务需要高可靠产品,这类产品对故障应具有容错能力,能够在不中断服务的条件下进行维护和升级。本文介绍如何利用有效的故障管理来提高系统可靠性,使其达到“五个九”质量水平。
电信业中的高可靠性又称为高可用性(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都相同,记为MTTFcomp,其中部件的失效相互之间独立,且不具有记忆性(即与以前的失效无关),同时每个部件的MTTR也一样,那末系统MTTF为:MTTFsystem=MTTFcomp/N
假设有100个不同的部件,则系统的可用性为:
可用性=(MTTFcomp/100)/((MTTFcomp/100)+MTTR)
如果每个部件都具有五个九的质量,即 MTTFcomp=99,999·MTTR
带入公式可得:可用性=0.999001,或者说是三个九的可用性。
![]() |
所以要想使系统达到HA或者五个九的质量,那么每个部件就必须具有七个九的可用性。这是一个简化的说明,但我们可以看到,MTTF是系统每个部件的函数,并且系统MTTF大致与系统中独立的部件数成反比。当部件数目增大时,提高一个部件的MTTFcomp对整个MTTFsystem影响不大(图1)。
![]() |
此外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(在有
上一篇:加强存储器测试避免可测性设计错误
下一篇:USB设备的调试与测试技巧