基于snmp協(xié)議的綜合網(wǎng)絡(luò)管理系統(tǒng)課程設(shè)計(jì)

1、<p><b>　　摘要</b></p><p>　　伴隨Internet時(shí)代的到來，網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展，越來越多的企業(yè)、政府、學(xué)校、個(gè)人等都融入到互聯(lián)網(wǎng)當(dāng)中。相比從前的專用網(wǎng)絡(luò)，現(xiàn)在的網(wǎng)絡(luò)已經(jīng)和人們的學(xué)習(xí)，工作及生活密不可分了。而作為整個(gè)互聯(lián)網(wǎng)，穩(wěn)定、高效、準(zhǔn)確的運(yùn)行就顯得極為重要。要做到這一點(diǎn)，除了要依靠網(wǎng)絡(luò)設(shè)備本身和網(wǎng)絡(luò)架構(gòu)的可靠性以外，還必須依靠一套有效的網(wǎng)絡(luò)管理手段來監(jiān)測(cè)

2、和管理整個(gè)網(wǎng)絡(luò)。本文介紹的綜合網(wǎng)絡(luò)管理系統(tǒng)應(yīng)用了基于SNMP的網(wǎng)絡(luò)設(shè)備性能管理與報(bào)表生成。性能管理主要負(fù)責(zé)全網(wǎng)性能監(jiān)視、性能控制和性能分析。性能管理還進(jìn)行鏈路性能測(cè)試，以及各類性能信息的收集、統(tǒng)計(jì)、存儲(chǔ)，性能信息數(shù)據(jù)庫的維護(hù)，性能管理閾值的設(shè)置與閾值越過報(bào)告，產(chǎn)生按需的性能報(bào)告。報(bào)表管理系統(tǒng)為管理人員提供從數(shù)據(jù)的收集，報(bào)表合并到報(bào)表展示生成的一整套報(bào)表體系。</p><p>　　本文還著重介紹了本系統(tǒng)的分層和業(yè)務(wù)

3、模塊劃分技術(shù)，使業(yè)務(wù)模塊和底層協(xié)議相分離，通過數(shù)據(jù)抽象層為中介對(duì)網(wǎng)絡(luò)設(shè)備進(jìn)行抽象，實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)資源的集中控制和調(diào)度。這是本系統(tǒng)的一大特色。</p><p>　　關(guān)鍵詞：網(wǎng)絡(luò)管理，簡(jiǎn)單網(wǎng)絡(luò)協(xié)議（SNMP），性能管理，報(bào)表管理</p><p><b>　　1．緒論</b></p><p>　　1.1 課題背景及目的</p><p&

4、gt;　　眾所周知，網(wǎng)絡(luò)管理的起源來自于美國(guó)國(guó)防部設(shè)計(jì)的世界上頭幾個(gè)包交換網(wǎng)之一的ARPANET。在70年代，TCP/IP協(xié)議正式被定為軍方通信標(biāo)準(zhǔn)，隨著此協(xié)議的廣泛使用，網(wǎng)絡(luò)管理成了一件大事。在80年代末和90年代初，網(wǎng)絡(luò)迅速發(fā)展，許多子網(wǎng)數(shù)目的增多使網(wǎng)絡(luò)活動(dòng)成為一種必須。在網(wǎng)絡(luò)管理的初期，對(duì)網(wǎng)絡(luò)的管理停留在使用ICMP和PING的基礎(chǔ)上，但是隨著網(wǎng)絡(luò)內(nèi)主機(jī)數(shù)據(jù)的不斷增多，這種簡(jiǎn)單的工具已經(jīng)不可能完</p><p&

5、gt;　　成網(wǎng)絡(luò)管理的工作了。 </p><p>　　隨著網(wǎng)絡(luò)數(shù)目與網(wǎng)絡(luò)內(nèi)主機(jī)數(shù)目的日益增多，單純依靠一些網(wǎng)絡(luò)專業(yè)進(jìn)行網(wǎng)絡(luò)管理已經(jīng)不可能了，必須有一種通行的網(wǎng)絡(luò)管理標(biāo)準(zhǔn)以及相應(yīng)的管理工具是普通人也能管理網(wǎng)絡(luò)。第一個(gè)相關(guān)的協(xié)議是SGMP，它提供了一種直接監(jiān)視網(wǎng)關(guān)的方法，也因此成了一種通用的網(wǎng)絡(luò)管理工具。下來，有三種可供選擇的管理工具：HEMS，SNMP和建立在TCP/IP基礎(chǔ)上的CMIP（CMOT），因?yàn)樾枰褂肐

6、SO/OSI模型進(jìn)行網(wǎng)絡(luò)管理，SNMP首選CMOT作為管理工具由于基本的SNMP已經(jīng)被廣泛使用了，所有的網(wǎng)絡(luò)產(chǎn)品都提供對(duì)SNMP的支持，新開發(fā)的具有遠(yuǎn)程管理能力的SNMP是RMON，它使管理人員可以將整個(gè)子網(wǎng)進(jìn)行管理，而不是對(duì)整個(gè)子網(wǎng)內(nèi)的設(shè)備進(jìn)行管理。 SNMP的核心功能是能讓管理員能改變基于SNMP協(xié)議裝置的狀態(tài)，比如說我們可以使用SNMP來關(guān)閉路由器，SNMP還能監(jiān)測(cè)交換機(jī)的問題，當(dāng)溫度過高時(shí)還能發(fā)出警告。SNMP通常是用來管理路由

7、器，但是更重要的是它還能用來管理很置，SNMP的前身SGMP，僅僅是用來管理互聯(lián)網(wǎng)路由器，而SNMP卻可以被用來管理Unix系統(tǒng)，Windows系統(tǒng)、打印機(jī)、調(diào)制解調(diào)器、供電器等等。同時(shí)，運(yùn)行在一些</p><p>　　信息的軟件同樣能被其管理，這就讓SNMP不僅僅包括物理硬件同樣也包含軟件，比如web服務(wù)器和數(shù)據(jù)庫。另一個(gè)網(wǎng)絡(luò)管理問題就是網(wǎng)絡(luò)監(jiān)控。網(wǎng)絡(luò)監(jiān)控不同于單個(gè)的路由器，主機(jī)或者是其他設(shè)備，它是一個(gè)整體的東

8、西。遠(yuǎn)程網(wǎng)絡(luò)監(jiān)控（RMON）能幫助我們了解整個(gè)網(wǎng)絡(luò)的運(yùn)作和每個(gè)設(shè)備在整個(gè)網(wǎng)絡(luò)中所起的作用，它不僅用于局域網(wǎng)更應(yīng)用于廣域網(wǎng)。</p><p>　　1.2 發(fā)展現(xiàn)狀和國(guó)內(nèi)外研究方向</p><p>　　伴隨Internet時(shí)代的到來，網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展，越來越多的企業(yè)。政府、學(xué)校、個(gè)人等都融入互聯(lián)網(wǎng)當(dāng)中，相比從前的專用網(wǎng)絡(luò)，現(xiàn)在的網(wǎng)絡(luò)已經(jīng)和人們的學(xué)習(xí)、工作及生活密不可分了。而作為整個(gè)互聯(lián)網(wǎng)、穩(wěn)

9、定、高效、準(zhǔn)確的運(yùn)行就顯得極為重要。要做到這一點(diǎn)，除了要依靠網(wǎng)絡(luò)設(shè)備本身和網(wǎng)絡(luò)架構(gòu)的可靠性以外，還必須依靠一套有效的網(wǎng)絡(luò)管理手段來監(jiān)測(cè)和管理整個(gè)網(wǎng)絡(luò)，而管理網(wǎng)絡(luò)就會(huì)需要一個(gè)適合的網(wǎng)絡(luò)協(xié)議，當(dāng)前最典型的網(wǎng)絡(luò)管理協(xié)議有基于OSI七層模型的公共管理信息協(xié)議（CMIP）和基于TCO/IP的簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議（SNMP）。OSI/CMIP系統(tǒng)管理模型是目前理論上最完備的網(wǎng)絡(luò)管理模型，是其他網(wǎng)絡(luò)管理模型的基本參考。但由于該模型比較復(fù)雜，實(shí)現(xiàn)代價(jià)高，因

10、此并沒有得到廣泛的應(yīng)用。相反，當(dāng)初只是為了管理TCP/IP網(wǎng)絡(luò)的SNMP卻得到了迅速的發(fā)展和廣泛應(yīng)用。SNMP網(wǎng)絡(luò)管理模型的突出特點(diǎn)是簡(jiǎn)單、易于實(shí)現(xiàn)，因此得到廠商的支持。特別是在Internet上的成功應(yīng)用，使得它的重要性越來越突出，已經(jīng)成為事實(shí)上的工業(yè)標(biāo)準(zhǔn)</p><p>　　1.3 課題研究方案</p><p><b>　　1.3.1 對(duì)象</b></p&g

