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

1、<p><b>　　摘要</b></p><p>　　伴隨Internet時代的到來，網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展，越來越多的企業(yè)、政府、學(xué)校、個人等都融入到互聯(lián)網(wǎng)當(dāng)中。相比從前的專用網(wǎng)絡(luò)，現(xiàn)在的網(wǎng)絡(luò)已經(jīng)和人們的學(xué)習(xí)，工作及生活密不可分了。而作為整個互聯(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)測

2、和管理整個網(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)行鏈路性能測試，以及各類性能信息的收集、統(tǒng)計(jì)、存儲，性能信息數(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ù)抽象層為中介對網(wǎng)絡(luò)設(shè)備進(jìn)行抽象，實(shí)現(xiàn)對網(wǎng)絡(luò)資源的集中控制和調(diào)度。這是本系統(tǒng)的一大特色。</p><p>　　關(guān)鍵詞：網(wǎng)絡(luò)管理，簡單網(wǎng)絡(luò)協(xié)議（SNMP），性能管理，報(bào)表管理</p><p><b>　　1．緒論</b></p><p>　　1.1 課題背景及目的</p><p&

4、gt;　　眾所周知，網(wǎng)絡(luò)管理的起源來自于美國國防部設(shè)計(jì)的世界上頭幾個包交換網(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ò)活動成為一種必須。在網(wǎng)絡(luò)管理的初期，對網(wǎng)絡(luò)的管理停留在使用ICMP和PING的基礎(chǔ)上，但是隨著網(wǎng)絡(luò)內(nèi)主機(jī)數(shù)據(jù)的不斷增多，這種簡單的工具已經(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ò)。第一個相關(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)品都提供對SNMP的支持，新開發(fā)的具有遠(yuǎn)程管理能力的SNMP是RMON，它使管理人員可以將整個子網(wǎng)進(jìn)行管理，而不是對整個子網(wǎng)內(nèi)的設(shè)備進(jìn)行管理。 SNMP的核心功能是能讓管理員能改變基于SNMP協(xié)議裝置的狀態(tài)，比如說我們可以使用SNMP來關(guān)閉路由器，SNMP還能監(jiān)測交換機(jī)的問題，當(dāng)溫度過高時還能發(fā)出警告。SNMP通常是用來管理路由

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

8、西。遠(yuǎn)程網(wǎng)絡(luò)監(jiān)控（RMON）能幫助我們了解整個網(wǎng)絡(luò)的運(yùn)作和每個設(shè)備在整個網(wǎng)絡(luò)中所起的作用，它不僅用于局域網(wǎng)更應(yīng)用于廣域網(wǎng)。</p><p>　　1.2 發(fā)展現(xiàn)狀和國內(nèi)外研究方向</p><p>　　伴隨Internet時代的到來，網(wǎng)絡(luò)技術(shù)的迅猛發(fā)展，越來越多的企業(yè)。政府、學(xué)校、個人等都融入互聯(lián)網(wǎng)當(dāng)中，相比從前的專用網(wǎng)絡(luò)，現(xiàn)在的網(wǎng)絡(luò)已經(jīng)和人們的學(xué)習(xí)、工作及生活密不可分了。而作為整個互聯(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)測和管理整個網(wǎng)絡(luò)，而管理網(wǎng)絡(luò)就會需要一個適合的網(wǎng)絡(luò)協(xié)議，當(dāng)前最典型的網(wǎng)絡(luò)管理協(xié)議有基于OSI七層模型的公共管理信息協(xié)議（CMIP）和基于TCO/IP的簡單網(wǎng)絡(luò)管理協(xié)議（SNMP）。OSI/CMIP系統(tǒng)管理模型是目前理論上最完備的網(wǎng)絡(luò)管理模型，是其他網(wǎng)絡(luò)管理模型的基本參考。但由于該模型比較復(fù)雜，實(shí)現(xiàn)代價高，因

