王曉東,楊學(xué)海

(中國西南電子技術(shù)研究所, 成都610036)

1 引 言

現(xiàn)有的航天地面測控系統(tǒng)中,監(jiān)控系統(tǒng)通過采用C/S架構(gòu)的方式基本實現(xiàn)了遠程中心對各套地面站設(shè)備的遠程監(jiān)控管理。遠程客戶端通過本地服務(wù)端對地面站設(shè)備運行狀態(tài)與參數(shù)進行監(jiān)視與控制,本地服務(wù)端將采集到的設(shè)備狀態(tài)參數(shù)信息傳送到遠程客戶端進行相應(yīng)顯示,遠程客戶端則向用戶提供良好的人機操作界面,并且發(fā)送各種操控命令到本地服務(wù)端,通過本地服務(wù)端對本地設(shè)備或數(shù)據(jù)庫進行相應(yīng)的操控。但是,由于遠程客戶端和本地服務(wù)端之間的信息傳輸沒有一套標準、統(tǒng)一的應(yīng)用層協(xié)議,致使遠程中心的監(jiān)控效率受到一定的影響,給用戶的使用帶來不便。

本文提出選擇簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)作為遠程客戶端與本地服務(wù)端之間進行網(wǎng)絡(luò)通信的應(yīng)用層協(xié)議,并以此為基礎(chǔ)構(gòu)建C/S(Client/Server)模式下的遠程監(jiān)控管理系統(tǒng)。通過原型系統(tǒng)的設(shè)計及實現(xiàn),以及仿真試驗的驗證,從而研究并探討了SNMP在遠程監(jiān)控中的應(yīng)用。

2 SNMP簡介

簡單網(wǎng)絡(luò)管理協(xié)議(Simple Network Management Protocol, SNMP)是一系列協(xié)議組和規(guī)范的集合, 20世紀80年代末期由IETF開發(fā)后,開始被廣泛應(yīng)用在各類網(wǎng)絡(luò)設(shè)備中,成為一種網(wǎng)管的工業(yè)標準,它被設(shè)計成為一種應(yīng)用層協(xié)議,規(guī)定了網(wǎng)絡(luò)信息傳輸?shù)姆椒ā⒏袷降?具有簡單、靈活、擴展性好等優(yōu)點,適合于管理員對不同種類的設(shè)備、不同廠家生產(chǎn)的設(shè)備、不同型號的設(shè)備、不同物理空間的設(shè)備進行統(tǒng)一的管理,是一種從網(wǎng)絡(luò)設(shè)備中收集網(wǎng)絡(luò)管理信息的有效簡便的方法。

SNMP采用管理者(manager)/代理(agent)模型。管理者(一般是運行網(wǎng)絡(luò)管理系統(tǒng)的計算機)通過向代理(一般是包含SNMP管理信息的設(shè)備)發(fā)送相應(yīng)的命令獲得代理中指定的信息,代理負責(zé)響應(yīng)管理者發(fā)出的各種信息,或者以主動上報的方式向管理者提供必要的信息,從而實現(xiàn)管理者與代理之間的信息通信。

SNMP通常由管理信息結(jié)構(gòu)(SMI)、管理信息庫(MIB)和管理協(xié)議(SNMP)[1]等幾個部分組成。

SMI是一套描述 SNMP如何訪問信息的標準[2],定義了SNMP框架所用信息的組織和標識,其中,被管理對象的定義要用抽象語句定義ASN.1來描述。SMI約束了抽象語句定義ASN.1的范圍,用于描述SNMP協(xié)議數(shù)據(jù)報和管理信息庫(MIB)。

MIB用來貯存管理信息,定義了可以通過網(wǎng)絡(luò)管理協(xié)議進行訪問的管理對象的集合,也即代理進程中所有可被查詢和修改的參數(shù)。MIB是一個樹形結(jié)構(gòu)的數(shù)據(jù)庫, MIB中的每個被管理資源都由一個對象來表示,每一個對象信息都是管理信息樹下的一個節(jié)點,擁有唯一的對象標識。管理者與代理之間都使用同一個MIB作為接口結(jié)構(gòu),可實現(xiàn)相互信息的理解與管理。

