??? 摘? 要:? 分析了網(wǎng)絡(luò)中故障的傳播原理，在此基礎(chǔ)上提出了一種使用移動(dòng)代理的三層網(wǎng)絡(luò)故障管理體系，對(duì)網(wǎng)絡(luò)故障管理中關(guān)聯(lián)問(wèn)題的難度進(jìn)行了有效的分解。根據(jù)網(wǎng)絡(luò)故障管理體系的要求設(shè)計(jì)了不同功能的移動(dòng)代理，及該體系下它們的工作交互過(guò)程。該體系充分利用了現(xiàn)有網(wǎng)絡(luò)條件，滿足了現(xiàn)代網(wǎng)管對(duì)于故障管理的及時(shí)性、自學(xué)習(xí)性的要求，減輕了網(wǎng)絡(luò)負(fù)載。此外，按照這種方法建立起來(lái)的網(wǎng)絡(luò)故障管理系統(tǒng)具有一定的通用性和靈活性，能夠適應(yīng)不同的網(wǎng)絡(luò)和網(wǎng)絡(luò)的變化，最后通過(guò)實(shí)驗(yàn)證明了系統(tǒng)的部分優(yōu)越性。?

??? 關(guān)鍵詞: 網(wǎng)絡(luò)故障； 移動(dòng)代理； 代理協(xié)作

?

??? 隨著計(jì)算機(jī)網(wǎng)絡(luò)的迅速發(fā)展和廣泛應(yīng)用，對(duì)網(wǎng)絡(luò)管理特別是網(wǎng)絡(luò)故障管理的要求也越來(lái)越高，傳統(tǒng)的集中式網(wǎng)絡(luò)管理技術(shù)越來(lái)越難以適應(yīng)網(wǎng)絡(luò)管理功能的需要，充分利用現(xiàn)有網(wǎng)絡(luò)的智能性進(jìn)行分布式的網(wǎng)絡(luò)管理成為現(xiàn)今研究的重點(diǎn)。本文將移動(dòng)代理技術(shù)^[1]與網(wǎng)絡(luò)故障管理結(jié)合起來(lái)，探討解決網(wǎng)絡(luò)故障管理的方法。?

??? 移動(dòng)代理的主要特點(diǎn)是智能性和移動(dòng)性。它是一個(gè)能夠自主地在異構(gòu)網(wǎng)絡(luò)中遷移并協(xié)作的執(zhí)行任務(wù)的程序?qū)嶓w^[2]。它能夠自行決定在網(wǎng)絡(luò)的各個(gè)節(jié)點(diǎn)之間移動(dòng)，代表其他實(shí)體（人或其他代理）進(jìn)行工作，它能夠自行選擇執(zhí)行的時(shí)間和地點(diǎn)，并可以根據(jù)具體情況中斷當(dāng)前自身的執(zhí)行，移動(dòng)至另一設(shè)備恢復(fù)運(yùn)行，并及時(shí)地將有關(guān)的結(jié)果返回。移動(dòng)代理的移動(dòng)性使得程序的執(zhí)行能夠盡可能地靠近數(shù)據(jù)源，降低了網(wǎng)絡(luò)的通信開(kāi)銷，節(jié)省了帶寬，平衡負(fù)載，加快任務(wù)的執(zhí)行^[3]，從而提高分布式系統(tǒng)的處理效率。智能性使得移動(dòng)代理能夠充分利用現(xiàn)今越來(lái)越強(qiáng)的節(jié)點(diǎn)計(jì)算能力，并能將人工智能技術(shù)引入移動(dòng)代理，以便更充分地完成管理任務(wù)^[4]。?

1 基于移動(dòng)代理的網(wǎng)絡(luò)故障管理模型?

1.1 網(wǎng)絡(luò)故障的傳播過(guò)程?

