網(wǎng)絡(luò)管理實戰(zhàn)：如何實現(xiàn)真正的監(jiān)控？

大學(xué)畢業(yè)以后，我在政府機構(gòu)找到了一份管理網(wǎng)站的工作。我們的服務(wù)器都是以前各個部門自己管理的，什么類型的機器都有，文檔基本上沒有，所以我們在整理這些機器環(huán)境時，就好像在做逆向工程一樣。我們把所有服務(wù)器都編入目錄，并納入監(jiān)控：第一項檢查是可用性檢查，從簡單的網(wǎng)絡(luò)ping測試，到發(fā)送HTTP請求和檢查響應(yīng)時間。為了能有更多的信息以診斷故障原因，除了對關(guān)鍵進程，如SSH、HTTPD、NTPD的檢查之外，又增加了對內(nèi)存、磁盤、CPU使用情況的檢查。查看這些結(jié)果，使我們對面臨的情形能有一個完整的大局觀。

偶爾人們會給我們發(fā)郵件，聲稱他們不能訪問網(wǎng)站。但我們檢查網(wǎng)站和監(jiān)控的結(jié)果是一切運行正常，我們就禮貌地回復(fù)這些郵件：就我們所見，一切運行正常，問題可能出在他們的PC機上，把機器重啟一下就好了。事實上，我們認為這些情況屬于典型的PEBKAC（問題出在鍵盤和座椅之間）。

后來有一天，老板發(fā)郵件給我，說他在訪問網(wǎng)站時也遇到問題了，他急著要一些信息。我馬上跑到他的辦公室，打開瀏覽器，輸入URL地址，什么都沒有。點擊重新加載按鈕，也不行。我打開命令行窗口，輸入命令來解析服務(wù)器地址，發(fā)現(xiàn)DNS服務(wù)器沒響應(yīng)。這下我明白了，我們的監(jiān)控腳本檢查網(wǎng)站時使用的是IP地址，所以沒有檢測出問題。我登錄到老板所在的網(wǎng)段的DNS服務(wù)器，重啟服務(wù)器，一切恢復(fù)正常。為了檢測這種類型的問題，修改監(jiān)控腳本，把對DNS服務(wù)器的監(jiān)控加進去，使用nslookup檢查DNS服務(wù)器，以確保能夠檢測出這類問題。

幾天以后，在一次會議上又遇到了老板，我問他現(xiàn)在還有什么問題沒有，他答道，“大多數(shù)時候沒問題，但在需要身份驗證的地方還是有問題。”我的老板是第一批訪問受限內(nèi)容的人，這個管理站點需要登錄，使用存儲在數(shù)據(jù)庫中的用戶名和密碼。我們已經(jīng)從DNS問題中學(xué)到了教訓(xùn)，所以也把數(shù)據(jù)庫服務(wù)器納入了監(jiān)控，我們是通過向數(shù)據(jù)庫發(fā)送一條簡單的SQL查詢對數(shù)據(jù)庫進行檢查的。所以，打開監(jiān)控頁面，看到數(shù)據(jù)庫服務(wù)的狀態(tài)一直是綠色的。嗯，我請他登錄網(wǎng)站，砰，失敗了。這證明，雖然Web服務(wù)器和數(shù)據(jù)庫服務(wù)器都運行正常，但由于防火墻的權(quán)限設(shè)置問題，Web服務(wù)器仍然不能訪問數(shù)據(jù)庫服務(wù)器。我默默地離開了老板辦公室：由于沒有檢測到問題，最終用戶又一次把板子打在了我們的監(jiān)控上。又一次升級了監(jiān)控腳本，增加登錄功能，對網(wǎng)站做更全面的檢查。

我一般上班比較早，在大部分用戶開始工作之前，對系統(tǒng)做全面檢查。一天早上，我開始收到大量的用戶抱怨，說網(wǎng)站宕掉了。檢查監(jiān)控，沒發(fā)現(xiàn)任何問題：所有狀態(tài)都是綠色的。我請用戶再試試，還是不能訪問。我告訴他們檢查DNS、網(wǎng)關(guān)，以及所有我能想到的事情，毫無效果。我甚至重啟了服務(wù)器，雖然一切正常。

在翻來覆去地檢查過配置文件和日志文件之后，我決定打電話給網(wǎng)絡(luò)組的同事，他正好與抱怨用戶在同一棟樓上。“嗨，可以看一下我們的網(wǎng)站嗎？”我問，回答，“不。”我想他是在跟我開玩笑，所以就溫和親切地把問題又重復(fù)了一遍。“不，”再一次的回答，接著又說：“這棟樓的一根動力線掉電了，一臺核心交換機停掉了，所以我沒辦法幫你看。”

