通信集群服務器監(jiān)視系統(tǒng)研究范文

本站小編為你精心準備了通信集群服務器監(jiān)視系統(tǒng)研究參考范文，愿這些范文能點燃您思維的火花，激發(fā)您的寫作靈感。歡迎深入閱讀并收藏。

前言

SNMP是目前常用的環(huán)境管理協(xié)議，它與協(xié)議無關并且可以在IP、IPX、APPLETALK、OSI等網(wǎng)絡傳輸協(xié)議上使用。它提供了從網(wǎng)絡上的設備中收集網(wǎng)絡管理信息的方法，為設備向網(wǎng)絡管理工作站報告問題和錯誤提供了方法，使用SNMP技術不會修改設備系統(tǒng)所有的網(wǎng)絡設置。目前的SNMP是一個從網(wǎng)絡上的設備收集管理信息的公用通信協(xié)議，并且絕大部分網(wǎng)絡設備都實現(xiàn)了對SNMP協(xié)議的支持。SNMP簡單模型如圖1所示。

SNMP定義了管理進程(manager)和管理(agent)之間的關系，這個關系稱為共同體(community)。描述共同體的語義是非常復雜的，但其句法卻很簡單。位于網(wǎng)絡管理工作站(運行管理進程)上和各網(wǎng)絡元素上利用SNMP相互通信對網(wǎng)絡進行管理的軟件統(tǒng)統(tǒng)稱為SNMP應用實體。若干個應用實體和SNMP組合起來形成一個共同體，不同的共同體之間用名字來區(qū)分，共同體的名字則必須符合Internet的層次結構命名規(guī)則，由無保留意義的字符串組成。此外，一個SNMP應用實體可以加入多個共同體。

1SNMP的基本實現(xiàn)

設備的管理者收集從網(wǎng)絡上的設備管理信息并記錄在管理信息庫(MIB)中，MIB包含了機(被監(jiān)視設備)中的有關配置和性能的數(shù)據(jù)，有一個組織體系和公共結構，其中包含分屬不同組的許多對象。MIB數(shù)據(jù)對象以一種樹狀分層結構進行組織，這個樹結構(見圖2)中的每個分枝都有一個專用的名字和一個數(shù)字節(jié)的標識符。本系統(tǒng)的MIB應用以一種樹狀結構瀏覽的方式訪問整個MIB數(shù)據(jù)庫，通過數(shù)字標識來查找MIB中的數(shù)據(jù)對象，這個數(shù)字標識符號從結構樹的頂部(根部)開始，直到各個葉子節(jié)點(數(shù)據(jù)對象)為止。到達目標設備的路徑即為設設備的對象標識符(objectidentifierdesendant,OID)，本系統(tǒng)可通過其尋址到要檢測和監(jiān)視設備。OID是以管理信息結構(StructureofManagementInformation,SMI)為基礎的一系列點分符號，如1.3.6.1.2.1.1，這些點分符號在任何網(wǎng)絡中都惟一標識某一個特定數(shù)據(jù)參數(shù)。跟其它程序?qū)崿F(xiàn)過程一樣，整個SNMP協(xié)議管理編程也要經(jīng)過一個創(chuàng)建、執(zhí)行、撤銷的過程。初始化SNMP環(huán)境即加載SNMP的功能，接著執(zhí)行所進行的操作，SNMP是基于消息機制的，所以消息的傳遞與管理是程序?qū)崿F(xiàn)的核心技術。整個SNMP協(xié)議的程序?qū)崿F(xiàn)過程可大體分為加載SNMP，建立會話，設置實體模式，發(fā)送接收消息，提取數(shù)據(jù)報，取得返回值，最終實現(xiàn)設備的實時監(jiān)視。

2關鍵技術分析

2.1ServerSystemMIB子集

