Linux SNMP協(xié)議的設(shè)計(jì)原理
通常,我們使用SNMP協(xié)議,最多地就是在Windows系統(tǒng)下進(jìn)行的。但是Linux SNMP的使用卻更為廣泛?,F(xiàn)在我們就來(lái)了解一下Linux SNMP的相關(guān)內(nèi)容吧??纯淳唧w的設(shè)計(jì)是如何實(shí)現(xiàn)的。事實(shí)上,Linux SNMP被設(shè)計(jì)成與協(xié)議無(wú)關(guān),所以它可以在IP,IPX,AppleTalk,OSI以及其他用到的傳輸協(xié)議上被使用。
Linux SNMP是一系列協(xié)議組和規(guī)范,它們提供了一種從網(wǎng)絡(luò)上的設(shè)備中收集網(wǎng)絡(luò)管理信息的方法。Linux SNMP也為設(shè)備向網(wǎng)絡(luò)管理工作站報(bào)告問(wèn)題和錯(cuò)誤提供了一種方法。
MIB:管理信息庫(kù)
SMI:管理信息的結(jié)構(gòu)和標(biāo)識(shí)
Linux SNMP算法
從被管理設(shè)備中收集數(shù)據(jù)有兩種方法:一種是只輪詢(polling-only)的方法,另一種是基于中斷(interrupt-based)的方法。
如果你只使用只輪詢的方法,那么網(wǎng)絡(luò)管理工作站總是在控制之下。而這種方法的缺陷在于信息的實(shí)時(shí)性,尤其是錯(cuò)誤的實(shí)時(shí)性。你多久輪詢一次,并且在輪詢時(shí)按照什么樣的設(shè)備順序呢?
如果輪詢間隔太小,那么將產(chǎn)生太多不必要的通信量。如果輪詢間隔太大,并且在輪詢時(shí)順序不對(duì),那么關(guān)于一些大的災(zāi)難性的事件的通知又會(huì)太饅。這就違背了積極主動(dòng)的網(wǎng)絡(luò)管理Linux SNMP目的。
當(dāng)有異常事件發(fā)生時(shí),基于中斷的方法可以立即通知網(wǎng)絡(luò)管理工作站(在這里假設(shè)該設(shè)備還沒(méi)有崩潰,并且在被管理設(shè)備和管理工作站之間仍有一條可用的通信途徑)。
然而,這種方法也不是沒(méi)有他的缺陷的,首先,產(chǎn)生錯(cuò)誤或自陷需要系統(tǒng)資源。如果自陷必須轉(zhuǎn)發(fā)大量的信息,那么被管理設(shè)備可能不得不消耗更多的時(shí)間和系統(tǒng)資源來(lái)產(chǎn)生自陷,從而影響了它執(zhí)行主要的功能(違背了網(wǎng)絡(luò)管理的原則2)。
而且,如果幾個(gè)同類型的自陷事件接連發(fā)生,那么大量網(wǎng)絡(luò)帶寬可能將被相同的信息所占用(違背了網(wǎng)絡(luò)管理的原則1)。尤其是如果自陷是關(guān)于網(wǎng)絡(luò)擁擠問(wèn)題的時(shí)候,事情就會(huì)變得特別糟糕。
克服這一缺陷的一種方法就是對(duì)于被管理設(shè)備來(lái)說(shuō),應(yīng)當(dāng)設(shè)置關(guān)于什么時(shí)候報(bào)告問(wèn)題的閾值(threshold)。但不幸的是這種方法可能再一次違背了網(wǎng)絡(luò)管理的原則2,因?yàn)樵O(shè)備必須消耗更多的時(shí)間和系統(tǒng)資源,來(lái)決定一個(gè)自陷是否應(yīng)該被產(chǎn)生。
結(jié)果,以上兩種方法的結(jié)合:面向自陷的輪詢方法(trap-directed polling)可能是執(zhí)行網(wǎng)絡(luò)管理Linux SNMP最為有效的方法了。一般來(lái)說(shuō),網(wǎng)絡(luò)管理工作站輪詢?cè)诒还芾碓O(shè)備中的代理來(lái)收集數(shù)據(jù),并且在控制臺(tái)上用數(shù)字或圖形的表示方式來(lái)顯示這些數(shù)據(jù)。這就允許網(wǎng)絡(luò)管理員分析和管理設(shè)備以及網(wǎng)絡(luò)通信量了。
被管理設(shè)備中的代理可以在任何時(shí)候向網(wǎng)絡(luò)管理工作站報(bào)告錯(cuò)誤情況,例如預(yù)制定閾值越界程度等等。代理并不需要等到管理工作站為獲得這些錯(cuò)誤情況而輪詢他的時(shí)候才會(huì)報(bào)告。這些錯(cuò)誤情況就是眾所周知的Linux SNMP自陷(trap)。