11、t;<p>　　SNMP（Simple Network Management Protocol,簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議）首先是由IETF的研究小組為了解決Internet上的路由器管理問題而提出的。SNMP的設(shè)計(jì)原則是簡(jiǎn)單性和擴(kuò)展性。簡(jiǎn)單性是通過信息類型限制，請(qǐng)求響應(yīng)或協(xié)議而取得。擴(kuò)展性是通過將管理信息模型與協(xié)議，被管理對(duì)象的詳細(xì)規(guī)定（MIB）分離而實(shí)現(xiàn)的。作為一個(gè)基于SNMP的網(wǎng)絡(luò)管理模型包括以下關(guān)鍵元素：管理站；代理者；管理

12、信息庫；網(wǎng)絡(luò)管理協(xié)議。管理站一般是一個(gè)分立的設(shè)備，也可以利用共享系統(tǒng)實(shí)現(xiàn)。管理站作為網(wǎng)絡(luò)管理員與網(wǎng)絡(luò)管理系統(tǒng)的接口，它的基本構(gòu)成為：一組具有分析數(shù)據(jù)，發(fā)現(xiàn)故障等功能的管理程序；一個(gè)用于網(wǎng)絡(luò)管理員監(jiān)控網(wǎng)絡(luò)的接口；將網(wǎng)絡(luò)管理員的要求轉(zhuǎn)變?yōu)閷?duì)遠(yuǎn)程網(wǎng)絡(luò)元素的實(shí)際監(jiān)控的能力；一個(gè)從所有被管網(wǎng)絡(luò)實(shí)體的MIB中抽取信息的數(shù)據(jù)庫。</p><p><b>　　1.3.2 框架 </b></p>

13、<p>　　當(dāng)今網(wǎng)絡(luò)越來越重要，網(wǎng)絡(luò)的規(guī)模、復(fù)雜度也越來越大，為了保證網(wǎng)絡(luò)有良好的性能，必須使用網(wǎng)絡(luò)管理系統(tǒng)，網(wǎng)絡(luò)管理系統(tǒng)監(jiān)視和控制網(wǎng)絡(luò)，即對(duì)網(wǎng)絡(luò)進(jìn)行配置、獲取信息、監(jiān)視網(wǎng)絡(luò)性能、監(jiān)視和管理故障以及進(jìn)行安全控制。但是，由于歷史的原因，現(xiàn)在的網(wǎng)絡(luò)管理系統(tǒng)存在著缺陷，不同的網(wǎng)絡(luò)運(yùn)營(yíng)商擁有各自分割的網(wǎng)管系統(tǒng)，有些廠商發(fā)展自己專用的協(xié)議。同時(shí)，針對(duì)不同的網(wǎng)絡(luò)管理功能，存在著大量功能單一的網(wǎng)絡(luò)管理系統(tǒng)。這些管理功能相互獨(dú)立，甚至不同廠

14、家同類設(shè)備間的管理系統(tǒng)也做不到很好的統(tǒng)一。這些情況致使網(wǎng)絡(luò)協(xié)議不兼容，管理信息分離，不能更好的共享管理資源，缺乏對(duì)整個(gè)網(wǎng)絡(luò)的統(tǒng)一管理，從技術(shù)方面看，管理內(nèi)容龐雜、操作界面多種多樣，從管理方面看，不同的網(wǎng)管系統(tǒng)需要更多的人員學(xué)習(xí)維護(hù)，浪費(fèi)人力，同時(shí)隨著網(wǎng)絡(luò)的復(fù)雜度增加，分散管理，不容易進(jìn)行問題定位和對(duì)網(wǎng)絡(luò)的優(yōu)化針對(duì)以上網(wǎng)絡(luò)管理中存在的問題，各網(wǎng)絡(luò)運(yùn)營(yíng)商希望能夠在目前網(wǎng)絡(luò)管理基礎(chǔ)上建</p><p>　　立一個(gè)綜合的

15、網(wǎng)絡(luò)管理系統(tǒng)，以實(shí)現(xiàn)網(wǎng)絡(luò)管理的統(tǒng)一。這就有了綜合網(wǎng)絡(luò)管理的需求，</p><p>　　即把現(xiàn)有的獨(dú)立的不同網(wǎng)管系統(tǒng)進(jìn)行整合，實(shí)現(xiàn)兼容和互操作性，形成一個(gè)界面友好、</p><p>　　功能齊全的網(wǎng)絡(luò)管理系統(tǒng)。</p><p>　　1.3.3 方案論證</p><p>　　隨著科技的不斷發(fā)展，網(wǎng)絡(luò)的使用和規(guī)模不斷的擴(kuò)大，現(xiàn)在的大部分網(wǎng)管軟件都只

16、有實(shí)現(xiàn)邏輯拓?fù)洌瑳]有網(wǎng)絡(luò)真實(shí)連接和鏈路真實(shí)情況的反映，無法幫助用戶了解和分析問題。而綜合網(wǎng)絡(luò)管理系統(tǒng)的拓?fù)浒l(fā)現(xiàn)過程，采用了物理拓?fù)渌惴ê屯負(fù)鋬?yōu)化算法。真正實(shí)現(xiàn)了用戶最關(guān)心的物理真實(shí)拓?fù)涞默F(xiàn)實(shí)。該系統(tǒng)能展現(xiàn)一個(gè)用戶從局域網(wǎng)到廣域網(wǎng)的所有網(wǎng)絡(luò)設(shè)備的真實(shí)連接情況，鏈接狀態(tài)和鏈接負(fù)載等，能幫助用戶分析問題和解決問題。拓?fù)鋱D不僅真實(shí)的再現(xiàn)了網(wǎng)絡(luò)結(jié)構(gòu)，且在拓?fù)鋱D上網(wǎng)絡(luò)管理人員能方便快速地定位到網(wǎng)絡(luò)故障，有利于網(wǎng)絡(luò)的維護(hù)。同時(shí)對(duì)于大規(guī)模用戶，會(huì)有各種

17、不同的網(wǎng)絡(luò)設(shè)備（包括核心網(wǎng)絡(luò)設(shè)備和邊緣網(wǎng)絡(luò)設(shè)備），不用網(wǎng)絡(luò)設(shè)備，需要有不同的管理和輪詢策略，才能保證實(shí)時(shí)管理能力的需要，同時(shí)不會(huì)對(duì)網(wǎng)絡(luò)造成太大的負(fù)載。輪詢間隔管理保證了對(duì)骨干網(wǎng)路流量，CPU負(fù)載較高時(shí)，網(wǎng)管軟件的運(yùn)行都不會(huì)對(duì)網(wǎng)絡(luò)性能造成太大的影響</p><p>　　簡(jiǎn)單網(wǎng)絡(luò)協(xié)議（SNMP）簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議（SNMP）是一個(gè)應(yīng)用層協(xié)議，是TCP/IP協(xié)議套件的一部分。SNMP協(xié)議的作用是在網(wǎng)絡(luò)構(gòu)件間提供并傳輸管理

18、信息。通常，SNMP協(xié)議可以管理網(wǎng)絡(luò)上所有的SNMP設(shè)備，管理應(yīng)用需要的所有數(shù)據(jù)（狀態(tài)、性能、故障、報(bào)警、報(bào)表等等）都是依靠SNMP協(xié)議在被管理設(shè)備間傳輸?shù)?lt;/p><p>　　2.1 SNMP模型 </p><p><b>　　SNMP</b></p><p>　　的簡(jiǎn)單模型如下圖所示</p><p>　　圖 2-1

19、SNMP簡(jiǎn)單模型圖</p><p>　　2.1.1 被管設(shè)備</p><p>　　被管理設(shè)備是這樣的網(wǎng)絡(luò)節(jié)點(diǎn)，它包括一SNMP代理并且駐留在一個(gè)被管理網(wǎng)絡(luò)中。被管理設(shè)備收集并存儲(chǔ)管理信息，并使這些信息對(duì)于使用SNMP的管理站點(diǎn)是可用的。被管理設(shè)備有時(shí)也叫網(wǎng)絡(luò)元素，它可以是路由器和訪問服務(wù)器、交換機(jī)和網(wǎng)橋、總線、計(jì)算機(jī)主機(jī)或打印機(jī)。 </p><p><b>

20、;　　2.1.2 代理</b></p><p>　　代理是一個(gè)網(wǎng)絡(luò)管理軟件模塊，它駐留在一個(gè)被管理設(shè)備中。代理具有管理信息的本地知識(shí)，并把這些信息翻譯成與SNMP兼容的形式。</p><p><b>　　2.1.3管理站點(diǎn)</b></p><p>　　管理站點(diǎn)監(jiān)測(cè)并控制被管理設(shè)備，它提供網(wǎng)絡(luò)管理所需的大部分進(jìn)程和內(nèi)存資源。管理站點(diǎn)只

21、存在于被管理網(wǎng)絡(luò)上。</p><p>　　2.2 SNMP特點(diǎn)分析 </p><p>　　簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議SNMP作為網(wǎng)管協(xié)議，它提供了監(jiān)控網(wǎng)絡(luò)和管理網(wǎng)絡(luò)的一整套系統(tǒng)的方法。它有以下特點(diǎn)： </p><p>　　1. 簡(jiǎn)單性：顧名思義，SNMP相對(duì)以前的管理協(xié)議簡(jiǎn)單，容易實(shí)現(xiàn)且成本低（盡管</p><p>　　實(shí)際上SNMP并不是太簡(jiǎn)單）。&