??? 當(dāng)網(wǎng)絡(luò)中發(fā)生故障時(shí)，故障會(huì)沿著橫向和縱向兩個(gè)方向傳播。橫向傳播是指故障沿著物理的或是邏輯的連接在設(shè)備之間水平的傳播，例如與發(fā)生故障的設(shè)備相連的設(shè)備感知到故障后也發(fā)生告警事件，這種故障甚至?xí)?a class="innerlink" href="http://m.jysgc.com/tags/子網(wǎng)" title="子網(wǎng)" target="_blank">子網(wǎng)與子網(wǎng)之間傳播。縱向傳播主要是指故障在一個(gè)設(shè)備內(nèi)部沿著協(xié)議棧從低層向高層傳播，低層協(xié)議實(shí)體的不正常狀態(tài)可能引起高層協(xié)議實(shí)體狀態(tài)的不正常。?

??? 基于這種分析，將網(wǎng)絡(luò)劃分為4個(gè)層次的網(wǎng)絡(luò)對(duì)象：全網(wǎng)、子網(wǎng)、網(wǎng)絡(luò)元素NE(Network Element )和原子對(duì)象。將被管網(wǎng)絡(luò)作為全網(wǎng)，而一個(gè)被管網(wǎng)絡(luò)可能包括多個(gè)子網(wǎng)，子網(wǎng)的類型可以是總線網(wǎng)、令牌環(huán)或星形網(wǎng)等。每個(gè)子網(wǎng)由一個(gè)或多個(gè)NE組成，這些NE的類型可以是主機(jī)、路由器、集線器、交換機(jī)或一段物理鏈路等。而每一個(gè)NE也可以表示為由多個(gè)原子對(duì)象組成的集合，例如可以將一臺(tái)路由器表示成由若干IP對(duì)象和若干接口對(duì)象組成的集合。網(wǎng)絡(luò)故障檢測(cè)的目標(biāo)就是識(shí)別出作為網(wǎng)絡(luò)故障根本原因的原子對(duì)象。?

??? 網(wǎng)絡(luò)故障傳播過(guò)程如圖1所示。當(dāng)某個(gè)原子對(duì)象發(fā)生故障時(shí)，例如某接口不可用，會(huì)使得包含該接口的網(wǎng)絡(luò)設(shè)備無(wú)法進(jìn)行某種數(shù)據(jù)的交換，進(jìn)而影響周?chē)W(wǎng)絡(luò)元素的正常工作，使得整個(gè)子網(wǎng)出現(xiàn)異常，如果故障得不到解決，整個(gè)網(wǎng)絡(luò)都可能受到影響。?

?

?

1.2 系統(tǒng)模型設(shè)計(jì)?

??? 基于以上分析，本文設(shè)計(jì)了一種集中式與分布式相結(jié)合的、分層的、基于智能代理和移動(dòng)代理的網(wǎng)絡(luò)故障管理模型，并按照故障傳播順序?qū)⑦@個(gè)模型分為三層，系統(tǒng)模型設(shè)計(jì)如圖2所示。?

?

?

??? (1) 網(wǎng)絡(luò)元素端（NE端）。由于故障會(huì)在NE端進(jìn)行縱向傳播，所以移動(dòng)代理在NE端先建立各層常用協(xié)議及協(xié)議間的依賴模型，根據(jù)網(wǎng)絡(luò)故障及協(xié)議實(shí)體間依賴關(guān)系的不確定性的特點(diǎn)，選用適用于不確定性推理的貝葉斯網(wǎng)絡(luò)推理模型。當(dāng)出現(xiàn)故障時(shí)使用移動(dòng)代理進(jìn)行NE端的故障縱向關(guān)聯(lián)，解決規(guī)則庫(kù)中匹配的故障，并將不匹配的故障上報(bào)。?