10、此并沒有得到廣泛的應(yīng)用。相反，當(dāng)初只是為了管理TCP/IP網(wǎng)絡(luò)的SNMP卻得到了迅速的發(fā)展和廣泛應(yīng)用。SNMP網(wǎng)絡(luò)管理模型的突出特點(diǎ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 對象</b></p&g

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

12、信息庫；網(wǎng)絡(luò)管理協(xié)議。管理站一般是一個分立的設(shè)備，也可以利用共享系統(tǒng)實(shí)現(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(yuǎn)程網(wǎng)絡(luò)元素的實(shí)際監(jiān)控的能力；一個從所有被管網(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ò)，即對網(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)營商擁有各自分割的網(wǎng)管系統(tǒng)，有些廠商發(fā)展自己專用的協(xié)議。同時，針對不同的網(wǎng)絡(luò)管理功能，存在著大量功能單一的網(wǎng)絡(luò)管理系統(tǒng)。這些管理功能相互獨(dú)立，甚至不同廠

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

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)兼容和互操作性，形成一個界面友好、</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)一個用戶從局域網(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ù)。同時對于大規(guī)模用戶，會有各種

17、不同的網(wǎng)絡(luò)設(shè)備（包括核心網(wǎng)絡(luò)設(shè)備和邊緣網(wǎng)絡(luò)設(shè)備），不用網(wǎng)絡(luò)設(shè)備，需要有不同的管理和輪詢策略，才能保證實(shí)時管理能力的需要，同時不會對網(wǎng)絡(luò)造成太大的負(fù)載。輪詢間隔管理保證了對骨干網(wǎng)路流量，CPU負(fù)載較高時，網(wǎng)管軟件的運(yùn)行都不會對網(wǎng)絡(luò)性能造成太大的影響</p><p>　　簡單網(wǎng)絡(luò)協(xié)議（SNMP）簡單網(wǎng)絡(luò)管理協(xié)議（SNMP）是一個應(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>　　的簡單模型如下圖所示</p><p>　　圖 2-1

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

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

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

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

23、t;/p><p>　　SNMP v1出臺后，在短短幾年內(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)這個協(xié)議，使得該協(xié)議的應(yīng)用越來越廣。從而，SNMP也成為網(wǎng)絡(luò)管理的一個較成功的標(biāo)準(zhǔn)。但隨著SNMP v1的廣泛使用，暴露出SNMP v1的如下缺點(diǎn)</p>

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

25、、取下一個請求和置請求命令一般導(dǎo)致網(wǎng)絡(luò)負(fù)擔(dān)沉重，因?yàn)閷τ诿恳粋€所要求的變量，請求和回答報(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)換、時序的正確性、共同體的假冒、信息的無驗(yàn)證讀。在由SNMP監(jiān)督與控制的網(wǎng)絡(luò)里，一個未驗(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)動態(tài)的結(jié)果而被動地、要么經(jīng)過破壞分子的改造而主動地推遲，或以修改了的次序到達(dá)接受站點(diǎn)。這樣一來未經(jīng)驗(yàn)證的用戶總是能隨意地修改數(shù)據(jù)內(nèi)容，而接收站卻無從</p><p>

28、　　發(fā)覺這類形式的變化。僅僅通過共同體串的重新定義，網(wǎng)管站的擁有者即可隨時訪問與該網(wǎng)絡(luò)相關(guān)聯(lián)的每一個代理。這種偽裝使一個未予驗(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ù)據(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)是一個標(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ī)讉€網(wǎng)絡(luò)管理站可以訪問一個代理。</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ò)管理者可同時扮演代理和管理站點(diǎn)進(jìn)程的角色。這一功能使管理者之間的通信成為可能。</p><p><b>　　4. 安全</b></p><p><b>　　SNMP v2</b></p><p>　　中采納了一些安全措施。如MD5算法已用于驗(yàn)證中。通過組合一種檢查和一時間戳，MD5算法為每個SNMP v2報(bào)文形成一個1

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

33、于成批數(shù)據(jù)傳輸顯著地減少了要處理的數(shù)據(jù)量，所以為其他數(shù)據(jù)保留了網(wǎng)絡(luò)傳輸容量。 </p><p>　　6. 擴(kuò)充的出錯信號在SNMP v2中對錯誤列表進(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ò)管理中的重要組成部分。每個MIB包含：系統(tǒng)與設(shè)備的狀態(tài)信息，運(yùn)行的數(shù)據(jù)統(tǒng)計(jì)，配置參數(shù)等。通過SNMP的五種命令就可以讀取或設(shè)置MIB</p><p>　　庫中變量的值。所以，通過MIB，網(wǎng)絡(luò)管理器對管理對象的管理就簡化為網(wǎng)絡(luò)管理器對被管對象

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

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

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

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