結合本部門的設備實際情況而言，集群服務器平臺下的DigitalUNIX4.0D操作系統(tǒng)使用了Compaq的ServerSystemMIB變量來建立EnvironmentMonitor，但是其缺乏靈活性和易用性，僅僅使用了ServerSystemMIB一個子集。如圖3所示。

本文的設計思想繞過系統(tǒng)的EnvironmentMonitor，直接調(diào)用系統(tǒng)函數(shù)SNMP_send、SNMP_get等函數(shù)訪問ServerSystemMIB(或在客戶端發(fā)送SNMP標準協(xié)議包實現(xiàn))，獲取系統(tǒng)當前的溫度、風扇、電源等傳感器狀態(tài)值，達到對系統(tǒng)硬件狀態(tài)的實時、準確的監(jiān)視。經(jīng)過擴展使用的ServerSystemMIB子集。如圖4所示。

2.2工作站的SNMP環(huán)境監(jiān)測技術分析

工作站的Windowns系統(tǒng)首先需要啟動SNMP服務，從而在工作站上建立起SNMP管理，使得管理客戶端只需要通過網(wǎng)絡發(fā)送標準的SNMP_send、SNMP_get等協(xié)議包既可獲取相應于系統(tǒng)硬件狀態(tài)的OID值。

從客戶端/服務器的角度來看，監(jiān)視系統(tǒng)工作站和SNMP既是客戶端，同時又充當服務器的角色。作為服務器，本系統(tǒng)監(jiān)聽UDP端口162，接收SNMP發(fā)送的消息；SNMP監(jiān)聽UDP端口161，接收本系統(tǒng)發(fā)送的查詢請求。作為客戶機，本系統(tǒng)可以隨時向SNMP發(fā)送查詢請求。因此，基于Windowns系統(tǒng)下開發(fā)的該“集群服務器狀態(tài)監(jiān)視系統(tǒng)”實際上就是一個客戶端。本系統(tǒng)開發(fā)的主要工作有以下兩點：

（1）構造正確的PDU，組成SNMP報文；

（2）對發(fā)送(接收)的SNMP報文進行BER編碼和解碼。BER編碼處理后的SNMP報文，提交給UDP，同時指定SNMP的IP地址和端口號即可。接收到返回的應答數(shù)據(jù)包后，再對SNMP報文進行相應的解碼分析和處理。

2.3網(wǎng)絡交換機的SNMP環(huán)境監(jiān)測技術分析

通過深入分析網(wǎng)絡交換機的MIB庫，選取適應本分系統(tǒng)的OID，可以實時監(jiān)測到包括網(wǎng)絡交換機的各個模塊的運行狀況，在此基礎上，還可以建立相關數(shù)據(jù)庫文件，統(tǒng)計網(wǎng)絡流量、擁塞狀態(tài)等，選取的switchhubMIB子集。如圖5所示。

3簡單網(wǎng)絡管理協(xié)議在集群服務器中的應用

目前國內(nèi)對大型集群服務器硬件設備監(jiān)視手段比較單一，缺乏對這些網(wǎng)絡集群運行設備的統(tǒng)一監(jiān)視手段，僅能從設備底層驅(qū)動級對其進行監(jiān)視，無法通過底層傳感器得到硬件設備實時參數(shù)信息(例如：機箱風扇狀態(tài)、CPU風扇狀態(tài)等)。這種基于簡單網(wǎng)絡協(xié)議思想建立、開發(fā)的硬件設備實時監(jiān)視系統(tǒng)，很好地利用底層傳感器的有效數(shù)據(jù)，解決了系統(tǒng)硬件狀態(tài)的實時監(jiān)視問題，基本實現(xiàn)了對各種服務器的監(jiān)視功能，能夠更好地對在線運行設備進行管理、維護，基本做到了全方位、全天候監(jiān)視，大大提高了系統(tǒng)的可維護性。

3.1SNMP與兩種常見協(xié)議的比較

集群服務器狀態(tài)監(jiān)視系統(tǒng)充分地利用了SNMP具有簡單性、擴展性、獨立性的特性。

