版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)
文檔簡介
1、<p><b> 摘要</b></p><p> 伴隨Internet時代的到來,網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展,越來越多的企業(yè)、政府、學校、個人等都融入到互聯(lián)網(wǎng)當中。相比從前的專用網(wǎng)絡(luò),現(xiàn)在的網(wǎng)絡(luò)已經(jīng)和人們的學習,工作及生活密不可分了。而作為整個互聯(lián)網(wǎng),穩(wěn)定、高效、準確的運行就顯得極為重要。要做到這一點,除了要依靠網(wǎng)絡(luò)設(shè)備本身和網(wǎng)絡(luò)架構(gòu)的可靠性以外,還必須依靠一套有效的網(wǎng)絡(luò)管理手段來監(jiān)測
2、和管理整個網(wǎng)絡(luò)。本文介紹的綜合網(wǎng)絡(luò)管理系統(tǒng)應用了基于SNMP的網(wǎng)絡(luò)設(shè)備性能管理與報表生成。性能管理主要負責全網(wǎng)性能監(jiān)視、性能控制和性能分析。性能管理還進行鏈路性能測試,以及各類性能信息的收集、統(tǒng)計、存儲,性能信息數(shù)據(jù)庫的維護,性能管理閾值的設(shè)置與閾值越過報告,產(chǎn)生按需的性能報告。報表管理系統(tǒng)為管理人員提供從數(shù)據(jù)的收集,報表合并到報表展示生成的一整套報表體系。</p><p> 本文還著重介紹了本系統(tǒng)的分層和業(yè)務(wù)
3、模塊劃分技術(shù),使業(yè)務(wù)模塊和底層協(xié)議相分離,通過數(shù)據(jù)抽象層為中介對網(wǎng)絡(luò)設(shè)備進行抽象,實現(xiàn)對網(wǎng)絡(luò)資源的集中控制和調(diào)度。這是本系統(tǒng)的一大特色。</p><p> 關(guān)鍵詞:網(wǎng)絡(luò)管理,簡單網(wǎng)絡(luò)協(xié)議(SNMP),性能管理,報表管理</p><p><b> 1.緒論</b></p><p> 1.1 課題背景及目的</p><p&
4、gt; 眾所周知,網(wǎng)絡(luò)管理的起源來自于美國國防部設(shè)計的世界上頭幾個包交換網(wǎng)之一的ARPANET。在70年代,TCP/IP協(xié)議正式被定為軍方通信標準,隨著此協(xié)議的廣泛使用,網(wǎng)絡(luò)管理成了一件大事。在80年代末和90年代初,網(wǎng)絡(luò)迅速發(fā)展,許多子網(wǎng)數(shù)目的增多使網(wǎng)絡(luò)活動成為一種必須。在網(wǎng)絡(luò)管理的初期,對網(wǎng)絡(luò)的管理停留在使用ICMP和PING的基礎(chǔ)上,但是隨著網(wǎng)絡(luò)內(nèi)主機數(shù)據(jù)的不斷增多,這種簡單的工具已經(jīng)不可能完</p><p&
5、gt; 成網(wǎng)絡(luò)管理的工作了。 </p><p> 隨著網(wǎng)絡(luò)數(shù)目與網(wǎng)絡(luò)內(nèi)主機數(shù)目的日益增多,單純依靠一些網(wǎng)絡(luò)專業(yè)進行網(wǎng)絡(luò)管理已經(jīng)不可能了,必須有一種通行的網(wǎng)絡(luò)管理標準以及相應的管理工具是普通人也能管理網(wǎng)絡(luò)。第一個相關(guān)的協(xié)議是SGMP,它提供了一種直接監(jiān)視網(wǎng)關(guān)的方法,也因此成了一種通用的網(wǎng)絡(luò)管理工具。下來,有三種可供選擇的管理工具:HEMS,SNMP和建立在TCP/IP基礎(chǔ)上的CMIP(CMOT),因為需要使用I
6、SO/OSI模型進行網(wǎng)絡(luò)管理,SNMP首選CMOT作為管理工具由于基本的SNMP已經(jīng)被廣泛使用了,所有的網(wǎng)絡(luò)產(chǎn)品都提供對SNMP的支持,新開發(fā)的具有遠程管理能力的SNMP是RMON,它使管理人員可以將整個子網(wǎng)進行管理,而不是對整個子網(wǎng)內(nèi)的設(shè)備進行管理。 SNMP的核心功能是能讓管理員能改變基于SNMP協(xié)議裝置的狀態(tài),比如說我們可以使用SNMP來關(guān)閉路由器,SNMP還能監(jiān)測交換機的問題,當溫度過高時還能發(fā)出警告。SNMP通常是用來管理路由
7、器,但是更重要的是它還能用來管理很置,SNMP的前身SGMP,僅僅是用來管理互聯(lián)網(wǎng)路由器,而SNMP卻可以被用來管理Unix系統(tǒng),Windows系統(tǒng)、打印機、調(diào)制解調(diào)器、供電器等等。同時,運行在一些</p><p> 信息的軟件同樣能被其管理,這就讓SNMP不僅僅包括物理硬件同樣也包含軟件,比如web服務(wù)器和數(shù)據(jù)庫。另一個網(wǎng)絡(luò)管理問題就是網(wǎng)絡(luò)監(jiān)控。網(wǎng)絡(luò)監(jiān)控不同于單個的路由器,主機或者是其他設(shè)備,它是一個整體的東
8、西。遠程網(wǎng)絡(luò)監(jiān)控(RMON)能幫助我們了解整個網(wǎng)絡(luò)的運作和每個設(shè)備在整個網(wǎng)絡(luò)中所起的作用,它不僅用于局域網(wǎng)更應用于廣域網(wǎng)。</p><p> 1.2 發(fā)展現(xiàn)狀和國內(nèi)外研究方向</p><p> 伴隨Internet時代的到來,網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展,越來越多的企業(yè)。政府、學校、個人等都融入互聯(lián)網(wǎng)當中,相比從前的專用網(wǎng)絡(luò),現(xiàn)在的網(wǎng)絡(luò)已經(jīng)和人們的學習、工作及生活密不可分了。而作為整個互聯(lián)網(wǎng)、穩(wěn)
9、定、高效、準確的運行就顯得極為重要。要做到這一點,除了要依靠網(wǎng)絡(luò)設(shè)備本身和網(wǎng)絡(luò)架構(gòu)的可靠性以外,還必須依靠一套有效的網(wǎng)絡(luò)管理手段來監(jiān)測和管理整個網(wǎng)絡(luò),而管理網(wǎng)絡(luò)就會需要一個適合的網(wǎng)絡(luò)協(xié)議,當前最典型的網(wǎng)絡(luò)管理協(xié)議有基于OSI七層模型的公共管理信息協(xié)議(CMIP)和基于TCO/IP的簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)。OSI/CMIP系統(tǒng)管理模型是目前理論上最完備的網(wǎng)絡(luò)管理模型,是其他網(wǎng)絡(luò)管理模型的基本參考。但由于該模型比較復雜,實現(xiàn)代價高,因
10、此并沒有得到廣泛的應用。相反,當初只是為了管理TCP/IP網(wǎng)絡(luò)的SNMP卻得到了迅速的發(fā)展和廣泛應用。SNMP網(wǎng)絡(luò)管理模型的突出特點是簡單、易于實現(xiàn),因此得到廠商的支持。特別是在Internet上的成功應用,使得它的重要性越來越突出,已經(jīng)成為事實上的工業(yè)標準</p><p> 1.3 課題研究方案</p><p><b> 1.3.1 對象</b></p&g
11、t;<p> SNMP(Simple Network Management Protocol,簡單網(wǎng)絡(luò)管理協(xié)議)首先是由IETF的研究小組為了解決Internet上的路由器管理問題而提出的。SNMP的設(shè)計原則是簡單性和擴展性。簡單性是通過信息類型限制,請求響應或協(xié)議而取得。擴展性是通過將管理信息模型與協(xié)議,被管理對象的詳細規(guī)定(MIB)分離而實現(xiàn)的。作為一個基于SNMP的網(wǎng)絡(luò)管理模型包括以下關(guān)鍵元素:管理站;代理者;管理
12、信息庫;網(wǎng)絡(luò)管理協(xié)議。管理站一般是一個分立的設(shè)備,也可以利用共享系統(tǒng)實現(xiàn)。管理站作為網(wǎng)絡(luò)管理員與網(wǎng)絡(luò)管理系統(tǒng)的接口,它的基本構(gòu)成為:一組具有分析數(shù)據(jù),發(fā)現(xiàn)故障等功能的管理程序;一個用于網(wǎng)絡(luò)管理員監(jiān)控網(wǎng)絡(luò)的接口;將網(wǎng)絡(luò)管理員的要求轉(zhuǎn)變?yōu)閷h程網(wǎng)絡(luò)元素的實際監(jiān)控的能力;一個從所有被管網(wǎng)絡(luò)實體的MIB中抽取信息的數(shù)據(jù)庫。</p><p><b> 1.3.2 框架 </b></p>
13、<p> 當今網(wǎng)絡(luò)越來越重要,網(wǎng)絡(luò)的規(guī)模、復雜度也越來越大,為了保證網(wǎng)絡(luò)有良好的性能,必須使用網(wǎng)絡(luò)管理系統(tǒng),網(wǎng)絡(luò)管理系統(tǒng)監(jiān)視和控制網(wǎng)絡(luò),即對網(wǎng)絡(luò)進行配置、獲取信息、監(jiān)視網(wǎng)絡(luò)性能、監(jiān)視和管理故障以及進行安全控制。但是,由于歷史的原因,現(xiàn)在的網(wǎng)絡(luò)管理系統(tǒng)存在著缺陷,不同的網(wǎng)絡(luò)運營商擁有各自分割的網(wǎng)管系統(tǒng),有些廠商發(fā)展自己專用的協(xié)議。同時,針對不同的網(wǎng)絡(luò)管理功能,存在著大量功能單一的網(wǎng)絡(luò)管理系統(tǒng)。這些管理功能相互獨立,甚至不同廠
14、家同類設(shè)備間的管理系統(tǒng)也做不到很好的統(tǒng)一。這些情況致使網(wǎng)絡(luò)協(xié)議不兼容,管理信息分離,不能更好的共享管理資源,缺乏對整個網(wǎng)絡(luò)的統(tǒng)一管理,從技術(shù)方面看,管理內(nèi)容龐雜、操作界面多種多樣,從管理方面看,不同的網(wǎng)管系統(tǒng)需要更多的人員學習維護,浪費人力,同時隨著網(wǎng)絡(luò)的復雜度增加,分散管理,不容易進行問題定位和對網(wǎng)絡(luò)的優(yōu)化針對以上網(wǎng)絡(luò)管理中存在的問題,各網(wǎng)絡(luò)運營商希望能夠在目前網(wǎng)絡(luò)管理基礎(chǔ)上建</p><p> 立一個綜合的
15、網(wǎng)絡(luò)管理系統(tǒng),以實現(xiàn)網(wǎng)絡(luò)管理的統(tǒng)一。這就有了綜合網(wǎng)絡(luò)管理的需求,</p><p> 即把現(xiàn)有的獨立的不同網(wǎng)管系統(tǒng)進行整合,實現(xiàn)兼容和互操作性,形成一個界面友好、</p><p> 功能齊全的網(wǎng)絡(luò)管理系統(tǒng)。</p><p> 1.3.3 方案論證</p><p> 隨著科技的不斷發(fā)展,網(wǎng)絡(luò)的使用和規(guī)模不斷的擴大,現(xiàn)在的大部分網(wǎng)管軟件都只
16、有實現(xiàn)邏輯拓撲,沒有網(wǎng)絡(luò)真實連接和鏈路真實情況的反映,無法幫助用戶了解和分析問題。而綜合網(wǎng)絡(luò)管理系統(tǒng)的拓撲發(fā)現(xiàn)過程,采用了物理拓撲算法和拓撲優(yōu)化算法。真正實現(xiàn)了用戶最關(guān)心的物理真實拓撲的現(xiàn)實。該系統(tǒng)能展現(xiàn)一個用戶從局域網(wǎng)到廣域網(wǎng)的所有網(wǎng)絡(luò)設(shè)備的真實連接情況,鏈接狀態(tài)和鏈接負載等,能幫助用戶分析問題和解決問題。拓撲圖不僅真實的再現(xiàn)了網(wǎng)絡(luò)結(jié)構(gòu),且在拓撲圖上網(wǎng)絡(luò)管理人員能方便快速地定位到網(wǎng)絡(luò)故障,有利于網(wǎng)絡(luò)的維護。同時對于大規(guī)模用戶,會有各種
17、不同的網(wǎng)絡(luò)設(shè)備(包括核心網(wǎng)絡(luò)設(shè)備和邊緣網(wǎng)絡(luò)設(shè)備),不用網(wǎng)絡(luò)設(shè)備,需要有不同的管理和輪詢策略,才能保證實時管理能力的需要,同時不會對網(wǎng)絡(luò)造成太大的負載。輪詢間隔管理保證了對骨干網(wǎng)路流量,CPU負載較高時,網(wǎng)管軟件的運行都不會對網(wǎng)絡(luò)性能造成太大的影響</p><p> 簡單網(wǎng)絡(luò)協(xié)議(SNMP)簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)是一個應用層協(xié)議,是TCP/IP協(xié)議套件的一部分。SNMP協(xié)議的作用是在網(wǎng)絡(luò)構(gòu)件間提供并傳輸管理
18、信息。通常,SNMP協(xié)議可以管理網(wǎng)絡(luò)上所有的SNMP設(shè)備,管理應用需要的所有數(shù)據(jù)(狀態(tài)、性能、故障、報警、報表等等)都是依靠SNMP協(xié)議在被管理設(shè)備間傳輸?shù)?lt;/p><p> 2.1 SNMP模型 </p><p><b> SNMP</b></p><p> 的簡單模型如下圖所示</p><p> 圖 2-1
19、SNMP簡單模型圖</p><p> 2.1.1 被管設(shè)備</p><p> 被管理設(shè)備是這樣的網(wǎng)絡(luò)節(jié)點,它包括一SNMP代理并且駐留在一個被管理網(wǎng)絡(luò)中。被管理設(shè)備收集并存儲管理信息,并使這些信息對于使用SNMP的管理站點是可用的。被管理設(shè)備有時也叫網(wǎng)絡(luò)元素,它可以是路由器和訪問服務(wù)器、交換機和網(wǎng)橋、總線、計算機主機或打印機。 </p><p><b>
20、; 2.1.2 代理</b></p><p> 代理是一個網(wǎng)絡(luò)管理軟件模塊,它駐留在一個被管理設(shè)備中。代理具有管理信息的本地知識,并把這些信息翻譯成與SNMP兼容的形式。</p><p><b> 2.1.3管理站點</b></p><p> 管理站點監(jiān)測并控制被管理設(shè)備,它提供網(wǎng)絡(luò)管理所需的大部分進程和內(nèi)存資源。管理站點只
21、存在于被管理網(wǎng)絡(luò)上。</p><p> 2.2 SNMP特點分析 </p><p> 簡單網(wǎng)絡(luò)管理協(xié)議SNMP作為網(wǎng)管協(xié)議,它提供了監(jiān)控網(wǎng)絡(luò)和管理網(wǎng)絡(luò)的一整套系統(tǒng)的方法。它有以下特點: </p><p> 1. 簡單性:顧名思義,SNMP相對以前的管理協(xié)議簡單,容易實現(xiàn)且成本低(盡管</p><p> 實際上SNMP并不是太簡單)。&
22、lt;/p><p> 2. 可伸縮性:SNMP可管理絕大部分符合Internet標準的設(shè)備。</p><p> 3. 擴展性:通過定義新的“被管理對象”即MIB,可以非常方便地擴展管理能力。 </p><p> 4. 健壯性:即使在被管理設(shè)備發(fā)生嚴重錯誤時,也不會影響管理者的正常工作。 </p><p> 2.2.1 SNMP v1 &l
23、t;/p><p> SNMP v1出臺后,在短短幾年內(nèi)得到了廣大用戶和廠商的支持。在實踐中,它確實顯示出能管理絕大部分與Internet相連的設(shè)備的強大能力。現(xiàn)今的數(shù)據(jù)通信設(shè)備生產(chǎn)廠家都把他們的產(chǎn)品缺省地兼容SNMP v1。大量的商業(yè)產(chǎn)品軟件都實現(xiàn)這個協(xié)議,使得該協(xié)議的應用越來越廣。從而,SNMP也成為網(wǎng)絡(luò)管理的一個較成功的標準。但隨著SNMP v1的廣泛使用,暴露出SNMP v1的如下缺點</p>
24、<p> 1. 簡單的結(jié)構(gòu) 采用SNMP里確立的功能,只讓一個管理站點執(zhí)行取請求、取下一個請求和置請求命令。利用取請求命令,SNMP管理員能夠請求代理所支持的變量的值。這些變量必須始終予以正確的指示。取下一個請求命令允許讀取代理中的任何對象的直接后繼。此命令大大簡化了讀表的手續(xù),但是它也的確意味著代理中的變量必須加以分類。結(jié)構(gòu)的簡單性導致了實現(xiàn)的復雜性。</p><p> 2. 繁重的網(wǎng)絡(luò)負擔取請求
25、、取下一個請求和置請求命令一般導致網(wǎng)絡(luò)負擔沉重,因為對于每一個所要求的變量,請求和回答報文都要經(jīng)過網(wǎng)絡(luò)發(fā)送。網(wǎng)管應用帶來了沉重的網(wǎng)絡(luò)負擔,占據(jù)了大量的網(wǎng)絡(luò)帶寬。</p><p> 3. 功能的固定分配因為在SNMP v1里,缺少管理員之間的通信,所以只有扁平的網(wǎng)關(guān)結(jié)構(gòu)能夠?qū)崿F(xiàn)。</p><p> 4. 僅用于TCP/IP網(wǎng)絡(luò)在理論上SNMP可用于任何可用的協(xié)議棧上。然而在實踐中,SNM
26、P</p><p> 的內(nèi)部結(jié)構(gòu)(地址、保留端口等)己表現(xiàn)太不靈活,以至難于并入多協(xié)議環(huán)境中。 </p><p> 5. 數(shù)據(jù)的安全性就安全性而言,SNMP v1存在下列問題:SNMP數(shù)據(jù)包的轉(zhuǎn)換、時序的正確性、共同體的假冒、信息的無驗證讀。在由SNMP監(jiān)督與控制的網(wǎng)絡(luò)里,一個未驗證的用戶總是可能捕捉到數(shù)據(jù)包并且為了其目的而修改其信息。在如此轉(zhuǎn)換之后,改變了的數(shù)據(jù)包又被發(fā)送至它們本來的
27、目標站。接收設(shè)備不可能知道此類數(shù)據(jù)的變化。于是它響應包里的信息,猶如是從管理站點直接收到一樣。一般而言,管理站點與相連代理之間的全部數(shù)據(jù),都是采用未加密的用戶數(shù)據(jù)報協(xié)議(UDP)服務(wù)發(fā)送的。由于UDP不保證數(shù)據(jù)順序的正確性,SNMP數(shù)據(jù)要么作為局域網(wǎng)動態(tài)的結(jié)果而被動地、要么經(jīng)過破壞分子的改造而主動地推遲,或以修改了的次序到達接受站點。這樣一來未經(jīng)驗證的用戶總是能隨意地修改數(shù)據(jù)內(nèi)容,而接收站卻無從</p><p>
28、 發(fā)覺這類形式的變化。僅僅通過共同體串的重新定義,網(wǎng)管站的擁有者即可隨時訪問與該網(wǎng)絡(luò)相關(guān)聯(lián)的每一個代理。這種偽裝使一個未予驗證的用戶可以冒充驗證用戶去讀取所有的信息并實施所有的管理操作。代理無從區(qū)分正確的實體和假冒者。由未予驗證的用戶采用數(shù)據(jù)分析儀順帶讀取數(shù)據(jù),這是跟數(shù)據(jù)網(wǎng)絡(luò)相關(guān)聯(lián)的固有問題。一般提供網(wǎng)絡(luò)故障檢修使用的全部功能和設(shè)備,亦可隨時濫用于骯臟的目的。任何數(shù)據(jù)(包括口令)在LAN上均可順帶讀到,隨后加以濫用。</p>
29、;<p> 2.2.2 SNMP v2 </p><p> SNMP v2是原始版本SNMP v1的發(fā)展。1993年,SNMP v2作為一系列建議的互聯(lián)網(wǎng)標準發(fā)表,現(xiàn)在它已經(jīng)是一個標準草案。SNMP v2規(guī)范為創(chuàng)造更先進的管理協(xié)議奠定了基礎(chǔ)。與SNMP v1相比,SNMP v2做了大量功能擴充。</p><p> 1. 擴充的通信模型</p><p&
30、gt; 安全和驗證機制可由網(wǎng)絡(luò)管理員通過伙伴來配置。各種訪問權(quán)限、管理信息庫的透</p><p> 視圖可分別借助伙伴來配置,而且?guī)讉€網(wǎng)絡(luò)管理站可以訪問一個代理。</p><p> 2. 管理信息結(jié)構(gòu)的擴充SNMP v2的管理框架在驗證和授權(quán)方面進行了擴展。 </p><p> 3. 管理站之間的通信在SNMP v2中代理和管理站點之間的嚴格區(qū)分己不復存在,
31、網(wǎng)絡(luò)管理者可同時扮演代理和管理站點進程的角色。這一功能使管理者之間的通信成為可能。</p><p><b> 4. 安全</b></p><p><b> SNMP v2</b></p><p> 中采納了一些安全措施。如MD5算法已用于驗證中。通過組合一種檢查和一時間戳,MD5算法為每個SNMP v2報文形成一個1
32、6字節(jié)的指紋。另外還有一加密選項,從而可阻止網(wǎng)絡(luò)的外部監(jiān)視者了解傳輸?shù)男畔?。進一步的安全措施是在SNMP消息的整個生命期內(nèi)運用時間戳,這用于防止有效信息的重復。還可對所有數(shù)據(jù)進行加密,所提供的加密機制是國家標準化研究所的DES(數(shù)據(jù)加密標準)。</p><p> 5. PDU (協(xié)議數(shù)據(jù)單元)中成批數(shù)據(jù)傳輸作為對老的SNMP命令的補充,在SNMP v2中引入了Bulk操作,通過一次請求就可以讀取整個MIB樹。由
33、于成批數(shù)據(jù)傳輸顯著地減少了要處理的數(shù)據(jù)量,所以為其他數(shù)據(jù)保留了網(wǎng)絡(luò)傳輸容量。 </p><p> 6. 擴充的出錯信號在SNMP v2中對錯誤列表進行了擴充。</p><p> 7. 各種傳輸服務(wù)的使用SNMP v2真正與多協(xié)議因特網(wǎng)相匹配,可適用于多種不同的傳輸協(xié)議。除了基于用戶數(shù)據(jù)報的傳輸映射外,也定義了基于其他協(xié)議使用的SNMP v2:OSI</p><p&g
34、t; 上的SNMP v2DPP上的SNMP v2和Novell-IPX上的SNMP v2。</p><p> 8. 向下兼容性在所有產(chǎn)品完全遷移到SNMP v2之前,所有代碼都用兩種語言予以實現(xiàn)。這樣,SNMP v2代理可以直接與其管理站進行通信,而SNMP v1必須經(jīng)過SNMP語言翻譯器</p><p><b> 才能進行通信。 </b></p>
35、<p><b> 2.3 管理信息庫</b></p><p> <MIB> 管理信息庫(MIB)是網(wǎng)絡(luò)管理中的重要組成部分。每個MIB包含:系統(tǒng)與設(shè)備的狀態(tài)信息,運行的數(shù)據(jù)統(tǒng)計,配置參數(shù)等。通過SNMP的五種命令就可以讀取或設(shè)置MIB</p><p> 庫中變量的值。所以,通過MIB,網(wǎng)絡(luò)管理器對管理對象的管理就簡化為網(wǎng)絡(luò)管理器對被管對象
36、的MIB庫的內(nèi)容的查看和設(shè)置。對不同的設(shè)備,只要它們有相應的代理軟件和統(tǒng)一的MIB,網(wǎng)絡(luò)管理器就可以對它進行統(tǒng)一管理。同時,網(wǎng)絡(luò)管理器對被管對象的控制也通過MIB改變?yōu)閷IB內(nèi)變量值的設(shè)置,這樣就避免了管理協(xié)議定義過多的控制信息,因為新的控制功能可以通過在MIB中增加對應的新的變量來實現(xiàn),而不必增加新的控制信息。大體來說,MIB變量可劃分為兩部分:簡單變量和表格。簡單變量包括諸如賦值的或未賦值的整型變量及字符串之類,也包括一些數(shù)據(jù)結(jié)構(gòu)
37、,它們對應于C語言中的“結(jié)構(gòu)”或PASCAL語言中的“記錄”。表格對應于一維數(shù)組,一張表格可以包含變量的多個實例</p><p> 2.3.1 MIB管理樹所有的MIB對象類型被收集到一個或多個管理信息庫中并且對象類型按照管理信息結(jié)構(gòu)和標識(SMI)定義。一個對象類型的名字明確地代表一個對象,稱為對象標識符。對象標識符是按照在OSI-MIB樹中建立的嚴格分層空間構(gòu)造的,對象標識符總是一個唯一的從樹根開始描述MI
38、B樹的整數(shù)序列。SMI明確要求所有被管理的信息和數(shù)據(jù)都要由管理樹來標識。這棵管理樹來源于OSI的定義,它具有從根開始的嚴格分層化結(jié)構(gòu)。管理樹的分支和葉子是用數(shù)字和字母兩種方式顯示的。數(shù)字化編碼是機器可讀的,字母顯示則更適合于人的眼睛并幫助用戶尋找穿過錯綜復雜分支的路徑與MIB相關(guān)的管理樹的結(jié)構(gòu)如下: </p><p><b> 圖</b></p><p> 2-2
39、 MIB管理樹結(jié)構(gòu)圖</p><p> 2.3.2 MIB對象類</p><p> 在SNMP中管理的對象定義在MIB中。為了方便,這些對象目前分為11類,每一類對應MIB-2下的11個節(jié)點中的一個,新的類型和對象可以繼續(xù)加入。具體如下表</p><p><b> 圖2-3 MIB</b></p><p> 對象
40、類表所以對于所有MIB對象,前面的路徑都為1.3.6.1.2.1。SNMP就是通過這棵命名樹來識別MIB中的不同對象的。例如:變量1.3.6.1.2.1表示IP地址和MAC地址轉(zhuǎn)換表的入口。</p><p> 2.4 抽象句法表示法</p><p> ASN.1 SNMP模型的核心是管理站點和管理代理的對象。對象的定義語言采用ASN.1(Abstract Syntax Notation
41、 One)。ASN.1使得數(shù)據(jù)的描述與系統(tǒng)和廠家無關(guān)。這種一致的數(shù)據(jù)標識意味著聯(lián)入網(wǎng)的所有SNMP終端都可以清楚地理解所傳輸?shù)男畔3]。</p><p> 2.4.1數(shù)據(jù)類型 </p><p> SMI (管理信息結(jié)構(gòu))定義了3種數(shù)據(jù)類型:原語類型、結(jié)構(gòu)類型和自定義的類型。</p><p> 1.原語類型原語ASN. 1類型有Integer(整數(shù))、Octe
42、t String(字節(jié)串)、Object Identifier(對象標識符)和NULL(空)幾種類型。整數(shù)類型主要用于數(shù)值顯示。字節(jié)串類型在SNMP</p><p> 里總是用于顯示一個設(shè)備的軟硬件信息(Display String)或顯示網(wǎng)絡(luò)構(gòu)件的物理地址(PhysAddress)。MIB樹中的每一個標號是用對象標識符描述的,實際上,對象標識符是一個整數(shù)數(shù)值的序列??疹愋捅挥米餍畔俗R,該信息能夠具有某種意義
43、,盡管它不包含任何值。</p><p> 2. 結(jié)構(gòu)類型結(jié)構(gòu)類型是一種用于匯集列表和表格的復合類型。結(jié)構(gòu)類型Sequence允許使用簡單類型的列表:SEQUENCE{<typel>,?,<typeN>} 表格Sequence of是對一些元素組成的抽象數(shù)據(jù)結(jié)構(gòu)的顯示,用entry表示列表名;SEQUENCE OF <entry> </p><p>
44、3. 自定義類型借助于列表和結(jié)構(gòu)類型,其他類型可以從基本類型派生。為此,</p><p> SMI定義了6種復合類型:Network Address(網(wǎng)絡(luò)地址),IP Address(因特網(wǎng)地址),Counter(計數(shù)器),Gauge(量規(guī)),Time Ticks(時間標記),Opaque(模糊)。Counter是32位非負整數(shù)計數(shù)器。從0記到2的32次冪減1(十進制的4294967295),如超出,從0重新計
45、數(shù)。Gauge與Counter類似,但既可遞增計數(shù)也可遞減計數(shù)。Time Ticks表示一個非負的計數(shù)器,按1/100s計數(shù)時間。Opaque的引入是為了繞過由SNMP定義帶來的任何可能的限制。 </p><p> 2.4.2 對象結(jié)構(gòu)和內(nèi)容 </p><p> 管理信息的結(jié)構(gòu)和標識沒有定義各自的被管對象,而定義了它們的形式化結(jié)構(gòu)和內(nèi)容,每個對象類型由5個字段構(gòu)成:對象名、句法、定義、
46、訪問方式和狀態(tài)。對象名與對象標識符總是成對出現(xiàn),句法用于描述對象數(shù)據(jù)類型,定義用于存儲描述被管對象的正文,訪問方式定義對象的訪問字段為只讀、只寫、讀寫或不可訪問,狀態(tài)字段可以是必備、可選或作廢閉。 2.5 SNMP報文操作</p><p> SNMPv2中提供了7種協(xié)議數(shù)據(jù)單元,列舉如下:Get Request,Get Next,Get Bulk,Set Request,Response,Trap和Inform
47、 Request[2]。</p><p> 2.5.1 Get Request報文管理站點利用</p><p> Get Request協(xié)議數(shù)據(jù)單元明確請求SNMP代理的MIB中的己知變量。對象標識符在這類報文中作為參量進行發(fā)送。Get Request的協(xié)議數(shù)據(jù)單元代碼規(guī)定為0。除協(xié)議數(shù)據(jù)單元代碼外, Get Request報文還包含另外4個字段:Request ID(請求標一記),E
48、rror Status(錯誤狀態(tài)),Error Index(錯誤索引),Variable Bindings(變量綁定)。 </p><p> 圖 2-4 Get Request</p><p> 報文請求標記僅用于監(jiān)視未完成的報文。有了這一標記,SNMP就可以將應答與發(fā)出的請求應起來。錯誤狀態(tài)和錯誤索引在Get Request協(xié)議數(shù)據(jù)單元中總是為0。變量綁定字段中定義所需的對象標識符。
49、2.5.2 Get Next 報文管理站點能夠利用Get Net Request命令查詢MIB樹型結(jié)構(gòu)中下一個對象的值,在這種PDU中,以上次己知對象作為標識符而不是所需對象標識符的值作為參量。Get Next操作特別適合于遍歷各個表或快速查詢連續(xù)數(shù)據(jù)對象。對那些不了解的對象,可以針對其前一對象發(fā)出Get Next Requests。</p><p> 圖 2-5 Get Next</p><
50、;p> 報文變量綁定字段包含的是緊接所需對象之前的對象。</p><p> 2.5.3 Get Bulk 報文</p><p> Get Bulk是對Get Next的推廣。有了Get Bulk協(xié)議數(shù)據(jù)單元,就可以對大量數(shù)據(jù)尤其是表格進行更為有效的讀取。與Get Next協(xié)議數(shù)據(jù)單元相比,Get Bulk操作中通過網(wǎng)絡(luò)發(fā)送的包更少。利用Get Bulk,基本重復操作僅局限于代理
51、中。如果在代理中可以用指定的值處理相關(guān)命令,則返回一個Response包從而確認操作有效。除了協(xié)議數(shù)據(jù)單元代碼外,Get Bulk</p><p> 報文還包含另外4個字段:Request ID、Non-Repeaters(非重復者)、Max-Repetitions(最大重復)、Variable Bindings。</p><p> 圖 2-6 Get Bulk 報文</p>
52、;<p> 非重復者參數(shù)指示變量表中有多少變量不必重復。Get Bulk協(xié)議數(shù)據(jù)單元中的重復計數(shù)器定義在代理中Get Next操作應該進行的頻度。然后代理將所請求的變量值封裝在一個Response協(xié)議數(shù)據(jù)單元中。如果Response協(xié)議數(shù)據(jù)單元到達了其最大值,則余下的變量值將被丟棄而必須由管理站再一次請求。 </p><p> 2.5.4 Set Request 報文</p>&l
53、t;p> Set Request命令使管理系統(tǒng)能夠改變代理上指定變量的值。對象標識符作為參量同這種報文一起發(fā)送。如果代理能夠處理帶有規(guī)定值的Set Request命令,則發(fā)回一個Response包從而確認操作有效,如果出錯,則創(chuàng)建一個Response包,并將相關(guān)出錯消息發(fā)回給請求者。 </p><p> 圖 2-7 Set Request 報文變量綁定字段中規(guī)定所需的對象標識符。</p>
54、<p> 2.5.5 Response 報文 </p><p> Response命令是代理能夠?qū)碜怨芾硐到y(tǒng)的所有Get Next,Set Request,Get Bulk或Get Request查詢進行響應。如果代理能夠?qū)⒅付ǖ闹嫡_操作,則錯誤狀態(tài)和錯誤索引的值為0。否則錯誤狀態(tài)和錯誤索引的值被設(shè)為原先預定的值。</p><p> 圖 2-8 Response<
55、/p><p> 報文為錯誤狀態(tài)字段規(guī)定的值在下表中列出:</p><p> 圖 2-9 Response</p><p> 表如果Response協(xié)議數(shù)據(jù)單元中的錯誤狀態(tài)字段為非0值,則說明在剛進行的請求中檢測到有錯誤發(fā)生。錯誤索引字段中含有的附加信息有助于標示錯誤的原因錯誤索引字段值的定義如下:</p><p> 圖 2-10錯誤索引字
56、段 </p><p> 2.5.6 Trap 報文 </p><p> SNMP v2中,如果代理探測到特殊情況,它就向管理站發(fā)出陷阱類型(trap-type)的報文。</p><p> 圖 2-10 Trap 報文 變量綁定字段結(jié)構(gòu)如下</p><p><b> [6]</b></p><p
57、> ?。篠ysUpTime定義了自上次設(shè)備重新引導以來所經(jīng)過的時間。SnmpTrapOID表示相應陷阱的固定名。對象標識符表示一個或多個對象。在RFC1450中,SNMP v2預先定義了若干陷阱:Traps Group陷阱組,那種可以進行配置以便發(fā)送SNMP v2 Trap PDL的代理預先規(guī)定的所有對象均包含在這個陷阱組中。Well Known Traps(周知陷阱),包括:1. cold Start—冷啟動陷阱指示某SNMP
58、v2代理已經(jīng)因配置變化而重新初始化。2. warm Start—熱啟動陷阱指示某SNMP v2代理己重新初始化,但沒有改變配置。3. Link Down—鏈路斷陷阱指示SNMP v2代理己檢測到某條鏈路出了差錯。4. LinkUp-LinkUp陷阱指示配置的某SNMP v2代理的鏈路已被激活。5. authentication Failure—該陷阱指示SNMP v2代理已檢測到在其收到的數(shù)據(jù)包中有驗證錯。6. egpNeighborL
59、oss—該陷阱指示SNMPv2代理已將通信進程讓于某EGP鄰居。2.5.7 Inform Request 報文與SNMP v1不同,</p><p> 3.1 系統(tǒng)可行性的提出 </p><p> 當今網(wǎng)絡(luò)越來越重要,網(wǎng)絡(luò)的規(guī)模、復雜度也越來越大,為了保證網(wǎng)絡(luò)有良好的性能,必須使用網(wǎng)絡(luò)管理系統(tǒng),網(wǎng)絡(luò)管理系統(tǒng)監(jiān)視和控制網(wǎng)絡(luò),即對網(wǎng)絡(luò)進行配置,獲取信息,監(jiān)視網(wǎng)絡(luò)性能,監(jiān)視和管理故障以及進行
60、安全控制。但是,由于歷史的原因,現(xiàn)在的網(wǎng)絡(luò)管理系統(tǒng)存在著缺陷,不同的網(wǎng)絡(luò)運營商擁有各自分割的網(wǎng)管系統(tǒng),有些廠商發(fā)展自己專用的協(xié)議。同時,針對不同的網(wǎng)絡(luò)管理功能,存在著大量功能單一的網(wǎng)絡(luò)管理系統(tǒng)。這些管理功能相互獨立,甚至不同廠家同類設(shè)備間的管理系統(tǒng)也做不到很好的統(tǒng)一。這些情況致使網(wǎng)絡(luò)協(xié)議不兼容,管理信息分離,不能更好的共享管理資源,缺乏對整個網(wǎng)絡(luò)的統(tǒng)一管理,從技術(shù)方面看,管理內(nèi)容龐雜、操作界面多種多樣,從管理方面看,不同的網(wǎng)管系統(tǒng)需要更
61、多的人員學習維護,浪費人力,同時隨著網(wǎng)絡(luò)的復雜度增加,分散管理,不容易進行問題定位和對網(wǎng)絡(luò)的優(yōu)化。針對以上網(wǎng)絡(luò)管理中存在的問題,各網(wǎng)絡(luò)運營商希望能夠在目前網(wǎng)絡(luò)管理基礎(chǔ)上建</p><p> 立一個綜合的網(wǎng)絡(luò)管理系統(tǒng),以實現(xiàn)網(wǎng)絡(luò)管理的統(tǒng)一。這就有了綜合網(wǎng)絡(luò)管理的需求,即把現(xiàn)有的獨立的不同網(wǎng)管系統(tǒng)進行整合,實現(xiàn)兼容和互操作性,形成一個界面友好、功能齊全的網(wǎng)絡(luò)管理系統(tǒng)。而該系統(tǒng)實現(xiàn)了跨平臺,支持多廠商設(shè)備,可以針對本
62、行業(yè)實際需要進行二次開發(fā)。該管理系統(tǒng)能集成國內(nèi),外各種主流網(wǎng)絡(luò)廠商的產(chǎn)品。如Cisco,3COM,華為等。提供了全中文的網(wǎng)絡(luò)管理平臺,符合國內(nèi)客戶的使用習慣,能有效協(xié)助用戶維護網(wǎng)絡(luò)系統(tǒng)正常運行,提高網(wǎng)絡(luò)利用率,幫助用戶更好的利用網(wǎng)絡(luò)為自己服務(wù)。隨著信息時代的到來,對計算機網(wǎng)絡(luò)的依賴使得計算機網(wǎng)絡(luò)本身運行的可靠性變得至關(guān)重要,對網(wǎng)絡(luò)管理也就有了更高的要求。按照OSI的定義,網(wǎng)絡(luò)管理主要包括五個功能域:故障管理、配置管理、性能管理、安全管理
63、和計費管理。在五大功能域中,配置管理是基礎(chǔ),它的主要功能包括發(fā)現(xiàn)網(wǎng)絡(luò)的拓撲結(jié)構(gòu)、監(jiān)視和管理網(wǎng)絡(luò)設(shè)備的配置情況。其它的各項功能都以已知網(wǎng)絡(luò)的拓撲結(jié)構(gòu)為基礎(chǔ)。網(wǎng)絡(luò)拓撲發(fā)現(xiàn)的主要目的是獲取和維護網(wǎng)絡(luò)節(jié)點的存在信息和它們之間的連接關(guān)系信息,并在此基礎(chǔ)上繪制出整個網(wǎng)絡(luò)拓撲圖。網(wǎng)絡(luò)管理人員在拓撲圖的基礎(chǔ)上對故障節(jié)點進行快速定位。 </p><p><b> 3.2 需求分析 </b></p>
64、;<p> 3.2.1 性能管理 </p><p> 性能管理主要負責全網(wǎng)性能監(jiān)視、性能控制和性能分析,完成鏈路性能測試,以及各類性能信息的收集、統(tǒng)計、存儲,性能信息數(shù)據(jù)庫的維護,性能管理閾值的設(shè)置與閾值越過報告,產(chǎn)生按需的性能報告,即提供性能信息查詢功能或周期性的性能報告。為操作人員和管理部門提供網(wǎng)絡(luò)運行狀態(tài)、報文數(shù)統(tǒng)計情況、處理機負荷能力等信息。性能管理模塊需要信息模型模塊和配置管理模塊提供
65、的信息來完成可定制的性能采集以及性能分析報告,還需要向報表模塊提供數(shù)據(jù)用于產(chǎn)生性能統(tǒng)計報表。性能管理子系統(tǒng)原始數(shù)據(jù)有兩類,一類是性能監(jiān)控和分析的數(shù)據(jù),這部分來自數(shù)據(jù)庫,有一個專門的數(shù)據(jù)采集模塊來完成,另一類是實時監(jiān)測數(shù)據(jù)所用到的數(shù)據(jù),這些數(shù)據(jù)直接調(diào)用SNMP數(shù)據(jù)通信模塊從被管設(shè)備那里獲得。</p><p> 3.2.2 報表管理 </p><p> 報表管理系統(tǒng)為管理人員提供從數(shù)據(jù)的收
66、集,報表合并到報表展示生成的一整套報表體系。各個管理模塊使用報表模塊開發(fā)了各種不同管理報表。使用這一報表功能,能為網(wǎng)管人員提供各種不同類型、從不同角度的報表,如性能報表、故障報表、各種日報、周報、月報、年報等。報表管理模塊以直觀的表格和圖形方式顯示故障、性能等各種參數(shù)信息,是網(wǎng)絡(luò)維護人員最為關(guān)心的模塊之一。該報表管理系統(tǒng)可以生成網(wǎng)絡(luò)維護人員想要到得到的各種形式的報表,如匯總報表,各種設(shè)備和接口的屬性報表,可以是歷史也可是實時報表,并且可
67、以保存以可選格式,如Excel、PDF格式等[14]。 </p><p><b> 3.3 系統(tǒng)組成 </b></p><p> 本軟件包括以下子系統(tǒng): </p><p> 1. 拓撲管理子系統(tǒng):包括IP</p><p> 拓撲發(fā)現(xiàn)與自動布局,拓撲圖管理等; </p><p> 2. 告
68、警管理子系統(tǒng):包括告警過濾、分類、排序、查看和直接定位等;</p><p> 3. 配置管理子系統(tǒng):包括對設(shè)備配置數(shù)據(jù)的管理和審計;</p><p> 4. 性能管理子系統(tǒng):檢測被管理設(shè)備的運行狀況,定時或者用戶驅(qū)動的性能數(shù)據(jù)的采集和表現(xiàn); </p><p> 5. 報表管理子系統(tǒng):報表的定制、產(chǎn)生、分發(fā)和展示;</p><p> 6
69、. 系統(tǒng)管理子系統(tǒng):對系統(tǒng)自身的管理包括用戶及其權(quán)限的管理、日志的記錄、數(shù)據(jù)備份、系統(tǒng)冗余; </p><p> 7. 信息模型服務(wù):提供對所有被管理網(wǎng)元(包括網(wǎng)絡(luò)軟件、硬件、應用和服務(wù)對象)的面向?qū)ο蟪橄?、存儲和查詢機制,實現(xiàn)管理對象持久化存儲和管理; </p><p> 8. 協(xié)議適配器:對設(shè)備網(wǎng)絡(luò)管理協(xié)議的統(tǒng)一抽象和描述; </p><p> 9. Ag
70、ent:實現(xiàn)對服務(wù)器及其軟件環(huán)境的監(jiān)控; </p><p> 10..分布式中間件:包括軟件實現(xiàn)結(jié)構(gòu)和分布式計算中必要的服務(wù)如名字解析,事務(wù),消息服務(wù)等,能夠?qū)崿F(xiàn)分布式服務(wù)對象定位和調(diào)用,負載平衡等分布式計算機制; </p><p> 3.4系統(tǒng)總體設(shè)計方案 </p><p> 3.4.1 系統(tǒng)上下文定義 </p><p> 系統(tǒng)與外
71、部環(huán)境[15]:</p><p> 圖3-1 系統(tǒng)和外部環(huán)境</p><p> 系統(tǒng)處于網(wǎng)絡(luò)管理層,實現(xiàn)網(wǎng)絡(luò)層的告警管理、性能管理、拓撲管理、報表管理、配置管理。既可以從網(wǎng)元上直接采集管理數(shù)據(jù),也可以通過標準接口與第三方網(wǎng)元管理系統(tǒng)交互取得管理數(shù)據(jù),也可以驅(qū)動第三方的管理系統(tǒng)實現(xiàn)網(wǎng)元級別的管理。對服務(wù)器及其軟件環(huán)境的管理由私有的Agent實現(xiàn)。向上可以支撐各業(yè)務(wù)系統(tǒng)。 </p&g
72、t;<p> 3.4.2 設(shè)計思路與方法 </p><p> 按照功能需求規(guī)格來決定主要軟件模塊的劃分。將整個軟件系統(tǒng)分為四層:數(shù)據(jù)采集層,數(shù)據(jù)抽象層,數(shù)據(jù)處理層和數(shù)據(jù)表現(xiàn)層;每一層的功能依托于下一層的實現(xiàn),一般不作跨越功能層次的調(diào)用。利用分布式總線實現(xiàn)各個模塊之間的通信。模塊之間通過接口,利用總線進行互操作。總體設(shè)計上先決定功能模塊,然后按照功能模塊設(shè)計其服務(wù)接口;按照功能模塊特點和數(shù)據(jù)流量以
73、及流向決定其部署方式和通信方式;按照性能需求和對移植性、開發(fā)強</p><p> 度的綜合考慮決定中間件和對象服務(wù)的選型。本系統(tǒng)采用自頂向下的設(shè)計方法。首先決定整體構(gòu)架,然后再逐步完善構(gòu)架的基礎(chǔ)上,分模塊完成各個功能模塊的設(shè)計。</p><p> 3.4.3 設(shè)計約束</p><p> 本系統(tǒng)運行于安裝操作系統(tǒng)Linux、Windows、Solaris的PC和
74、服務(wù)器平臺,應用層界面能夠同時運行在以上平臺上;服務(wù)層、中間件、對象服務(wù)、數(shù)據(jù)采集層要求能夠在這三種平臺上以較小修改被移植;網(wǎng)絡(luò)接口,要求運行平臺支持100M以太網(wǎng)接口;在采用集中配置的方案下,網(wǎng)管服務(wù)器應通過網(wǎng)絡(luò)接口與被管理網(wǎng)絡(luò)實現(xiàn)SNMP等管理協(xié)議互通;在采用分布式配置的方案下,網(wǎng)管服務(wù)器應該與分布式數(shù)據(jù)采集機實現(xiàn)基于TCP/IP的網(wǎng)絡(luò)互聯(lián)。本系統(tǒng)的技術(shù)限制是由于采用java實現(xiàn)系統(tǒng),考慮到數(shù)據(jù)網(wǎng)絡(luò)業(yè)務(wù)和協(xié)議融合的趨勢,在設(shè)計上保留
75、擴展以支持其他管理協(xié)議的能力,如TL1、CMIP、MML或者其他私有協(xié)議等,但需要為這些協(xié)議編寫適配層。服務(wù)層主要處理(更新,一致性檢查,匯總)來自各個管理域中以管理信息模型組織的管理信息,并將其處理為面向用戶和應用的數(shù)據(jù)組織,存入數(shù)據(jù)庫。這樣可以將底層數(shù)據(jù)提取、抽象等操作與對用戶請求的響應操作分別處理,提高了應用層的響應速度,屏蔽了底層復雜性。數(shù)據(jù)庫中的信息按照面向應用的方式進行組織,便于備份,查詢。充分采用中間件提供的各種服務(wù)來實現(xiàn)
76、分布式計算中的事務(wù)、并發(fā)控制、名字服務(wù)、持續(xù)性</p><p><b> 性。</b></p><p> 3.4.4 系統(tǒng)框架圖 </p><p> 從軟件體系結(jié)構(gòu)角度看,系統(tǒng)可以分為以下四層: </p><p> 數(shù)據(jù)采集層:本層由各種協(xié)議適配器構(gòu)成,向上層提供統(tǒng)一的接口訪問管理協(xié)議棧(SNMP、CMIP、TL
77、1等),獲取管理信息(包括事件信息、日志信息、性能信息和拓撲信息等),并在初始發(fā)現(xiàn)時作為驅(qū)動模塊構(gòu)建信息模型;數(shù)據(jù)抽象層:對底層數(shù)據(jù)采集的數(shù)據(jù)進行統(tǒng)一的描述,組織為管理信息庫。向上提供一個統(tǒng)一的管理語義和調(diào)用接口。使得各個業(yè)務(wù)模塊面對統(tǒng)一的數(shù)據(jù)模型,使得對資源的管理方式一致并處于單一的可控路徑下,方便對資源進行權(quán)限管理,互斥訪問等操作,使得面向事務(wù)的并發(fā)管理成為可能。內(nèi)部的Adapter Controller作為控制器決定上層的請求應該
78、由哪個適配器處理; 數(shù)據(jù)處理層:專注于管理業(yè)務(wù)的實現(xiàn),不再關(guān)心底層協(xié)議的差異性。響應前臺應用的請求,完成數(shù)據(jù)查詢,處理等功能; 數(shù)據(jù)表現(xiàn)層:前臺界面,從數(shù)據(jù)處理層得到數(shù)據(jù)加以顯示,它是管理員與網(wǎng)絡(luò)管理系統(tǒng)的接口;每一層的功能依托于下一層的實現(xiàn)。每一層包含一組相互操作的組件,每層組件向下層組件獲取服務(wù),并提供服務(wù)給上層組件;層與層之間的服務(wù)訪問點通過明確定義的接口來進行。層次是對系統(tǒng)的一種橫向劃分,從縱向看,針對性能、事件、拓撲、配置、用
79、戶和安全等每個管理功能</p><p> 圖 3-2 軟件體系結(jié)構(gòu)圖</p><p> 數(shù)據(jù)處理層添加視圖處理模塊。配置管理需要對系統(tǒng)的可擴展部分進行配置,比如如何添加一個設(shè)備對象。</p><p> 圖3-2中,系統(tǒng)被刻畫為前臺界面和后臺程序。這是從簡化了軟件部署信息和實際調(diào)用關(guān)系后,按照模塊層次和邏輯關(guān)系畫的系統(tǒng)邏輯結(jié)構(gòu)圖。反映了每個系統(tǒng)組件從邏輯上看處于
80、系統(tǒng)的哪個位置。而在實際應用中,整個系統(tǒng)將按照應用環(huán)境和網(wǎng)絡(luò)管理需求,被部署在一臺或者多臺服務(wù)器和數(shù)據(jù)采集前置機上。從數(shù)據(jù)采集層、數(shù)據(jù)抽象層、數(shù)據(jù)處理層直到數(shù)據(jù)表現(xiàn)層,這些可能分布于不同機器和進程空間的軟件組件,通過公共中間件提供的通信和服務(wù)機制實現(xiàn)互操作。</p><p><b> 3.4.5 模塊</b></p><p> 子系統(tǒng)分解描述 性能管理(Perfo
81、rmance Module):包括性能數(shù)據(jù)采集、實時分析和歷史分析;子模塊:性能管理界面:實時性能管理界面(分析、采集配置);歷史性能管理界面(分析、采集配置);門限配置界面。性能服務(wù):性能數(shù)據(jù)匯總(入庫);性能分析實現(xiàn)(實時分析與轉(zhuǎn)發(fā),歷史分析);性能采集配置(實時,歷史);門限配置(存儲,分發(fā));數(shù)據(jù)采集(實時,歷史采集任務(wù)配置,執(zhí)行);門限檢查;門限事件生成(按照內(nèi)部事件格式);數(shù)據(jù)緩存(歷史數(shù)據(jù));數(shù)據(jù)上報(實時,歷史);性能門
82、限</p><p> 1.get perf item</p><p> 2.schedule collect perf data</p><p> 3.snmp get</p><p> 4.threshold event</p><p> 5.push event</p><p>
83、 圖 3-3性能門限示意圖 </p><p> 說明:性能模塊從信息模型管理器上得到性能指標對象;請求協(xié)議適配器收集性能數(shù)據(jù);協(xié)議適配器從設(shè)備上獲取數(shù)據(jù);如性能越界則發(fā)送性能越界事件給jms;jms將事件推送到告警模塊進行處理。報表管理(Report Manager):包括報表配置,自動生成和分發(fā); 子模塊:報表管理界面:配置,察看界面;報表服務(wù):報表模板配置功能;報表模板管理(存儲,查找);報表任務(wù)配置功能;
84、定時任務(wù)執(zhí)行(報表生成,存放,分發(fā))功能;報表察看響應;1.get alarm data</p><p> 2.get topo data</p><p> 3.get perf data</p><p> 4.get conf data</p><p> 圖 3-4報表產(chǎn)生示意圖</p><p> 產(chǎn)生報表
85、:報表模塊從各個業(yè)務(wù)模塊獲得生產(chǎn)報表的原始數(shù)據(jù),再根據(jù)報表模版生成報表。 3.4.6 模塊</p><p> 子系統(tǒng)間的依賴關(guān)系 各業(yè)務(wù)功能模塊之間的依賴關(guān)系如下圖所示:</p><p> 圖 3-5依賴關(guān)系圖</p><p> 如圖3-5所示,模塊按功能組織,表現(xiàn)為功能之間的依賴關(guān)系。 4. 系統(tǒng)的技術(shù)特點 </p><p><
86、b> 4.1分層的系統(tǒng)</b></p><p> 本系統(tǒng)的特點是業(yè)務(wù)模塊與底層協(xié)議相分離,通過數(shù)據(jù)抽象層為中介對網(wǎng)絡(luò)設(shè)備進行抽象,實現(xiàn)對網(wǎng)絡(luò)資源的集中控制和調(diào)度。 </p><p><b> 4.2信息模型 </b></p><p> 使用了信息模型的觀念來管理整個網(wǎng)絡(luò),使網(wǎng)管的所有業(yè)務(wù)都基于信息模型。使各個業(yè)務(wù)模塊對
87、網(wǎng)絡(luò)的理解一致,便于信息的交互。在信息模型與設(shè)備之間使用適配層來處理設(shè)備管理協(xié)議的差異,適配層與具體的網(wǎng)管業(yè)務(wù)無關(guān),只負責設(shè)備的管理協(xié)議與信息模型的映射。我們需要將所有可管理的資源以被管對象的方式來表現(xiàn),每一個獨立的設(shè)備或業(yè)務(wù)系統(tǒng)是一棵獨立的包含樹。COL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLEA業(yè)務(wù)系統(tǒng)網(wǎng)絡(luò)設(shè)備服務(wù)器 </p><p> 圖 4-1被管對象包含
88、樹</p><p> 整個網(wǎng)絡(luò)有一個根節(jié)點,管理域作為根節(jié)點下的被管對象,所有設(shè)備和業(yè)務(wù)系統(tǒng)都包含到對應的管理域節(jié)點下。COL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLECOL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLECOL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLECOL
89、-ACT-</p><p><b> STA-</b></p><p> 123456789101112</p><p> HS1HS2OK1OK2PS</p><p><b> CONSOLE</b></p><p><b> COL-</b>
90、;</p><p><b> ACT-</b></p><p><b> STA-</b></p><p> 123456789101112</p><p> HS1HS2OK1OK2PS</p><p><b> CONSOLE</b><
91、;/p><p><b> COL-</b></p><p><b> ACT-</b></p><p><b> STA-</b></p><p> 123456789101112</p><p> HS1HS2OK1OK2PS</p>
92、<p><b> CONSOLE</b></p><p><b> 服務(wù)器 </b></p><p><b> 圖 4-2管理域</b></p><p> 以一個管理域為例,信息模型管理器只維護被管對象之間的包含關(guān)系,與業(yè)務(wù)模塊</p><p> 相關(guān)的
93、部分數(shù)據(jù)由業(yè)務(wù)模塊以被管對象為基礎(chǔ)自行維護。</p><p> 如拓撲,維護被管對象之間的連接關(guān)系,配置模塊定義了被管對象之間的依賴關(guān)系。COL-</p><p><b> ACT-</b></p><p><b> STA-</b></p><p> 123456789101112<
94、/p><p> HS1HS2OK1OK2PS</p><p><b> CONSOLE</b></p><p> 服務(wù)器業(yè)務(wù)系統(tǒng)服務(wù)器網(wǎng)絡(luò)設(shè)備網(wǎng)絡(luò)設(shè)備服務(wù)器業(yè)務(wù)系統(tǒng)服務(wù)器port1port2進程1port2拓撲模塊配置模塊信息模型管理器 </p><p><b> 圖4-3連接關(guān)系圖</b>&l
95、t;/p><p> 從邏輯上看整個信息模型是統(tǒng)一的,既包含了網(wǎng)絡(luò)資源的抽象,也包含業(yè)務(wù)數(shù)據(jù)。port1port2進程1 </p><p><b> 圖 4-4邏輯抽象</b></p><p> 這樣使各個業(yè)務(wù)模塊的數(shù)據(jù)可以統(tǒng)一的方式進行共享。當網(wǎng)絡(luò)設(shè)備的端口(port1)發(fā)生故障或性能發(fā)生劣化時,會發(fā)送相應端口事件。故障管理模塊接收到該事件,
96、從拓撲模塊得知該端口對象與服務(wù)器上的端口(port2)有連接關(guān)系,必然對port2造成影響;從配置模塊得知port2 被進程1所依賴,進程1被業(yè)務(wù)系統(tǒng)所依賴,由此可以判斷由于port1的故障或性能劣化必將對業(yè)務(wù)系統(tǒng)造成影響。由此可以有選擇的發(fā)送告警信息,并對告警進行準確的定位。從實現(xiàn)的層面考慮將業(yè)務(wù)數(shù)據(jù)由各業(yè)務(wù)模塊去維護簡化了數(shù)據(jù)抽象層的實現(xiàn),提高</p><p> 信息模型的檢索效率,同時當某業(yè)務(wù)模塊發(fā)生故障
97、、數(shù)據(jù)發(fā)生錯誤時不會影響其他的業(yè)</p><p> 務(wù)模塊,最大限度的保障系統(tǒng)的正常運行。對網(wǎng)絡(luò)設(shè)備的對象化是以我們預先定義的被</p><p> 管對象類為依據(jù)來實現(xiàn)的。每個被管對象類包含公有屬性和私有屬性。私有屬性是為了唯一標識一個對象,并供協(xié)議適配器從網(wǎng)元上獲取數(shù)據(jù)時使用,實例化為被管對象后私有屬性被賦與固定的值。公有屬性是供數(shù)據(jù)處理層使用,定義被管對象所管理的內(nèi)容,實例化為被管
98、對象后不賦值。當數(shù)據(jù)處理層需要讀取或設(shè)置公有屬性的值時由協(xié)議適配器從網(wǎng)元上直接獲得或?qū)懭?。實例化后的管理信息樹如下?lt;/p><p> -type=CISCO 3550</p><p> -EquID=10.0.0.1</p><p><b> -Index=1</b></p><p> -EquID=10.0.
99、0.1</p><p><b> -Index=2</b></p><p> -EquID=10.0.0.1</p><p><b> -Index=24</b></p><p> -EquID=10.0.0.1</p><p> -EquID=10.0.0.1&l
100、t;/p><p> -EquID=10.0.0.1</p><p> -EquID=10.0.0.1</p><p><b> 1</b></p><p><b> 1</b></p><p><b> 1</b></p><p
101、><b> 1</b></p><p><b> 1</b></p><p><b> 1</b></p><p><b> 1</b></p><p><b> 1</b></p><p>&
102、lt;b> 1</b></p><p><b> 1</b></p><p><b> 1</b></p><p><b> 1</b></p><p> 圖 4-6管理信息樹圖</p><p> 需要管理的設(shè)備及其邏輯功能
103、及物理結(jié)構(gòu)被抽象化為被管對象類,系統(tǒng)運行時將這些類實例化為被管對象,所有的對象都可以統(tǒng)一的方式分配權(quán)限。所有的被管對象組成管理信息樹,由協(xié)議適配器根據(jù)預先定義好的被管對象類和實際被管理的資源來構(gòu)造。當數(shù)據(jù)處理層需要從設(shè)備上獲得數(shù)據(jù)時只需要從樹上找到相應的對象,交給協(xié)議適配器即可,每個被管對象中包含相關(guān)的網(wǎng)絡(luò)管理協(xié)議的信息如SNMP OID信息模型管理器實現(xiàn)對象化的接口來創(chuàng)建、維護被管對象樹和被管對象類,持久化機制由管理器提供。業(yè)務(wù)層只需
104、要和信息模型交互。在統(tǒng)一的信息模型之下我們可以實現(xiàn)更為復雜的管理需求,比如基于策略的管理、基于業(yè)務(wù)的管理、對管理活動的事務(wù)化等,同時可以方便的開發(fā)新的業(yè)務(wù)模塊,以及集成第三方的產(chǎn)品,包括硬件產(chǎn)品和軟件產(chǎn)品。同時以信息模型為基礎(chǔ)還可以使業(yè)務(wù)模塊最大限度的獨立開來,單獨提供給市場,以滿足不同客戶的需求,也為更上層的管理系統(tǒng)如NGOSS提供了良好的支持。信息模型包含兩部分: </p><p> 1. 被管對象類及其包
105、含關(guān)系。描述系統(tǒng)可管理的資源; </p><p> 2. 根據(jù)被管對象類生成的被管對象。描述系統(tǒng)目前管理的資源的實例;被管對象類定義的原則:1. 以物理設(shè)備為基礎(chǔ),以物理設(shè)備上需要本網(wǎng)管系統(tǒng)管理的功能模塊為節(jié)點構(gòu)造基</p><p> 本被管對象類;2. 被管對象不包括設(shè)備及其功能實際的信息,只作為它們的抽象表示;</p><p> 3. 被管對象包含低層協(xié)議
106、的詳細信息,這些信息供協(xié)議適配層使用;</p><p> 4. 每個設(shè)備是一棵獨立的包含樹,在做分域管理時,相應的設(shè)備樹被聚合到對應的</p><p><b> 域節(jié)點中;</b></p><p> 5. 被管對象只具有屬性; </p><p> 6. 如果是對業(yè)務(wù)系統(tǒng)或服務(wù)器的管理,也參照上面的原則。 <
107、/p><p><b> 4.3 可擴展性 </b></p><p> 可擴展性體現(xiàn)在以下幾個方面: </p><p> 1. 協(xié)議適配層,可以動態(tài)添加需要的協(xié)議適配器,對系統(tǒng)尚不支持的管理協(xié)議進行處理,向數(shù)據(jù)抽象層提供統(tǒng)一的接口,使得上層模塊無需關(guān)心底層協(xié)議適配器的變化; </p><p> 2. 數(shù)據(jù)抽象層,可以添
108、加新的被管對象類,作為協(xié)議適配器創(chuàng)建被管對象的依據(jù); </p><p> 3. 數(shù)據(jù)處理層,可以動態(tài)添加新的業(yè)務(wù)模塊,以支持用戶的特殊需求;</p><p> 4. 添加一個特殊的SNMP設(shè)備或添加新的功能時,只需要通過系統(tǒng)管理模塊的圖形化界面,在信息模型管理器中定義新的管理類,并聚合到適當?shù)墓?jié)點上,就可以實現(xiàn)</p><p> 對該設(shè)備或功能的管理。<
109、/p><p><b> 4.4技術(shù)框架 </b></p><p> 本系統(tǒng)主要使用java語言實現(xiàn),表現(xiàn)方式主要采用B/S方式。部分需要實時顯示的部分,如告警、實時性能監(jiān)控、實時拓撲更新等要增加基于瀏覽器applet方式作為用戶的可選項。數(shù)據(jù)表現(xiàn)層直接相關(guān)部分采用STRUTS作為框架,負責界面的構(gòu)成。數(shù)據(jù)處理層、數(shù)據(jù)抽象層、數(shù)據(jù)采集層使用EJB3.0作為實現(xiàn)框架。數(shù)據(jù)
110、處理層各模塊:拓撲管理、故障管理、性能管理、系統(tǒng)管理、配置管理使用各自的無狀態(tài)會話Bean向上提供接口。各模塊需要接收消息,使用消息驅(qū)動Bean。數(shù)據(jù)抽象層使用一個無狀態(tài)會話Bean向上和向下提供接口。數(shù)據(jù)采集層將每一個協(xié)議適配器實現(xiàn)為單獨的Resource Adapter。使用中間件提供的JMS作為整個系統(tǒng)的消息轉(zhuǎn)發(fā)中心。中間件使用Jboss4.0.4,需要嵌入服務(wù)器的Agent模塊使用基于ACE+TAO的C++實現(xiàn),提供CORBA接
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 眾賞文庫僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 基于SNMP協(xié)議的網(wǎng)絡(luò)行為管理系統(tǒng).pdf
- 基于SNMP協(xié)議的網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn).pdf
- 基于SNMP協(xié)議的分布式網(wǎng)絡(luò)管理系統(tǒng)設(shè)計與實現(xiàn).pdf
- 基于SNMP協(xié)議的網(wǎng)絡(luò)故障管理系統(tǒng)的設(shè)計與實現(xiàn).pdf
- 基于SNMP協(xié)議進行網(wǎng)絡(luò)管理的研究.pdf
- 基于SNMP協(xié)議的行業(yè)網(wǎng)絡(luò)管理研究.pdf
- 基于SNMP協(xié)議的實驗測控網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn).pdf
- 基于SNMP協(xié)議的網(wǎng)絡(luò)拓撲發(fā)現(xiàn)系統(tǒng)設(shè)計與實現(xiàn).pdf
- 基于snmp的網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn)
- 淺談基于snmp網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn)
- 基于SNMP協(xié)議的網(wǎng)絡(luò)主機系統(tǒng)監(jiān)測管理軟件的設(shè)計與實現(xiàn).pdf
- 基于SNMP協(xié)議可移植的校園網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn).pdf
- 基于SNMP協(xié)議的分布式網(wǎng)絡(luò)管理.pdf
- 基于SNMP協(xié)議的OTA平臺網(wǎng)絡(luò)管理設(shè)計與實現(xiàn).pdf
- 網(wǎng)絡(luò)綜合管理課程設(shè)計
- 基于SNMP的向量網(wǎng)網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計.pdf
- 基于SNMP協(xié)議的網(wǎng)絡(luò)流量監(jiān)控系統(tǒng).pdf
- 基于SNMP網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計和實現(xiàn).pdf
- 網(wǎng)絡(luò)協(xié)議課程設(shè)計基于udp的多人聊天系統(tǒng)源代碼
- 網(wǎng)絡(luò)綜合管理課程設(shè)計
評論
0/150
提交評論