基于OSI标准的网络故障管理系统的设计与实现

◆李维峰

基于OSI标准的网络故障管理系统的设计与实现

◆李维峰

（中国飞行试验研究院 陕西 710089）

由于受管网络设备的数量庞大以及涉及的管理目标众多，网络管理已经成为通信网络设计和维护中讨论的核心问题。但是当前网络管理工具和技术的使用不当或效率低下使得管理员对于某些网络通信系统的有效管理几乎不可能实现。这些趋势只会增加对有效网络管理的迫切需求，上述情况的迫切性也促使许多组织与国际标准化组织（ISO）合作定义网络管理框架。本文基于OSI标准设计了一种网络故障管理系统。

网络管理；故障管理；OSI

0 引言

开放系统互连（OSI）网络管理分为五个特定管理功能区（SMFAS）。它们分别是故障管理、配置管理、计费管理、性能管理和安全管理。这些功能区通常被称为FCAPS，彼此互相配合，共同完成所有网络管理任务。但是，本文主要集中在故障管理功能区。网络管理中首先要提到的内容就是故障管理。它的主要作用是确保网络的高可用性。因此，需要一个预防和避免网络故障的系统，并且在不能避免故障的情况下，该系统需要采取必要的步骤来遏制这种损害并且解决对网络的影响。该系统的功能应包括自动检测并通知故障发生的能力、隔离故障的能力以及尽可能纠正故障的能力。由于标准化进程缓慢，用户缺乏故障管理应用系统，多个组件的间歇性故障，需要特定的监测和故障排除工具。本文选择研究和解决故障管理问题，希望找到故障发生 的真正原因，通过接收到的大量告警和执行故障诊断所需的信息，预测网络故障的发生，从而可以缩短故障间隔时间和故障恢复时间。

1 网络故障管理

在本节中，我们提供与网络故障相关的一些术语的定义，并介绍执行故障管理时可能遇到的典型问题。

1.1术语及故障特征

fault，error和failure这三个术语经常被混淆，这些条款的错误解释可能会导致错误的使用。fault是系统中的软件或硬件缺陷，会干扰通信或降低性能。error是系统组件的错误输出，如果组件产生error，我们说组件失败，这是组件故障。failure是组件故障对应于由该组件产生的错误。我们必须区分上述条款，fault是产生错误的直接或间接原因，error是错误的表现形式，fault是故障的总体结果。但是，如果组件产生错误，我们不能断定组件中存在错误。网络故障的特点可能包括其症状，例如：传播（从一个组件到另一个组件的错误传输）、网络持续时间和严重程度等几个方面。虽然网络故障可以通过它们的特点加以区分，但是值得注意的是，由于它们受到控制和管理的方式不同，所以难以准确地测量这些特性。用户可能因为error而导致某些网络组件产生的症状来检测到fault的发生。故障症状可以分为四种类型:定时错误、及时错误、调试错误和遗漏错误。这些症状可能表现为以下形式之一：

（1）具有预期值的输出要么太早，要么太迟：这种情况是由于定时错误造成的。当用户的应用受到故障的间接影响时，通常被用户看作是缓慢的响应或超时。

（2）在指定的时间间隔内出现意外值：这种情况是由于及时错误造成的，通常表现在应用程序或底层软件和硬件中出现轻微故障。

（3）在指定的时间间隔之外出现意外值：这是由于调试错误造成的，如果没有产生响应，则与遗漏错误相关联。遗漏错误可被视为调试错误的特例，调试错误通常意味着网络出现严重故障。

如果观察到这些症状，则可能在网络中某处发生故障，导致组件产生错误的输出（error）。一个组件中的故障可能对其他相关组件造成影响。除了系统自己以外，它可能会传播到其他组件，进而影响整个系统。这样，单个组件中的故障可能具有全局影响，在网络上，这种现象被称为故障传播。发生在孤立系统中的故障可能不会影响其他系统，因为它们之间没有交互作用。但是，当孤立系统通过通信连接在一起时，由故障产生的错误可能在分组中传播到其他系统。一个组件可能由于其中的错误和其他组件中的错误而产生错误，这是网络故障的主要特征之一。

