从网管系统到网管云:论网管集约化的建设思路

李 洪，渠 凯，周文红，伍思源，申文俊

（1.中国电信集团公司网络运行维护事业部 北京100032；2.中通服软件科技有限公司 上海200127）

1 网管的发展

电信网络在过去很长一段时间一直处于持续发展的阶段。在这个阶段中，由于市场竞争，电信运营商一直重点关注市场的拓展和用户的增长。因此在IT支撑系统的建设中，一直关注的是与业务发展有关的BSS域系统以及与业务开通有关的OSS域系统，在与服务保障有关的系统建设方面相对落后。特别是在网管领域，长期以来一直是以厂商网管建设为主，缺乏在专业和综合网管方面的投入，比如中国电信集团公司（以下简称中国电信）在2005-2006年完成综合告警系统建设后，就再也没有相关的举动，导致在网络运营方面前后端能力严重脱节，不得不为支撑业务运营增加临时的工具类系统，故而如激活系统、服务能力前置系统等应运而生。

电信运营商在经历了网络和客户的大规模发展之后，意识到竞争格局已从单纯的客户竞争转向了全方位的服务竞争，而体现电信运营商的服务能力和服务差异化之处在于后端网络的运营能力。因此自动化、智能化将成为电信运营商在后端不断追求的目标。

2 网管集约化——综合网管

实现网管自动化、智能化，首先要实现基于网管信息的完整和准确。但正如前文所述，长久以来在网管领域的投入偏废，导致各级网管系统的建设参差不齐，系统极其零散。在系统内的数据质量都难以保证的情况下，系统间数据的一致性就更难保证，更不要说是端到端的全程数据了。而在现行计算模式下，自动化和智能化严重依赖于数据的完备，这一点在综合告警系统的实施过程中体现得非常突出，所有的故障关联分析、故障定位都离不开资源数据的支持，而数据的准确性也决定了自动化、智能化的程度和效果。

归根结底，目前掣肘网管自动化、智能化发展的最大因素是在网管领域没有一个能够完整覆盖所有电信智能网络、实现端到端的全网统一管理的集中管理系统。

因此，实现智能网管的第一步是实现网管的集约化，即综合网管系统。

3 集约化综合网管的建设模式

全网集约化模式下的综合网管将面临众多现实的问题。传统意义上，网管分为网元（NE）、厂商网管（EMS）、专业网管（NMS）和综合网管（INMS）4个层次。随着网络与网络技术的发展，网元数量增长迅速，随之增长的是厂商网管的数量，且存在接口众多、技术复杂、规范不统一、在建设期没有规范要求的问题，有些厂商网管甚至不提供或要有偿提供北向接口；而在专业网管层面，由于长期的投入不足，专业网管的建设大多落后，没有专业网管，完全依赖厂商网管的情况普遍存在。

在这样的情况下建设集约化网管，一直以来在其建设模式上存在争议，尤其在技术日趋成熟的今天，条件已经具备，系统如何落地成为一个现实问题。

3.1 集中系统

传统上，按照我国电信运营商多级管理的模式，可以分级建立集中的综合网管，从网元→厂商网管→专业网管→省级综合网管→集团综合网管，将网管的能力进行逐级汇集，建立物理集中的综合网管，如图1所示。

图1 集中系统模式的综合网管

分级集中适合于垂直管理的体系。在这种体系下，上级网管通过下级网管行使网管职能，上级网管的能力严重依赖下级网管的能力：任何一个层级的网管能力都是不可缺失的，因为任何一个层级的网管能力不足或缺失，都将影响上级网管对下级网管的管理；同时，同级网管间没有互联的通道，相互之间的沟通都依赖于上级网管，所以一定程度上还存在信息“孤岛”，能力没有形成真正的共享。

集中系统的模式在网管系统建设比较完善、能够制定相对完整的网管北向接口规范且系统逐级收敛的情况下才可能实现。否则，集中系统的建设将直接面对繁多的多专业多厂商接口，对这些接口的适应和接口的功能及可靠性将成为制约集中系统发展的关键，这也是长期以来困扰综合网管发展的最大因素。

综合网管的提出已有很长时间了，但一直以来都停留在集中系统建设的传统模式上。很多厂商和运营商在这条道路上已经走了很多弯路，也碰过很多钉子，特别是目前网管建设相对落后，要按照集中模式逐级建立完备的网管体系，仅补齐中间缺失的环节，就需耗费大量的人力、物力，而未来网络的发展变化愈加频繁，新技术、新网络愈加不断出现，要网管逐级适应这些新技术、新网络，很难满足市场快速变化的需求。