（1）簡單性：不用采取類似UDP的連接方式需要在被管理設備上創(chuàng)建新進程的方法，從而影響到其它程序的穩(wěn)定運行；也不使用TCP“三次握手”來建立的連接方式，避免了浪費網(wǎng)絡、內(nèi)存資源，實現(xiàn)比較復雜，而且TCP協(xié)議很少參與底層網(wǎng)絡的操作，無法監(jiān)視到底層設備，適合在復雜的互聯(lián)網(wǎng)上運行；

（2）擴展性：通過定義新的被管理設備即擁有MIB信息的設備，可以非常方便地擴展管理功能而且可管理絕大部分符合Internet標準的設備；

（3）獨立性：即使被管理設備發(fā)生嚴重錯誤時，也不會影響管理設備的正常工作。

3.2簡單網(wǎng)絡協(xié)議中MIB的應用

管理信息庫(MIB)是網(wǎng)絡管理中的重要組成部分。每個MIB包含系統(tǒng)與設備的狀態(tài)信息、運行的數(shù)據(jù)統(tǒng)計、配置參數(shù)等。通過SNMP的五種命令就可以讀取或設置MIB庫中變量的值，獲得MIB信息的七種PDU。

所有的MIB對象類型被收集到一個或多個管理信息庫中并且對象類型按照管理信息結構和標識(SMI)定義。一個對象類型的名字明確地代表一個對象，稱為對象標識符。對象標識符是按照在MIB樹中建立的嚴格分層空間構造的，對象標識符總是一個惟一的從樹根開始描述MIB樹的整數(shù)序列。這里處于簡單性考慮，使用了SNMP定義其中的五種操作，每種操作對應一種PDU。

（1）GetRequest查詢請求PDU，由管理工作站發(fā)出，PDU中指明一個或多個要求查詢的對象。接收、處理后，返回GetRequest應答PDU。

（2）SetRequest設置請求PDU，由管理工作站發(fā)出，PDU中指明一個或多個要求設置的對象。接收、設置后，返回GetResponse應答PDU。

（3）GetNextRequest查詢請求PDU，由管理工作站發(fā)出，PDU中指明一個或多個要求查詢的對象。和GetRequestPDU不同的是，GetNextRequestPDU實際操作的對象，不是PDU中指明的對象，而是按字典序的下一個對象。接收、處理后，返回GetResponse應答PDU。

（4）GetResponse應答PDU，由應答管理工作站發(fā)出的查詢、設置請求PDU。應答PDU中包含了處理結果以及出錯代碼。

（5）Trap發(fā)出，向管理工作站報告本地網(wǎng)絡事件。所以，通過MIB，網(wǎng)絡管理器對管理對象的管理就簡化為網(wǎng)絡管理器對被管對象的MIB庫的內(nèi)容的查看和設置。對不同的設備，只要它們有相應的軟件和統(tǒng)一的MIB，網(wǎng)絡管理器就可以對它進行統(tǒng)一管理。同時，網(wǎng)絡管理器對被管對象的控制也通過MIB改變?yōu)閷IB內(nèi)變量值的設置，這樣就避免了管理協(xié)議定義過多的控制信息，因為新的控制功能可以通過在MIB中增加對應的新的變量來實現(xiàn)，而不必增加新的控制信息。

3.3集群服務器狀態(tài)監(jiān)視系統(tǒng)

在對SNMP進行細致分析的基礎上，該軟件設計了基于Windows系統(tǒng)、面向UNIX應用軟件的集群服務器狀態(tài)監(jiān)視系統(tǒng)。管理信息庫的組織方式采取類似于SNMP的管理信息組織方式—MIB樹的方式來組織被管對象。協(xié)議數(shù)據(jù)單元方面保持SNMP基本操作，力求在管理站點上提供給管理機一個整個管理區(qū)域內(nèi)的MIB樹的直觀映射，以方便管理機對管理對象的實時監(jiān)視。