??? (2) 子網(wǎng)端。由于故障的橫向傳播，在進(jìn)行告警關(guān)聯(lián)時(shí)如果能夠只考慮子網(wǎng)內(nèi)部與其他子網(wǎng)連接點(diǎn)產(chǎn)生的告警，而不考慮其他子網(wǎng)產(chǎn)生的告警，就可以大大減少告警信息的冗余程度。在子網(wǎng)內(nèi)部與其他子網(wǎng)的連接點(diǎn)上設(shè)置移動(dòng)代理，對(duì)NE端移動(dòng)代理發(fā)回的報(bào)告進(jìn)行分析，將事件的關(guān)聯(lián)在事件發(fā)出者所在的子網(wǎng)內(nèi)部進(jìn)行。告警事件產(chǎn)生時(shí)，首先判斷其產(chǎn)生者所在的子網(wǎng)，然后只在其內(nèi)部進(jìn)行基于規(guī)則的事件關(guān)聯(lián)。對(duì)于產(chǎn)生的故障在子網(wǎng)連接點(diǎn)的情況，即將事件在其所連接的所有子網(wǎng)內(nèi)進(jìn)行關(guān)聯(lián)，并與各子網(wǎng)規(guī)則庫(kù)中的規(guī)則進(jìn)行匹配判斷，如果判斷成功，則表明故障發(fā)生在該子網(wǎng)。?

??? (3) 全網(wǎng)端。有一些涉及到全網(wǎng)的告警事件則由各子網(wǎng)代理匯報(bào)到全網(wǎng)網(wǎng)絡(luò)管理站。為了實(shí)現(xiàn)實(shí)時(shí)性和自學(xué)習(xí)性，網(wǎng)管站采用基于規(guī)則的推理與基于案例的推理相結(jié)合的方式進(jìn)行故障告警的關(guān)聯(lián)。網(wǎng)管中心將子網(wǎng)智能代理上報(bào)上來(lái)的告警事件進(jìn)行基于規(guī)則的推理，當(dāng)上報(bào)事件與規(guī)則不匹配時(shí)，則產(chǎn)生異常推斷，并進(jìn)入基于案例的推理。在基于案例的推理算法中有一個(gè)檢索模塊和一個(gè)修改模塊。檢索模塊負(fù)責(zé)在規(guī)則/案例庫(kù)中尋找與問(wèn)題最為相似的案例，然后由修改模塊對(duì)該實(shí)例作適當(dāng)?shù)男拚Ｒ坏┬拚Y(jié)果將問(wèn)題解決，則新的實(shí)例將加入到事例庫(kù)中，以備以后的應(yīng)用。?

2 故障管理模型的移動(dòng)代理設(shè)計(jì)?

2.1 代理功能設(shè)計(jì)?

??? 依據(jù)一般的故障管理系統(tǒng)應(yīng)該包含的基本功能設(shè)置代理：?

??? (1)故障發(fā)現(xiàn)代理。故障發(fā)現(xiàn)代理主動(dòng)地或被動(dòng)地收集網(wǎng)絡(luò)上的各種事件，并識(shí)別出其中與網(wǎng)絡(luò)和故障相關(guān)的內(nèi)容，確定是否存在故障。?

??? (2)過(guò)濾關(guān)聯(lián)代理。過(guò)濾關(guān)聯(lián)代理將告警過(guò)濾與告警關(guān)聯(lián)結(jié)合起來(lái)。過(guò)濾關(guān)聯(lián)代理是用上文介紹的一些過(guò)濾關(guān)聯(lián)技術(shù)將非主要的、非根本的告警濾除，保留主要的根本原因的告警。例如被派往NE端進(jìn)行網(wǎng)絡(luò)縱向關(guān)聯(lián)的移動(dòng)代理，需要將NE端的協(xié)議依賴體系帶入到貝葉斯網(wǎng)絡(luò)推理中進(jìn)行故障關(guān)聯(lián)，找出原子故障。過(guò)濾關(guān)聯(lián)代理可以設(shè)置成基于RBR技術(shù)的代理，也可以設(shè)置成基于貝葉斯推理等技術(shù)的代理。?

??? (3)故障分析代理。故障分析代理負(fù)責(zé)將過(guò)濾關(guān)聯(lián)后的告警進(jìn)行分析，判斷子網(wǎng)歸屬，查找規(guī)則庫(kù)匹配，并派出故障解決代理。當(dāng)信息庫(kù)中沒(méi)有相關(guān)的告警時(shí)，生成如連通性測(cè)試代理之類的從代理找出故障的可能位置和原因，形成案例，然后激活故障告知代理更新案例庫(kù)。?

