一种实现分布式网络管理的方法及系统

摘要

本发明公开了一种分布式网络管理系统，包括至少两台网管服务器，所述网管服务器通过通信链路相互连接，在所述网管服务器中分别部署网管处理模块，还包括：调度模块，用于调度部署在所有网管服务器中的各网管处理模块的服务进程；将不同网管处理模块提供的服务安排在不同的进程中，将可能导致处理瓶颈的同一类处理模块提供的服务分离在不同的进程中，以避免或减少处理瓶颈。另一种分布式网络管理系统，包括至少两台网管服务器以及服务访问协调器，以使得各网管服务可在各网管服务器之间切换。还提供了相应实现方法。根据本发明可以对超大规模的网络进行有效管理，使网管系统扩容更平滑，节省了硬件成本。

说明书

技术领域

本发明涉及网络通信技术领域，尤其涉及网络管理技术，具体地说，涉及一种实现分布式网络管理的方法及系统。

背景技术

网络管理系统用于收集网络中各种网元设备的工作参数、工作状态信息，显示给管理操作人员，并根据操作员的指令或根据对上述数据的处理结果向网络中的服务器等设备发出控制指令(改变工作状态或工作参数)；监视指令的执行结果，保证网络设备按照网络管理系统的要求进行工作，网络管理系统主要包括五大功能模块：配置管理、性能管理、故障管理、计费管理和安全管理。

当前，通常采用集中式网络管理系统，该网络管理系统的操作维护中心(OMC，Operation & Maintenance Center)的服务通常都部署在一台硬件服务器中。OMC服务可以按照功能分为采集和业务处理。采集主要完成从网元抽取数据并经过处理转换形成OMC格式的数据并保存到数据库或者文件。业务处理主要完成用户的请求，根据用户的输入参数去获取系统中的信息并把经过处理后的返回给客户的这么一个过程。

由于一台服务器的硬件资源(如：CPU、内存)的限制，所以一套OMC的处理能力是有限的，随着网络的规模急剧膨胀以及网络结构的复杂程度不断增加，产生了许多传统的集中式网络管理系统所不曾遇到的问题。

发明人在研究中发现，随着电信行业及网络的发展，用户数据的爆炸式增长，网络中的网络节点，网元，也成倍增长。对于一个大规模网络采用集中式的管理会给网络造成不必要的负担，例如，导致网管服务器出现处理瓶颈，集中式OMC难以管理较大规模网络中的所有节点。目前，OMC在管理大规模网络方面面临的主要问题，如，如何提供充分的管理能力满足以超大网络的管理需要？如何保证OMC系统的平滑扩容，减少对现网业务的影响？如何保护用户投资成本，提高硬件重复利用率，减少建设成本？如何保障集中管理的优势，提高人员效率，提高运维整体质量，节约运维成本？等等。

现有技术中对大规模网络管理，比较流行的解决方案有：

(1)不断升级，更新服务器配置，谋求更大的管理能力。

如图1所示，当现有服务器的管理能力不足，就通过使用更高端服务器替换现有服务器的方式来谋求OMC的更大的管理能力。如OMC采用的服务器由起初的Netra240，更新成V890，再升级到后来的E4900。利用该方案集中管理的优势可得到保障，但是，每次扩容均会对现网业务造成中断影响，不能利用已有硬件设备，导致前期投资成本得不到保护；而且单服务器的管理能力有限，要么面临再次替换；要么没有更好的硬件替换。

(2)实施多套OMC分管策略。

如图2所示，当现有服务器的管理能力不足，就通过增加硬件组成多套OMC系统以谋求更大的管理能力。

利用该方案，虽然每次扩容现网业务不会受到影响，前期的硬件投资能得到保护，通过不停增加硬件管理能力也可以持续加强，但是，多套OMC同时维护，丧失集中管理优势，信息分散，无法全局监控。而且需要更多运营商的操作维护人员，人力成本较高。

(3)多套OMC+集中策略。

如图3所示，该方案是在前述方案(2)的基础上增加了一台服务器充当集中操作维护的代理。

利用该方案，每次扩容现网业务不会受到影响，前期的硬件投资能得到保护。管理能力通过不断增加OMC扩充，但与NMC性能有关联。

具备一定的集中管理特性，OMC只能实现很少部分的OMC功能，或者实际功能只是单个OMC的功能的简单代理。

发明内容