3.4系統(tǒng)流程

根據(jù)以上關于SNMP協(xié)議的理論，結合本部門的實際情況，集群服務器狀態(tài)監(jiān)視系統(tǒng)的流程設計如圖6。

3.5SNMP與集群服務器的有機結合

就近些年國內(nèi)對硬件設備監(jiān)視的種類來看，基于SNMP技術對設備監(jiān)視的手段已經(jīng)存在，這種基于SNMP協(xié)議建立的硬件設備實時監(jiān)視系統(tǒng)的方法實現(xiàn)了對集群服務器進行運行狀態(tài)監(jiān)視的功能。針對集群服務器設備的特點，我們實現(xiàn)了SNMP技術與集群服務器的有機結合，使得集群服務器狀態(tài)監(jiān)視系統(tǒng)方法和手段變得更為靈活、易于使用，并且該方法不需要對操作系統(tǒng)做任何的改動，大大增強了該方法的穩(wěn)定性。而且通過該技術研發(fā)的硬件實時監(jiān)視系統(tǒng)還具有很強的可擴展性和移植性。可將支持SNMP協(xié)議的所有設備添加到該系統(tǒng)內(nèi)，為構建統(tǒng)一的監(jiān)視平臺提供了技術支持，為其進行全面的設備狀態(tài)監(jiān)視，以便達到更好的設備管理、維護目的(如圖7)。

4完成情況和有待解決的問題

4.1完成情況

基于簡單網(wǎng)絡協(xié)議、數(shù)據(jù)處理分系統(tǒng)設備的現(xiàn)狀，通過VC具體編譯設計監(jiān)視系統(tǒng)，實現(xiàn)了利用底層傳感器得到集群服務器實時參數(shù)信息的功能，并使該系統(tǒng)達到在線運行設備狀態(tài)可視化的程度，使得設備的維護、管理更加科學化。

現(xiàn)在已可實現(xiàn)的基本功能：

（1）網(wǎng)絡狀態(tài)實時嗅探功能；

（2）實時監(jiān)視各服務器CPU的運算頻率；

（3）實時監(jiān)視各服務器CPU的數(shù)量；

（4）實時監(jiān)視各服務器CPU的緩存容量；

（5）實時監(jiān)視各服務器磁盤的容量；

（6）實時監(jiān)視各服務器內(nèi)存的容量；

（7）實時監(jiān)視各服務器內(nèi)存的數(shù)量；

（8）實時監(jiān)視各服務器電源狀態(tài)；

（9）實時監(jiān)視各服務器CPU狀態(tài)；

（10）實時監(jiān)視各服務器CPU風扇狀態(tài)；

（11）實時監(jiān)視各服務器電源風扇狀態(tài)；

（12）實時監(jiān)視各服務器機箱溫度及狀態(tài)；

（13）實時監(jiān)視各服務器內(nèi)部底層傳感器狀態(tài)；

（14）實時監(jiān)視各網(wǎng)絡交換機內(nèi)部模塊狀態(tài)；

（15）實時監(jiān)視各網(wǎng)絡交換機內(nèi)部底層傳感器狀態(tài)。

4.2有待解決的問題

在集群服務器狀態(tài)監(jiān)視系統(tǒng)管理方面完成了實現(xiàn)預期管理所需的基本功能，測試的結果基本符合設計的要求，但其中也存在一些問題。如系統(tǒng)的反應不夠靈敏，MIB信息的更新速度不夠快；監(jiān)控模塊的容錯性能較差，發(fā)生故障后容易掛起。

還需在系統(tǒng)的安全性方面，和對結構數(shù)據(jù)類型和用戶自定義數(shù)據(jù)類型的支持方面作進一步的工作。另外可以考慮擴大監(jiān)控的范圍，不僅僅對類中的成員變量進行監(jiān)控，還要對類中的成員函數(shù)進行監(jiān)控。