SNMP協(xié)議是管理者和代理之間的異步請求和響應(yīng)協(xié)議,定義了管理者如何對代理進程的MIB對象進行讀寫操作,定義了所使用的傳輸層協(xié)議、支持的操作、操作相關(guān)的PDU結(jié)構(gòu)等。網(wǎng)絡(luò)管理信息的數(shù)據(jù)由SNMP從MIB庫中獲取,再經(jīng)過網(wǎng)絡(luò)管理系統(tǒng)應(yīng)用程序進行過濾、分析、加工等處理。 SNMP通常使用無連接的UDP進行通信,使用命令的方式來訪問MIB數(shù)據(jù)庫,每個SNMP命令稱為協(xié)議數(shù)據(jù)單元(PDU)。典型的PDU包括GetRequest、GetNextRequest、SetRequest、Trap、Response等幾種類型。

3 SNMP在遠程監(jiān)控管理中的應(yīng)用

3.1 遠程監(jiān)控系統(tǒng)模型

目前,航天地面測控系統(tǒng)中,通過采用C/S模式構(gòu)建的遠程監(jiān)控管理系統(tǒng),部署在遠程中心的遠程客戶端已可基本實現(xiàn)對各個地面測控站設(shè)備進行遠程操控。地面站的本地服務(wù)端采集本地設(shè)備所有的參數(shù)、狀態(tài)信息,并將信息上報至遠程客戶端;遠程客戶端向用戶提供人機操作界面,同時將遠程控制命令發(fā)送到本地服務(wù)端,再由本地服務(wù)端對設(shè)備進行統(tǒng)一的分發(fā)控制?；赟NMP構(gòu)建C/S模式的遠程監(jiān)控管理系統(tǒng),并未改變既有遠程監(jiān)控的框架,只是采用了SNMP作為遠程客戶端與服務(wù)端之間的網(wǎng)絡(luò)信息交互的基礎(chǔ)。遠程監(jiān)控管理系統(tǒng)模型如圖1所示。

圖1 遠程監(jiān)控管理系統(tǒng)模型Fig.1 Remotemonitoring and controlmanagementsystem model

監(jiān)控服務(wù)端可被看作是SNMP中的代理角色,遠程客戶端可被看作是SNMP中的管理者角色,這時的遠程中心客戶端軟件同地面站的本地服務(wù)端軟件之間的網(wǎng)絡(luò)信息交互即是采用SNMP的方式來實現(xiàn)。

3.2 監(jiān)控M IB庫設(shè)計

在采用SNMP進行C/S模式遠程監(jiān)控管理系統(tǒng)的構(gòu)建中,重要的一個工作是遠程監(jiān)控MIB庫的設(shè)計,以使得在管理者與代理之間使用同一個MIB作為網(wǎng)絡(luò)信息傳輸?shù)幕A(chǔ)。圖2是遠程監(jiān)控MIB庫的對象標識命名樹結(jié)構(gòu)示意圖,可按路徑尋找到設(shè)備DC的對象標識(OID)為1.3.6.1.4.1.100000.1,或者也可表示為iso.org.dod.internet.private.enterprises.station.dc。

圖2 對象標識命名樹示例Fig.2 Named tree of objects identificationmodel