有鉴于此，本发明提供一种实现分布式网络管理的方法及系统，以提供充分的管理能力满足超大网络的管理需要，保证OMC系统的平滑扩容，减少对现网业务的影响，提高硬件重复利用率，保护用户投资成本，并保障集中管理的优势，节约运维成本。

本发明提供的一种分布式网络管理系统，包括至少两台设置在网络的不同区域的网管服务器，所述网管服务器通过通信链路相互连接，在所述网管服务器中分别部署网管处理模块，还包括：

调度模块，用于调度部署在所有网管服务器中的各网管处理模块的服务进程；将不同网管处理模块提供的服务安排在不同的进程中，将可能导致处理瓶颈的同一类处理模块提供的服务分离在不同的进程中，以避免或减少处理瓶颈；

其中，所述网管处理模块至少包括以下模块中之一：

性能管理模块、配置管理模块、故障管理模块、计费管理模块以及安全管理模块。

本发明提供的另一种分布式网络管理系统，包括至少两台位于不同网络区域的网管服务器，所述至少两台网管服务器中分别部署有网管处理模块；该系统还包括：

服务访问协调器，用于实现图形用户接口GUI接入管理并屏蔽服务位置差异性，以使得所述各网管处理模块提供的服务可在所述各网管服务器之间切换；

所述网管处理模块至少包括以下模块中之一：

性能管理模块、配置管理模块、故障管理模块、计费管理模块以及安全管理模块。

本发明提供的一种实现分布式网络管理的方法，在网管系统中设置至少两台网管服务器，该方法包括：

将各网管处理模块部署到所述至少两台网管服务器中；

将不同的网管处理模块提供的服务设置在不同的进程；

将导致处理瓶颈的同一类处理模块提供的服务分离到不同的进程中。

本发明提供的一种实现分布式网络管理的方法，分别在至少两台网管服务器中部署网管处理模块，该方法还包括将所述各网管处理模块提供的服务在所述各网管服务器之间切换的步骤：

将网管处理模块提供的服务从一台服务器中的进程迁移到该服务器的不同进程或另一台服务器的进程中；

将业务服务进程从一台服务器迁移到另一台服务器。

从本发明提供的技术方案中可知，分布式网络管理方案可以通过多台服务器以及每个服务器挂一个阵列或者使用集中存储方式，可以解决单套服务器的瓶颈，这些网管服务器设置在网络的不同区域中，使OMC能管理的网元随着服务器数量的增加而不断增加，增加OMC的管理能力，以支撑超大规模网络的管理。

另外，本发明实施例提供的分布式网络管理系统采用多台网管服务器组成网管系统可以管理超大规模的网络。由于分布式方案中各服务器的地位是对等的，如果存在Master和Slave之分的情况，其各Slave的地位是对等的，可以增加服务器以及存储资源，平滑增强一套OMC的管理能力，实现OMC的平滑扩容。相对于多套OMC来说，分布式方案相当于把多套OMC的硬件组合成一套OMC，用户只需要管理和维护一套OMC，降低了用户的管理成本。省去了再次北向对接一套独立的OMC等操作，简化了工程实施，降低了扩容的复杂度以及工程实施和测试的时间。分布式方案的扩容过程不涉及硬件替换，系统中已有硬件可以继续使用，扩容过程不需要替换现网硬件，从而保护硬件资源的投资，节省了硬件成本。单套OMC集中管理，运营商只需要面向一套OMC就可以实现对网络资源的管理，从而节省了管理成本以及工程维护成本。

附图说明

图1为现有技术中网络管理系统采用硬件升级方式的示意图；

图2为现有技术中网络管理系统采用多套OMC扩容的示意图；

图3为现有技术中网络管理系统采用多套OMC扩容及集中策略的示意图；

图4为本发明实施例提供的一种分布式网络管理系统的架构示意图；

图5为本发明实施例中分布式进程部署方式示意图；

图6为本发明实施例中另一种分布式进程部署方式示意图；

图7为本发明实施例中另一种分布式客户端接入访问过程示意图；

图8为本发明另一实施例中分布式网络管理系统的架构示意图；

图9为本发明又一实施例中分布式网络管理系统的架构示意图；

图10为本发明实施例中另一种分布式网络管理系统的架构示意图；

图11为本发明实施例中又一种分布式网络管理系统的架构示意图。

具体实施方式