22、lt;/p><p>　　2. 可伸縮性：SNMP可管理絕大部分符合Internet標(biāo)準(zhǔn)的設(shè)備。</p><p>　　3. 擴(kuò)展性：通過定義新的“被管理對(duì)象”即MIB，可以非常方便地?cái)U(kuò)展管理能力。 </p><p>　　4. 健壯性：即使在被管理設(shè)備發(fā)生嚴(yán)重錯(cuò)誤時(shí)，也不會(huì)影響管理者的正常工作。 </p><p>　　2.2.1 SNMP v1 &l

23、t;/p><p>　　SNMP v1出臺(tái)后，在短短幾年內(nèi)得到了廣大用戶和廠商的支持。在實(shí)踐中，它確實(shí)顯示出能管理絕大部分與Internet相連的設(shè)備的強(qiáng)大能力?，F(xiàn)今的數(shù)據(jù)通信設(shè)備生產(chǎn)廠家都把他們的產(chǎn)品缺省地兼容SNMP v1。大量的商業(yè)產(chǎn)品軟件都實(shí)現(xiàn)這個(gè)協(xié)議，使得該協(xié)議的應(yīng)用越來越廣。從而，SNMP也成為網(wǎng)絡(luò)管理的一個(gè)較成功的標(biāo)準(zhǔn)。但隨著SNMP v1的廣泛使用，暴露出SNMP v1的如下缺點(diǎn)</p>

24、<p>　　1. 簡(jiǎn)單的結(jié)構(gòu) 采用SNMP里確立的功能，只讓一個(gè)管理站點(diǎn)執(zhí)行取請(qǐng)求、取下一個(gè)請(qǐng)求和置請(qǐng)求命令。利用取請(qǐng)求命令，SNMP管理員能夠請(qǐng)求代理所支持的變量的值。這些變量必須始終予以正確的指示。取下一個(gè)請(qǐng)求命令允許讀取代理中的任何對(duì)象的直接后繼。此命令大大簡(jiǎn)化了讀表的手續(xù)，但是它也的確意味著代理中的變量必須加以分類。結(jié)構(gòu)的簡(jiǎn)單性導(dǎo)致了實(shí)現(xiàn)的復(fù)雜性。</p><p>　　2. 繁重的網(wǎng)絡(luò)負(fù)擔(dān)取請(qǐng)求

25、、取下一個(gè)請(qǐng)求和置請(qǐng)求命令一般導(dǎo)致網(wǎng)絡(luò)負(fù)擔(dān)沉重，因?yàn)閷?duì)于每一個(gè)所要求的變量，請(qǐng)求和回答報(bào)文都要經(jīng)過網(wǎng)絡(luò)發(fā)送。網(wǎng)管應(yīng)用帶來了沉重的網(wǎng)絡(luò)負(fù)擔(dān)，占據(jù)了大量的網(wǎng)絡(luò)帶寬。</p><p>　　3. 功能的固定分配因?yàn)樵赟NMP v1里，缺少管理員之間的通信，所以只有扁平的網(wǎng)關(guān)結(jié)構(gòu)能夠?qū)崿F(xiàn)。</p><p>　　4. 僅用于TCP/IP網(wǎng)絡(luò)在理論上SNMP可用于任何可用的協(xié)議棧上。然而在實(shí)踐中，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)換、時(shí)序的正確性、共同體的假冒、信息的無驗(yàn)證讀。在由SNMP監(jiān)督與控制的網(wǎng)絡(luò)里，一個(gè)未驗(yàn)證的用戶總是可能捕捉到數(shù)據(jù)包并且為了其目的而修改其信息。在如此轉(zhuǎn)換之后，改變了的數(shù)據(jù)包又被發(fā)送至它們本來的

27、目標(biāo)站。接收設(shè)備不可能知道此類數(shù)據(jù)的變化。于是它響應(yīng)包里的信息，猶如是從管理站點(diǎn)直接收到一樣。一般而言，管理站點(diǎn)與相連代理之間的全部數(shù)據(jù)，都是采用未加密的用戶數(shù)據(jù)報(bào)協(xié)議（UDP）服務(wù)發(fā)送的。由于UDP不保證數(shù)據(jù)順序的正確性，SNMP數(shù)據(jù)要么作為局域網(wǎng)動(dòng)態(tài)的結(jié)果而被動(dòng)地、要么經(jīng)過破壞分子的改造而主動(dòng)地推遲，或以修改了的次序到達(dá)接受站點(diǎn)。這樣一來未經(jīng)驗(yàn)證的用戶總是能隨意地修改數(shù)據(jù)內(nèi)容，而接收站卻無從</p><p>

28、　　發(fā)覺這類形式的變化。僅僅通過共同體串的重新定義，網(wǎng)管站的擁有者即可隨時(shí)訪問與該網(wǎng)絡(luò)相關(guān)聯(lián)的每一個(gè)代理。這種偽裝使一個(gè)未予驗(yàn)證的用戶可以冒充驗(yàn)證用戶去讀取所有的信息并實(shí)施所有的管理操作。代理無從區(qū)分正確的實(shí)體和假冒者。由未予驗(yàn)證的用戶采用數(shù)據(jù)分析儀順帶讀取數(shù)據(jù)，這是跟數(shù)據(jù)網(wǎng)絡(luò)相關(guān)聯(lián)的固有問題。一般提供網(wǎng)絡(luò)故障檢修使用的全部功能和設(shè)備，亦可隨時(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)標(biāo)準(zhǔn)發(fā)表，現(xiàn)在它已經(jīng)是一個(gè)標(biāo)準(zhǔn)草案。SNMP v2規(guī)范為創(chuàng)造更先進(jìn)的管理協(xié)議奠定了基礎(chǔ)。與SNMP v1相比，SNMP v2做了大量功能擴(kuò)充。</p><p>　　1. 擴(kuò)充的通信模型</p><p&

30、gt;　　安全和驗(yàn)證機(jī)制可由網(wǎng)絡(luò)管理員通過伙伴來配置。各種訪問權(quán)限、管理信息庫的透</p><p>　　視圖可分別借助伙伴來配置，而且?guī)讉€(gè)網(wǎng)絡(luò)管理站可以訪問一個(gè)代理。</p><p>　　2. 管理信息結(jié)構(gòu)的擴(kuò)充SNMP v2的管理框架在驗(yàn)證和授權(quán)方面進(jìn)行了擴(kuò)展。 </p><p>　　3. 管理站之間的通信在SNMP v2中代理和管理站點(diǎn)之間的嚴(yán)格區(qū)分己不復(fù)存在，

31、網(wǎng)絡(luò)管理者可同時(shí)扮演代理和管理站點(diǎn)進(jìn)程的角色。這一功能使管理者之間的通信成為可能。</p><p><b>　　4. 安全</b></p><p><b>　　SNMP v2</b></p><p>　　中采納了一些安全措施。如MD5算法已用于驗(yàn)證中。通過組合一種檢查和一時(shí)間戳，MD5算法為每個(gè)SNMP v2報(bào)文形成一個(gè)1

32、6字節(jié)的指紋。另外還有一加密選項(xiàng)，從而可阻止網(wǎng)絡(luò)的外部監(jiān)視者了解傳輸?shù)男畔ⅰ＿M(jìn)一步的安全措施是在SNMP消息的整個(gè)生命期內(nèi)運(yùn)用時(shí)間戳，這用于防止有效信息的重復(fù)。還可對(duì)所有數(shù)據(jù)進(jìn)行加密，所提供的加密機(jī)制是國(guó)家標(biāo)準(zhǔn)化研究所的DES（數(shù)據(jù)加密標(biāo)準(zhǔn)）。</p><p>　　5. PDU （協(xié)議數(shù)據(jù)單元）中成批數(shù)據(jù)傳輸作為對(duì)老的SNMP命令的補(bǔ)充，在SNMP v2中引入了Bulk操作，通過一次請(qǐng)求就可以讀取整個(gè)MIB樹。由

33、于成批數(shù)據(jù)傳輸顯著地減少了要處理的數(shù)據(jù)量，所以為其他數(shù)據(jù)保留了網(wǎng)絡(luò)傳輸容量。 </p><p>　　6. 擴(kuò)充的出錯(cuò)信號(hào)在SNMP v2中對(duì)錯(cuò)誤列表進(jìn)行了擴(kuò)充。</p><p>　　7. 各種傳輸服務(wù)的使用SNMP v2真正與多協(xié)議因特網(wǎng)相匹配，可適用于多種不同的傳輸協(xié)議。除了基于用戶數(shù)據(jù)報(bào)的傳輸映射外，也定義了基于其他協(xié)議使用的SNMP v2：OSI</p><p&g

34、t;　　上的SNMP v2DPP上的SNMP v2和Novell-IPX上的SNMP v2。</p><p>　　8. 向下兼容性在所有產(chǎn)品完全遷移到SNMP v2之前，所有代碼都用兩種語言予以實(shí)現(xiàn)。這樣，SNMP v2代理可以直接與其管理站進(jìn)行通信，而SNMP v1必須經(jīng)過SNMP語言翻譯器</p><p><b>　　才能進(jìn)行通信。 </b></p>

