CN1968148A - 用于实现应用软件系统与主机资源综合监管的网管系统 - Google Patents

Abstract

本发明提供了一种网管系统，用于综合监管软件系统及其所部署主机，包括：设备接入模块，用于创建映射软件系统及其所部署主机的公共信息模型，公共信息模型包括：逻辑网元层，其所包括的各个逻辑网元用于映射软件系统的各个部分，具有可供查询的标准接口；物理网元层，其所包括的各个物理网元用于映射各个部分所部署的主机，具有可供查询的标准接口；以及模块服务层，用于映射逻辑网元与物理网元之间的对应关系；网管系统还包括：业务网管子系统，用于通过逻辑网元层的标准接口来监管软件系统；以及IP网管子系统，用于通过物理网元层的标准接口来监管主机。本发明还提供了一种网管方法。

Description

用于实现应用软件系统与主机资源 综合监管的网管系统

技术领域

本发明涉及通信领域，更具体而言，涉及用于实现应用软件系统与主机资源综合监管的网管系统。

背景技术

电信级网络中分布着数量众多种类各异的硬件设备和规模不一的应用软件系统，它们在电信管理网(TMN)的网元管理层(Network Element Management Layer)被抽象为网络单元(NetworkElement，简称网元)，其中各型网络设备、服务器等硬件设备通常被称为为物理网元(Physical Network Element，缩写为PNE)，位于IP层次；而各种应用软件系统则被抽象为逻辑网元(Logic NetworkElement，缩写为LNE)。逻辑网元一般由若干模块(Module)组成，每个模块又包含若干运行在服务器(主机)之上的进程实体。这些模块、进程实体可部署于一个或多台服务器(主机)之上，并且多个逻辑网元之间可共享这些资源。

图1示出了根据相关技术的一个简单的网络管理模型。图中的NE可能是物理网元，也可能是逻辑网元。

在该网络管理模型中，逻辑网元的实际部署情况可划分为逻辑网元(LNE)、模块(Module)、进程实体(Process)及主机四个层次，按照从上至下的顺序，每一层都对自己的下一层存在依赖。根据依赖的传递性，最上层的逻辑网元存在对最下层的主机的依赖，而这些主机在电信管理网的网元管理层被抽象为物理网元，因此存在逻辑网元对于物理网元的依赖。图2示出了根据相关技术的逻辑网元部署的层次结构。

在图2中，这种依赖具体表现为，主机的运行状况及处理性能(如CPU是否过于繁忙、内存是否够用、硬盘是否有足够剩余空间等)会直接影响软件系统整体的运行状况，因此保障软件系统部署运行所在主机的可用性、可靠性和性能，是保障软件系统正常运行的基础之一，所以有必要把对主机、进程及应用软件系统的监控管理结合起来。

对于众多网络管理系统(Network Management System，以下简称NMS)的具体实现而言，一般是将主机及进程的管理纳入IP网管，而软件系统及其模块的管理则纳入与软件系统产品厂商紧密相关的业务网管，由这两类不同的网管系统分别进行监控管理。

业界对于主机本身的监管已经形成了一些较为成熟的工业标准及应用解决方案。根据RFC2790标准，定义了统一、公共的主机资源管理模型，确定了CPU、网络设备(网卡)、打印机、磁盘(硬盘、软盘、光盘等)、键盘、Modem、端口等硬件资源的管理接口；RFC1514标准则提供了存储实体(内存、虚拟内存、磁盘等等)的利用率的管理接口；各类型的主机一般都实现了以上标准中定义的内容，网管系统的实现者可以以较小的代价来实现主机监管功能。

下面将结合附图和实施例来说明相关技术中对应用软件系统和主机资源进行监管的网管解决方案。

图3示出了根据相关技术提供的一种网管系统模块划分方案。在该方案中，网管系统300模块划分如下：

软件系统、进程与主机由集成在一个大网管系统中的业务网管与IP网管子系统分别进行管理，保持一致的界面特性及用户操作习惯，共享相同的基础功能子系统(如告警、性能、数据采集等子系统)，仅满足最简单的界面集成。业务网管与IP网管子系统之间没有业务逻辑的关联性。

然而，由于软件系统与主机等设备分别由不同的网管子系统进行监控管理，导致这两个子系统间不共享相关的管理信息，功能也不互通，所以丢失了软件系统与主机之间的依赖信息，主机运行状态和性能对于软件系统的影响，系统本身无法直接表达出来，只能通过人工去发现及判别这种影响。