SNMP版本2中提供了多種命令類型的PDU操作,在遠程監(jiān)控軟件中實際用到最多的是Trap操作與SetRequest操作兩種。在應(yīng)用程序運行時,所有的Trap操作都在程序的某一個入口處接收數(shù)據(jù),所有的SetRequest操作又在程序的另一個入口處接收數(shù)據(jù)。而在同一個 PDU操作命令中(例如 SetRequest操作)劃分出具體是遠程監(jiān)控命令或數(shù)據(jù)的哪一種,則需要應(yīng)用程序本身提供一種處理機制來進行解析。一種方式是,可以將收到的數(shù)據(jù)進行全MIB庫元素的遍歷,直至找到對應(yīng)的元素,其缺點為進行遍歷操作將要消耗大量的資源,尤其在秒定時及大數(shù)據(jù)量傳輸時表現(xiàn)更為明顯。為了解決此問題,在進行遠程監(jiān)控MIB庫設(shè)計時,將同一條命令或返回響應(yīng)的數(shù)據(jù)集合在一個對象節(jié)點下,在節(jié)點內(nèi)的第1個元素設(shè)計為本節(jié)點的名稱,通過查找第1個元素標識即可識別這一節(jié)點內(nèi)的數(shù)據(jù)具體是哪一個設(shè)備的什么類型的數(shù)據(jù)或者是哪一類型的命令操作等。程序數(shù)據(jù)接收入口處收到響應(yīng)或命令時,首先將收到的第1個元素解出,得到此識別標識后,再根據(jù)標識調(diào)用對應(yīng)的處理方法即可對其后的MIB元素數(shù)據(jù)進行處理,不再需要對MIB庫對象進行全部遍歷操作。

在進行遠程監(jiān)控的MIB庫設(shè)計時,以DC設(shè)備為例,總共需要進行控制的元素為兩項,包括dcDNLFreq、dcNCAttenLevel;需要設(shè)備上報的參數(shù)與狀態(tài)元素為8項,包括控制參數(shù)兩項以及狀態(tài)參數(shù)(dc-MonMode、 dcLO1Status、 dcLO2Status、 dcPower1Ind、dcPower2Ind、dcPower3Ind)6 項。所有參數(shù)定義為Integer32型, DC的MIB庫設(shè)計如圖3所示。

圖3 MIB庫中設(shè)備DC的定義Fig.3 The difinition fo DC in MIB

設(shè)備DC的節(jié)點名稱定義為“dc”,節(jié)點下定義的第1個元素dcNameID為此設(shè)備的String類型的元素,在發(fā)送控制命令或上報參數(shù)狀態(tài)時,填入一個相應(yīng)的識別字符串,例如,對于設(shè)備DC狀態(tài)與參數(shù)的返回填入“DCStatus”,避免應(yīng)用程序在對接收數(shù)據(jù)進行處理時對全MIB庫進行遍歷操作。在接收到服務(wù)端Trap上報的數(shù)據(jù)時,解出第1個元素對象,如設(shè)備DC上報“DCStatus”時,即可知道Trap的數(shù)據(jù)為設(shè)備DC的參數(shù)狀態(tài),直接調(diào)用相應(yīng)的處理過程即可,節(jié)省全MIB遍歷所需的處理時間和資源。

MIB中對所有設(shè)備監(jiān)控、業(yè)務(wù)管理和數(shù)據(jù)庫操作的設(shè)計均采用同樣的方式。

3.3監(jiān)控軟件設(shè)計及實現(xiàn)

遠程監(jiān)控管理系統(tǒng)設(shè)計主要體現(xiàn)在監(jiān)控軟件的設(shè)計上,監(jiān)控軟件分為兩部分:一部分為監(jiān)控服務(wù)端軟件,它實現(xiàn)對所有需要管理的設(shè)備進行參數(shù)的采集,將采集到的參數(shù)實時上報到遠程監(jiān)控客戶端軟件,或者接收遠程客戶端軟件發(fā)出的控制命令,對設(shè)備進行控制操作以及對數(shù)據(jù)庫數(shù)據(jù)的操作;另一部分為遠程監(jiān)控客戶端軟件,提供一個良好的人機圖形界面供用戶操作控制設(shè)備。