35、<p><b>　　2.3 管理信息庫</b></p><p>　　<MIB> 管理信息庫（MIB）是網(wǎng)絡(luò)管理中的重要組成部分。每個(gè)MIB包含：系統(tǒng)與設(shè)備的狀態(tài)信息，運(yùn)行的數(shù)據(jù)統(tǒng)計(jì)，配置參數(shù)等。通過SNMP的五種命令就可以讀取或設(shè)置MIB</p><p>　　庫中變量的值。所以，通過MIB，網(wǎng)絡(luò)管理器對(duì)管理對(duì)象的管理就簡(jiǎn)化為網(wǎng)絡(luò)管理器對(duì)被管對(duì)象

36、的MIB庫的內(nèi)容的查看和設(shè)置。對(duì)不同的設(shè)備，只要它們有相應(yīng)的代理軟件和統(tǒng)一的MIB，網(wǎng)絡(luò)管理器就可以對(duì)它進(jìn)行統(tǒng)一管理。同時(shí)，網(wǎng)絡(luò)管理器對(duì)被管對(duì)象的控制也通過MIB改變?yōu)閷?duì)MIB內(nèi)變量值的設(shè)置，這樣就避免了管理協(xié)議定義過多的控制信息，因?yàn)樾碌目刂乒δ芸梢酝ㄟ^在MIB中增加對(duì)應(yīng)的新的變量來實(shí)現(xiàn)，而不必增加新的控制信息。大體來說，MIB變量可劃分為兩部分：簡(jiǎn)單變量和表格。簡(jiǎn)單變量包括諸如賦值的或未賦值的整型變量及字符串之類，也包括一些數(shù)據(jù)結(jié)構(gòu)

37、，它們對(duì)應(yīng)于C語言中的“結(jié)構(gòu)”或PASCAL語言中的“記錄”。表格對(duì)應(yīng)于一維數(shù)組，一張表格可以包含變量的多個(gè)實(shí)例</p><p>　　2.3.1 MIB管理樹所有的MIB對(duì)象類型被收集到一個(gè)或多個(gè)管理信息庫中并且對(duì)象類型按照管理信息結(jié)構(gòu)和標(biāo)識(shí)（SMI）定義。一個(gè)對(duì)象類型的名字明確地代表一個(gè)對(duì)象，稱為對(duì)象標(biāo)識(shí)符。對(duì)象標(biāo)識(shí)符是按照在OSI-MIB樹中建立的嚴(yán)格分層空間構(gòu)造的，對(duì)象標(biāo)識(shí)符總是一個(gè)唯一的從樹根開始描述MI

38、B樹的整數(shù)序列。SMI明確要求所有被管理的信息和數(shù)據(jù)都要由管理樹來標(biāo)識(shí)。這棵管理樹來源于OSI的定義，它具有從根開始的嚴(yán)格分層化結(jié)構(gòu)。管理樹的分支和葉子是用數(shù)字和字母兩種方式顯示的。數(shù)字化編碼是機(jī)器可讀的，字母顯示則更適合于人的眼睛并幫助用戶尋找穿過錯(cuò)綜復(fù)雜分支的路徑與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對(duì)象類</p><p>　　在SNMP中管理的對(duì)象定義在MIB中。為了方便，這些對(duì)象目前分為11類，每一類對(duì)應(yīng)MIB-2下的11個(gè)節(jié)點(diǎn)中的一個(gè)，新的類型和對(duì)象可以繼續(xù)加入。具體如下表</p><p><b>　　圖2-3 MIB</b></p><p>　　對(duì)象

40、類表所以對(duì)于所有MIB對(duì)象，前面的路徑都為1.3.6.1.2.1。SNMP就是通過這棵命名樹來識(shí)別MIB中的不同對(duì)象的。例如：變量1.3.6.1.2.1表示IP地址和MAC地址轉(zhuǎn)換表的入口。</p><p>　　2.4 抽象句法表示法</p><p>　　ASN.1 SNMP模型的核心是管理站點(diǎn)和管理代理的對(duì)象。對(duì)象的定義語言采用ASN.1（Abstract Syntax Notation

41、 One）。ASN.1使得數(shù)據(jù)的描述與系統(tǒng)和廠家無關(guān)。這種一致的數(shù)據(jù)標(biāo)識(shí)意味著聯(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（對(duì)象標(biāo)識(shí)符）和NULL（空）幾種類型。整數(shù)類型主要用于數(shù)值顯示。字節(jié)串類型在SNMP</p><p>　　里總是用于顯示一個(gè)設(shè)備的軟硬件信息（Display String）或顯示網(wǎng)絡(luò)構(gòu)件的物理地址（PhysAddress）。MIB樹中的每一個(gè)標(biāo)號(hào)是用對(duì)象標(biāo)識(shí)符描述的，實(shí)際上，對(duì)象標(biāo)識(shí)符是一個(gè)整數(shù)數(shù)值的序列。空類型被用作信息標(biāo)識(shí)，該信息能夠具有某種意義

43、，盡管它不包含任何值。</p><p>　　2. 結(jié)構(gòu)類型結(jié)構(gòu)類型是一種用于匯集列表和表格的復(fù)合類型。結(jié)構(gòu)類型Sequence允許使用簡(jiǎn)單類型的列表：SEQUENCE{<typel>，?，<typeN>} 表格Sequence of是對(duì)一些元素組成的抽象數(shù)據(jù)結(jié)構(gòu)的顯示，用entry表示列表名；SEQUENCE OF <entry> </p><p>　　

44、3. 自定義類型借助于列表和結(jié)構(gòu)類型，其他類型可以從基本類型派生。為此，</p><p>　　SMI定義了6種復(fù)合類型：Network Address（網(wǎng)絡(luò)地址），IP Address（因特網(wǎng)地址），Counter（計(jì)數(shù)器），Gauge（量規(guī)），Time Ticks（時(shí)間標(biāo)記），Opaque（模糊）。Counter是32位非負(fù)整數(shù)計(jì)數(shù)器。從0記到2的32次冪減1（十進(jìn)制的4294967295），如超出，從0重新計(jì)

45、數(shù)。Gauge與Counter類似，但既可遞增計(jì)數(shù)也可遞減計(jì)數(shù)。Time Ticks表示一個(gè)非負(fù)的計(jì)數(shù)器，按1/100s計(jì)數(shù)時(shí)間。Opaque的引入是為了繞過由SNMP定義帶來的任何可能的限制。 </p><p>　　2.4.2 對(duì)象結(jié)構(gòu)和內(nèi)容 </p><p>　　管理信息的結(jié)構(gòu)和標(biāo)識(shí)沒有定義各自的被管對(duì)象，而定義了它們的形式化結(jié)構(gòu)和內(nèi)容，每個(gè)對(duì)象類型由5個(gè)字段構(gòu)成：對(duì)象名、句法、定義、

46、訪問方式和狀態(tài)。對(duì)象名與對(duì)象標(biāo)識(shí)符總是成對(duì)出現(xiàn)，句法用于描述對(duì)象數(shù)據(jù)類型，定義用于存儲(chǔ)描述被管對(duì)象的正文，訪問方式定義對(duì)象的訪問字段為只讀、只寫、讀寫或不可訪問，狀態(tài)字段可以是必備、可選或作廢閉。 2.5 SNMP報(bào)文操作</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報(bào)文管理站點(diǎn)利用</p><p>　　Get Request協(xié)議數(shù)據(jù)單元明確請(qǐng)求SNMP代理的MIB中的己知變量。對(duì)象標(biāo)識(shí)符在這類報(bào)文中作為參量進(jìn)行發(fā)送。Get Request的協(xié)議數(shù)據(jù)單元代碼規(guī)定為0。除協(xié)議數(shù)據(jù)單元代碼外， Get Request報(bào)文還包含另外4個(gè)字段：Request ID（請(qǐng)求標(biāo)一記），E

48、rror Status（錯(cuò)誤狀態(tài)），Error Index（錯(cuò)誤索引），Variable Bindings（變量綁定）。 </p><p>　　圖 2-4 Get Request</p><p>　　報(bào)文請(qǐng)求標(biāo)記僅用于監(jiān)視未完成的報(bào)文。有了這一標(biāo)記，SNMP就可以將應(yīng)答與發(fā)出的請(qǐng)求應(yīng)起來。錯(cuò)誤狀態(tài)和錯(cuò)誤索引在Get Request協(xié)議數(shù)據(jù)單元中總是為0。變量綁定字段中定義所需的對(duì)象標(biāo)識(shí)符。

49、2.5.2 Get Next 報(bào)文管理站點(diǎn)能夠利用Get Net Request命令查詢MIB樹型結(jié)構(gòu)中下一個(gè)對(duì)象的值，在這種PDU中，以上次己知對(duì)象作為標(biāo)識(shí)符而不是所需對(duì)象標(biāo)識(shí)符的值作為參量。Get Next操作特別適合于遍歷各個(gè)表或快速查詢連續(xù)數(shù)據(jù)對(duì)象。對(duì)那些不了解的對(duì)象，可以針對(duì)其前一對(duì)象發(fā)出Get Next Requests。</p><p>　　圖 2-5 Get Next</p><

50、;p>　　報(bào)文變量綁定字段包含的是緊接所需對(duì)象之前的對(duì)象。</p><p>　　2.5.3 Get Bulk 報(bào)文</p><p>　　Get Bulk是對(duì)Get Next的推廣。有了Get Bulk協(xié)議數(shù)據(jù)單元，就可以對(duì)大量數(shù)據(jù)尤其是表格進(jìn)行更為有效的讀取。與Get Next協(xié)議數(shù)據(jù)單元相比，Get Bulk操作中通過網(wǎng)絡(luò)發(fā)送的包更少。利用Get Bulk，基本重復(fù)操作僅局限于代理

51、中。如果在代理中可以用指定的值處理相關(guān)命令，則返回一個(gè)Response包從而確認(rèn)操作有效。除了協(xié)議數(shù)據(jù)單元代碼外，Get Bulk</p><p>　　報(bào)文還包含另外4個(gè)字段：Request ID、Non-Repeaters（非重復(fù)者）、Max-Repetitions（最大重復(fù)）、Variable Bindings。</p><p>　　圖 2-6 Get Bulk 報(bào)文</p>

52、;<p>　　非重復(fù)者參數(shù)指示變量表中有多少變量不必重復(fù)。Get Bulk協(xié)議數(shù)據(jù)單元中的重復(fù)計(jì)數(shù)器定義在代理中Get Next操作應(yīng)該進(jìn)行的頻度。然后代理將所請(qǐng)求的變量值封裝在一個(gè)Response協(xié)議數(shù)據(jù)單元中。如果Response協(xié)議數(shù)據(jù)單元到達(dá)了其最大值，則余下的變量值將被丟棄而必須由管理站再一次請(qǐng)求。 </p><p>　　2.5.4 Set Request 報(bào)文</p>&l

53、t;p>　　Set Request命令使管理系統(tǒng)能夠改變代理上指定變量的值。對(duì)象標(biāo)識(shí)符作為參量同這種報(bào)文一起發(fā)送。如果代理能夠處理帶有規(guī)定值的Set Request命令，則發(fā)回一個(gè)Response包從而確認(rèn)操作有效，如果出錯(cuò)，則創(chuàng)建一個(gè)Response包，并將相關(guān)出錯(cuò)消息發(fā)回給請(qǐng)求者。 </p><p>　　圖 2-7 Set Request 報(bào)文變量綁定字段中規(guī)定所需的對(duì)象標(biāo)識(shí)符。</p>

54、<p>　　2.5.5 Response 報(bào)文 </p><p>　　Response命令是代理能夠?qū)碜怨芾硐到y(tǒng)的所有Get Next，Set Request，Get Bulk或Get Request查詢進(jìn)行響應(yīng)。如果代理能夠?qū)⒅付ǖ闹嫡_操作，則錯(cuò)誤狀態(tài)和錯(cuò)誤索引的值為0。否則錯(cuò)誤狀態(tài)和錯(cuò)誤索引的值被設(shè)為原先預(yù)定的值。</p><p>　　圖 2-8 Response<

