电信综合网管系统中的数据管理

    摘要从综合网管的定义和地位出发，讨论了电信 综合网管系统中数据管理的重要性及其数据的特点，并介绍了一种应用在电信综合网管系统中的数据管理方案，说明了该模型的优点。

    1、电信综合网管系统定义及其在OSS中的地位

    如图1所示，OSS系统由资源管理系统、网管系统（包括综合网管系统和专业网管系统——EMS/NMS）和运维管理系统三部分构成，是一个统一的业务支撑 和业务保障系统。它的主要任务是管理全专业的通信资源和业务资源，对业务提供与保障提供监控和管理的手段，并与BSS、财务、建设、采购等部门有着明确的 界面与分工。在OSS系统中，资源管理系统负责实现自动/半自动化的资源调配；综合/专业网管系统完成对故障和服务质量的管理；运维管理系统完成单据流 转、专家库等其它运维功能。

    综合网管系统是OSS系统中的一个重要组成部分，它集成了多专业、多厂家的网元设备进行综合管理，在实现故障管理、性能管理的基础上，结合资源信息和客户信息，向电信运营商 提供以大客户为中心的，面向客户的服务支持，实现电信运营商积极倡导的服务质量保证。

    图1  OSS系统的定位与边界

    综合网管系统与多个外部系统存在着数据交换 ：

    （1）专业网管系统（EMS/NMS）：综合网管系统从中采集得到网络配置、告警与性能等数据；

    （2）资源管理系统：资源管理系统从综合网管系统中得到网络上采集得到的设备配置数据，而综合网管系统则从资源管理系统中获取客户、电路等业务共享数据；

    （3）运维管理系统：综合网管系统根据告警信息，产生出各种工单发送给运维管理系统；

    2、电信综合网管中数据管理的重要性及其特点

    对于综合网管系统，其核心价值在于对电信网络的综合管理和大客户服务质量的重点保障。而要实现这种价值，综合的数据管理就是必不可少的。不管是网络告警的 准确定位、专业内/跨专业的根告警关联性分析，还是针对告警的业务、客户影响分析，都必须要有全面而准确的网络配置数据和关联业务数据作为分析的基础。综 合系统的意义就在于将各方面的数据在自身的平台中进行整合后，加工成有用的信息，并体现在上层的综合应用中。

    资源管理系统的数据管理目标在于面向业务调度、核查网络资源，而对于综合管理系统来说，这个目标则是面向业务保障、支撑网络运营，因此综合网管系统的数据管理侧重点与资源管理系统也存在不同，必须针对综合网管系统的管理需求来进行数据模型管理。

    在大部分情况下，综合网管系统只关心数据对象本身，其属性更多的是作为对象的附加描述而存在，针对属性的操作也很少；因此在数据建模的时候，我们就可以忽略对象的细节内容，而将对象本身作为建模的重点。

    在综合网管系统中，不管是告警关联性分析，还是业务影响性分析，其分析的数据重点都在于网络数据与网络数据之间的关系，或者网络数据与业务数据之间的关系，这就决定了数据建模的另一个关键点是对象间关系的管理。

    对于综合网管系统，其数据主要来源有两种：从资源管理系统中获取业务数据、从专业网管系统中获取网络数据。由于接入 设备多种多样，涉及了各种专业和各种厂商，导致了综合网管系统内的配置数据呈现出数据量大、种类多、信息模型差异大的特点；而在综合网管系统和资源管理系统之间存在的大批量的实时/准实时数据交互，也同时要求数据建模能适应这种频繁的数据交换活动。

    3、数据管理方案介绍

    根据以上说明，我们对电信综合网管系统中的数据管理有了一个初步的认识。下面，就从对象建模和关系建模两个方面简述一种数据管理方案。

    3.1对象建模过程

    网络环境下资源的表示是网络管理 的 一个关键问题，目前一般采用所谓“被管对象”（ManagedObject，可缩写为MO）来表示网络中的资源。ISO认为，被管对象是从OSI角度所看 的OSI环境下的资源，这些资源可以通过使用OSI管理协议而被管理。另一个关键概念是所谓的“管理信息库’ （ManagementInformation Base，可缩写为MIB），MIB是被管对象的一个概念上的集合，所有相关的网络管理客体信息都放在此信息库中。

    在专业网管系统中，其北向接口的网络协议一般为：SNMP（简单网络管理协议）、CORBA（公共对象请求代理架构）、CMIP（公共管理信息协议）或者 厂家私有协议；其中，SNMP和CMIP均是基于MO和MIB概念对网络进行管理。对于综合网管系统，由于大量数据均是从专业网管中采集得到的，使用MO 和MIB的概念进行数据管理也是顺理成章的事情。

    根据抽象层次不同，我们可以将MO分为被管对象类（ManagedObjectClass，可缩写为MOC）和被管对象实例（ManagedObject Instance，可缩写为MOI），分别描述数据类和数据实例。

    3.1.1被管对象类（MOC）

    被管对象类（MOC）用来描述资源对象的类别，比如：机框、插盘、端口、交换机、传输 网元、阿尔卡特传输网元、EWSD交换机，每个被管对象类（MOC）都用唯一标识（OID）来确定。

    被管对象类（MOC）之间存在着继承关系，所有的MOC会组织成一个具有继承关系的层次结构。例如：对于“华为传输网元”和“阿尔卡特传输网元”，我们可以将其抽象为“传输网元”，继而将其抽象为“网元”，如图2所示。

    图2  管理对象类（MOC）之间的继承关系

    一组存在包含关系的被管对象类（MOC）组合在一起，就可以形成一棵管理信息树（MIB树）。在综合网管系统中，管理信息树（MIB树）的构成并不是任意 的，而是与特定厂商、特定设备相关的，由特定设备本身决定。当综合网管接入设备时，可以根据设备的具体情况构造出一棵特定的管理信息树（MIB树）。如： 对于华为传输网元，其管理信息树（MIB树）结构形式可能为“系统—网元—机架—机框—插板—端口—时隙”，如图3所示；但对于阿尔卡特传输网元，其管理 信息树（MIB树）结构形式则可能与之不同，表现为“系统—网元—机框—插板—端口—时隙”。

    系统提供被管对象类模板对被管对象类（MOC）进行定义，描述类的继承关系以及属性定义，对于行为、动作和通知则不做约定。

    3.1.2被管对象实例（MOI）

    被管对象实例（MOI）表示在所要管理的网络中，需要网管系统管理的各种实际存在的资源对象在网管系统中的“映像”，代表一个实际存在的资源对象，是MOC的实例化。

 

    图3  华为传输设备的管理信息树（MIB树）

    按照管理对象类（MOC）的管理信息树（MIB树）定义，相应的被管对象实例（MOI）对象之间也会存在包含关系，并组合形成一棵更大的被管对象实例 （MOI）包含树。被管对象实例（MOI）的名称即是按照该包含树的结构描述的，这种描述与它在实际设备中的所表现出来的层次相一致。例如：

    /System=sampleSystem1/Subnetwork=sampleSubnetwork3/NE=sampleNE3

    即表示一个网元，它是属于系统（System）为“sampleSystem1”，位于子网（Subnetwork）“sampleSubnetwork3”中，网元（NE）标识为“SampleNE3”。

    虽然本数据管理方案借鉴了SNMP和CMIP的建模思想，却根据综合网管系统的实际情况，并结合SNMP和CMIP在使用中遇到的问题，对其信息模型增加或者简化了部分内容，形成了一个特有的解决方案 。该解决方案与SNMP、CMIP信息模型的比较如表1所示。

    表1  信息模型比较

    如表1所示，本数据管理方案结合了SNMP和CMIP模型的优点，采用了相对简单的面向对象建模方式，避免了SNMP数据抽象度不够导致MIB混乱无法实现通用管理、而CMIP又过于复杂难于实现的缺点，比较适合综合网管系统的使用。

    3.2关系建模过程

    对于综合网管系统，对象间的关系管理则是更重要的内容。在综合网管系统中，存在“承载关系”、“拓扑关系”、“包含关系”等多种数据关系，对这些关系如何 定义、抽象和管理，一直是网络管理信息模型没有涉及的部分。在本数据管理方案中，我们将这些“善变的关系”也进行了对象建模，并作为管理的重点内容。

    被管对象间的复杂关系，我们通过定义各种“关系类”来抽象，用具体的“关系实例”来确定；某种被管对象（实例）与其他被管对象（实例）具有哪种关系，可以 通过设置这种被管对象（实例）进入和退出某种关系类，来实现关系的管理。用户可通过设置这些关系，实现从不同的视角来观察对象。

    资源对象间的关系，可以通过类和实例两个层面来定义：

    第一层面，关系类（RelationshipClass，可缩写为RC），用于描述具体被管对象类（MOC）间的关系。例如描述“交换网元”类与“中继” 类之间存在“交换网元-中继的拓扑关系”，还可以描述“传输网元”与“段”之间存在“传输网元-段的拓扑关系”。

    关系类之间也会存在继承关系，如“交换网元-中继的拓扑关系”和“传输网元-段的拓扑关系”，我们可以将其进一步抽象成为“拓扑关系”。对“拓扑关系”， 我们可以描述为：三元关系、参与对象为一个线对象和两个端点对象、线对象的两端为两个端点对象；对于“交换网元-中继的拓扑关系”，则除了以上定义之外， 还需增加描述：线对象为中继（实例）、点对象为交换网元（实例）。

    通过关系类（RC）之间的继承，使对象间关系在不同层次上都有相应的类对其进行描述，满足了系统在不同场合对关系进行分析的需要。例如：“拓扑关系”类，就可以在绘制全网拓扑图时使用；而在绘制交换网络拓扑图时，则会使用到“交换网元-中继的拓扑关系”类。

    第二层面，关系实例（RelationshipInstance，可缩写为RI），用于确定具体被管对象实例（MOI）之间的关系，是关系类（RC）的实 例化。例如沈阳市名为NE666交换网元与NE888交换网元之间存在直达中继I666-888，则这3个实体之间构成一个“交换网元-中继的拓扑关 系”，是一条拓扑关系的实例。

    通过类与实例两个层面的描述，从抽象到具体，逐步将对象间关系描述清楚，这就是我们所建立的关系模型；该模型实现了资源对象与对象间关系的分离管理，将对象间的耦合度降到了最低，也有利于关系的维护和管理。

    在具体系统实现时，我们可以将MO与RO分别建表存储，从物理上实现对象与关系的分离管理，仅依靠表之间的外键实现关联。

    下面，我们以一种状态计算引擎为例，说明这种方案在业务影响分析中的应用。该状态计算引擎描述如下：

    （1）对每一个需要监控的被管对象实例（MOI）建立一个状态对象（StateElement，可缩写为SE），用来记录当前被管对象实例（MOI）的状态。

    （2）状态对象（SE）之间存在一种特殊的关系：源-目的（source-target）关系，这种关系被用来进行状态传播。一旦源（source）对象 的状态取值发生变化时，目的（target）对象的状态就会被重新计算。如果该目的（target）对象是另一个状态对象（SE）的源（Source）， 那么这种传播过程将会继续下去，直至不存在源-目的（Source-target）关系。

    （3）状态的计算是通过状态对象（SE）内部一个特定的状态计算公式进行的，该公式可与被管对象实例（MOI）所属的被管对象类（MOC）相关。当状态对 象（SE）接收到一个告警事件或者与其相关的源（source）对象状态发生变化时，该公式才会被触发。此时，状态对象（SE）的状态取值会根据计算出的 结果进行修改，并有可能触发上送一个新的告警事件。

    （4）告警上送和状态传播的具体过程如图4所示。

    图4  告警上送和状态传播

    根据我们对于被管对象类（MOC）与被管对象实例（MOI）的定义，我们可以抽象出以下几类状态对象（SE）：客户（customer）、业务 （servicePackage）、通路（trail）、通道终结点（sncendpoint）、永久虚电路（pvc），并在他们之间建立源-目的 （source-target）关系。

    如图5所示，当通道终结点（sncendpoint）实体有告警产生时，状态就会按照箭头所示进行传播，最后影响到特定的业务、特定的客户。根据这种原则，我们可以建立更加复杂的传播关系，处理更加复杂的业务分析问题。

    图5  状态传播示例

    4、该方案的优点

    从系统建设来说，使用该数据管理方案恰好满足了综合网管系统中数据量大、种类多、信息模型差异大的特点，大大增强了系统的扩展性和对不同设备接入的包容性，同时也有利于与资源系统的数据交换。

    （1）以新设备接入为例，无论该设备网管采用何种网络协议进行管理，我们均可将其纳入本数据模型中，而不仅限于支持SNMP的设备。当系统需要接入一种新 设备时，用户只需重新定义一套被管对象类（MOC）、一棵该设备相关的MIB树和若干关系类，即可以在不影响系统框架，不影响原有功能，且不修改系统代码 的情况下，接入该新设备；系统需要新开发的内容只仅仅限定在接入模块部分，即插即用成为可能。

 

    （2）在现阶段，资源管理系统一般是个静态的系统，数据来源主要靠人工录入和核对，很容易造成数据缺失和错误；资源管理系统如果想要得到真实的网络信息， 从综合网管系统中获取是一个比较好的方案。而开放这个数据接口，就需要对综合网管系统和资源管理系统的数据模型进行转换。资源管理系统是一个面向业务的系 统，其网络数据也是按照面向业务的原则进行建模，摈弃了与设备有关的物理细节，只关心设备的共有特性；而这就要求综合网管系统中的数据模型也能满足设备无 关的条件。在本数据方案中，通过具有继承关系的被管对象类（MOC）、关系类（RC）的定义，抽取了数据的共性，使得综合网管系统的模型与资源管理系统的 模型之间的转换相对容易，模型映射不再成为频繁数据交换的性能瓶颈。

    从系统应用来讲，该数据管理方案迎合了综合网管系统的主要功能需求，为系统的功能实现提供了有力的数据保证。

    （1）告警精确定位：通过被管对象实例（MOI）的命名，可以唯一确定一个网络上的资源对象。仅仅从名称上，我们就可以很清晰地获取到该对象的全部定位信 息，直接与网元吐出的告警报告中的相关信息相匹配，从而很容易地实现了告警的精确定位，也为之后的根告警关联分析以及业务影响分析提供了数据基础。

    （2）根告警关联性分析：跨域的告警关联分析一直是行业内的难题，也只有真正做到了这一点，才能有效降低告警数量，提高维护人员工作效率。使用本数据管理方案，通过分析对象间的关系和告警原始信息，系统就可以实现在海量告警中准确找到故障根源。例如：当一个SDH 网元的光端口上出现RIS告警的时候，系统可以根据网元之间的连接关系，如果发现其上行网元的相应光端口也同时出现了LOS告警，我们就可以认为该网元出现了掉点重大故障，而并非仅为简单的网管失去连接告警，就提示用户对此故障进行重点关注，尽快解决。

    （3）告警业务影响分析：由于本数据管理方案屏蔽了各厂商设备数据之间的差异性，抽取出了共有特性，并将对象间关系也作为一种特殊对象看待，因此业务影响性分析也变得相对简单，并大大提高了功能的扩展性。

    综上所述，本方案迎合了电信综合网管系统的特点，能够适应当前电信企业的复杂网络情况和管理需求，实现起来也相对简单，是一种值得推广的实用的数据管理方案。