43、，盡管它不包含任何值。</p><p>　　2. 結(jié)構(gòu)類型結(jié)構(gòu)類型是一種用于匯集列表和表格的復(fù)合類型。結(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種復(fù)合類型：Network Address（網(wǎng)絡(luò)地址），IP Address（因特網(wǎng)地址），Counter（計(jì)數(shù)器），Gauge（量規(guī)），Time Ticks（時間標(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表示一個非負(fù)的計(jì)數(shù)器，按1/100s計(jì)數(shù)時間。Opaque的引入是為了繞過由SNMP定義帶來的任何可能的限制。 </p><p>　　2.4.2 對象結(jié)構(gòu)和內(nèi)容 </p><p>　　管理信息的結(jié)構(gòu)和標(biāo)識沒有定義各自的被管對象，而定義了它們的形式化結(jié)構(gòu)和內(nèi)容，每個對象類型由5個字段構(gòu)成：對象名、句法、定義、

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

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

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

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

51、中。如果在代理中可以用指定的值處理相關(guān)命令，則返回一個Response包從而確認(rèn)操作有效。除了協(xié)議數(shù)據(jù)單元代碼外，Get Bulk</p><p>　　報(bào)文還包含另外4個字段：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)行的頻度。然后代理將所請求的變量值封裝在一個Response協(xié)議數(shù)據(jù)單元中。如果Response協(xié)議數(shù)據(jù)單元到達(dá)了其最大值，則余下的變量值將被丟棄而必須由管理站再一次請求。 </p><p>　　2.5.4 Set Request 報(bào)文</p>&l

53、t;p>　　Set Request命令使管理系統(tǒng)能夠改變代理上指定變量的值。對象標(biāo)識符作為參量同這種報(bào)文一起發(fā)送。如果代理能夠處理帶有規(guī)定值的Set Request命令，則發(fā)回一個Response包從而確認(rèn)操作有效，如果出錯，則創(chuàng)建一個Response包，并將相關(guān)出錯消息發(fā)回給請求者。 </p><p>　　圖 2-7 Set Request 報(bào)文變量綁定字段中規(guī)定所需的對象標(biāo)識符。</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ū)⒅付ǖ闹嫡_操作，則錯誤狀態(tài)和錯誤索引的值為0。否則錯誤狀態(tài)和錯誤索引的值被設(shè)為原先預(yù)定的值。</p><p>　　圖 2-8 Response<

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

56、段 </p><p>　　2.5.6 Trap 報(bào)文 </p><p>　　SNMP v2中，如果代理探測到特殊情況，它就向管理站發(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)過的時間。SnmpTrapOID表示相應(yīng)陷阱的固定名。對象標(biāo)識符表示一個或多個對象。在RFC1450中，SNMP v2預(yù)先定義了若干陷阱：Traps Group陷阱組，那種可以進(jìn)行配置以便發(fā)送SNMP v2 Trap PDL的代理預(yù)先規(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ù)包中有驗(yàn)證錯。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ò)，即對網(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)營商擁有各自分割的網(wǎng)管系統(tǒng)，有些廠商發(fā)展自己專用的協(xié)議。同時，針對不同的網(wǎng)絡(luò)管理功能，存在著大量功能單一的網(wǎng)絡(luò)管理系統(tǒng)。這些管理功能相互獨(dú)立，甚至不同廠家同類設(shè)備間的管理系統(tǒng)也做不到很好的統(tǒng)一。這些情況致使網(wǎng)絡(luò)協(xié)議不兼容，管理信息分離，不能更好的共享管理資源，缺乏對整個網(wǎng)絡(luò)的統(tǒng)一管理，從技術(shù)方面看，管理內(nèi)容龐雜、操作界面多種多樣，從管理方面看，不同的網(wǎng)管系統(tǒng)需要更

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

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

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ǔ)上繪制出整個網(wǎng)絡(luò)拓?fù)鋱D。網(wǎng)絡(luò)管理人員在拓?fù)鋱D的基礎(chǔ)上對故障節(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)視、性能控制和性能分析，完成鏈路性能測試，以及各類性能信息的收集、統(tǒng)計(jì)、存儲，性能信息數(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ù)庫，有一個專門的數(shù)據(jù)采集模塊來完成，另一類是實(shí)時監(jiān)測數(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)表體系。各個管理模塊使用報(bào)表模塊開發(fā)了各種不同管理報(bào)表。使用這一報(bào)表功能，能為網(wǎng)管人員提供各種不同類型、從不同角度的報(bào)表，如性能報(bào)表、故障報(bào)表、各種日報(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í)時報(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)與自動布局，拓?fù)鋱D管理等； </p><p>　　2. 告