55、/p><p>　　報(bào)文為錯(cuò)誤狀態(tài)字段規(guī)定的值在下表中列出：</p><p>　　圖 2-9 Response</p><p>　　表如果Response協(xié)議數(shù)據(jù)單元中的錯(cuò)誤狀態(tài)字段為非0值，則說明在剛進(jìn)行的請(qǐng)求中檢測(cè)到有錯(cuò)誤發(fā)生。錯(cuò)誤索引字段中含有的附加信息有助于標(biāo)示錯(cuò)誤的原因錯(cuò)誤索引字段值的定義如下：</p><p>　　圖 2-10錯(cuò)誤索引字

56、段 </p><p>　　2.5.6 Trap 報(bào)文 </p><p>　　SNMP v2中，如果代理探測(cè)到特殊情況，它就向管理站發(fā)出陷阱類型（trap-type）的報(bào)文。</p><p>　　圖 2-10 Trap 報(bào)文 變量綁定字段結(jié)構(gòu)如下</p><p><b>　　[6]</b></p><p

57、>　?。篠ysUpTime定義了自上次設(shè)備重新引導(dǎo)以來所經(jīng)過的時(shí)間。SnmpTrapOID表示相應(yīng)陷阱的固定名。對(duì)象標(biāo)識(shí)符表示一個(gè)或多個(gè)對(duì)象。在RFC1450中，SNMP v2預(yù)先定義了若干陷阱：Traps Group陷阱組，那種可以進(jìn)行配置以便發(fā)送SNMP v2 Trap PDL的代理預(yù)先規(guī)定的所有對(duì)象均包含在這個(gè)陷阱組中。Well Known Traps（周知陷阱），包括：1. cold Start—冷啟動(dòng)陷阱指示某SNMP

58、v2代理已經(jīng)因配置變化而重新初始化。2. warm Start—熱啟動(dòng)陷阱指示某SNMP v2代理己重新初始化，但沒有改變配置。3. Link Down—鏈路斷陷阱指示SNMP v2代理己檢測(cè)到某條鏈路出了差錯(cuò)。4. LinkUp-LinkUp陷阱指示配置的某SNMP v2代理的鏈路已被激活。5. authentication Failure—該陷阱指示SNMP v2代理已檢測(cè)到在其收到的數(shù)據(jù)包中有驗(yàn)證錯(cuò)。6. egpNeighborL

59、oss—該陷阱指示SNMPv2代理已將通信進(jìn)程讓于某EGP鄰居。2.5.7 Inform Request 報(bào)文與SNMP v1不同，</p><p>　　3.1 系統(tǒng)可行性的提出 </p><p>　　當(dāng)今網(wǎng)絡(luò)越來越重要，網(wǎng)絡(luò)的規(guī)模、復(fù)雜度也越來越大，為了保證網(wǎng)絡(luò)有良好的性能，必須使用網(wǎng)絡(luò)管理系統(tǒng)，網(wǎng)絡(luò)管理系統(tǒng)監(jiān)視和控制網(wǎng)絡(luò)，即對(duì)網(wǎng)絡(luò)進(jìn)行配置，獲取信息，監(jiān)視網(wǎng)絡(luò)性能，監(jiān)視和管理故障以及進(jìn)行

60、安全控制。但是，由于歷史的原因，現(xiàn)在的網(wǎng)絡(luò)管理系統(tǒng)存在著缺陷，不同的網(wǎng)絡(luò)運(yùn)營(yíng)商擁有各自分割的網(wǎng)管系統(tǒng)，有些廠商發(fā)展自己專用的協(xié)議。同時(shí)，針對(duì)不同的網(wǎng)絡(luò)管理功能，存在著大量功能單一的網(wǎng)絡(luò)管理系統(tǒng)。這些管理功能相互獨(dú)立，甚至不同廠家同類設(shè)備間的管理系統(tǒng)也做不到很好的統(tǒng)一。這些情況致使網(wǎng)絡(luò)協(xié)議不兼容，管理信息分離，不能更好的共享管理資源，缺乏對(duì)整個(gè)網(wǎng)絡(luò)的統(tǒng)一管理，從技術(shù)方面看，管理內(nèi)容龐雜、操作界面多種多樣，從管理方面看，不同的網(wǎng)管系統(tǒng)需要更

61、多的人員學(xué)習(xí)維護(hù)，浪費(fèi)人力，同時(shí)隨著網(wǎng)絡(luò)的復(fù)雜度增加，分散管理，不容易進(jìn)行問題定位和對(duì)網(wǎng)絡(luò)的優(yōu)化。針對(duì)以上網(wǎng)絡(luò)管理中存在的問題，各網(wǎng)絡(luò)運(yùn)營(yíng)商希望能夠在目前網(wǎng)絡(luò)管理基礎(chǔ)上建</p><p>　　立一個(gè)綜合的網(wǎng)絡(luò)管理系統(tǒng)，以實(shí)現(xiàn)網(wǎng)絡(luò)管理的統(tǒng)一。這就有了綜合網(wǎng)絡(luò)管理的需求，即把現(xiàn)有的獨(dú)立的不同網(wǎng)管系統(tǒng)進(jìn)行整合，實(shí)現(xiàn)兼容和互操作性，形成一個(gè)界面友好、功能齊全的網(wǎng)絡(luò)管理系統(tǒng)。而該系統(tǒng)實(shí)現(xiàn)了跨平臺(tái)，支持多廠商設(shè)備，可以針對(duì)本

62、行業(yè)實(shí)際需要進(jìn)行二次開發(fā)。該管理系統(tǒng)能集成國(guó)內(nèi)，外各種主流網(wǎng)絡(luò)廠商的產(chǎn)品。如Cisco，3COM，華為等。提供了全中文的網(wǎng)絡(luò)管理平臺(tái)，符合國(guó)內(nèi)客戶的使用習(xí)慣，能有效協(xié)助用戶維護(hù)網(wǎng)絡(luò)系統(tǒng)正常運(yùn)行，提高網(wǎng)絡(luò)利用率，幫助用戶更好的利用網(wǎng)絡(luò)為自己服務(wù)。隨著信息時(shí)代的到來，對(duì)計(jì)算機(jī)網(wǎng)絡(luò)的依賴使得計(jì)算機(jī)網(wǎng)絡(luò)本身運(yùn)行的可靠性變得至關(guān)重要，對(duì)網(wǎng)絡(luò)管理也就有了更高的要求。按照OSI的定義，網(wǎng)絡(luò)管理主要包括五個(gè)功能域：故障管理、配置管理、性能管理、安全管理

