??? 摘? 要:? 分析了網(wǎng)絡(luò)中故障的傳播原理，在此基礎(chǔ)上提出了一種使用移動(dòng)代理的三層網(wǎng)絡(luò)故障管理體系，對(duì)網(wǎng)絡(luò)故障管理中關(guān)聯(lián)問題的難度進(jìn)行了有效的分解,。根據(jù)網(wǎng)絡(luò)故障管理體系的要求設(shè)計(jì)了不同功能的移動(dòng)代理，及該體系下它們的工作交互過程,。該體系充分利用了現(xiàn)有網(wǎng)絡(luò)條件,，滿足了現(xiàn)代網(wǎng)管對(duì)于故障管理的及時(shí)性、自學(xué)習(xí)性的要求,，減輕了網(wǎng)絡(luò)負(fù)載,。此外，按照這種方法建立起來的網(wǎng)絡(luò)故障管理系統(tǒng)具有一定的通用性和靈活性,，能夠適應(yīng)不同的網(wǎng)絡(luò)和網(wǎng)絡(luò)的變化,，最后通過實(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ò)故障管理的要求也越來越高,，傳統(tǒng)的集中式網(wǎng)絡(luò)管理技術(shù)越來越難以適應(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é)合起來，探討解決網(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ò)的通信開銷,，節(jié)省了帶寬，平衡負(fù)載,，加快任務(wù)的執(zhí)行^[3],，從而提高分布式系統(tǒng)的處理效率。智能性使得移動(dòng)代理能夠充分利用現(xiàn)今越來越強(qiáng)的節(jié)點(diǎn)計(jì)算能力,，并能將人工智能技術(shù)引入移動(dòng)代理,，以便更充分地完成管理任務(wù)^[4]。?

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

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

??? 當(dāng)網(wǎng)絡(luò)中發(fā)生故障時(shí),，故障會(huì)沿著橫向和縱向兩個(gè)方向傳播,。橫向傳播是指故障沿著物理的或是邏輯的連接在設(shè)備之間水平的傳播，例如與發(fā)生故障的設(shè)備相連的設(shè)備感知到故障后也發(fā)生告警事件,，這種故障甚至?xí)?a class="innerlink" href="http://forexkbc.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ò)故障檢測的目標(biāo)就是識(shí)別出作為網(wǎng)絡(luò)故障根本原因的原子對(duì)象,。?

??? 網(wǎng)絡(luò)故障傳播過程如圖1所示。當(dāng)某個(gè)原子對(duì)象發(fā)生故障時(shí),，例如某接口不可用,，會(huì)使得包含該接口的網(wǎng)絡(luò)設(shè)備無法進(jìn)行某種數(shù)據(jù)的交換，進(jìn)而影響周圍網(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ī)則庫中匹配的故障，并將不匹配的故障上報(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ī)則庫中的規(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)上來的告警事件進(jìn)行基于規(guī)則的推理，當(dāng)上報(bào)事件與規(guī)則不匹配時(shí),，則產(chǎn)生異常推斷,，并進(jìn)入基于案例的推理。在基于案例的推理算法中有一個(gè)檢索模塊和一個(gè)修改模塊,。檢索模塊負(fù)責(zé)在規(guī)則/案例庫中尋找與問題最為相似的案例,，然后由修改模塊對(duì)該實(shí)例作適當(dāng)?shù)男拚Ｒ坏┬拚Y(jié)果將問題解決,，則新的實(shí)例將加入到事例庫中,，以備以后的應(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ān)聯(lián)代理,。過濾關(guān)聯(lián)代理將告警過濾與告警關(guān)聯(lián)結(jié)合起來。過濾關(guān)聯(lián)代理是用上文介紹的一些過濾關(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ān)聯(lián)代理可以設(shè)置成基于RBR技術(shù)的代理,，也可以設(shè)置成基于貝葉斯推理等技術(shù)的代理,。?

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

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

??? (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ān)聯(lián)代理,，進(jìn)行預(yù)定義規(guī)則的過濾操作以后，視情況激活基于貝葉斯的關(guān)聯(lián)從代理或基于規(guī)則的關(guān)聯(lián)從代理,；并將關(guān)聯(lián)結(jié)果返回給過濾關(guān)聯(lián)代理,，經(jīng)過過濾關(guān)聯(lián)代理的簡單處理后，將結(jié)果送到子網(wǎng)端的故障分析代理,，子網(wǎng)端的代理在將關(guān)聯(lián)結(jié)果進(jìn)行子網(wǎng)判斷后,，查找規(guī)則庫。若規(guī)則庫中沒有匹配的規(guī)則時(shí),，則激活網(wǎng)絡(luò)連通性測試之類的從代理,，找出故障可能發(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ī)則庫中的匹配對(duì)象，若沒有匹配規(guī)則,，則將最后關(guān)聯(lián)結(jié)果以日志的形式上報(bào)給網(wǎng)絡(luò)管理員,，并更新案例庫。其中故障數(shù)據(jù)庫是案例庫和規(guī)則庫的統(tǒng)稱,。?

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

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

??? 圖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)觀測到的echo request數(shù)據(jù)包引起告警的門限值,，采樣間隔為1min,，每次持續(xù)1min，當(dāng)采樣到的數(shù)據(jù)包超過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消息,。將沒有應(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)來，告警消息約在5 KB~6 KB,告警消息的傳輸引起了瓶頸連接流量的驟然增長,，至告警消息傳輸完畢,，結(jié)點(diǎn)掃描被禁止后，瓶頸連接處的流量降至了正常業(yè)務(wù)水平,。由圖6可以看到應(yīng)用移動(dòng)代理的系統(tǒng)整體對(duì)網(wǎng)絡(luò)負(fù)載的壓力較小,。需要指出的是，當(dāng)網(wǎng)絡(luò)流量較大時(shí),，告警消息的傳輸帶來的流量影響是很小的,。因此對(duì)于大型異構(gòu)多應(yīng)用的網(wǎng)絡(luò)故障管理，應(yīng)用移動(dòng)代理系統(tǒng)的優(yōu)勢是明顯的,。?

??? 基于移動(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é)同工作過程,。在這種體系下，網(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.?