張鐵


[摘要]針對傳統有線電視網絡存在網絡兼容性差、功能單一以及無法遠程管理等問題,本文提出了一種新的網管代理系統架構設計方法,能夠解決對有線電視網絡系統的遠程集中管理。經測試,網管代理系統的平均響應時間為0.5秒左右,能夠滿足網絡管理的時效性。
[關鍵詞]有線電視網絡 網管代理 時效性
0引言
隨著有線電視基礎設施的不斷建設和業務結構復雜性越來越高,提供相應服務的硬件設備數量也在不斷增加,只靠人為去管理如此龐大的網絡設備資源,無法對網絡中出現的突發事件做出快速準確的響應,從而在很大程度上降低了用戶的滿意度。目前在有線電視基礎網絡和設備管理中面臨的問題較多,比如當網絡出現故障后,傳統的管理模式響應速度慢,使得網絡整體的穩定性降低,客戶服務質量下降。
網絡管理是對網絡中包括軟件、硬件和人力的綜合、使用以及協調,以實現對網絡資源的監督、組合和控制。隨著有線電視網絡技術的快速發展及業務規模的不斷擴大,建立一個科學有效的網管系統,實現對所有有線電視網絡設備的集中管理,提高網絡運營的可靠性與服務質量,成為有線電視網絡管理領域迫切需要解決的問題。
1網管代理系統架構設計
本網管代理系統主要由網管通信、協議轉換、串口通信三個功能模塊組成。網管代理系統架構如圖1所示。
串口通信功能主要負責與OmniStar光傳輸平臺進行串口通信,一方面通過輪詢的方式獲取OmniStar光傳輸平臺的告警信息,還能根據請求獲取各個模塊的狀態信息,同時向OmniStar光傳輸平臺特定的模塊發送設值指令進行配置,另一方面將從Omn-iStar光傳輸平臺返回的狀態信息指令傳遞給協議轉換功能,該功能能從這些串口通信指令解析并分離出狀態信息;協議轉換功能主要負責串口通信指令的解析與串口通信指令的封裝,能從串口通信功能獲取的串口通信指令中解析出數據信息,將其存入MIB庫中,提供給網管通信功能,同時能將網管通信功能傳遞而來的來自管理站的Get、Set請求封裝成相應的串口通信指令轉發給Om-niStar光傳輸平臺,進行查詢和配置管理;網管通信功能主要負責與管理站進行SNMP協議通信及與協議轉換功能通信,它接受來自管理站的請求,并將其解析處理后將請求傳遞給協議轉換功能,同時能將協議轉換功能存入MIB的值封裝成SNMP協議報文轉發給管理站。
2網管代理系統進程設計
依據本網管代理設計的三個功能,將網管代理系統的進程設計為參數收集、SNMP代理和Trap輪詢三個進程,三者之間協同工作確保軟件系統正常運行。參數收集進程主要負責與OmniStar光傳輸平臺進行串口指令通信,通過對串口指令的解析提取狀態信息數據、描述信息數據等并將其存入MIB庫中,為SNMP代理進程提供數據信息服務,同時還能將SNMP代理進程的Set請求組裝成串口通信指令的設置請求轉發給OmniStar光傳輸平臺,從而對OmniStar光傳輸平臺進行配置管理。參數收集進程設計流程見圖2所示。
SNMP代理進程主要負責與管理站的SNMP協議通信,能解析管理站的請求并從MIB庫中讀取數據信息及向參數收集進程發送配置管理請求。SNMP代理進程能從MIB庫中讀取數據信息,并可將管理站的Set請求傳遞給參數收集進程,SNMP代理進程狀態轉換流程見圖3所示。
Trap輪詢進程主要負責收集OmniStar光傳輸平臺的告警信息,同時通過輪詢的方式發現本網管代理所需管理的OmniStar機架的個數以及每個機架中所管理的模塊個數,然后將所收集的告警數據信息封裝成SNMP消息報文轉發給管理站。其中參數收集進程與Trap輪詢進程對串口的使用進行競爭獲取,參數收集進程的優先級高于Trap輪詢進程。
3網管代理系統測試與分析
網管代理系統根據網管接口測試標準進行測試,包括標準MIB變量的讀取和設置、告警信息的獲取以及代理系統響應時間等測試。嵌入式網管代理的響應時間是指嵌入式網管代理對來自管理端的SNMP請求的處理響應時間,即網管軟件MIB Browser向網管代理發送SNMP請求到收到嵌入式網管代理返回的響應報文之間的時間。表1為測試得到的網管代理系統響應時間,表2為采集100次數據得到的網管代理系統平均響應時間。
測試結果表明,所設計的網管代理系統因受網絡環境的影響會產生不同的響應時間,響應時間范圍為0.3-0.7秒,平均響應時間為0.5秒左右,能夠滿足遠程集中管理的需求。
4結論
本文從有線電視網絡管理的實際問題出發,以OmniStar光傳輸平臺為開發對象,提出了面向有線電視網絡的網管代理系統架構設計方法,并對三個進程進行了詳細設計,最后對設計網管代理系統進行了測試,測試結果良好,能夠滿足對有線電視網絡的集中管理。