63、和計(jì)費(fèi)管理。在五大功能域中，配置管理是基礎(chǔ)，它的主要功能包括發(fā)現(xiàn)網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)、監(jiān)視和管理網(wǎng)絡(luò)設(shè)備的配置情況。其它的各項(xiàng)功能都以已知網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)為基礎(chǔ)。網(wǎng)絡(luò)拓?fù)浒l(fā)現(xiàn)的主要目的是獲取和維護(hù)網(wǎng)絡(luò)節(jié)點(diǎn)的存在信息和它們之間的連接關(guān)系信息，并在此基礎(chǔ)上繪制出整個(gè)網(wǎng)絡(luò)拓?fù)鋱D。網(wǎng)絡(luò)管理人員在拓?fù)鋱D的基礎(chǔ)上對(duì)故障節(jié)點(diǎn)進(jìn)行快速定位。 </p><p><b>　　3.2 需求分析 </b></p>

64、;<p>　　3.2.1 性能管理 </p><p>　　性能管理主要負(fù)責(zé)全網(wǎng)性能監(jiān)視、性能控制和性能分析，完成鏈路性能測(cè)試，以及各類性能信息的收集、統(tǒng)計(jì)、存儲(chǔ)，性能信息數(shù)據(jù)庫的維護(hù)，性能管理閾值的設(shè)置與閾值越過報(bào)告，產(chǎn)生按需的性能報(bào)告，即提供性能信息查詢功能或周期性的性能報(bào)告。為操作人員和管理部門提供網(wǎng)絡(luò)運(yùn)行狀態(tài)、報(bào)文數(shù)統(tǒng)計(jì)情況、處理機(jī)負(fù)荷能力等信息。性能管理模塊需要信息模型模塊和配置管理模塊提供

65、的信息來完成可定制的性能采集以及性能分析報(bào)告，還需要向報(bào)表模塊提供數(shù)據(jù)用于產(chǎn)生性能統(tǒng)計(jì)報(bào)表。性能管理子系統(tǒng)原始數(shù)據(jù)有兩類，一類是性能監(jiān)控和分析的數(shù)據(jù)，這部分來自數(shù)據(jù)庫，有一個(gè)專門的數(shù)據(jù)采集模塊來完成，另一類是實(shí)時(shí)監(jiān)測(cè)數(shù)據(jù)所用到的數(shù)據(jù)，這些數(shù)據(jù)直接調(diào)用SNMP數(shù)據(jù)通信模塊從被管設(shè)備那里獲得。</p><p>　　3.2.2 報(bào)表管理 </p><p>　　報(bào)表管理系統(tǒng)為管理人員提供從數(shù)據(jù)的收

66、集，報(bào)表合并到報(bào)表展示生成的一整套報(bào)表體系。各個(gè)管理模塊使用報(bào)表模塊開發(fā)了各種不同管理報(bào)表。使用這一報(bào)表功能，能為網(wǎng)管人員提供各種不同類型、從不同角度的報(bào)表，如性能報(bào)表、故障報(bào)表、各種日?qǐng)?bào)、周報(bào)、月報(bào)、年報(bào)等。報(bào)表管理模塊以直觀的表格和圖形方式顯示故障、性能等各種參數(shù)信息，是網(wǎng)絡(luò)維護(hù)人員最為關(guān)心的模塊之一。該報(bào)表管理系統(tǒng)可以生成網(wǎng)絡(luò)維護(hù)人員想要到得到的各種形式的報(bào)表，如匯總報(bào)表，各種設(shè)備和接口的屬性報(bào)表，可以是歷史也可是實(shí)時(shí)報(bào)表，并且可

67、以保存以可選格式，如Excel、PDF格式等[14]。 </p><p><b>　　3.3 系統(tǒng)組成 </b></p><p>　　本軟件包括以下子系統(tǒng)： </p><p>　　1. 拓?fù)涔芾碜酉到y(tǒng)：包括IP</p><p>　　拓?fù)浒l(fā)現(xiàn)與自動(dòng)布局，拓?fù)鋱D管理等； </p><p>　　2. 告

68、警管理子系統(tǒng)：包括告警過濾、分類、排序、查看和直接定位等；</p><p>　　3. 配置管理子系統(tǒng)：包括對(duì)設(shè)備配置數(shù)據(jù)的管理和審計(jì)；</p><p>　　4. 性能管理子系統(tǒng)：檢測(cè)被管理設(shè)備的運(yùn)行狀況，定時(shí)或者用戶驅(qū)動(dòng)的性能數(shù)據(jù)的采集和表現(xiàn)； </p><p>　　5. 報(bào)表管理子系統(tǒng)：報(bào)表的定制、產(chǎn)生、分發(fā)和展示；</p><p>　　6

69、. 系統(tǒng)管理子系統(tǒng)：對(duì)系統(tǒng)自身的管理包括用戶及其權(quán)限的管理、日志的記錄、數(shù)據(jù)備份、系統(tǒng)冗余； </p><p>　　7. 信息模型服務(wù)：提供對(duì)所有被管理網(wǎng)元（包括網(wǎng)絡(luò)軟件、硬件、應(yīng)用和服務(wù)對(duì)象）的面向?qū)ο蟪橄?、存?chǔ)和查詢機(jī)制，實(shí)現(xiàn)管理對(duì)象持久化存儲(chǔ)和管理； </p><p>　　8. 協(xié)議適配器：對(duì)設(shè)備網(wǎng)絡(luò)管理協(xié)議的統(tǒng)一抽象和描述； </p><p>　　9. Ag

70、ent：實(shí)現(xiàn)對(duì)服務(wù)器及其軟件環(huán)境的監(jiān)控； </p><p>　　10..分布式中間件：包括軟件實(shí)現(xiàn)結(jié)構(gòu)和分布式計(jì)算中必要的服務(wù)如名字解析，事務(wù)，消息服務(wù)等，能夠?qū)崿F(xiàn)分布式服務(wù)對(duì)象定位和調(diào)用，負(fù)載平衡等分布式計(jì)算機(jī)制； </p><p>　　3.4系統(tǒng)總體設(shè)計(jì)方案 </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ò)管理層，實(shí)現(xiàn)網(wǎng)絡(luò)層的告警管理、性能管理、拓?fù)涔芾?、?bào)表管理、配置管理。既可以從網(wǎng)元上直接采集管理數(shù)據(jù)，也可以通過標(biāo)準(zhǔn)接口與第三方網(wǎng)元管理系統(tǒng)交互取得管理數(shù)據(jù)，也可以驅(qū)動(dòng)第三方的管理系統(tǒng)實(shí)現(xiàn)網(wǎng)元級(jí)別的管理。對(duì)服務(wù)器及其軟件環(huán)境的管理由私有的Agent實(shí)現(xiàn)。向上可以支撐各業(yè)務(wù)系統(tǒng)。 </p&g

72、t;<p>　　3.4.2 設(shè)計(jì)思路與方法 </p><p>　　按照功能需求規(guī)格來決定主要軟件模塊的劃分。將整個(gè)軟件系統(tǒng)分為四層：數(shù)據(jù)采集層，數(shù)據(jù)抽象層，數(shù)據(jù)處理層和數(shù)據(jù)表現(xiàn)層；每一層的功能依托于下一層的實(shí)現(xiàn)，一般不作跨越功能層次的調(diào)用。利用分布式總線實(shí)現(xiàn)各個(gè)模塊之間的通信。模塊之間通過接口，利用總線進(jìn)行互操作。總體設(shè)計(jì)上先決定功能模塊，然后按照功能模塊設(shè)計(jì)其服務(wù)接口；按照功能模塊特點(diǎn)和數(shù)據(jù)流量以

73、及流向決定其部署方式和通信方式；按照性能需求和對(duì)移植性、開發(fā)強(qiáng)</p><p>　　度的綜合考慮決定中間件和對(duì)象服務(wù)的選型。本系統(tǒng)采用自頂向下的設(shè)計(jì)方法。首先決定整體構(gòu)架，然后再逐步完善構(gòu)架的基礎(chǔ)上，分模塊完成各個(gè)功能模塊的設(shè)計(jì)。</p><p>　　3.4.3 設(shè)計(jì)約束</p><p>　　本系統(tǒng)運(yùn)行于安裝操作系統(tǒng)Linux、Windows、Solaris的PC和