另外，由于这两个网管子系统实际上可能由不同的人员负责维护，所以导致这种影响无法被及时有效地发现出来，从而实际上无法有效缩短设备维护周期，及降低维护成本。

一个比较有代表性的例子：例如，某主机因为磁盘剩余空间不足而产生告警，但是负责软件系统的维护人员并不知道该告警的产生，直至磁盘完全占满而导致软件系统运行异常而产生告警，所以，维护人员在该软件系统告警产生之前无法预警，在告警产生之后也无法迅速定位其根源。

相关技术中还提供了另外一种网管解决方案。

根据该方案，针对部署于软件系统中的软件系统代理(Agent)模块进行定制开发，使之能够收集、存储所在主机的CPU占用率、内存使用率、磁盘使用情况等主机监控信息，并提供相应接口，使得网管侧在接入管理目标应用软件及业务模块的同时，也能够访问这些信息；同时，软件系统预定义一些主机相关的告警，软件系统代理收集并上报这些告警；业务网管子系统也针对主机监控接口进行开发，提供主机监控的管理界面。也就是说，业务和硬件资源节点的关联性由网元侧实现。

然而，该解决方案主要存在如下缺点：

(1)无法利用已经标准化且相对成熟的主机管理接口，受管软件系统需要自行实现主机信息的采集、存储及上报功能，增加了应用软件及业务模块的复杂度及开发难度；

(2)缺乏相应的行业标准，各受管软件系统提供的主机监管功能不一致，接口不兼容；

(3)网管系统开发者无法提供一个一致的主机监管模型，不得不为各种不同的受管软件系统定制相应的主机监管模型及界面，导致接入管理成本较高。

由以上描述可知，上述相关技术的解决方案都存在着各自的问题，因此，人们需要一种新的网管解决方案，能够解决上述相关技术中的问题。

发明内容

本发明旨在提供一种能够综合监管应用软件系统及其部署所在主机的解决方案，该方案解决了上述相关技术中存在的业务软件系统及业务模块的复杂度及开发难度大等问题。

根据本发明的一个方面，提供了一种网管系统，用于综合监管软件系统及其所部署主机，包括：设备接入模块，用于创建映射软件系统及其所部署主机的公共信息模型，公共信息模型包括：逻辑网元层，其所包括的各个逻辑网元用于映射软件系统的各个部分，具有可供查询的标准接口；物理网元层，其所包括的各个物理网元用于映射各个部分所部署的主机，具有可供查询的标准接口；以及模块服务层，用于映射逻辑网元与物理网元之间的对应关系；网管系统还包括：业务网管子系统，用于通过逻辑网元层的标准接口来监管软件系统；以及IP网管子系统，用于通过物理网元层的标准接口来监管主机。

在上述的网管系统中，设备接入模块，用于通过记录逻辑网元所部署主机的IP地址，并根据IP地址定位物理网元，在逻辑网元与物理网元之间创建关联，将关联信息存储在模块服务层中。

在上述的网管系统中，设备接入模块，用于通过主机IP地址查找与之相匹配的逻辑网元，并在逻辑网元与物理网元之间创建关联，将关联信息存储在模块服务层中。

在上述的网管系统中，业务网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、计费管理子系统、业务管理子系统、告警子系统、数据采集子系统；IP网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、告警子系统、数据采集子系统。

在上述的网管系统中，业务网管子系统和IP网管子系统均包括告警、性能管理、配置管理子系统，告警、性能管理、配置管理子系统都包含预处理模块，这些预处理模块用于查询存储在公共信息模型中的逻辑网元与物理网元的关联信息，使得子系统能够识别逻辑网元与物理网元之间的关系。

在上述的网管系统中，在主机发生硬件故障并发送告警后，IP网管子系统用于接收并处理该告警，IP网管子系统中的告警子系统的预处理模块根据存储在公共信息模型中的物理网元与逻辑网元的关联信息来查询哪些逻辑网元因此受到影响，并通知业务网管子系统进行相应处理，从而在业务网管子系统侧能够观察到已经发生在主机上的告警。

在上述的网管系统中，主机上发生的告警如果可能导致软件系统出现运行异常，业务网管子系统会发出预警，并通知业务维护人员采取措施。