68、警管理子系統(tǒng)：包括告警過濾、分類、排序、查看和直接定位等；</p><p>　　3. 配置管理子系統(tǒng)：包括對設(shè)備配置數(shù)據(jù)的管理和審計(jì)；</p><p>　　4. 性能管理子系統(tǒng)：檢測被管理設(shè)備的運(yùn)行狀況，定時或者用戶驅(qū)動的性能數(shù)據(jù)的采集和表現(xiàn)； </p><p>　　5. 報(bào)表管理子系統(tǒng)：報(bào)表的定制、產(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ò)軟件、硬件、應(yīng)用和服務(wù)對象）的面向?qū)ο蟪橄?、存儲和查詢機(jī)制，實(shí)現(xiàn)管理對象持久化存儲和管理； </p><p>　　8. 協(xié)議適配器：對設(shè)備網(wǎng)絡(luò)管理協(xié)議的統(tǒng)一抽象和描述； </p><p>　　9. Ag

70、ent：實(shí)現(xiàn)對服務(wù)器及其軟件環(huán)境的監(jiān)控； </p><p>　　10..分布式中間件：包括軟件實(shí)現(xiàn)結(jié)構(gòu)和分布式計(jì)算中必要的服務(wù)如名字解析，事務(wù)，消息服務(wù)等，能夠?qū)崿F(xiàn)分布式服務(wù)對象定位和調(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ū)動第三方的管理系統(tǒng)實(shí)現(xiàn)網(wǎng)元級別的管理。對服務(wù)器及其軟件環(huán)境的管理由私有的Agent實(shí)現(xiàn)。向上可以支撐各業(yè)務(wù)系統(tǒng)。 </p&g

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

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

74、服務(wù)器平臺，應(yīng)用層界面能夠同時運(yùn)行在以上平臺上；服務(wù)層、中間件、對象服務(wù)、數(shù)據(jù)采集層要求能夠在這三種平臺上以較小修改被移植；網(wǎng)絡(luò)接口，要求運(yùn)行平臺支持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è)計(jì)上保留

75、擴(kuò)展以支持其他管理協(xié)議的能力，如TL1、CMIP、MML或者其他私有協(xié)議等，但需要為這些協(xié)議編寫適配層。服務(wù)層主要處理（更新，一致性檢查，匯總）來自各個管理域中以管理信息模型組織的管理信息，并將其處理為面向用戶和應(yīng)用的數(shù)據(jù)組織，存入數(shù)據(jù)庫。這樣可以將底層數(shù)據(jù)提取、抽象等操作與對用戶請求的響應(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)時作為驅(qū)動模塊構(gòu)建信息模型；數(shù)據(jù)抽象層：對底層數(shù)據(jù)采集的數(shù)據(jù)進(jìn)行統(tǒng)一的描述，組織為管理信息庫。向上提供一個統(tǒng)一的管理語義和調(diào)用接口。使得各個業(yè)務(wù)模塊面對統(tǒng)一的數(shù)據(jù)模型，使得對資源的管理方式一致并處于單一的可控路徑下，方便對資源進(jìn)行權(quán)限管理，互斥訪問等操作，使得面向事務(wù)的并發(fā)管理成為可能。內(nèi)部的Adapter Controller作為控制器決定上層的請求應(yīng)該

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

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