3.2 多系统互联

基于ESB（enterprise service bus，企业服务总线）的SOA（service oriented architecture，面向服务的体系结构）集成架构体系为多系统互联提供了基础。在这种模式下，各级网管以SOA规范对现有网管进行改造或重新构建，也就是经过SOA治理的过程后，各系统向ESB暴露封装好的、符合规范的服务，通过ESB将服务进行集成和整合。多系统互联的综合网管架构如图2所示。

图2 多系统互联的综合网管架构

采用ESB进行互联，首先需要对现有系统进行改造，即SOA治理的过程。SOA要求遵循服务封装、服务松耦合、服务契约、服务抽象、服务的重用性、服务的可组合性、服务自治、服务无状态、服务的可被发现性等原则进行分层。

SOA体系架构如图3所示。按照SOA架构的要求，各级网管将其网管能力封装成规范的服务并注册在ESB上。综合网管应用通过ESB访问注册的网管服务，实现集中管理。

通过ESB进行多网管系统互联的方式，很好地解决了系统间信息的传递和服务调用问题，实现了上级网管和下级网管之间的互动。通过ESB，网管能力得以共享，使得全网集中管理成为可能。

但是以系统形式互联在全网规模下也同样存在很多问题，介绍如下。

·该方式主要基于将单个网管作为独立的系统来看待这一基础。ESB作为SOA集成架构平台，主要用于系统间互联，以服务方式进行集成。对于体系和功能架构相对一致的网管系统是否需要ESB来集成，值得商榷。

·基层网管数量众多，若以其直接接入ESB，则完成SOA治理的成本巨大，而且具有大量老旧系统，实施难度和风险巨大。

·ESB除完成服务注册、管理、路由、组装等基本功能外，还在系统间引入了中介处理环节，进行审计、对账、安全等第三方仲裁功能，对于网管这样以同步操作为主（可以不需要仲裁）、实时性要求非常高、数据交换频繁的系统，ESB很可能成为性能瓶颈。

3.3 云化

随着互联网技术的发展，特别是海量数据应用在互联网企业的实践，云计算的概念越来越符合IT系统发展的趋势。以云化实现运营商IT系统集约化的条件也日渐成熟。

网管域系统主要有以下3个特点。

图3 SOA体系架构

·不管是厂商网管、专业网管还是综合网管，在功能域上都是完成TMF定义的FCAPS五大功能，因此一定意义上，各级网管系统的功能是近似的，也可以是对等的。

·网管的数量依赖于网络的复杂度和规模，具备不确定性，可任意扩展；对于全网来说，网管系统的数量是海量的。

·网管是自管理的。对于自己管理的范围，网管可以不依赖于其他系统而独立进行管理。

以上都具备云计算的基本特征，说明网管系统云化具备一定的基础。

在讨论网管系统云化前，先介绍下比较流行的云计算平台Hadoop的基本架构，如图4所示。

图4 云计算平台Hadoop的基本架构

Hadoop的分布式文件系统由命名节点（name node）和数据节点（data node）构成，数据节点负责提供数据存取服务。命名节点负责数据节点的管理，不参与数据存取。数据节点是对等的，各自负责一部分数据的存取；也是可以任意扩展，所以整个体系具备很好的可伸缩性。

对照Hadoop的结构，可以将全网网管作为一个分布式系统来考虑，而不是把每个网管都作为单独的系统看待。每个对等的网管都可以作为一个网管能力节点，负责提供一部分网元的网管能力。于是只要建立全网的网管能力管理节点，就可以将全网的网管统一管理起来，进而具备全网网元的管理能力。

实际上，可以运用SOA的观点，将网管按照“平台+应用”的模式进行建设，全网集约化的网管可以形成如图5所示的两朵“云”，提供基础网管服务的网管平台形成网管云，各级网管应用可以基于网管云形成应用云。

不管是厂商网管还是专业网管或各级的综合网管，都是网管云中的一个服务节点，不同的只是各自提供的能力和管理范围不同。

图5 全网集约化的网管

这样，引入一个新的网管就如同增加一个云数据节点一样简单。云架构具备的良好的可伸缩性可以很好地支持海量网管服务节点的引入，使得网管云的服务能力可以无限地扩展。而应用云相比网管云来说，可以更不拘于既定的管理范围和形式，任何一个应用都可以使用网管云提供的全网网管服务能力，而不管它在什么位置。

采用云化实施网管集约化有以下3个明显的好处。

