“操作回溯”解決網(wǎng)絡故障

網(wǎng)絡環(huán)境

我校部分網(wǎng)絡架構(gòu)和業(yè)務分布如圖1所示。

核心交換：銳捷S8606加AC擴展板，承載有線與無線業(yè)務。

匯聚交換：華為S7506，承載東西兩棟教學樓的交換業(yè)務，與核心交換機通過兩根萬兆光纖聚合鏈接,同時鏈接銳捷桌面云虛擬化系統(tǒng)，六臺服務器提供200點辦公虛擬化支持。華三S5500，鏈接 FTP，DHCP等服務器設備。

接入交換：兩棟教學樓樓層間部署華為S5130。

故障現(xiàn)象

早晨上班不久接到故障反饋：東教學樓A、B兩個用戶的桌面云打開速度慢，“開始”菜單無反應。按照描述，判斷是一般應用層軟件故障，絲毫沒有聯(lián)想到網(wǎng)絡問題。筆者登錄銳捷云桌面管理端，對A、B兩個賬戶執(zhí)行關機，重置系統(tǒng)操作。

沒想到的是，在接下來的一個小時里，反映此癥狀的用戶增加到十幾人，范圍也擴大到兩棟教學樓的多個樓層。此時意識到可能是桌面云服務器故障，判斷此十幾個用戶很可能是集中在某一臺服務器上的。馬上登錄管理后臺查看，結(jié)果各服務器CPU和內(nèi)存使用率一切正常，仔細排查后發(fā)現(xiàn)，這些用戶也并非集中在一臺服務器上，推翻了此前的判斷。

故障排查

與同事前往故障現(xiàn)場確認情況，有一典型辦公室六臺設備只有一臺使用正常，其余都出現(xiàn)打開應用軟件速度慢、無法關閉窗口情況。此時，意識到很可能是網(wǎng)絡故障。將焦點集中到接入層交換機上，懷疑私接設備造成環(huán)路。測試網(wǎng)絡連通率，在有故障的終端上Ping服務器，丟包率1-2%，未見較大異常。繼續(xù)登錄接入層交換機查看了CPU、風扇、溫度等狀態(tài)數(shù)據(jù)，皆一切正常。難道接入層設備沒有問題？于是，繼續(xù)登錄匯聚層交換機查看各項數(shù)據(jù)，果不其然，還是一切正常。

此時，兩棟教學樓的接入層和匯聚層檢查完畢，依然無法定位故障，難道問題出在核心交換機上？同時，用戶C反饋重要線索：今天FTP下載文件失敗。此用戶用的不是桌面云系統(tǒng)，而是實體機，側(cè)方印證了故障出現(xiàn)在網(wǎng)絡而非服務器上，很可能就出在銳捷S8606或者H3C 5500上。

圖1 網(wǎng)絡結(jié)構(gòu)

圖2 查看聚合組工作狀況

隨著故障范圍縮小，決定變換思路，按照“操作回溯，現(xiàn)場還原”的原則，回憶之前對網(wǎng)絡所做的各種操作，特別是對核心交換機的操作。時值周一，回憶上周五的操作如下：

1.增加了一個POE交換機直連核心交換機，做了更改VLAN和端口操作。

2.一臺教室用服務器移機到H3C 5500上，也只在該交換機上增加了VLAN和端口。

無論如何也想不通，以上操作簡單可靠，很難隱藏危機。但是依然制定策略如下：Down掉核心交換連接POE交換機的接口；將H3C 5500的VLAN恢復，并將教室用服務器關機。

故障解決

正要行動之際，忽然有人提示：周五下午有工程師過來更換了核心交換機上的一個萬兆聚合模塊。馬上意識到問題可能出在這里，登錄并查看聚合組工作狀況，發(fā)現(xiàn)本應是2萬兆的速率居然是1萬兆（如圖2）。

嘗試刪除聚合組，并重新配置，發(fā)現(xiàn)速率正常了，故障解除。

后來得知，當初聚合模塊壞了一個，但是并未影響業(yè)務，工程師更換模塊后也沒有查看運行情況。猜測可能是新模塊不匹配或是一端設備將其Down掉了。

經(jīng)驗總結(jié)

網(wǎng)絡故障最難纏的就是隱性故障，時通時斷或是時好時壞最撓頭。本次解決故障過程，從應用層反饋故障挖掘到網(wǎng)絡層誘因，又按照從低到高原則，從接入到核心逐層排查，最后沖刺階段按照“操作回溯”方法進行定位，最終解決了故障。