從網管系統到網管云:論網管集約化的建設思路

李 洪，渠 凱，周文紅，伍思源，申文俊

（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系統建設的模式和思路上也需要互聯網應用化。

當然云計算不是萬能的，現在也還是模式的問題，落實到具體的系統建設，網管云還有很多技術問題需要解決，海量數據的處理和性能的提升仍是需要面對的難題。但從互聯網技術發展的歷程上看，技術革新是不可逆轉的，只要積極擁抱這樣的變革，未來一定會取得回報。