网络故障的持续时间虽然被认为是其重要标准之一，但有时难以衡量。这是由于三个原因：首先，直到产生错误才会感觉到错误。其次，一个特定的错误可能需要很长时间才能被感知。最后，故障排除后，网络故障的影响可能不会自动消除。他们将保持一段时间，直到整个系统运行稳定为止。因此，网络故障一般根据其持续时间分为永久性、间歇性和瞬时性三类。网络中将存在永久性故障，直到采取修复措施。间歇性故障以不连续和周期性的方式发生，其结果将是当前进程的失败。这意味着在短时间内服务水平有很大程度的降低，短暂的故障会暂时导致服务水平的轻微下降。第一种类型的故障将导致事件报告被发出，并在网络配置中进行改变，以禁止进一步利用该资源。对于第二种类型的故障，如果这种故障的过度发生变得显著，则故障的严重程度可以从间歇性转变为永久性。最后，网络协议的错误恢复过程通常会掩盖瞬态错误，因此用户可能不会观察到。故障管理系统的设计者必须具备故障特征的知识，这是因为不是所有的故障都会有相同的优先级，故障管理系统设计者将必须决定哪些故障必须被管理。

1.2故障管理流程

一些文献认为综合故障管理系统由监测、报告、记录、故障单、过滤、关联、诊断和恢复活动组成。本节试图讨论故障管理系统将运行的领域，为便于讨论，我们选择将与故障管理有关的活动分为检测、隔离、纠正和管理四大类。错误检测提供了识别错误的能力，它包含监测和报告活动。监控设备提供的信息必须是最新的、及时的、准确的、相关的和完整的。报告活动包括调查需要通知的关键标准和报告生成机制，还涉及确定发送通知的适当目的地。

检测的目的是为了隔离实际的故障，给出了一些可能的故障假设。

隔离包括四个活动：过滤、解释、关联和诊断。过滤涉及分析管理信息以便识别新的故障或者之前是否发生故障，以更新其计数。过滤丢弃没有意义的管理信息通知，并将适用的通知路由到系统内适当的目的地。

隔离后，必须通过旁路和恢复将故障的影响降至最低，这就是纠正。在适用的情况下，必须采取措施确保问题不再发生。这个程序包括三个活动：重新配置、恢复和修复。重新配置或旁路包括激活专门分配给关键实体备份、暂停服务或将冗余资源重新分配到更重要的用途，目标是减少失败的直接影响。这个功能可能是手动，半自动和自动程序的混合。

故障管理是为了确保故障不会丢失或被忽略。这部分工作包括监控故障记录，维护故障信息档案、分析趋势、跟踪成本、教育人员和执行单位关于问题解决的政策。它由三个活动组成：记录、跟踪和趋势分析。记录维护网络中发生故障的事件报告日志。这将用于趋势分析，报告和将来的类型相同或类似故障诊断。跟踪是指跟踪现有的问题和负责人或每个人的工作，促进问题解决实体之间的沟通，并防止问题重复出现。趋势分析可能意味着需要重新设计通信环境、更换劣质设备、增强解决问题的专业知识，获得新的解决问题的工具，改进解决问题的程序、改进教育，重新协商服务水平等工作。

1.3典型问题

故障监测的最关键问题之一是不可观测的故障，在这种情况下，特定故障的内部联系是难以观察到的。加之缺乏自动化测试工具：测试隔离故障困难、昂贵且耗时。它需要设备行为和工具的重要专业知识来进行测试。即使像沿着虚拟电路来跟踪分组进程一样简单的任务，通常也是不可能完成的。这导致经验性的操作规则是“测试虚拟电路是否正常工作的唯一方法，就是把它拿下来”[1]。

恢复过程通常包括自动本地重置与手动恢复过程的组合。恢复提出了一些有趣的技术挑战。其中包括自动恢复作为故障的来源：由于大多数网络设备或进程设计为从本地故障自动恢复，这也可能是故障的来源。故障管理中的问题是维护故障报告日志，由于缺少创建或删除记录的功能，故障报告日志变得困难。日志记录工具通常以静态方式执行，其中日志记录特征是停滞的。因此，一些重要的故障事件不能被记录。如果可以更改日志属性值，则日志记录行为也可能会改变。

2 系统设计

为了解决上述问题，我们设计并实施了FMS（Fault Management System）。它提供了三种类型的故障管理应用程序，如图1所示，即故障维护应用程序（FMA）、日志维护应用程序（LMA）和诊断测试应用程序（DTA）。这些故障管理应用程序与OSI代理一起在网络资源上执行故障管理任务。OSI代理充当故障监视代理，它有能力独立地向FMA报告错误，当监控变量超过阈值时，它也可以发出报告，这就使得FMS可以预测故障。另外，它维护事件的日志。这些日志可以通过LMA访问和操作。DTA提供可由用户调用的一组诊断测试。这对网络管理员来说是有利的，只要有人怀疑某些资源不能按照要求工作。