SNMPv2提供了GetRequest、GetNextRequest、SetRequest、Trap、Response、InformRequest、GetBulkRequest等7種命令類型的PDU操作,結(jié)合遠程監(jiān)控軟件的功能特點以及所傳送數(shù)據(jù)的特點,將使用到GetRequest、SetRequest和Trap等3種操作方式,其中,又主要會大量的使用到SetRequest和Trap這兩種操作方式。監(jiān)控服務(wù)端采用Trap操作方式定時(如每秒)將采集的數(shù)據(jù)上報至客戶端進行顯示;監(jiān)控客戶端對監(jiān)控服務(wù)端采用SetRequest操作方式進行監(jiān)控命令的下達,對部分需要獲得少量返回參數(shù)的監(jiān)控命令使用GetRequest操作方式進行下達。監(jiān)控信息流程如圖4所示。

圖4 監(jiān)控信息流程圖Fig.4 The flow chart of information onmonitoring＆control

根據(jù)實際遠程監(jiān)控管理的功能需求,主要包括設(shè)備參數(shù)與狀態(tài)的監(jiān)視、設(shè)備參數(shù)控制、數(shù)據(jù)庫操作、用戶信息管理、圖像傳輸?shù)葞讉€部分。對監(jiān)控軟件實現(xiàn)上述功能的操作將根據(jù)各自的功能特點采用不同方式進行實現(xiàn)。

在本原型系統(tǒng)的實現(xiàn)過程中, SNMP的開發(fā)平臺采用AdventNet API,編程語言采用C#。

3.3.1 設(shè)備參數(shù)與狀態(tài)監(jiān)視

監(jiān)控服務(wù)端創(chuàng)建單獨的一個線程,以每秒主動發(fā)送Trap的方式將設(shè)備參數(shù)與狀態(tài)上報至監(jiān)控客戶端。在Trap的PDU中將所有的參數(shù)、狀態(tài)進行一次性綁定并發(fā)送。服務(wù)端與客戶端使用相同的MIB庫文件,在接收的時候只需將收到的Trap包中數(shù)據(jù)的OID對應(yīng)至MIB庫文件中的相應(yīng)部分,即可解析出所需元素的數(shù)值,填入已經(jīng)定義好的數(shù)據(jù)結(jié)構(gòu)中以便監(jiān)控客戶端使用。發(fā)送設(shè)備參數(shù)與狀態(tài)線程部分程序示例如下:

3.3.2 設(shè)備參數(shù)控制

獲得監(jiān)控客戶端界面中需要更改的參數(shù)并將其填入對應(yīng)的控制數(shù)據(jù)結(jié)構(gòu)中,發(fā)送命令方式采用SetRequest操作。設(shè)備參數(shù)控制命令類型依靠所定義的不同的命令代碼表示,將所需控制的命令代碼與所需要傳送的命令參數(shù),綁定在SetRequest操作的PDU中進行發(fā)送。監(jiān)控服務(wù)端在收到SetRequest命令后,首先將命令類型數(shù)據(jù)解出,判斷出具體是哪一條命令,再由具體對應(yīng)的命令解碼方法解出余下的命令參數(shù)并控制到設(shè)備或進行相應(yīng)的操作。

3.3.3 數(shù)據(jù)庫操作

在設(shè)定的數(shù)據(jù)庫中,主要記錄設(shè)備的參數(shù)狀態(tài),因此對于監(jiān)控客戶端來說,操作數(shù)據(jù)庫實際上更多的是對數(shù)據(jù)庫內(nèi)容的瀏覽與刪除兩項操作。對數(shù)據(jù)庫操作,監(jiān)控客戶端采用SetRequest方式將查詢或刪除數(shù)據(jù)庫命令發(fā)出,在發(fā)出的命令中綁定了兩個日期參數(shù),監(jiān)控服務(wù)端收到命令后,在處理刪除數(shù)據(jù)庫命令時,直接將兩個日期之間的所有數(shù)據(jù)記錄刪除。處理查詢命令時需要將數(shù)據(jù)記錄讀出后全部返回到監(jiān)控客戶端。因一條記錄可能包含有多個參數(shù)狀態(tài),因此在返回查詢數(shù)據(jù)記錄時,采用Trap方式上報,一次返回一條記錄的方式進行。監(jiān)控服務(wù)端單獨創(chuàng)建一個線程用于循環(huán)返回數(shù)據(jù)記錄,一次返回發(fā)送50條記錄到監(jiān)控客戶端進行顯示。如查詢的數(shù)據(jù)記錄大于50條,則可在監(jiān)控客戶端進行翻頁操作,每點擊一次翻頁事件,查詢下面50條記錄并返回,以解決數(shù)據(jù)記錄過多可能造成的獲取與顯示問題。