针对大规模网络管理，有必要将管理工作分散到整个系统中进行分布处理，再将处理结果汇总。在这样的环境中会有多个管理者存在，网络管理工作也应按照一定的管理结构划分给各个管理站。这种管理结构可以是一种能够反映网络联结关系的结构，也可以是一种反映等级管理关系的结构，甚至可以是一种反映分布应用的结构。通过按管理员的意图或按照采用相同管理政策的原则将一些被管理对象分组归并，可以简化按照管理结构为不同的管理站划分管理责任的工作。

因此，对一个大规模的网络的管理采用分布式管理更具优势。

本发明提供的分布式网络管理系统中采用多台网管服务器，使网络管理系统能管理的网元随着服务器数量的增加而不断增加，可以管理超大规模的网络。扩容过程仅需要增加服务器和存储容量，使网络管理系统扩容更平滑，简化了工程实施。

为使本发明的原理、特性和优点更加清楚，下面结合具体实施例对本发明进行详细描述。

本发明实施例提供的分布式网络管理系统中包括多台网管服务器，根据网络拓扑结构以及业务情况将这些网管服务器设置在网络的不同区域中，将可能导致处理瓶颈的网管处理模块部署到不同的网管服务器，并对所有网管处理模块提供的服务进程进行调度管理。以避免或减少出现处理瓶颈。

可能导致处理瓶颈的网管处理模块包括：数据采集模块、性能管理模块、配置管理模块、故障管理模块、计费管理模块以及安全管理模块。

从处理层次上看，数据采集模块可能成为处理瓶颈，数据采集模块由于要进行较多转换和计算，其处理过程也可能是一个瓶颈。数据采集模块要做协议转换，要把网元的数据转换成网管系统可以理解的格式，还要对数据进行分析等操作。

从业务角度看，性能模块可能成为瓶颈，由于性能数据量大且具有周期性，每个周期都会上报一定量的数据，每个周期产生的数据量都非常巨大。

由于分布式管理系统中管理的网元比单台服务器管理的网元更多，配置管理模块和故障管理模块在网元上升到一定数量以后，也可能成为处理瓶颈。分布式网管处理方案也要处理由于网元数量上限的增加而导致的其他瓶颈问题，因此将配置管理模块和故障管理模块分布出去。

实施例一

参照图4，本发明实施例提供的一种分布式网络管理系统，设置有四台网管服务器，当然根据需要可配置更多服务器，所述四台网管服务器中分别部署不同的网管处理模块，如性能管理模块、配置管理模块、故障管理模块、计费管理模块以及安全管理模块。

本发明提供的分布式网络管理系统中的各网管服务器统一调度，协同工作，在此，将网管服务器中之一作为主网管服务器，其上部署有公共配置文件及公共管理模块，其他网管服务器为从网管服务器，所述从网管服务器上设置有网管处理模块。例如，在本发明实施例提供的分布式网络管理系统中有四台网管服务器，其中一台网管服务器作为主机(Master)，其他三台网管服务器作为从机(Slave1，Slave2，Slave3)。Master服务器承担控制并协调其他Slave服务器的职责；在Master服务器上部署了一些公共服务，如：命名服务、性能服务、告警服务、配置服务等，以及所有公共配置文件都放置在Master服务器上；

Slave服务器主要是分担处理负荷，部署导致处理瓶颈的处理模块，如性能管理模块、数据采集模块、配置管理模块、故障管理模块。当Master服务器的一些公共服务已经出现处理瓶颈，可以将一些公共业务服务以及业务处理单独部署到一台Slave服务器上。

本发明实施例的分布式网络管理系统中设置有调度单元，用于调度部署在所有网管服务器中的各网管处理模块的服务进程；具体地，将不同网管处理模块提供的服务安排在不同的进程中，将可能导致处理瓶颈的同一类处理模块提供的服务分离在不同的进程中，以避免或减少处理瓶颈。

具体地，该调度单元在计算处理上的划分为两个维度，一个维度就是按照处理业务分类，不同的业务处理模块放到不同的进程中；另一个维度是同一类业务由于处理瓶颈，按照一定的原则将服务处理分离到不同的进程中，也就是服务处理的多进程方式。利用分布式处理的特性和优势，以避免或减少出现处理瓶颈。

该调度单元支持两种类型的迁移，一种是将具体负责网元采集的模块从一台服务器中的采集进程迁移到另一台服务器的采集进程中。另一种是将业务服务进程，如：配置管理和故障管理服务，从一台服务器迁移到另一台服务器。后一种情况，多是用于从Master服务器迁移到Slave服务器。