??? (4）故障告知代理。故障告知代理負(fù)責(zé)將告警關(guān)聯(lián)分析的結(jié)果上報(bào)給管理者并更新信息庫(kù)。?

??? (5）故障解決代理。當(dāng)故障原因確定后，派遣相應(yīng)的故障解決代理解決故障。?

2.2 代理協(xié)作模型?

??? 圖3給出了本文設(shè)計(jì)的多個(gè)代理之間協(xié)作進(jìn)行故障關(guān)聯(lián)的交互圖。?

?

?

??? 如圖3所示，故障發(fā)現(xiàn)代理一直在NE端進(jìn)行故障采集工作。當(dāng)發(fā)現(xiàn)異常后，激活過(guò)濾關(guān)聯(lián)代理，進(jìn)行預(yù)定義規(guī)則的過(guò)濾操作以后，視情況激活基于貝葉斯的關(guān)聯(lián)從代理或基于規(guī)則的關(guān)聯(lián)從代理；并將關(guān)聯(lián)結(jié)果返回給過(guò)濾關(guān)聯(lián)代理，經(jīng)過(guò)過(guò)濾關(guān)聯(lián)代理的簡(jiǎn)單處理后，將結(jié)果送到子網(wǎng)端的故障分析代理，子網(wǎng)端的代理在將關(guān)聯(lián)結(jié)果進(jìn)行子網(wǎng)判斷后，查找規(guī)則庫(kù)。若規(guī)則庫(kù)中沒(méi)有匹配的規(guī)則時(shí)，則激活網(wǎng)絡(luò)連通性測(cè)試之類的從代理，找出故障可能發(fā)生的時(shí)間、地點(diǎn)等信息，形成案例。并將子網(wǎng)關(guān)聯(lián)結(jié)果上報(bào)給網(wǎng)管端的故障分析代理，網(wǎng)管端的故障分析代理從全網(wǎng)的角度對(duì)上報(bào)故障進(jìn)行分析，查找規(guī)則庫(kù)中的匹配對(duì)象，若沒(méi)有匹配規(guī)則，則將最后關(guān)聯(lián)結(jié)果以日志的形式上報(bào)給網(wǎng)絡(luò)管理員，并更新案例庫(kù)。其中故障數(shù)據(jù)庫(kù)是案例庫(kù)和規(guī)則庫(kù)的統(tǒng)稱。?

3 實(shí)驗(yàn)?

??? 該實(shí)驗(yàn)以對(duì)網(wǎng)絡(luò)掃描的告警為例，對(duì)系統(tǒng)的效果進(jìn)行檢測(cè)。?

??? 圖4給出了實(shí)驗(yàn)使用的網(wǎng)絡(luò)拓?fù)鋱D，假設(shè)網(wǎng)絡(luò)存在一個(gè)共享的瓶頸連接。一些用戶在進(jìn)行正常的網(wǎng)絡(luò)業(yè)務(wù)，網(wǎng)絡(luò)攻擊者對(duì)結(jié)點(diǎn)C進(jìn)行結(jié)點(diǎn)掃描，為了隱蔽自己，利用s臺(tái)主機(jī)頻繁向結(jié)點(diǎn)C發(fā)送ping命令進(jìn)行掃描，在B結(jié)點(diǎn)派遣移動(dòng)代理，實(shí)驗(yàn)中取Ftp、UDP業(yè)務(wù)主機(jī)數(shù)m為7，s為5。設(shè)定n=15為1min內(nèi)觀測(cè)到的echo request數(shù)據(jù)包引起告警的門(mén)限值，采樣間隔為1min，每次持續(xù)1min，當(dāng)采樣到的數(shù)據(jù)包超過(guò)150時(shí)產(chǎn)生結(jié)點(diǎn)掃描告警。?

?

?

??? 圖5是實(shí)驗(yàn)結(jié)果，位于B點(diǎn)的移動(dòng)代理在第37次掃描時(shí)產(chǎn)生結(jié)點(diǎn)掃描告警。?

?

?

??? 本文設(shè)置代理將結(jié)點(diǎn)掃描告警發(fā)送到網(wǎng)絡(luò)管理站，告警中包括被掃描的結(jié)點(diǎn)、echo request的發(fā)送地址列表等，網(wǎng)絡(luò)管理站將收到的告警消息解碼分析，然后禁止echo request發(fā)送地址列表中的地址發(fā)送ping消息。將沒(méi)有應(yīng)用移動(dòng)代理系統(tǒng)和應(yīng)用移動(dòng)代理系統(tǒng)的A、B間的流量進(jìn)行對(duì)比，如圖6所示。非移動(dòng)代理系統(tǒng)瓶頸鏈路上的網(wǎng)絡(luò)流量隨著網(wǎng)絡(luò)掃描流量的增多而逐漸發(fā)生擁塞。?

?

?

??? 在結(jié)點(diǎn)掃描初期，大量結(jié)點(diǎn)掃描數(shù)據(jù)包占用了瓶頸帶寬，當(dāng)B點(diǎn)設(shè)置的移動(dòng)代理向管理站A點(diǎn)發(fā)出告警后， 管理站將禁止告警消息中的echo request發(fā)送地址列表中的地址繼續(xù)發(fā)送掃描數(shù)據(jù)包，代理與管理站之間采用ATP協(xié)議進(jìn)行通信，將數(shù)據(jù)報(bào)頭考慮進(jìn)來(lái)，告警消息約在5 KB~6 KB,告警消息的傳輸引起了瓶頸連接流量的驟然增長(zhǎng)，至告警消息傳輸完畢，結(jié)點(diǎn)掃描被禁止后，瓶頸連接處的流量降至了正常業(yè)務(wù)水平。由圖6可以看到應(yīng)用移動(dòng)代理的系統(tǒng)整體對(duì)網(wǎng)絡(luò)負(fù)載的壓力較小。需要指出的是，當(dāng)網(wǎng)絡(luò)流量較大時(shí)，告警消息的傳輸帶來(lái)的流量影響是很小的。因此對(duì)于大型異構(gòu)多應(yīng)用的網(wǎng)絡(luò)故障管理，應(yīng)用移動(dòng)代理系統(tǒng)的優(yōu)勢(shì)是明顯的。?

??? 基于移動(dòng)代理的網(wǎng)絡(luò)故障管理體系將移動(dòng)代理技術(shù)引入到網(wǎng)絡(luò)故障管理之中，它摒棄了傳統(tǒng)網(wǎng)絡(luò)故障管理體系中全網(wǎng)的故障都在網(wǎng)絡(luò)管理中心進(jìn)行管理的方式，利用代理的智能性和移動(dòng)性，將故障管理放在更加靠近故障源的地方進(jìn)行，減輕了網(wǎng)絡(luò)負(fù)載。本文根據(jù)移動(dòng)代理的特點(diǎn)，設(shè)計(jì)3層網(wǎng)管體系，并設(shè)計(jì)了各種代理以及代理之間的協(xié)同工作過(guò)程。在這種體系下，網(wǎng)管任務(wù)被細(xì)化，移動(dòng)代理的特點(diǎn)得到了充分的體現(xiàn)。實(shí)驗(yàn)結(jié)果證明了系統(tǒng)的部分優(yōu)越性。?

參考文獻(xiàn)?

[1] 張?jiān)朴? 劉錦德. 移動(dòng)Agent技術(shù). 北京: 清華大學(xué)出版社, 2003.?

[2] DALMEIJER M, HAMMER D K. TMAERTS A. Mobile?software agents. Computers in Industry,2000,(14):251-260.?

[3] SATOH I. Building reusable mobile agents for network?management systems. Man and Cybernetics, 2003, 33(3):?350-357.?

[4]?MILOJICIC D. Agent systems and applications.IEEE Concurrency, 2000,8(2):22-23.?