在上述的网管系统中，在逻辑网元上创建监控物理网元运行状况的监视任务或故障检测任务后，性能管理子系统的预处理模块用于将相关参数发送给IP网管子系统，IP网管子系统用于根据这些参数采集物理网元的状态数据，并将已采集结果实时送到状态监控界面。

在上述的网管系统中，业务网管子系统和IP网管子系统是基于管理领域划分，二者区分为业务拓扑视图与主机拓扑视图。

根据本发明的另一方面，提供了一种网管方法，用于综合监管软件系统及其所部署主机，包括以下步骤：创建映射软件系统及其所部署主机的公共信息模型，公共信息模型包括：逻辑网元层，其所包括的各个逻辑网元用于映射软件系统的各个部分，具有可供查询的标准接口；物理网元层，其所包括的各个物理网元用于映射各个部分所部署的主机，具有可供查询的标准接口；以及模块服务层，用于映射逻辑网元与物理网元之间的对应关系；业务网管子系统通过逻辑网元层的标准接口来监管软件系统；以及IP网管子系统通过物理网元层的标准接口来监管主机。

在上述的网管方法中，创建公共信息模型中的物理网元层包括以下步骤：记录逻辑网元所部署主机的IP地址，并根据IP地址映射物理网元，然后在逻辑网元与物理网元之间创建关联，将关联信息存储在模块服务层中。

在上述的网管方法中，创建公共信息模型中的逻辑网元层包括以下步骤：通过主机IP地址查找与之相匹配的逻辑网元，并在逻辑网元与物理网元之间创建关联，将关联信息存储在模块服务层中。

在上述的网管方法中，业务网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、计费管理子系统、业务管理子系统、告警子系统、数据采集子系统；IP网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、告警子系统、数据采集子系统。

在上述的网管方法中，业务网管子系统和IP网管子系统均包括告警、性能管理、配置管理子系统，告警、性能管理、配置管理子系统都包含预处理模块，监管主机包括以下步骤：这些预处理模块查询存储在公共信息模型中的逻辑网元与物理网元的关联信息，使得子系统能够识别逻辑网元与物理网元之间的关系。

在上述的网管方法中，监管主机包括以下步骤：在主机发生硬件故障并发送告警后，IP网管子系统接收并处理该告警，IP网管子系统中的告警子系统的预处理模块根据存储在公共信息模型中的物理网元与逻辑网元的关联信息来查询哪些逻辑网元因此受到影响，并通知业务网管子系统进行相应处理，从而在业务网管子系统侧能够观察到已经发生在主机上的告警。

在上述的网管方法中，监管主机包括以下步骤：主机上发生的告警如果可能导致软件系统出现运行异常，业务网管子系统会发出预警，并通知业务维护人员采取措施。

在上述的网管方法中，监管主机包括以下步骤：在逻辑网元上创建监控物理网元运行状况的监视任务或故障检测任务后，性能管理子系统的预处理模块将相关参数发送给IP网管子系统，IP网管子系统根据这些参数采集物理网元的状态数据，并将已采集结果实时送到状态监控界面。

在上述的网管方法中，业务网管子系统和IP网管子系统是基于管理领域划分，二者区分为业务拓扑视图与主机拓扑视图。

从以上的描述中，可以看出，本发明充分利用主机监管的标准接口，不需要应用软件系统进行大规模适配性的开发，网管系统实现较为简单。

具体来说，本发明实现了如下技术效果：

通过在业务网管子系统中集成主机监管的功能以实现应用软件系统及其部署所在主机的综合监管后，可以有效降低因硬件故障导致的软件系统故障的产生率(通过及时预警)，并提升该类故障的排查效率，降低应用软件系统的维护成本，降低网管系统及应用软件系统提供商的总体开发成本。

网管系统不区分业务网管与IP网管子系统，仅区分不同的拓扑视图(业务拓扑视图与主机拓扑视图)，在完成应用软件系统接入后同时提供这些不同类型的视图，并根据软件模块部署的IP地址自动执行对于相关主机的监控。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1示出了根据相关技术的一个简单的网络管理模型；

图2示出了根据相关技术的逻辑网元部署的层次结构；

图3示出了根据相关技术提供的一种网管系统模块划分方案；

图4示出了根据本发明实施例的网管系统的方框图；

图5示出了根据本发明的一个实施例的网元管理信息模型；

