鐵通省級IP城域網網管建設及關鍵問題研究

陳 煉

陳 煉:中國鐵通集團廣東分公司 工程師 510080 廣州

1 IP城域網網管問題

鐵通省級IP城域網的管理范圍，一般包括集團骨干網絡節(jié)點、省干網絡、省網NDC數據中心以及下轄若干個地市城域網，管理設備數千臺，約百萬數量級的寬帶接入用戶，覆蓋了路由器、BRAS、交換機、DSLAM、OLT、ONU等設備類型，涉及到思科、華為、中興、烽火、港灣等廠商的數十種型號。網內大量的設備對日常運營維護管理能力提出了較高的要求。就管理手段而言，部分設備廠家提供了專業(yè)網管 (EMS)，但缺乏統(tǒng)一高效的監(jiān)控和管理手段，直接影響了鐵通省級IP城域網的維護水平和運行質量，具體問題如下。

1．故障診斷時間長。網管人員需要同時監(jiān)控多個網管的告警信息。當網絡出現故障時，維護人員需要在多個網管系統(tǒng)之間切換，甚至可能還要登錄到網元設備上判斷故障點，故障排查時間長。

2．數據格式不統(tǒng)一。各個廠家專業(yè)網管提供的數據格式和內容不同，側重點也不同，有的側重于設備配置和告警監(jiān)控，有的側重于網元設備資源和性能管理。

3．缺少面向全網的歷史統(tǒng)計性數據。各廠家的專業(yè)網管往往在設備配置管理方面非常完備，但缺少對整個網絡的歷史統(tǒng)計，不能給運維人員提供前瞻性建議。

隨著寬帶接入市場的蓬勃發(fā)展，用戶對網絡服務質量的要求不斷提高，急需一套完整的IP城域網網絡管理系統(tǒng)，以實現網絡資源管理、故障監(jiān)控、性能監(jiān)測與統(tǒng)計分析等功能。為此，廣東鐵通進行了互聯(lián)網省級綜合網管建設工程。

2 綜合網管建設

根據廣東鐵通的網絡及業(yè)務需求，采用省集中方式統(tǒng)一規(guī)劃建設IP城域網網絡管理平臺，實現面向全省IP城域網網絡的監(jiān)控和管理。目前已實現對城域網核心層、匯聚層和接入層設備的監(jiān)控和管理。

2.1 功能要求

根據鐵通IP城域網日常管理工作內容，將系統(tǒng)功能要求分為告警與性能監(jiān)控、資源與拓撲管理、安全管理、報表管理等四大部分。

1．告警與性能監(jiān)控。為了統(tǒng)一監(jiān)控網絡的運行質量，IP城域網網管需要對設備的告警信息進行采集、預處理，需要支持確認、恢復、升級、重定義、查詢統(tǒng)計等功能，監(jiān)控被管設備的性能信息，包括網元設備的CPU利用率、內存利用率、硬盤利用率、環(huán)境參數等，并對性能數據支持門限告警、查詢統(tǒng)計等功能。流量是IP網絡維護的重要指標，采集設備端口的流量數據得到帶寬利用率，以圖形化的方式進行展示和監(jiān)控。

2．資源與拓撲管理。了解IP網絡的資源狀態(tài)，支持對被管設備的資源與拓撲管理，包括資源和設備配置信息采集、維護、查詢統(tǒng)計等功能，以及對被管設備之間的拓撲連接關系進行發(fā)現、瀏覽、增刪和查改等操作。

3．安全管理。根據鐵通IP城域網的維護體系組織情況，支持對網絡設備的分權、分域管理，即要求系統(tǒng)能夠根據用戶名及其相關聯(lián)的角色，對用戶的操作進行功能范圍和區(qū)域范圍控制，同時記錄操作日志以備日后審計。

4．報表管理。被管理網絡的各項統(tǒng)計信息需要通過報表進行統(tǒng)計呈現，支持常見告警、性能、資源等方面的統(tǒng)計報表，同時支持特殊管理需求的自定義報表。

2.2 系統(tǒng)設計

IP城域網綜合網管系統(tǒng)采用分布式、模塊化、組件化設計，符合NGOSS構架，充分保證系統(tǒng)的開放、靈活、先進性。廣東鐵通IP城域網網管分為數據采集層、數據匯聚層、業(yè)務處理層和UI呈現層等4層。

1．數據采集層。完成接口協(xié)議轉換，根據設備的接口類型，將不同設備的數據和消息轉換為統(tǒng)一的內部格式，傳到數據匯聚層進行處理。該層支持基于SNMP、TL1、Telnet、SYSLOG等網管協(xié)議的數據采集。

2．數據匯聚層。采用統(tǒng)一的管理對象模型來描述網絡中的管理對象和事件消息。統(tǒng)一的管理對象模型能夠實現跨廠家、跨設備類型的統(tǒng)一描述，使復雜的異構網絡以統(tǒng)一的面貌呈現給網管操作者。

3．業(yè)務處理層。該層基于統(tǒng)一的管理對象模型，實現了多種網絡管理業(yè)務，包括資源管理、拓撲管理、性能管理、報表、安全管理等業(yè)務，并為UI呈現層提供遠程業(yè)務調用接口，實現了業(yè)務邏輯集中處理。

4．UI呈現層。采用Java Swing技術，生成IP城域網網管的數據呈現和操作的界面。