74、服務(wù)器平臺(tái)，應(yīng)用層界面能夠同時(shí)運(yùn)行在以上平臺(tái)上；服務(wù)層、中間件、對(duì)象服務(wù)、數(shù)據(jù)采集層要求能夠在這三種平臺(tái)上以較小修改被移植；網(wǎng)絡(luò)接口，要求運(yùn)行平臺(tái)支持100M以太網(wǎng)接口；在采用集中配置的方案下，網(wǎng)管服務(wù)器應(yīng)通過網(wǎng)絡(luò)接口與被管理網(wǎng)絡(luò)實(shí)現(xiàn)SNMP等管理協(xié)議互通；在采用分布式配置的方案下，網(wǎng)管服務(wù)器應(yīng)該與分布式數(shù)據(jù)采集機(jī)實(shí)現(xiàn)基于TCP/IP的網(wǎng)絡(luò)互聯(lián)。本系統(tǒng)的技術(shù)限制是由于采用java實(shí)現(xiàn)系統(tǒng)，考慮到數(shù)據(jù)網(wǎng)絡(luò)業(yè)務(wù)和協(xié)議融合的趨勢(shì)，在設(shè)計(jì)上保留

75、擴(kuò)展以支持其他管理協(xié)議的能力，如TL1、CMIP、MML或者其他私有協(xié)議等，但需要為這些協(xié)議編寫適配層。服務(wù)層主要處理（更新，一致性檢查，匯總）來自各個(gè)管理域中以管理信息模型組織的管理信息，并將其處理為面向用戶和應(yīng)用的數(shù)據(jù)組織，存入數(shù)據(jù)庫。這樣可以將底層數(shù)據(jù)提取、抽象等操作與對(duì)用戶請(qǐng)求的響應(yīng)操作分別處理，提高了應(yīng)用層的響應(yīng)速度，屏蔽了底層復(fù)雜性。數(shù)據(jù)庫中的信息按照面向應(yīng)用的方式進(jìn)行組織，便于備份，查詢。充分采用中間件提供的各種服務(wù)來實(shí)現(xiàn)

76、分布式計(jì)算中的事務(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ù)湫畔⒌龋?并在初始發(fā)現(xiàn)時(shí)作為驅(qū)動(dòng)模塊構(gòu)建信息模型；數(shù)據(jù)抽象層：對(duì)底層數(shù)據(jù)采集的數(shù)據(jù)進(jìn)行統(tǒng)一的描述，組織為管理信息庫。向上提供一個(gè)統(tǒng)一的管理語義和調(diào)用接口。使得各個(gè)業(yè)務(wù)模塊面對(duì)統(tǒng)一的數(shù)據(jù)模型，使得對(duì)資源的管理方式一致并處于單一的可控路徑下，方便對(duì)資源進(jìn)行權(quán)限管理，互斥訪問等操作，使得面向事務(wù)的并發(fā)管理成為可能。內(nèi)部的Adapter Controller作為控制器決定上層的請(qǐng)求應(yīng)該

78、由哪個(gè)適配器處理； 數(shù)據(jù)處理層：專注于管理業(yè)務(wù)的實(shí)現(xiàn)，不再關(guān)心底層協(xié)議的差異性。響應(yīng)前臺(tái)應(yīng)用的請(qǐng)求，完成數(shù)據(jù)查詢，處理等功能； 數(shù)據(jù)表現(xiàn)層：前臺(tái)界面，從數(shù)據(jù)處理層得到數(shù)據(jù)加以顯示，它是管理員與網(wǎng)絡(luò)管理系統(tǒng)的接口；每一層的功能依托于下一層的實(shí)現(xiàn)。每一層包含一組相互操作的組件，每層組件向下層組件獲取服務(wù)，并提供服務(wù)給上層組件；層與層之間的服務(wù)訪問點(diǎn)通過明確定義的接口來進(jìn)行。層次是對(duì)系統(tǒng)的一種橫向劃分，從縱向看，針對(duì)性能、事件、拓?fù)?、配置、?/p>

79、戶和安全等每個(gè)管理功能</p><p>　　圖 3-2 軟件體系結(jié)構(gòu)圖</p><p>　　數(shù)據(jù)處理層添加視圖處理模塊。配置管理需要對(duì)系統(tǒng)的可擴(kuò)展部分進(jìn)行配置，比如如何添加一個(gè)設(shè)備對(duì)象。</p><p>　　圖3-2中，系統(tǒng)被刻畫為前臺(tái)界面和后臺(tái)程序。這是從簡(jiǎn)化了軟件部署信息和實(shí)際調(diào)用關(guān)系后，按照模塊層次和邏輯關(guān)系畫的系統(tǒng)邏輯結(jié)構(gòu)圖。反映了每個(gè)系統(tǒng)組件從邏輯上看處于

80、系統(tǒng)的哪個(gè)位置。而在實(shí)際應(yīng)用中，整個(gè)系統(tǒng)將按照應(yīng)用環(huán)境和網(wǎng)絡(luò)管理需求，被部署在一臺(tái)或者多臺(tái)服務(wù)器和數(shù)據(jù)采集前置機(jī)上。從數(shù)據(jù)采集層、數(shù)據(jù)抽象層、數(shù)據(jù)處理層直到數(shù)據(jù)表現(xiàn)層，這些可能分布于不同機(jī)器和進(jìn)程空間的軟件組件，通過公共中間件提供的通信和服務(wù)機(jī)制實(shí)現(xiàn)互操作。</p><p><b>　　3.4.5 模塊</b></p><p>　　子系統(tǒng)分解描述 性能管理（Perfo

81、rmance Module）：包括性能數(shù)據(jù)采集、實(shí)時(shí)分析和歷史分析；子模塊：性能管理界面：實(shí)時(shí)性能管理界面（分析、采集配置）；歷史性能管理界面（分析、采集配置）；門限配置界面。性能服務(wù)：性能數(shù)據(jù)匯總（入庫）；性能分析實(shí)現(xiàn)（實(shí)時(shí)分析與轉(zhuǎn)發(fā)，歷史分析）；性能采集配置（實(shí)時(shí)，歷史）；門限配置（存儲(chǔ)，分發(fā)）；數(shù)據(jù)采集（實(shí)時(shí)，歷史采集任務(wù)配置，執(zhí)行）；門限檢查；門限事件生成（按照內(nèi)部事件格式）；數(shù)據(jù)緩存（歷史數(shù)據(jù)）；數(shù)據(jù)上報(bào)（實(shí)時(shí)，歷史）；性能門

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>　　說明：性能模塊從信息模型管理器上得到性能指標(biāo)對(duì)象；請(qǐng)求協(xié)議適配器收集性能數(shù)據(jù)；協(xié)議適配器從設(shè)備上獲取數(shù)據(jù)；如性能越界則發(fā)送性能越界事件給jms；jms將事件推送到告警模塊進(jìn)行處理。報(bào)表管理（Report Manager）：包括報(bào)表配置，自動(dòng)生成和分發(fā)； 子模塊：報(bào)表管理界面：配置，察看界面；報(bào)表服務(wù)：報(bào)表模板配置功能；報(bào)表模板管理（存儲(chǔ)，查找）；報(bào)表任務(wù)配置功能；

84、定時(shí)任務(wù)執(zhí)行（報(bào)表生成，存放，分發(fā)）功能；報(bào)表察看響應(yīng)；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報(bào)表產(chǎn)生示意圖</p><p>　　產(chǎn)生報(bào)表

85、：報(bào)表模塊從各個(gè)業(yè)務(wù)模塊獲得生產(chǎn)報(bào)表的原始數(shù)據(jù)，再根據(jù)報(bào)表模版生成報(bào)表。 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ù)特點(diǎn) </p><p><

86、b>　　4.1分層的系統(tǒng)</b></p><p>　　本系統(tǒng)的特點(diǎn)是業(yè)務(wù)模塊與底層協(xié)議相分離，通過數(shù)據(jù)抽象層為中介對(duì)網(wǎng)絡(luò)設(shè)備進(jìn)行抽象，實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)資源的集中控制和調(diào)度。 </p><p><b>　　4.2信息模型 </b></p><p>　　使用了信息模型的觀念來管理整個(gè)網(wǎng)絡(luò)，使網(wǎng)管的所有業(yè)務(wù)都基于信息模型。使各個(gè)業(yè)務(wù)模塊對(duì)

87、網(wǎng)絡(luò)的理解一致，便于信息的交互。在信息模型與設(shè)備之間使用適配層來處理設(shè)備管理協(xié)議的差異，適配層與具體的網(wǎng)管業(yè)務(wù)無關(guān)，只負(fù)責(zé)設(shè)備的管理協(xié)議與信息模型的映射。我們需要將所有可管理的資源以被管對(duì)象的方式來表現(xiàn)，每一個(gè)獨(dú)立的設(shè)備或業(yè)務(wù)系統(tǒng)是一棵獨(dú)立的包含樹。COL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLEA業(yè)務(wù)系統(tǒng)網(wǎng)絡(luò)設(shè)備服務(wù)器 </p><p>　　圖 4-1被管對(duì)象包含

88、樹</p><p>　　整個(gè)網(wǎng)絡(luò)有一個(gè)根節(jié)點(diǎn)，管理域作為根節(jié)點(diǎn)下的被管對(duì)象，所有設(shè)備和業(yè)務(wù)系統(tǒng)都包含到對(duì)應(yīng)的管理域節(jié)點(diǎn)下。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>　　以一個(gè)管理域?yàn)槔?，信息模型管理器只維護(hù)被管對(duì)象之間的包含關(guān)系，與業(yè)務(wù)模塊</p><p>　　相關(guān)的