由于一个采集进程中运行有多个网元采集模块，每个采集模块对应一个网元，这些采集模块可以在同一台服务器中的采集进程之间自由迁移，由于涉及到持久数据的迁移以及服务器访问信息的更改，如：访问IP地址的更改，所以在不同服务器上的采集进程之间迁移采集模块，需要额外的操作支持。这些额外的操作主要是用于把采集模块的持久信息从一台服务器迁移到另一台服务器以及调整采集模块的访问信息，也就是其他模块要与该采集模块通信时，其连接信息需要做调整。业务进程的迁移主要也是迁移其持久数据信息以及访问信息。

该调度单元可独立设置，也可设在其中一个网管服务器内，但通常设置在Master服务器，GUI只识别Master服务器。

本实施例的分布式网络管理系统中为各服务器配备有数据库及存储单元，分别用于管理各网管服务器上的数据。

存储单元可根据具体情况采用适合的存储介质，如本实施例中采用的是磁盘阵列，所述每台服务器单独连接一个磁盘阵列用于分别保存各服务器上的数据。

本实施例的分布式网络管理系统中还设置有命名服务模块，用于标识提供服务的网管服务器，以屏蔽各服务的位置差异性。

所述命名服务模块独立部署在其中一台网管服务器；或

在每台网管服务器都部署所述命名服务功能模块，以使客户端可访问任意一台网管服务器。

本实施例的分布式网络管理系统配置有多台服务器，为了使GUI配置简单，需要屏蔽服务位置的差异性。通过命名服务来屏蔽服务位置的差异性。GUI只需要认识命名服务所在的服务器就可以了，从而屏蔽了各个服务的位置差异性。后续服务器数量的增减以及服务在各个服务器之间的迁移，都不会影响GUI的接入。

分布式网管安装程序界面支持用户把不同的采集服务分布到不同的服务器上，也支持把不同的业务服务，如：配置管理和故障管理服务，部署到不同的服务器上。

安装程序把客户的部署设置情况形成配置文件，并存放到Master服务器上。全局服务监控程序根据该配置文件中的部署情况信息在不同的服务器上启动不同的进程。全局服务监控程序的主程序运行在Master上，各个Slave上运行有其代理，代理负责执行全局服务监控程序的指令，如：启动服务、停止服务、报告服务运行异常等。

具体地，参照图5，每个Slave服务器上除了部署采集模块，还部署有性能管理模块及数据库。每个Slave服务器上的性能数据库存储该Slave服务器上的采集模块收集的性能数据。如前所述可采用多数据库设计，在此不再赘述。

如图6所示，当Master服务器上的服务资源存在处理瓶颈时，可以将一些服务单独放到一台Slave服务器上，以减轻Master服务器的处理压力。下面给出故障模块和配置模块从Master服务器迁移到Slave服务器的过程。

Slave服务器多到一定数量以后，服务需要的硬件资源会越来越多，Master服务器的处理会成为瓶颈。在本发明提供的分布式网管处理具体方案中，可将故障管理模块和配置管理模块等部署到一台Slave服务器上。

当然，在具体实施过程中，可以不区分Master和Slave，所有服务器都具有同等地位。根据具体情况，在各网管服务器中根据需要配置相应的网管处理模块：性能管理模块、数据采集模块、配置管理模块、故障管理模块、计费管理模块以及安全管理模块，并对这些网管处理模块进行统一协调管理。

在一个系统中允许存在多个性能数据库，在分布式网络管理系统的处理节点(可以是Master也可以是Slave)上，如果该节点上配置有数据采集模块，那么该节点就会部署性能数据库。

另外，可选择SAN等存储方案，并选择适合SAN存储方案的数据库，这种情况下可不采用多性能数据库。

本发明实施例中实现分布式网络管理的方法，在网管系统中设置四台网管服务器，该方法包括：

根据网络拓扑结构以及业务情况，将各网管处理模块部署到所述四台网管服务器中；具体地，将可能导致处理瓶颈的网管处理模块，如数据采集模块、性能管理模块、配置管理模块、故障管理模块、计费管理模块以及安全管理模块等，分别部署到所述各网管服务器，参照图中在主网管服务器，其上部署有公共配置文件及公共管理模块，其他从服务器上配置数据采集模块、性能管理模块、配置管理模块、故障管理模块，当然也可在其中的从服务器上配置一个或多个管理模块。