FMA解决了由于供应商设备配置不当而无法观察到故障的问题。这是通过监视实际资源的关键特性来完成的，当发生涉及这些特性的重大事件时，将这些事件报告给FMA，以便开展进一步调查。这些过程包括对事件解释和过滤，事件关联，调用预定义的诊断测试以及启动恢复过程。FMA使用事件或警报来解决观察点太多的问题。另外，报告标准设计得相当严格，以减少FMA收到的警报量。为了达到这个目的，只报告需要注意的事件。因此，在FMS实施中，事件报告等于报警。FMA通过为接收到的每个事件报告安排预定义诊断测试的执行来提供自动化测试，从而使失败的根源变得明显。随后，自动执行与诊断有关的恢复操作。

图1 系统结构图

另一方面，DTA提供了允许用户调用诊断测试的功能。这对有意跳过微不足道的测试的有经验用户是有利的，并且只选择特定的测试可以使管理目的网络的资源消耗较低。LMA提供的支持克服了缺乏系统审计的适当工具，并有能力启动错误条件（事件）记录。此外，LMA可以通过设置其日志属性值来访问这些日志并控制日志记录行为。其他支持包括删除日志和日志记录的功能，以及审查事件（通过审查日志记录）以进行诊断或趋势分析。

3 系统实现

FMS在OSI管理信息服务（OSIMIS）管理平台上实施。OSIMIS本身是在伦敦大学学院（UCL）开发的，为实施管理系统提供了一个平台[2,3]。OSIMIS提供OSI管理协议、管理系统实施和运行时平台，以及一些简单的管理应用程序。OSIMIS管理的系统平台被称为“通用管理系统”（GMS）。GMS平台提供的支持包括为构建OSI代理提供通用支持，为与真实资源交互提供支持，为生成源（C/C++）代码的编译器，以及用于测试目的的一些OSI客户端应用程序。要使用GMS生成托管系统，实现者必须实现C++对象类，这些类将用于表示托管对象类以及代理的后端与真实资源进行交互。如图2所示，FMS的实施被分成六个功能组件，即用户界面、管理应用程序、系统管理器、系统管理代理、管理信息库和实际资源接口程序。

图2 系统功能组件图

3.1用户界面

由于FMS的用户可以有不同的职责，例如网络管理员或网络运营商，用户界面为针对不同用户的各种故障管理应用提供了一个专注的界面，网络管理员可以启动或终止FMA。如图3所示：

图3 用户应用程序接口

3.2管理应用程序

管理应用程序是用C++开发的。有三组管理申请、FMA、LMA和DTA，所有这些应用程序都是可执行的形式。管理应用程序使用OSI系统管理器，将管理操作发送到OSI系统管理代理。

（1）FMA

该管理应用程序处理从接收到恢复行动发生之时的事件报告。故障管理程序通过管理功能事件处理、事件关联、故障诊断和故障恢复来实现。它可以由用户以管理角色调用。在这种情况下，当网络管理员需要干预来执行恢复操作时，输出是以建议的形式给出的。否则，故障恢复将自动进行。

（2）LMA

这个记录器完成维护事件报告日志的任务。它是趋势分析和报告的工具，并为相同或类似问题的未来诊断提供了库。LMA本身是通过三个独立的程序来实现的。用于记录和设置日志属性值的设施由程序LogSet实现，删除日志和日志记录的工具是通过DelLogRec程序来实现的，用于查看logRecords的工具由程序RevRec实现。

（3）DTA

此工具的存在是为了方便用户，由网络管理员或技术人员负责，它允许用户对特定的网络资源执行诊断测试。其目的是检查诊断测试提供的功能是否正确，或者是通过查看由SMA上的日志记录的事件日志的历史记录来执行诊断例程。

3.3系统管理器