2.3 關鍵技術

2.3.1 告警采集、預處理與呈現

告警管理是IP城域網綜合網管的重要功能，通過對網內多種異構設備的告警采集、預處理和統(tǒng)一呈現，維護人員可以在單獨界面上，以統(tǒng)一的方式監(jiān)控網內所有設備的告警。IP城域網綜合網管實現了基于SNMP TRAP、TL1、SYSLOG等多種接口協(xié)議的告警采集。SNMP TRAP主要用于對路由器、交換機等設備的告警采集，通過配置設備，將 SNMP TRAP的目標地址設置為網管告警采集機，即可接收設備的告警;TL1協(xié)議是基于文本格式的網管接口協(xié)議，在IP綜合網管中主要用于面向xPON設備專業(yè)網管(EMS)的信息采集;SYSLOG協(xié)議主要用于對防火墻等設備的告警采集。

為了實現告警的統(tǒng)一預處理與呈現，IP城域網網管中提出了告警服務器的概念 (Alarm Server)。Alarm Server負責管理全局告警列表，主要功能包括:告警消息同資源信息的關聯(lián)、告警預處理、更新告警全局列表、向客戶端發(fā)送告警消息等。多個告警采集機將收到的告警信息格式化之后，發(fā)至預先設定的Alarm Server，由Alarm Server進行相關處理之后，再發(fā)送到各個訂閱了告警消息的客戶端呈現。

系統(tǒng)采用上述的告警處理結構，統(tǒng)一了告警處理流程，便于后續(xù)添加新的告警源;增加告警相關新功能時只要修改Alarm Server即可，方便升級與部署;Alarm Server可以部署在多臺專用服務器上，實現了處理能力的線性擴展。

2.3.2 高效的性能指標采集

IP城域網綜合網管的重要功能是設備性能監(jiān)控和性能分析，要求網管實現大規(guī)模的性能指標采集，這也是綜合網管同設備廠家專業(yè)網管的重要區(qū)別之一。通常專業(yè)網管在性能指標方面只實現少量指標的測試功能，無法提供大規(guī)模、長時間、細粒度的性能指標采集。為了實現在較短的采集周期內(通常是5 min)，對大量的性能指標 (數十萬數量級)進行大規(guī)模采集，必須仔細考慮性能指標的采集、入庫的速度。

性能采集模塊的基本設計思路是建立性能采集任務表，由調度程序對任務表進行周期性掃描，獲得采集任務的基本信息。任務調度程序在相應的時間點啟動采集進程，進行指標采集和入庫。在廣東鐵通IP網管性能采集模塊的設計上，考慮了下面幾點。

1．數據庫連接池。主要用于解決數據入庫的性能瓶頸。采集機在拿到數據之后，需要將數據寫入數據庫進行后續(xù)分析，通常需要:①打開數據庫連接，②寫入數據，③關閉數據庫連接3個步驟。實際測試發(fā)現，在每次寫入的性能數據規(guī)模較小(數十個字節(jié))情況下，步驟①③占用了大量的時間。解決這一問題有2個方案:第一，增加步驟②中的數據寫入的規(guī)模，使步驟①③在入庫過程中占用時間比例縮小;第二，建立數據庫連接池，在每個采集機為性能采集保持若干個數據庫連接，省去步驟①③。通過分析發(fā)現，在現有的性能數據入庫場景中，多次小規(guī)模寫入和一次大規(guī)模寫入的單條性能數據平均時間開銷是類似的，并且增加數據緩存后會較大地增加設計復雜度。所以，采用了方案二建立數據庫連接池，其規(guī)模需要通過試驗確定。

2．多線程并發(fā)處理。SNMP采集的基本過程如圖1所示。其中，較大的時間開銷是設備響應時間，即從SNMP管理程序發(fā)出請求消息，到收到響應消息之間占用的時間。考慮利用多線程技術，在同一個采集進程中同時發(fā)起對若干個設備多個性能指標的采集。由于線程間的調度會占用一部分處理器開銷，過大的并發(fā)線程數量可能會導致整體效率下降，所以并不是并發(fā)線程的數量越大，采集的效率就會越高。由于網絡因素和網絡設備SNMP代理程序的性能情況并不確定，性能采集程序的最佳并發(fā)線程個數需要通過試驗來確定。

圖1 SNMP采集過程

3 總結

廣東鐵通IP城域網綜合網管的建設，將歸屬廣東鐵通的鐵通集團骨干網廣東節(jié)點、省干網絡、省網NDC數據中心，以及下轄地市城域網全部納入了統(tǒng)一管理。通過在網絡運維中使用該網管，網絡管理人員可以快速、準確、完整地了解網絡運行的狀態(tài)和相關信息，對整個網絡進行及時的監(jiān)測、調整和優(yōu)化，實現了提高網絡的運營效率、寬帶服務品質，降低網絡管理成本，提高網絡維護效率，保證廣東鐵通IP城域網能夠提供穩(wěn)定、高效的互聯(lián)網接入服務。

［1］ TMF 053 v4．0．The NGOSS Technology Neutral Architecture(TNA)［S］．2004．

［2］ J．Case，et al，RFC 1157．A Simple Network Management Protocol(SNMP) ［M］．1990．

［3］ Telcordia，GR-831-CORE，Operations Application Messages-Language For Operations Application Messages［M］，1996．