调度部署在所有网管服务器中的各网管处理模块的服务进程：

将不同的网管处理模块提供的服务设置在不同的进程，将导致处理瓶颈的同一类处理模块提供的服务分离到不同的进程中。

本发明实施例中，可根据需要增加网管服务器及存储空间，可对系统进行平滑扩容，扩容的基本步骤如下：

步骤S01：新增加硬件，包括新增加的服务器以及对应的阵列。

步骤S02：初始化新增加的硬件，并在上面安装OMC软件。

步骤S03：把新增加的服务器连接到OMC所在的网络。

步骤S04：在Master服务器上配置新增加的服务器的相关信息，如：网络访问地址信息，需要运行的服务器信息等。通过这些信息，Master就可以对新增加的服务器进行管理。

步骤S05：通过命令方式或者其他触发方式，如：GUI界面等，触发Master对新增加服务器的管理，Master负责启动和管理新增加服务器上相关的OMC服务。

如果新增加的服务器中的进程是采集服务，采集服务与其他业务服务之间没有依赖，所以新增加服务的过程对其他服务没有影响。如果新增加的服务器中集成的是业务服务，业务服务需要向其他服务器迁移过来，则受影响的服务只会局限于需要迁移的服务。迁移服务过程是在服务器添加成功以后执行的。

本发明实施例中，客户端通过图形用户接口GUI使用命名服务屏蔽各个业务服务的位置差异性。

分布式网络管理系统中设置有命名服务模块，用于标识提供服务的网管服务器，以屏蔽个服务的位置差异性。

假设命名服务部署在Master服务器上。命名服务的部署方式可以多种多样：可以独立部署在其中一台服务器，如：部署在Master服务器上或者一台Slave服务器上；也可以在每个机器上都部署有命名服务，这样客户端可以任意选择一台服务器作为接入。

本发明提供的分布式网管方案中，使用CORBA通信机制中的命名服务来屏蔽服务的位置差异性。通过向CORBA的命名服务注册服务，实现了服务位置的通报，其他服务可以从位置服务中获取到注册服务的访问信息。本实施例可使用CORBA的命名服务机制实现服务位置透明性，以方便服务的开发、部署以及客户的连接。也可以使用其他技术方案来实现服务位置透明性，如：ICE、EJB等相关技术。采用其他技术实现服务位置透明性，属于公知技术，在此不再描述。

下面以命名服务部署在Master服务器为例进行说明。

参照图7，假设客户端(GUI)要访问故障服务，且故障服务是部署在Slave服务器上的。

为了便于描述，图中只给出存在两台服务器的情况，一台作为Master服务器，一台作为Slave服务器。

客户端(GUI)访问步骤如下：

步骤S11：客户端(GUI)向Master服务器的命名服务请求故障服务所在的服务器。

步骤S12：客户端(GUI)获取到故障服务所在的位置Slave服务器上故障服务的访问地址。

步骤S13：客户端(GUI)向故障服务所在的服务器发起请求。

步骤S14：故障服务向客户端GUI返回相应结果。

通过以上步骤，客户端(GUI)不需要知道各个服务的部署位置，屏蔽了服务的位置差异性，简化了客户端(GUI)的访问信息的配置。

实施例二

本实施例与前述实施例一基本相同，不同之处在于：不采用多数据库系统，而是采用集中数据存储，如：采用SAN存储方案，并使用一个单独的数据库系统实例。

参照图8，采用独立的阵列和数据库系统实例，其主要目的是为了解决集中IO的处理瓶颈问题。如果采用合适的数据库技术以及类似SAN存储技术，集中IO处理瓶颈将不再存在。此时，建议采用集中存储并使用单套数据库系统。如果数据库系统支持多数据库实例，那么单套数据库系统中可以根据需要划分成多个数据库实例。如：在一个Sybase的ASE数据库系统中，可以根据需要划分成多个数据库(database)。

上面的连线主要表达了服务器与阵列之间的数据流。服务器之间的网络联系与图4中所示一致，即服务器独立阵列，且服务器重要性有区别。

数据库服务器(Database Server)与阵列连接，主要目的是管理阵列中数据库的数据。其他服务器(Master以及各个Slave)与阵列连接，主要目的是存储系统在运行过程中的数据，如：服务配置数据和运行过程数据等。

