1 简介

OTP 中的操作和维护 (OAM) 支持包含一个用于 OTP 中管理子系统的通用模型，以及一些在这些子系统中使用的组件。本节描述该模型。

该模型的主要思想是，它不与任何特定的管理协议绑定。定义了一个应用程序编程接口 (API)，可用于编写针对特定管理协议的适配器。

OTP 中的每个 OAM 组件都实现为一个子应用程序，该子应用程序可以包含在系统的管理应用程序中。请注意，此类完整的管理应用程序不在此通用功能的范围之内。但是，本节包括说明如何构建此类应用程序的示例。

1.1 术语

网络级别的协议无关架构模型是众所周知的管理操作的客户端-服务器模型。此模型基于客户端-服务器原理，其中管理器（客户端）在访问管理信息时从管理器向代理（服务器）发送请求。代理将回复发送回管理器。与正常的客户端-服务器模型相比，存在两个主要差异

通常，一些管理器与许多代理通信。
代理可以自发地向管理器发送通知，例如警报。

下图说明了该想法

图 1.1：术语

管理器通常被称为网络管理系统 (NMS)，以强调它通常实现为向操作员呈现数据的程序。

代理是在网络元素 (NE) 中执行的实体。在 OTP 中，NE 可以是分布式系统，这意味着分布式系统被管理为一个实体。当然，代理可以配置为能够在多个节点中的一个上运行，使其成为分布式 OTP 应用程序。

管理信息在管理信息库 (MIB) 中定义。它是代理向管理器提供哪些信息的正式定义。管理器通过管理协议访问 MIB，例如 SNMP、CMIP、HTTP 或 CORBA。每种协议都有自己的 MIB 定义语言。在 SNMP 中，它是 ASN.1 的一个子集，在 CMIP 中它是 GDMO，在 HTTP 中它是隐式的，使用 CORBA，它是 IDL。

通常，在 MIB 中定义的实体被称为受管对象 (MO)，尽管它们不必以面向对象的方式成为对象。例如，在 MIB 中定义的简单标量变量称为 MO。MO 是逻辑对象，不一定与资源进行一对一的映射。

1.2 模型

本节介绍在基于 OTP 的 NE 内使用的通用协议无关模型。此模型由所有 OAM 组件使用，也可以由应用程序使用。该模型的优点是它将资源与管理协议明确分开。资源不需要知道用于管理系统的管理协议。因此，可以使用不同的协议管理相同的资源。

参与此模型的实体是代理，它终止管理协议，以及要管理的资源，即实际的应用程序实体。一般来说，资源不应了解所使用的管理协议，代理也不应了解受管理的资源。这意味着需要一个转换机制来将管理操作转换为对资源的操作。这种转换机制通常称为检测，实现它的函数称为检测函数。为每种管理协议和要管理的资源组合编写检测函数。例如，如果要通过 SNMP 和 HTTP 管理应用程序，则定义两组检测函数；一组将 SNMP 请求映射到资源，一组例如为一些资源生成 HTML 页面。

当管理器向代理发出请求时，下图说明了这种情况

图 1.2：管理器向代理发出请求

检测函数和资源之间的映射不一定是 1-1 的。也可以为每个资源编写一个检测函数，并从不同的协议中使用该函数。

代理接收请求并将其映射到对一个或多个检测函数的调用。这些函数对资源执行操作，以实现与 MO 相关的语义。

例如，使用 SNMP 和 HTTP 管理的系统可以按如下结构构建

图 1.3：使用 SNMP 和 HTTP 管理的系统的结构

资源也可以向管理器发送通知。通知的示例包括事件和警报。资源需要生成协议无关的通知。下图说明了如何实现这一点

图 1.4：通知处理

主要思想是资源将通知作为 Erlang 术语发送到一个专用的 gen_event 进程。在此进程中，安装了针对不同管理协议的处理程序。当此进程收到事件时，它将事件转发到每个已安装的处理程序。处理程序负责将事件转换为要通过管理协议发送的通知。例如，SNMP 处理程序将每个事件转换为 SNMP 陷阱。

1.3 基于 SNMP 的 OAM

对于所有 OAM 组件，都提供了 SNMP 适配器。将来可能会定义其他适配器。

OAM 组件以及其他一些 OTP 应用程序定义了 SNMP MIB。这些 MIB 使用 RFC 1902 中定义的 SNMPv2 SMI 语法编写。为了方便起见，我们还提供了 SNMPv1 SMI 等效项。所有 MIB 都设计为 v1/v2 兼容，即 v2 MIB 不使用 v1 中不可用的任何构造。

MIB 结构

顶层 OTP MIB 称为 OTP-REG，它包含在 SNMP 应用程序中。所有其他 OTP MIB 都从该 MIB 导入一些对象。

每个 MIB 都包含在一个应用程序中。MIB 文本文件存储在应用程序目录下的 mibs/<MIB>.mib 中。生成的包含常量声明的 .hrl 文件存储在 include/<MIB>.hrl 中，编译后的 MIB 存储在 priv/mibs/<MIB>.bin 中。

需要将 MIB 导入另一个 MIB 的应用程序将使用 il 选项传递给 SNMP MIB 编译器

snmp:c("MY-MIB", [{il, ["snmp/priv/mibs"]}]).

如果应用程序需要包含生成的 .hrl 文件，它将使用 -include_lib 指令传递给 Erlang 编译器

-module(my_mib).
-include_lib("snmp/include/OTP-REG.hrl").

以下是 OTP 系统中定义的一些 MIB 的列表

OTP-REG（在 SNMP 中）包含所有其他 MIB 使用的顶层 OTP 注册对象。
OTP-TC（在 SNMP 中）包含通用文本约定，任何其他 MIB 都可以使用这些约定。
OTP-SNMPEA-MIB（在 snmp 中）包含用于可扩展 SNMP 代理本身的检测和控制的对象。代理还实现了标准 SNMPv2-MIB（如果使用 SNMPv1，则为 MIB-II 的 v1 部分）。

不同的应用程序使用不同的策略将 MIB 加载到代理中。一些 MIB 实现是纯代码的，而另一些则需要服务器。一种由纯代码 MIB 实现使用的方法是，用户调用诸如 snmpa:load_mibs(Agent, [Mib]) 之类的函数来加载 MIB，以及 snmpa:unload_mibs(Agent, [Mib]) 来卸载 MIB。有关如何加载每个 MIB 的说明，请参阅每个应用程序的手册页。