80、系統(tǒng)的哪個位置。而在實(shí)際應(yīng)用中，整個系統(tǒng)將按照應(yīng)用環(huán)境和網(wǎng)絡(luò)管理需求，被部署在一臺或者多臺服務(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í)時性能管理界面（分析、采集配置）；歷史性能管理界面（分析、采集配置）；門限配置界面。性能服務(wù)：性能數(shù)據(jù)匯總（入庫）；性能分析實(shí)現(xiàn)（實(shí)時分析與轉(zhuǎn)發(fā)，歷史分析）；性能采集配置（實(shí)時，歷史）；門限配置（存儲，分發(fā)）；數(shù)據(jù)采集（實(shí)時，歷史采集任務(wù)配置，執(zhí)行）；門限檢查；門限事件生成（按照內(nèi)部事件格式）；數(shù)據(jù)緩存（歷史數(shù)據(jù)）；數(shù)據(jù)上報(bào)（實(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)對象；請求協(xié)議適配器收集性能數(shù)據(jù)；協(xié)議適配器從設(shè)備上獲取數(shù)據(jù)；如性能越界則發(fā)送性能越界事件給jms；jms將事件推送到告警模塊進(jìn)行處理。報(bào)表管理（Report Manager）：包括報(bào)表配置，自動生成和分發(fā)； 子模塊：報(bào)表管理界面：配置，察看界面；報(bào)表服務(wù)：報(bào)表模板配置功能；報(bào)表模板管理（存儲，查找）；報(bào)表任務(wù)配置功能；

84、定時任務(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)表模塊從各個業(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ù)抽象層為中介對網(wǎng)絡(luò)設(shè)備進(jìn)行抽象，實(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)，只負(fù)責(zé)設(shè)備的管理協(xié)議與信息模型的映射。我們需要將所有可管理的資源以被管對象的方式來表現(xiàn)，每一個獨(dú)立的設(shè)備或業(yè)務(wù)系統(tǒng)是一棵獨(dú)立的包含樹。COL-ACT-STA-123456789101112HS1HS2OK1OK2PSCONSOLEA業(yè)務(wù)系統(tǒng)網(wǎng)絡(luò)設(shè)備服務(wù)器 </p><p>　　圖 4-1被管對象包含

88、樹</p><p>　　整個網(wǎng)絡(luò)有一個根節(jié)點(diǎn)，管理域作為根節(jié)點(diǎn)下的被管對象，所有設(shè)備和業(yè)務(wù)系統(tǒng)都包含到對應(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>　　以一個管理域?yàn)槔畔⒛Ｐ凸芾砥髦痪S護(hù)被管對象之間的包含關(guān)系，與業(yè)務(wù)模塊</p><p>　　相關(guān)的

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

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

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

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

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

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

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

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

107、/p><p><b>　　4.3 可擴(kuò)展性 </b></p><p>　　可擴(kuò)展性體現(xiàn)在以下幾個方面： </p><p>　　1. 協(xié)議適配層，可以動態(tài)添加需要的協(xié)議適配器，對系統(tǒng)尚不支持的管理協(xié)議進(jìn)行處理，向數(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)管理模塊的圖形化界面，在信息模型管理器中定義新的管理類，并聚合到適當(dāng)?shù)墓?jié)點(diǎn)上，就可以實(shí)現(xiàn)</p><p>　　對該設(shè)備或功能的管理。<

109、/p><p><b>　　4.4技術(shù)框架 </b></p><p>　　本系統(tǒng)主要使用java語言實(shí)現(xiàn)，表現(xiàn)方式主要采用B/S方式。部分需要實(shí)時顯示的部分，如告警、實(shí)時性能監(jiān)控、實(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)會話Bean向上提供接口。各模塊需要接收消息，使用消息驅(qū)動Bean。數(shù)據(jù)抽象層使用一個無狀態(tài)會話Bean向上和向下提供接口。數(shù)據(jù)采集層將每一個協(xié)議適配器實(shí)現(xiàn)為單獨(dú)的Resource Adapter。使用中間件提供的JMS作為整個系統(tǒng)的消息轉(zhuǎn)發(fā)中心。中間件使用Jboss4.0.4，需要嵌入服務(wù)器的Agent模塊使用基于ACE+TAO的C++實(shí)現(xiàn)，提供CORBA接