3.3.4 用戶信息管理

對用戶信息的增加、刪除操作采用SetRequest方式發(fā)送到監(jiān)控服務(wù)端即可,已登錄用戶實時信息綁定在設(shè)備參數(shù)與狀態(tài)獲取的Trap包中一并返回,不需要進行單獨的處理。在用戶信息中最重要的處理為漢字的傳輸,對于用戶信息,使用漢字進行描述,而使用的AdventNet API無法支持String型傳輸漢字,因此處理漢字時需要在綁定至PDU上之前將漢字進行編碼轉(zhuǎn)換,轉(zhuǎn)換為能夠正常傳輸?shù)木幋a再綁定到PDU上發(fā)送,監(jiān)控客戶端收到漢字后需要進行一次逆轉(zhuǎn)換,轉(zhuǎn)換為正常的漢字編碼再進行顯示。

3.3.5 圖像傳輸

監(jiān)控軟件中對圖像傳輸?shù)囊笾饕獮椴ㄐ螆D像,用于設(shè)備頻譜儀圖像的實時監(jiān)視。圖像傳輸標志置為開始后一直進行傳送,因此監(jiān)控服務(wù)端單獨創(chuàng)建傳輸線程,并使用Trap方式進行圖像數(shù)據(jù)的傳輸。頻譜儀圖像采用每秒600點的采樣率進行波形采集,對每點的數(shù)據(jù)存儲方式為N[X][ Y],即把X與Y軸位置進行存儲,發(fā)送到監(jiān)控客戶端后進行相應(yīng)的還原、重繪以恢復(fù)圖像顯示。由于SNMP在對數(shù)據(jù)的傳輸時,需要將對象的OID與對象數(shù)據(jù)一起綁定,若單獨設(shè)定一個對象OID對應(yīng)一個點的方式進行綁定,按圖像數(shù)據(jù)每秒更新一次計算,即每秒需要進行600 個點的數(shù)據(jù)傳輸,在MIB庫中,對圖像的傳輸就要設(shè)定600個元素,這樣導(dǎo)致MIB過于冗長,因此這里采用在MIB中只設(shè)定6個String型元素對象,每100 個點轉(zhuǎn)換為一個String型數(shù)據(jù)進行傳輸,一秒內(nèi)傳輸6個String型(分為6個數(shù)據(jù)包)即可完成。在監(jiān)控客戶端收到數(shù)據(jù)后進行一個循環(huán)依次解包,待6個數(shù)據(jù)包全部接收完畢并解碼完成后,即可對圖像進行重繪顯示。

3.4 SNMP在遠程監(jiān)控中的應(yīng)用分析

采用基于SNMP協(xié)議的方式實現(xiàn)客戶端和服務(wù)端之間的網(wǎng)絡(luò)信息傳輸,可以規(guī)范統(tǒng)一各地面站對外的信息接口,提高接口的可擴展性,有利于遠程監(jiān)控中心收集、處理分布在異地的各地面站的各種設(shè)備監(jiān)控信息。