图6示出了根据本发明的一个实施例的网元管理信息模型；

图7示出了根据本发明的一个实施例的网管系统；以及

图8示出了根据本发明实施例的网管方法的流程图。

具体实施方式

下面将参考附图并结合实施例，来详细说明本发明。

本发明提出，应用软件系统、主机仍然由集成在一个大网管系统中的业务网管与IP网管子系统分别进行管理，二者保持一致的界面特性及用户操作习惯，共享相同的基础功能模块(如告警、性能、数据采集等模块)，以数据集成为核心，同时满足界面集成与功能集成。应用软件系统与主机管理信息模型之间的数据集成基于IP地址实现。

在原有系统中增加一个专门的设备接入子系统，建立公共的信息模型，并在其他子系统增加一些预处理模块，从而将主机和应用在模型和各个关联功能上完整地关联起来。

图4示出了根据本发明实施例的网管系统的方框图。如图4所示，根据本发明实施例的网管系统400包括：

设备接入模块406，用于创建映射软件系统及其所部署主机的公共信息模型，公共信息模型包括：逻辑网元层，其所包括的各个逻辑网元用于映射软件系统的各个部分，具有可供查询的标准接口；物理网元层，其所包括的各个物理网元用于映射各个部分所部署的主机，具有可供查询的标准接口；以及模块服务层，用于映射逻辑网元与物理网元之间的对应关系；

业务网管子系统404，用于通过逻辑网元层的标准接口来监管软件系统；以及

IP网管子系统402，用于通过物理网元层的标准接口来监管主机。

可选地，设备接入模块406用于通过记录逻辑网元所部署主机的IP地址，并根据IP地址定位物理网元，在逻辑网元与物理网元之间创建关联，将关联信息存储在模块服务层中。

可选地，设备接入模块406用于通过主机IP地址查找与之相匹配的逻辑网元，并在逻辑网元与物理网元之间创建关联，将关联信息存储在模块服务层中。

可选地，业务网管子系统404包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、计费管理子系统、业务管理子系统、告警子系统、数据采集子系统；IP网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、告警子系统、数据采集子系统。

可选地，业务网管子系统404和IP网管子系统402均包括告警、性能管理、配置管理子系统，告警、性能管理、配置管理子系统都包含预处理模块，这些预处理模块用于查询存储在公共信息模型中的逻辑网元与物理网元的关联信息，使得子系统能够识别逻辑网元与物理网元之间的关系。

可选地，在主机发生硬件故障并发送告警后，IP网管子系统402用于接收并处理该告警，IP网管子系统402中的告警子系统的预处理模块根据存储在公共信息模型中的物理网元与逻辑网元的关联信息来查询哪些逻辑网元因此受到影响，并通知业务网管子系统进行相应处理，从而在业务网管子系统侧能够观察到已经发生在主机上的告警。

可选地，主机上发生的告警如果可能导致软件系统出现运行异常，业务网管子系统404会发出预警，并通知业务维护人员采取措施。

可选地，在逻辑网元上创建监控物理网元运行状况的监视任务或故障检测任务后，性能管理子系统的预处理模块用于将相关参数发送给IP网管子系统402，IP网管子系统402用于根据这些参数采集物理网元的状态数据，并将已采集结果实时送到状态监控界面。

可选地，业务网管子系统404和IP网管子系统402是基于管理领域划分，二者区分为业务拓扑视图与主机拓扑视图。

图8示出了根据本发明实施例的网管方法的流程图，其包括以下步骤：

步骤S802，创建映射软件系统及其所部署主机的公共信息模型，公共信息模型包括：逻辑网元层，其所包括的各个逻辑网元用于映射软件系统的各个部分，具有可供查询的标准接口；物理网元层，其所包括的各个物理网元用于映射各个部分所部署的主机，具有可供查询的标准接口；以及模块服务层，用于映射逻辑网元与物理网元之间的对应关系；

步骤S804，业务网管子系统通过逻辑网元层的标准接口来监管软件系统；以及

步骤S806，IP网管子系统通过物理网元层的标准接口来监管主机。

可选地，创建公共信息模型中的物理网元层包括以下步骤：记录逻辑网元所部署主机的IP地址，并根据IP地址映射物理网元，然后在逻辑网元与物理网元之间创建关联，将关联信息存储在模块服务层中。