93、部分?jǐn)?shù)據(jù)由業(yè)務(wù)模塊以被管對(duì)象為基礎(chǔ)自行維護(hù)。</p><p>　　如拓?fù)?，維護(hù)被管對(duì)象之間的連接關(guān)系，配置模塊定義了被管對(duì)象之間的依賴關(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進(jìn)程1port2拓?fù)淠K配置模塊信息模型管理器 </p><p><b>　　圖4-3連接關(guān)系圖</b>&l

95、t;/p><p>　　從邏輯上看整個(gè)信息模型是統(tǒng)一的，既包含了網(wǎng)絡(luò)資源的抽象，也包含業(yè)務(wù)數(shù)據(jù)。port1port2進(jìn)程1 </p><p><b>　　圖 4-4邏輯抽象</b></p><p>　　這樣使各個(gè)業(yè)務(wù)模塊的數(shù)據(jù)可以統(tǒng)一的方式進(jìn)行共享。當(dāng)網(wǎng)絡(luò)設(shè)備的端口（port1）發(fā)生故障或性能發(fā)生劣化時(shí)，會(huì)發(fā)送相應(yīng)端口事件。故障管理模塊接收到該事件，

96、從拓?fù)淠K得知該端口對(duì)象與服務(wù)器上的端口（port2）有連接關(guān)系，必然對(duì)port2造成影響；從配置模塊得知port2 被進(jìn)程1所依賴，進(jìn)程1被業(yè)務(wù)系統(tǒng)所依賴，由此可以判斷由于port1的故障或性能劣化必將對(duì)業(yè)務(wù)系統(tǒng)造成影響。由此可以有選擇的發(fā)送告警信息，并對(duì)告警進(jìn)行準(zhǔn)確的定位。從實(shí)現(xiàn)的層面考慮將業(yè)務(wù)數(shù)據(jù)由各業(yè)務(wù)模塊去維護(hù)簡(jiǎn)化了數(shù)據(jù)抽象層的實(shí)現(xiàn)，提高</p><p>　　信息模型的檢索效率，同時(shí)當(dāng)某業(yè)務(wù)模塊發(fā)生故障

97、、數(shù)據(jù)發(fā)生錯(cuò)誤時(shí)不會(huì)影響其他的業(yè)</p><p>　　務(wù)模塊，最大限度的保障系統(tǒng)的正常運(yùn)行。對(duì)網(wǎng)絡(luò)設(shè)備的對(duì)象化是以我們預(yù)先定義的被</p><p>　　管對(duì)象類為依據(jù)來實(shí)現(xiàn)的。每個(gè)被管對(duì)象類包含公有屬性和私有屬性。私有屬性是為了唯一標(biāo)識(shí)一個(gè)對(duì)象，并供協(xié)議適配器從網(wǎng)元上獲取數(shù)據(jù)時(shí)使用，實(shí)例化為被管對(duì)象后私有屬性被賦與固定的值。公有屬性是供數(shù)據(jù)處理層使用，定義被管對(duì)象所管理的內(nèi)容，實(shí)例化為被管

98、對(duì)象后不賦值。當(dāng)數(shù)據(jù)處理層需要讀取或設(shè)置公有屬性的值時(shí)由協(xié)議適配器從網(wǎng)元上直接獲得或?qū)懭搿?shí)例化后的管理信息樹如下：</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)被抽象化為被管對(duì)象類，系統(tǒng)運(yùn)行時(shí)將這些類實(shí)例化為被管對(duì)象，所有的對(duì)象都可以統(tǒng)一的方式分配權(quán)限。所有的被管對(duì)象組成管理信息樹，由協(xié)議適配器根據(jù)預(yù)先定義好的被管對(duì)象類和實(shí)際被管理的資源來構(gòu)造。當(dāng)數(shù)據(jù)處理層需要從設(shè)備上獲得數(shù)據(jù)時(shí)只需要從樹上找到相應(yīng)的對(duì)象，交給協(xié)議適配器即可，每個(gè)被管對(duì)象中包含相關(guān)的網(wǎng)絡(luò)管理協(xié)議的信息如SNMP OID信息模型管理器實(shí)現(xiàn)對(duì)象化的接口來創(chuàng)建、維護(hù)被管對(duì)象樹和被管對(duì)象類，持久化機(jī)制由管理器提供。業(yè)務(wù)層只需

104、要和信息模型交互。在統(tǒng)一的信息模型之下我們可以實(shí)現(xiàn)更為復(fù)雜的管理需求，比如基于策略的管理、基于業(yè)務(wù)的管理、對(duì)管理活動(dòng)的事務(wù)化等，同時(shí)可以方便的開發(fā)新的業(yè)務(wù)模塊，以及集成第三方的產(chǎn)品，包括硬件產(chǎn)品和軟件產(chǎn)品。同時(shí)以信息模型為基礎(chǔ)還可以使業(yè)務(wù)模塊最大限度的獨(dú)立開來，單獨(dú)提供給市場(chǎng)，以滿足不同客戶的需求，也為更上層的管理系統(tǒng)如NGOSS提供了良好的支持。信息模型包含兩部分： </p><p>　　1. 被管對(duì)象類及其包

105、含關(guān)系。描述系統(tǒng)可管理的資源； </p><p>　　2. 根據(jù)被管對(duì)象類生成的被管對(duì)象。描述系統(tǒng)目前管理的資源的實(shí)例；被管對(duì)象類定義的原則：1. 以物理設(shè)備為基礎(chǔ)，以物理設(shè)備上需要本網(wǎng)管系統(tǒng)管理的功能模塊為節(jié)點(diǎn)構(gòu)造基</p><p>　　本被管對(duì)象類；2. 被管對(duì)象不包括設(shè)備及其功能實(shí)際的信息，只作為它們的抽象表示；</p><p>　　3. 被管對(duì)象包含低層協(xié)議

106、的詳細(xì)信息，這些信息供協(xié)議適配層使用；</p><p>　　4. 每個(gè)設(shè)備是一棵獨(dú)立的包含樹，在做分域管理時(shí)，相應(yīng)的設(shè)備樹被聚合到對(duì)應(yīng)的</p><p><b>　　域節(jié)點(diǎn)中；</b></p><p>　　5. 被管對(duì)象只具有屬性； </p><p>　　6. 如果是對(duì)業(yè)務(wù)系統(tǒng)或服務(wù)器的管理，也參照上面的原則。 <

107、/p><p><b>　　4.3 可擴(kuò)展性 </b></p><p>　　可擴(kuò)展性體現(xiàn)在以下幾個(gè)方面： </p><p>　　1. 協(xié)議適配層，可以動(dòng)態(tài)添加需要的協(xié)議適配器，對(duì)系統(tǒng)尚不支持的管理協(xié)議進(jìn)行處理，向數(shù)據(jù)抽象層提供統(tǒng)一的接口，使得上層模塊無需關(guān)心底層協(xié)議適配器的變化； </p><p>　　2. 數(shù)據(jù)抽象層，可以添

108、加新的被管對(duì)象類，作為協(xié)議適配器創(chuàng)建被管對(duì)象的依據(jù)； </p><p>　　3. 數(shù)據(jù)處理層，可以動(dòng)態(tài)添加新的業(yè)務(wù)模塊，以支持用戶的特殊需求；</p><p>　　4. 添加一個(gè)特殊的SNMP設(shè)備或添加新的功能時(shí)，只需要通過系統(tǒng)管理模塊的圖形化界面，在信息模型管理器中定義新的管理類，并聚合到適當(dāng)?shù)墓?jié)點(diǎn)上，就可以實(shí)現(xiàn)</p><p>　　對(duì)該設(shè)備或功能的管理。<

109、/p><p><b>　　4.4技術(shù)框架 </b></p><p>　　本系統(tǒng)主要使用java語言實(shí)現(xiàn)，表現(xiàn)方式主要采用B/S方式。部分需要實(shí)時(shí)顯示的部分，如告警、實(shí)時(shí)性能監(jiān)控、實(shí)時(shí)拓?fù)涓碌纫黾踊跒g覽器applet方式作為用戶的可選項(xiàng)。數(shù)據(jù)表現(xiàn)層直接相關(guān)部分采用STRUTS作為框架，負(fù)責(zé)界面的構(gòu)成。數(shù)據(jù)處理層、數(shù)據(jù)抽象層、數(shù)據(jù)采集層使用EJB3.0作為實(shí)現(xiàn)框架。數(shù)據(jù)

110、處理層各模塊：拓?fù)涔芾?、故障管理、性能管理、系統(tǒng)管理、配置管理使用各自的無狀態(tài)會(huì)話Bean向上提供接口。各模塊需要接收消息，使用消息驅(qū)動(dòng)Bean。數(shù)據(jù)抽象層使用一個(gè)無狀態(tài)會(huì)話Bean向上和向下提供接口。數(shù)據(jù)采集層將每一個(gè)協(xié)議適配器實(shí)現(xiàn)為單獨(dú)的Resource Adapter。使用中間件提供的JMS作為整個(gè)系統(tǒng)的消息轉(zhuǎn)發(fā)中心。中間件使用Jboss4.0.4，需要嵌入服務(wù)器的Agent模塊使用基于ACE+TAO的C++實(shí)現(xiàn)，提供CORBA接