通過原型系統(tǒng)的設(shè)計及試驗驗證,采用SNMP的方式可以實現(xiàn)遠程監(jiān)控管理的設(shè)備參數(shù)與狀態(tài)的監(jiān)視、設(shè)備參數(shù)控制、數(shù)據(jù)庫操作、用戶信息管理、圖像獲取等幾個主要功能。其中,控制命令發(fā)出后設(shè)備或數(shù)據(jù)返回的響應(yīng)時間均小于2.5 s,并且響應(yīng)時間可通過對程序內(nèi)部數(shù)據(jù)處理邏輯的優(yōu)化進行縮減;監(jiān)控軟件模擬實際系統(tǒng)運行情況,進行操作測試,在600 s內(nèi)統(tǒng)計對24種不同設(shè)備的共870個元素進行監(jiān)視,并進行30次不同設(shè)備的控制操作,總共產(chǎn)生9 487 500 byte數(shù)據(jù)量,監(jiān)控客戶端與監(jiān)控服務(wù)端之間的網(wǎng)絡(luò)信息傳輸?shù)钠骄加脦挒? 487 500/600=126.5 kbit/s。

采用SNMP方式構(gòu)建的C/S模式遠程監(jiān)控管理系統(tǒng)中,對設(shè)備的參數(shù)與狀態(tài)的監(jiān)視、對設(shè)備的參數(shù)控制以及自動化測試等功能均能得到良好的實現(xiàn)。但在進行數(shù)據(jù)庫操作與圖像傳輸時,由于數(shù)據(jù)本身的信息含量很大,網(wǎng)絡(luò)傳輸?shù)臅r效性將受到一定的影響。特別是在進行數(shù)據(jù)庫瀏覽、查詢時,數(shù)據(jù)量超過規(guī)定帶寬(例如256 kbit)時,將會出現(xiàn)傳輸延遲現(xiàn)象,根據(jù)數(shù)據(jù)量的多少,完全傳輸一張表的內(nèi)容需要幾秒至幾十秒不等。

基于SNMP構(gòu)建C/S模式遠程監(jiān)控管理系統(tǒng)具有一定的可行性,雖然在數(shù)據(jù)庫操作、圖像傳輸?shù)葞讉€特殊方面表現(xiàn)有所欠佳,但這主要還是由于其功能本身的特點以及網(wǎng)絡(luò)傳輸帶寬等因素所決定的。

4 結(jié)束語

本文提出了將SNMP協(xié)議與基于C/S結(jié)構(gòu)的遠程監(jiān)控管理系統(tǒng)進行融合,實現(xiàn)了監(jiān)控服務(wù)端與監(jiān)控客戶端之間的網(wǎng)絡(luò)傳輸采用標準的SNMP協(xié)議進行通信,構(gòu)建C/S模式的遠程監(jiān)控管理方式。同時,提出了遠程監(jiān)控主要功能在SNMP協(xié)議下的實現(xiàn)方式以及MIB中相應(yīng)的功能與設(shè)備的對象元素的設(shè)計方式,通過試驗驗證監(jiān)控服務(wù)端與監(jiān)控客戶端之間采用SNMP協(xié)議實現(xiàn)遠程監(jiān)控功能的可行性、占用帶寬及性能等。在SNMP協(xié)議下,客戶端與服務(wù)端之間的網(wǎng)絡(luò)通信為點對點方式,因此,我們在對多遠程客戶端自由接入服務(wù)端的功能支持上并不完善,這將是后續(xù)研究的主要方向。

[ 1] 曾凡鋒.基于SNMP的網(wǎng)絡(luò)流量統(tǒng)計分析系統(tǒng)[ J].北方工業(yè)大學(xué)學(xué)報, 2003, 15(1):17-20.

ZENG Fan-feng.The Netflow Statistical and Analytical System Based on SNMP[J].Journal of North China University of Technology, 2003, 15(1):17 -20.(in Chinese)

[ 2] 劉翔, 沈明玉.基于 SNMP與Web的服務(wù)監(jiān)控系統(tǒng)[ J] .合肥工業(yè)大學(xué)學(xué)報, 2008, 31(1):44-47.

LIU Xiang, SHEN Ming-yu.Design of a server monitoring system based on the SNMP and Web[J].Journal of Hefei University of Technology, 2008, 31(1):44-47.(in Chinese)