可选地，创建公共信息模型中的逻辑网元层包括以下步骤：通过主机IP地址查找与之相匹配的逻辑网元，并在逻辑网元与物理网元之间创建关联，将关联信息存储在模块服务层中。

可选地，业务网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、计费管理子系统、业务管理子系统、告警子系统、数据采集子系统；IP网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、告警子系统、数据采集子系统。

可选地，业务网管子系统和IP网管子系统均包括告警、性能管理、配置管理子系统，告警、性能管理、配置管理子系统都包含预处理模块，监管主机包括以下步骤：这些预处理模块查询存储在公共信息模型中的逻辑网元与物理网元的关联信息，使得子系统能够识别逻辑网元与物理网元之间的关系。

可选地，监管主机包括以下步骤：在主机发生硬件故障并发送告警后，IP网管子系统接收并处理该告警，IP网管子系统中的告警子系统的预处理模块根据存储在公共信息模型中的物理网元与逻辑网元的关联信息来查询哪些逻辑网元因此受到影响，并通知业务网管子系统进行相应处理，从而在业务网管子系统侧能够观察到已经发生在主机上的告警。

可选地，监管主机包括以下步骤：主机上发生的告警如果可能导致软件系统出现运行异常，业务网管子系统会发出预警，并通知业务维护人员采取措施。

可选地，监管主机包括以下步骤：在逻辑网元上创建监控物理网元运行状况的监视任务或故障检测任务后，性能管理子系统的预处理模块将相关参数发送给IP网管子系统，IP网管子系统根据这些参数采集物理网元的状态数据，并将已采集结果实时送到状态监控界面。

可选地，业务网管子系统和IP网管子系统是基于管理领域划分，二者区分为业务拓扑视图与主机拓扑视图。

下面对相应的网元管理信息模型进行详细描述。

图5示出了根据本发明的一个实施例的网元管理信息模型。

如图5所示，网元管理信息模型分为四层：逻辑网元(LNE)/模块(Module)/服务(Service)/主机(Host)；其中LNE是应用软件系统的映射，Service是进程实体的映射；Module对象存储有包含该对象的网元对象标识(NEID)，每个Service对象都存储有包含该对象的模块标识(ModuleID)，同时Service对象也存储有该服务运行所在的主机IP地址。Host对象是主机资源的映射。

图6示出了根据本发明的一个实施例的网元管理信息模型。

对于部分结构不太复杂的应用软件系统而言，每个模块就是单独的一个进程实体。因此根据本发明的另一个实施例，如图6所示，网元管理信息模型也可以进行一定简化：Service层合并到Module层，则Module对象既存储有包含该对象的网元对象标识(NEID)，也存储了该Module运行所在主机的IP地址。

图7示出了根据本发明的一个实施例的网管系统。在该实施例中，应用软件系统及主机综合监管的基本流程如下：

A、应用软件系统的代理提供应用软件系统各部分的部署信息(包括所在主机的IP地址)；

B、对于主机的监管基于业界的工业标准接口进行；

C、在将应用软件系统接入业务网管子系统进行管理时，设备接入子系统从代理处查询应用软件系统各部分的部署信息并存储到公共模型中；

D、设备接入模块如果发现该应用软件系统部署所在的主机已经由IP网管接入，则在应用软件系统与主机抽象映射后的逻辑网元与物理网元间创建关系，标识逻辑网元对于物理网元的依赖，后续流程中各功能模块都会查询及使用这些关系进行一些关联操作；

E、主机发生硬件故障并发送告警后，IP网管子系统接收并处理该告警，由预处理模块通知业务网管子系统，某软件系统部署所在的某主机发生故障，业务网管子系统接收该通知后重置目标软件系统对应的逻辑网元的告警状态；

F、业务维护人员查询逻辑网元的告警状态时，可以观察到软件系统部署所在的主机上产生的硬件告警，如果某些硬件告警可能最终导致软件系统运行异常，则需要通知主机维护人员及时修复这些硬件告警；业务维护人员在对这些告警进行确认、清除操作时，相应的操作命令最终下发到相应的主机上；

G、业务维护人员在逻辑网元上创建监控主机运行状况的监视任务或故障检测任务后，性能管理预处理模块将相关参数发送给IP网管子系统，IP网管子系统再根据这些参数采集目标主机的状态数据，并将已采集结果实时送到状态监控界面；业务维护人员一旦发现目标主机运行异常，则通知IP业务维护人员及时处理以恢复目标主机的正常运行；