為了找到問題出在哪兒，我花了一個多小時。沒人費心告訴我們這個小組停電了，要是我早點知道該多好。后來我了解到，負責(zé)網(wǎng)絡(luò)的人和負責(zé)大樓的人各有自己的監(jiān)控系統(tǒng)，首先，我們要能夠訪問他們的系統(tǒng)，這樣，出現(xiàn)問題之后，就能夠驗證系統(tǒng)狀態(tài)。然后，在發(fā)生問題時，要相互告知。最后，我們把不同的監(jiān)控系統(tǒng)集成起來，提供統(tǒng)一的運行狀態(tài)圖。

隨著時間的推移，各個Web服務(wù)器的參數(shù)和配置更加地趨于一致。有些站點的硬件能力沒有充分利用，而其他的卻需要增加容量。我們決定把各個站點分布在不同的服務(wù)器上進行負載均衡。這樣，除了性能和利用率得到提高之外，還提高了可用性，因為站點現(xiàn)在是運行在多臺服務(wù)器上，即使一臺服務(wù)器宕掉了，也可以通過負載均衡器將用戶重定向到另外的可用服務(wù)器上，來保證用戶的正常使用，同時將數(shù)據(jù)庫服務(wù)器轉(zhuǎn)成了高可用性的集群。

網(wǎng)絡(luò)部門的朋友們做了同樣的事：為路由器、交換機、防火墻增加了冗余?，F(xiàn)在，可以放心地說，我們消除了架構(gòu)中存在的大量單點故障。管理服務(wù)器變得容易了，可以從服務(wù)器池中把一臺移出來進行維護，而不會影響系統(tǒng)運行。把監(jiān)控站點開放給內(nèi)部的最終用戶，讓他們驗證自己的環(huán)境狀況，這樣他們就可以了解哪些問題是站點的問題，哪些問題是他們自己電腦的問題。在我們引入冗余級別之后，用戶給搞糊涂了，他們無法區(qū)分哪些是服務(wù)器的服務(wù)，哪些是負載均衡器提供的全局服務(wù)。我們又在監(jiān)控顯示上提供了一個服務(wù)級別，以便區(qū)分。對于其他的冗余機制，譬如用于DNS（NS記錄）、Mail（MX記錄）、NTP時鐘等服務(wù)的冗余機制，以及像RAID5和磁盤鏡像這樣的磁盤冗余機制等，都同樣提供服務(wù)級別，以便區(qū)分。

負載均衡器是由服務(wù)器團隊管理的，因為從邏輯上講，負載均衡更接近于應(yīng)用程序，而且要正確地管理負載均衡器，需要深入的HTTP知識。在進行更新時，先在被動的負載均衡器上準備配置，然后再將主動負載均衡器切換為被動負載均衡器，我們很自信，可以在工作時間做這種更新。偶爾切換的時間會很長，以至于監(jiān)控系統(tǒng)會認為發(fā)生了錯誤。這種情況很難理解，因為我們配置的負載均衡器應(yīng)該是立即切換的。我們開始檢查歷史日志，看是否能夠找到發(fā)生了其他問題的線索。最后證明，我們那兩次碰到問題，是由于防火墻、路由器、交換機出問題了。這就解釋通了，負載均衡器沒有問題。那天下午，網(wǎng)絡(luò)部門也打電話給我們，問是不是改了負載均衡器上的什么東西。“是的，”我們說，“安裝了新的配置，失效轉(zhuǎn)移工作正常，只是你們的路由器、交換機、防火墻出問題了。”我們在繼續(xù)轉(zhuǎn)換的時候，他們最終把問題追蹤到了負載均衡器的失效轉(zhuǎn)移上：負載均衡器在做失效轉(zhuǎn)移時，防火墻也在做失效轉(zhuǎn)移，因為它檢測到了路由問題。最后，我們把兩種失效轉(zhuǎn)移機制緊密耦合在一起，從而可以讓它們一起進行失效轉(zhuǎn)移。

【推薦閱讀】

◆網(wǎng)管軟件專區(qū)

◆網(wǎng)絡(luò)監(jiān)控原理與技術(shù)實現(xiàn)

◆巧用泛普BTNM智能分析網(wǎng)管軟件解決網(wǎng)絡(luò)故障

◆奇怪的排障：企業(yè)網(wǎng)絡(luò)管理要突破慣有思維

◆IT運維管理專區(qū)

本文來自互聯(lián)網(wǎng)，僅供參考

發(fā)布：2007-04-15 10:40 編輯：泛普軟件 · xiaona [打印此頁] [關(guān)閉]

相關(guān)欄目：