为了减少服务器与阵列连接的连线，可以在阵列和服务器之间增加交换层，如：光纤交换机。

为了提供可靠性，可以部署两个存储交换设备，做成双平面。

集中的存储使数据利于使用和集中管理。如：利于利用数据库机制实现数据的关联查询，利于多个数据之间的对比，利于集中备份和恢复，利于集中扩容等。

同样可以通过增加服务器以及存储空间方式来增加一套OMC的管理能力。使用该实施例，前一个实施例的功能并没有减少或者削弱。

为了提供可靠性，可以部署两个存储交换设备，做成双平面。如图9所示，在所述数据存储单元与所述各网管服务器之间设置存储交换装置，用于实现所述数据存储单元与所述各网管服务器之间以及网管服务器之间的数据交换。

实施例三

与前面的实施例不同之处在于：各服务器之间的地位没有差别。各服务器之间不再区分主Master和从Slave。服务器只是运行服务的一个平台。因此，服务可以根据需要，如：负荷原因以及硬件故障原因等，在各个服务器之间自由迁移和移动。服务具体运行在哪台服务器上是不固定的。客户端要访问这些服务，必须有一个实体告知这些服务的访问地址，这个实体就是服务访问协调器。

服务访问协调器主要管理各个服务的位置信息，管理服务位置变化，并接受客户(Client)对服务的位置查询。客户包括GUI客户端和其他服务，这些服务不仅对外提供服务，还访问其他服务。服务访问协调器与命名服务的职责基本一致。如果客户端不进行持久化服务访问信息(服务引用信息)，则可以使用命名服务替代，如果要持久化服务访问信息，则需要具备访问信息变更通知的服务访问协调器。

下面以GUI客户端访问服务为例介绍服务访问协调器功能，客户访问服务的过程与此相同在此不再赘述。

参照图10，GUI客户端访问服务器时，可以任意选择一个服务器作为接入点。每个服务器上都部署有服务访问协调器。服务访问协调器的主要目的是完成GUI客户端接入管理并屏蔽服务位置差异性。

当GUI客户端需要访问服务时，GUI客户端向服务访问协调器获取服务的位置信息；服务访问协调器返回需要的服务的位置信息给所述GUI客户端，所述GUI客户端根据获得的地址访问服务。

如果GUI客户端持久化了服务的访问信息，GUI要负责更服务访问信息，如：重启GUI客户端以后或者服务访问失败以后，重新获取一遍服务访问信息；接收服务访问协调器的服务访问信息变更通知等。

参照图11，服务访问协调器可以单独部署到一台服务器。

服务访问协调器单独部署到一套服务器上，使GUI客户端是需要识别服务协调器所在的服务器的访问地址，不再需要知道实际服务的服务器有多台。

与前述实施例2中一样，可在服务器与阵列之间设置存储交换设备。

本实施例中，不区分服务器的重要性，服务可以在各个服务器之间切换，例如，各网管处理模块提供的服务在所述各网管服务器之间切换是按照下述原则进行：

将不同网管处理模块提供的服务安排在不同的进程中，将可能导致处理瓶颈的同一类处理模块提供的服务分离在不同的进程中，这样达到以避免或减少处理瓶颈的目的。

可以更合理分配物理资源，并支持N+M方式的容灾方案。

同样可以通过增加服务器以及存储空间方式来增加网络管理系统的管理能力。使用该实施例，前一个实施例的功能并没有减少或者削弱。

综上所述，本发明实施例提供的分布式网络管理系统中采用多台网管服务器组成一操作维护中心OMC，使OMC能管理的网元随着服务器数量的增加而不断增加，可以管理超大规模的网络。扩容过程仅需要增加服务器和存储，使扩容更平滑，简化了工程实施，省去了再次北向对接一套独立的OMC等操作，降低了扩容的复杂度以及工程实施和测试的时间。扩容过程不需要替换现有硬件，节省了硬件成本。单套OMC集中管理，运营商只需要面向一套OMC就可以实现对网络资源的管理，从而节省了管理成本以及工程维护成本。

上述实施例是用于说明和解释本发明的原理的。显然，本发明的具体实施方式不限于此。对于本领域技术人员而言，在不脱离本发明的实质和范围的前提下进行的各种变更和修改均涵盖在本发明的保护范围之内。因此，本发明的保护范围由权利要求确定。