OSI系统管理器是一个负责一个或多个管理活动的应用程序。它发出管理操作请求（操作）并代表管理应用程序功能接收通知（事件）。因此它包括一组连接OSI系统管理代理程序和检索管理信息的程序。这些程序是CMIS原语的实现，它们被管理应用程序用来执行各种故障管理功能。OSI系统管理器以CMIS请求形式向OSI系统管理代理发送命令并等待回复。已经实现了五个OSI系统管理器，即执行M-SET原语、M-GET原语、M-EVENT-REPORT原语，用于在OSI上记录事件记录的M-SET原语的cmis_set、cmis_get、cmis_evrecv、cmis_setlog和cmis_dellog系统管理代理和M-DELETE原语，分别用于删除OSI系统管理代理中的现有事件记录。

3.4系统管理代理

管理员访问各网络元素是通过系统管理代理（SMA）进行的，访问网络元素涉及收集其统计信息并将其用于管理活动。SMA是作为一个单独的UNIX进程实现的，是OSIMIS GMS提供的OSI代理支持，支持ISO CMIP协议。它对MIB实例中的对象执行作用域和过滤，并自动处理所有的CMIP功能。它通过管理应用程序传达的管理操作执行管理操作。其职责还包括发布反映被管理对象行为的通知。SMA充当FMS的最低级功能组件，并通过X.25 MIB提供对X.25网络的访问。OSI SMA要执行的任务可以被概括为与执行通信协议的进程进行内部通信，允许通过CMIS远程访问被管理对象属性，从而实现外部控制管理功能。例如，在管理对象内设置阈值，检测重大事件和超出阈值，以及随后生成事件报告。

3.5管理信息库

MIB通过ISO CMIS和CMIP与FMS进行通信，包括读写特定管理对象属性的能力，向“集合值”属性添加和移除元素的能力，自发生成事件报告以及管理与远程管理器进程的关联。系统的管理对象树随着网络活动的变化而变化，实现反映了这一点，必要时创建和销毁对象。MIB不仅仅是一个被动数据库，该实现支持定义事件，指定在发生特定网络事件时要采取的操作。在实施过程中，行动始终是发送报告。计数器和仪表上的阈值也被支持，超过阈值可能会导致生成报告。如前一节所述，MIB由一个称为系统管理代理的UNIX进程支持，通过实际资源接口程序来访问这些资源。

3.6真实资源接口程序

这是特定于代表真实资源的特定管理对象的部分。它不仅要适应实际的资源类型，也要适应实际资源如何呈现管理信息的手段。它不是由GMS提供的，必须由MIB实现者来实现。这些真实的资源可能驻留在操作系统的内核、用户进程或者通过代理管理的远程系统中。因此，接口程序根据他们想要访问的实际资源的管理信息而变化。目前，定义了两种接口程序来从SunOS内核和SunNet X.25软件中为X25 MIB提取信息。代理收到CMIS请求后，调用执行资源操作的接口程序。同样，当超时指示真实资源应该汇集时，接口程序被调用。这个过程是有目的地进行的，以更新真实的资源管理信息。作为处理从该接口程序接收到的信息的结果，真实资源管理对象可以确定已经超过阈值并且可能需要通知。如果管理对象确定事件转发鉴别器过滤器设置为转发此类通知，则通知SMA。

FMS提供的应用程序是以模块化的方式设计和实现的，彼此独立。这个特性证明了一个优点，就是当需要时可以很容易地添加新的应用程序。

4 结论

随着人们工作和生活越来越依赖计算机网络。这意味着计算机网络必须可用，并在大多数时间提供良好的性能。永久性和间歇性故障的发生是不能容忍的，必须避免。因此，在规划计算机网络时，主动管理网络故障是必须包括的重要项目。我们已经描述了OSI网络管理的概念，并且发现OSI管理的一个重要部分涉及网络管理应用（FCAPS）。对故障管理功能区及其相关问题进行了详细的研究。得出的结论是，通过提供基于OSI的故障管理应用程序的支持，可以更好地实现这种环境下的网络故障管理，帮助网络管理员和技术人员执行故障管理任务。

[1]Dupuy, J. Schwartz, Y. Yemini, G. Barzilai, A. Cahana, “Network Fault Management A User’s View”, Integrated Network Management I, B. Meandzija and J. Westcott (Editors) Elsevier Science Publishers B.V. (North-Holland), IFIP, 1989.

[2]MIDAS Work Package 2.2.1, “Runtime Support for Interaction with Real Resources in the OSIMIS management platform”, Document MIDAS/ UCL/93/08, February 1993.

[3]Project INCA, “An OSI Network Management System”, G. Night, G. Pavlou, Simon Walton, University College London，1988.