H、如果软件系统某模块产生了特定的告警，业务维护人员首先查询该模块部署的主机上是否产生了一些特定的告警，并确认这些告警是否会引发目标告警；如确认软件故障由主机硬件故障引发，则通知主机维护人员进行修复。

流程C与D对于应用软件系统等于相关主机设备接入网管的情况也一样适用，只是前者是根据应用软件系统模块部署所在主机IP来查询相关的物理网元，后者是通过主机IP来查询相关的逻辑网元。另外业务维护人员与主机维护人员可能是同一批人，以上流程对于此种情况也同样适用。

实现应用软件系统及其部署所在主机综合监管的网管系统，除去配置管理、故障管理、性能管理、安全管理等传统功能子系统外，还包括公共模型管理模块、故障管理预处理模块、性能管理预处理模块以及扩展的设备接入模块，其中公共模型管理模块负责存储及管理各类NE、Module及Service等对象以及它们之间的关系，故障管理预处理模块负责将主机(物理网元)上产生的告警关联到相应的逻辑网元上，性能管理预处理模块负责将主机(物理网元)上预设置的部分性能统计任务及监控任务关联到相应的逻辑网元上，扩展的设备接入模块则负责在设备接入的过程中发现及完成物理网元与逻辑网元之间的关联。

从以上的描述中，可以看出，本发明充分利用主机监管的标准接口，不需要应用软件系统进行大规模适配性的开发，网管系统实现较为简单。

具体来说，本发明实现了如下技术效果：

通过在业务网管子系统中集成主机监管的功能以实现应用软件系统及其部署所在主机的综合监管后，可以有效降低因硬件故障导致的软件系统故障的产生率(通过及时预警)，并提升该类故障的排查效率，降低应用软件系统的维护成本，降低网管系统及应用软件系统提供商的总体开发成本。

网管系统不区分业务网管与IP网管子系统，仅区分不同的拓扑视图(业务拓扑视图与主机拓扑视图)，在完成应用软件系统接入后同时提供这些不同类型的视图，并根据软件模块部署的IP地址自动执行对于相关主机的监控。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。应该明白，这些具体实施中的变化对于本领域的技术人员来说是显而易见的，不脱离本发明的精神保护范围。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

1.一种网管系统，用于综合监管软件系统及其所部署主机，其特征在于，包括：

设备接入模块，用于创建映射所述软件系统及其所部署主机的公共信息模型，所述公共信息模型包括：

逻辑网元层，其所包括的各个逻辑网元用于映射所述软件系统的各个部分，具有可供查询的标准接口；

物理网元层，其所包括的各个物理网元用于映射所述各个部分所部署的主机，具有可供查询的标准接口；以及

模块服务层，用于映射所述逻辑网元与所述物理网元之间的对应关系；

所述网管系统还包括：

业务网管子系统，用于通过所述逻辑网元层的标准接口来监管所述软件系统；以及

IP网管子系统，用于通过所述物理网元层的标准接口来监管所述主机。

2.根据权利要求1所述的网管系统，其特征在于，所述设备接入模块，用于通过记录所述逻辑网元所部署主机的IP地址，并根据所述IP地址定位所述物理网元，在所述逻辑网元与所述物理网元之间创建关联，将所述关联信息存储在所述模块服务层中。

3.根据权利要求1所述的网管系统，其特征在于，所述设备接入模块，用于通过主机IP地址查找与之相匹配的所述逻辑网元，并在所述逻辑网元与所述物理网元之间创建关联，将所述关联信息存储在所述模块服务层中。

4.根据权利要求1所述的网管系统，其特征在于，所述业务网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、计费管理子系统、业务管理子系统、告警子系统、数据采集子系统；所述IP网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、告警子系统、数据采集子系统。

5.根据权利要求1所述的网管系统，其特征在于，所述业务网管子系统和所述IP网管子系统均包括告警、性能管理、配置管理子系统，所述告警、性能管理、配置管理子系统都包含预处理模块，这些预处理模块用于查询存储在公共信息模型中的逻辑网元与物理网元的关联信息，使得所述子系统能够识别逻辑网元与物理网元之间的关系。