·相比ESB，对网管系统的SOA改造是必须的，完成基本服务的封装，但采用“平台+应用”方式实施的云架构体系对网管平台的改造要求更简单，由于在基础架构上支持高度的可伸缩性，因此集成更加简便、灵活，易于实施。

·网管云趋向于扁平化结构，应用直接访问服务的提供者而不需要有第三方参与，这样在服务访问过程中减少了中间环节和不必要的处理，避免产生更多的性能瓶颈。

·体系架构的简便也带来了对应用要求门槛的降低，使得应用可以关注不同的维度，依不同的维度构建创新应用，如更关注端到端管理的综合应用、更倾向于技术深度的专业应用等，这样从体系上更有利于应用层面的微创新。

4 网管云技术

从技术上看，网管系统具有与其他系统不同的特点。（1）网管功能可分为如图6所示的三大域。

图6 网管功能三大域

·网管Ⅰ:网管的数据来自于网络设备，形成数据采集域或网元同步域。

·网管Ⅱ：对采集数据进行管理，形成数据管理域。

·网管Ⅲ：对网元设备进行操作，形成网元配置域。

其中，网元同步域和网元配置域涉及网元的接口，这是网管系统与其他系统最大的不同之处。

（2）网元同步具有海量的事件信息上传，需要应对数据风暴这样的极端情况。

（3）网元配置以同步调用为主，需要保证高可靠性和实时性。

因此，在采用云技术上，要针对网管系统的特点进行适当的选择。

4.1 Hadoop+HBase

Hadoop是目前比较常见的开源分布式系统基础框架，用户可以在不了解分布式底层细节的情况下开发分布式程序，充分利用集群的威力高速运算和存储。Hadoop具有高可靠性、高扩展性、高效性和高容错性，可以在低成本平台上实现可伸缩的分布式计算能力。Hadoop由分布式文件系统（HDFS）和分布式计算框架（MapReduce）组成。

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC服务器上搭建起大规模结构化存储集群。

Hadoop+HBase系统架构如图7所示。

图7 Hadoop+HBase系统架构

在集约化网管的模式下，集中进行事件处理，将面对海量的事件信息，包括告警、性能和日志信息。以往对于大量的原始信息，通常没有办法长期保存，主要是先进行处理加工，对处理加工后的信息进行管理。这在一定程度上丢失了部分网络的信息，同时无法针对大范围的数据进行趋势分析和统计，而使用Hadoop+HBase，提供了一条具有可伸缩性、低成本的海量数据解决思路。Hadoop+HBase可以广泛地应用在告警、性能以及日志信息的存储和处理上。

4.2 分布式网管基础架构

从上面的讨论看，服务总线的引入会在系统性能上带来瓶颈，因此为适应网管系统的特点，需要采用分布式系统架构，演进过程如图8所示。

图8 分布式架构的演进

针对网管云的建设，并吸取过去网管系统统一协议的经验教训，集约式网管应该采用一种轻量级的分布式系统架构来进行部署。这样的轻量级分布式网管基础构件包括：命名节点、基础服务节点（base node）（其中分为日志服务（审计）、安全服务（鉴权）和事件服务（告警/性能））、服务节点（service node）、应用节点（App node）。

所谓轻量级,就是基础架构不在协议层保证负载均衡、不在协议层保证事务一致性、不在协议层保证数据完整性，依赖于各自的应用解决相应的问题。这在一定程度上降低了基础架构对应用的要求，应用的开发难度降低。

服务节点首先让命名节点注册服务信息，应用在调用服务之前向命名节点查询服务访问节点，之后应用直接向服务节点发起服务调用，如图9所示，服务节点和命名节点就构成网管云。

分布式网管的基本过程包括服务注册、服务查询、服务调用，如图10所示。

5 结束语

根据笔者长期从事OSS建设的经验教训，按照网管云方式建立的扁平化综合网管系统是最适合网管特点的系统建设模式，也是最符合OSS未来发展趋势的。从“物理统一”的集中建设模式到“逻辑统一”的云化建设模式，关键是将所有网管的集合作为一个大系统看待，而不是系统的集成，这一点是观念上的一大变革，是对传统模式的挑战。但电信运营商在“去电信化”和互联网企业化的过程中，在IT系统建设的模式和思路上也需要互联网应用化。

当然云计算不是万能的，现在也还是模式的问题，落实到具体的系统建设，网管云还有很多技术问题需要解决，海量数据的处理和性能的提升仍是需要面对的难题。但从互联网技术发展的历程上看，技术革新是不可逆转的，只要积极拥抱这样的变革，未来一定会取得回报。