6.根据权利要求5所述的网管系统，其特征在于，在所述主机发生硬件故障并发送告警后，所述IP网管子系统用于接收并处理该告警，所述IP网管子系统中的告警子系统的预处理模块根据存储在公共信息模型中的物理网元与逻辑网元的关联信息来查询哪些逻辑网元因此受到影响，并通知业务网管子系统进行相应处理，从而在业务网管子系统侧能够观察到已经发生在主机上的告警。

7.根据权利要求6所述的网管系统，其特征在于，所述主机上发生的告警如果可能导致所述软件系统出现运行异常，业务网管子系统会发出预警，并通知业务维护人员采取措施。

8.根据权利要求5所述的网管系统，其特征在于，在逻辑网元上创建监控物理网元运行状况的监视任务或故障检测任务后，性能管理子系统的预处理模块用于将相关参数发送给所述IP网管子系统，所述IP网管子系统用于根据这些参数采集物理网元的状态数据，并将已采集结果实时送到状态监控界面。

9.根据权利要求1所述的网管系统，其特征在于，所述业务网管子系统和所述IP网管子系统是基于管理领域划分，二者区分为业务拓扑视图与主机拓扑视图。

10.一种网管方法，用于综合监管软件系统及其所部署主机，其特征在于，包括以下步骤：

创建映射所述软件系统及其所部署主机的公共信息模型，所述公共信息模型包括：

逻辑网元层，其所包括的各个逻辑网元用于映射所述软件系统的各个部分，具有可供查询的标准接口；

物理网元层，其所包括的各个物理网元用于映射所述各个部分所部署的主机，具有可供查询的标准接口；以及

模块服务层，用于映射所述逻辑网元与所述物理网元之间的对应关系；

业务网管子系统通过所述逻辑网元层的标准接口来监管所述软件系统；以及

IP网管子系统通过所述物理网元层的标准接口来监管所述主机。

11.根据权利要求10所述的网管方法，其特征在于，创建所述公共信息模型中的物理网元层包括以下步骤：记录所述逻辑网元所部署主机的IP地址，并根据所述IP地址映射所述物理网元，然后在所述逻辑网元与所述物理网元之间创建关联，将所述关联信息存储在所述模块服务层中。

12.根据权利要求10所述的网管方法，其特征在于，创建所述公共信息模型中的逻辑网元层包括以下步骤：通过主机IP地址查找与之相匹配的所述逻辑网元，并在所述逻辑网元与所述物理网元之间创建关联，将所述关联信息存储在所述模块服务层中。

13.根据权利要求10所述的网管方法，其特征在于，所述业务网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、计费管理子系统、业务管理子系统、告警子系统、数据采集子系统；所述IP网管子系统包括以下至少之一：配置管理子系统、安全管理子系统、故障管理子系统、性能管理子系统、告警子系统、数据采集子系统。

14.根据权利要求10所述的网管方法，其特征在于，所述业务网管子系统和所述IP网管子系统均包括告警、性能管理、配置管理子系统，所述告警、性能管理、配置管理子系统都包含预处理模块，监管所述主机包括以下步骤：这些预处理模块查询存储在公共信息模型中的逻辑网元与物理网元的关联信息，使得所述子系统能够识别逻辑网元与物理网元之间的关系。

15.根据权利要求14所述的网管方法，其特征在于，监管所述主机包括以下步骤：在所述主机发生硬件故障并发送告警后，所述IP网管子系统接收并处理该告警，所述IP网管子系统中的告警子系统的预处理模块根据存储在公共信息模型中的物理网元与逻辑网元的关联信息来查询哪些逻辑网元因此受到影响，并通知业务网管子系统进行相应处理，从而在业务网管子系统侧能够观察到已经发生在主机上的告警。

16.根据权利要求15所述的网管方法，其特征在于，监管所述主机包括以下步骤：所述主机上发生的告警如果可能导致所述软件系统出现运行异常，业务网管子系统会发出预警，并通知业务维护人员采取措施。

17.根据权利要求14所述的网管方法，其特征在于，监管所述主机包括以下步骤：在逻辑网元上创建监控物理网元运行状况的监视任务或故障检测任务后，性能管理子系统的预处理模块将相关参数发送给所述IP网管子系统，所述IP网管子系统根据这些参数采集物理网元的状态数据，并将已采集结果实时送到状态监控界面。

18.根据权利要求10所述的网管方法，其特征在于，所述业务网管子系统和所述IP网管子系统是基于管理领域划分，二者区分为业务拓扑视图与主机拓扑视图。

Images