當(dāng)數(shù)據(jù)中心的網(wǎng)絡(luò)規(guī)模變得很大時，不得不要增加網(wǎng)絡(luò)設(shè)備，實現(xiàn)多層級聯(lián)?，F(xiàn)在的數(shù)據(jù)中心往往都是樹形結(jié)構(gòu)，核心放置幾臺轉(zhuǎn)發(fā)容量超大的設(shè)備，然后下掛多層設(shè)備(因為端口數(shù)量不夠，可能需要多層)，數(shù)十臺甚至幾百臺的網(wǎng)絡(luò)設(shè)備級聯(lián)到一起，一旦出了故障，如何能快速找到故障設(shè)備，經(jīng)常困擾著很多網(wǎng)絡(luò)運維人員。
數(shù)據(jù)中心的網(wǎng)絡(luò)設(shè)備都是有冗余的，只要網(wǎng)絡(luò)故障時找到故障設(shè)備，將其隔離即可恢復(fù)業(yè)務(wù)，然后再去慢慢排查故障原因，但從數(shù)百臺的設(shè)備中找到具體哪臺故障絕非易事。網(wǎng)絡(luò)故障往往先從應(yīng)用側(cè)得到故障反饋，然后開始排障，這時應(yīng)用人員往往描述的只是一個應(yīng)用訪問故障現(xiàn)象，他不會告訴你具體哪些地址到哪些地址不通，有時甚至是錯誤的信息，這極大延誤了問題定位時長。問題定位大部分時間都是花在故障現(xiàn)象的整理過程中，怎么辦?數(shù)據(jù)中心網(wǎng)絡(luò)該如何快速排障?本文將給出答案。
網(wǎng)絡(luò)故障如果要從應(yīng)用側(cè)反饋的故障現(xiàn)象去分析，這時已經(jīng)晚了，而且容易被應(yīng)用人員帶入誤區(qū)，有些應(yīng)用人員反饋的現(xiàn)象只是他自己看到的，現(xiàn)象很可能只是一個局部現(xiàn)象，并不能反映出整個網(wǎng)絡(luò)的故障情況。所以要靠自己，做好網(wǎng)絡(luò)監(jiān)控，通過監(jiān)控去發(fā)現(xiàn)問題，從而迅速找到故障設(shè)備，做設(shè)備隔離或者解除故障。
早期的網(wǎng)絡(luò)監(jiān)控主要是對設(shè)備的一些日志和端口流量做監(jiān)控，更多的時候這些信息并不夠，并不能及時發(fā)現(xiàn)問題。很多網(wǎng)絡(luò)設(shè)備廠商說自己的設(shè)備日志非常完整，但實際使用時仍有一些極端情況或者軟件BUG導(dǎo)致故障時無日志輸出，這時就要針對流量進(jìn)行定位。到了這個時候，就需要網(wǎng)絡(luò)人員去找應(yīng)用人員了解故障現(xiàn)象，通過現(xiàn)場找出一些丟包或者不通的IP地址來，然后進(jìn)行網(wǎng)絡(luò)流通，對這個故障流量經(jīng)過的設(shè)備都做流通，找到故障設(shè)備。既然是樹形網(wǎng)絡(luò)，每一層都有很多設(shè)備，這個流通量是相當(dāng)大的，而且并不是所有的設(shè)備都能支持對所有特征的流量做統(tǒng)計，有不支持的設(shè)備就會使得統(tǒng)計不準(zhǔn)，加大了尋找故障設(shè)備的難度，做網(wǎng)絡(luò)運維的這些年都是這樣堅持過來的。
顯然，之前的網(wǎng)絡(luò)排障方式有效但效率太低，定位故障時間長，對業(yè)務(wù)影響大?，F(xiàn)在的網(wǎng)絡(luò)監(jiān)控都是針對數(shù)據(jù)流的，對網(wǎng)絡(luò)中的具體數(shù)據(jù)流進(jìn)行監(jiān)控，這樣一旦數(shù)據(jù)流量有中斷，立即可以查明故障位置。在這里，要提到幾種新興的網(wǎng)絡(luò)監(jiān)控方法，也叫網(wǎng)絡(luò)可視化技術(shù)，是快速排障的最有效方法。
首先是INT(In-band Network Telemetry，帶內(nèi)網(wǎng)絡(luò)遙測技術(shù))技術(shù)，INT通過在數(shù)據(jù)層面收集和報告網(wǎng)絡(luò)的狀態(tài)來實現(xiàn)對網(wǎng)絡(luò)狀態(tài)的監(jiān)控。當(dāng)數(shù)據(jù)報文進(jìn)入第一個網(wǎng)絡(luò)設(shè)備時，設(shè)備上設(shè)置采樣方式采樣并鏡像出該業(yè)務(wù)流報文，INT在報文基礎(chǔ)上封裝一個INT頭，并將需要收集的交換機(jī)信息填入到INT數(shù)據(jù)段中，報文經(jīng)過的所有網(wǎng)絡(luò)設(shè)備均這樣處理，直到最后一個服務(wù)器連接的網(wǎng)絡(luò)設(shè)備將INT頭剝離。
報文經(jīng)過的每臺設(shè)備都將采集到的INT報文通過gRPC報文發(fā)送到遠(yuǎn)端的監(jiān)控服務(wù)器進(jìn)行解析和呈現(xiàn)，INT報文中攜帶了報文轉(zhuǎn)發(fā)的延遲、設(shè)備擁塞等情況，都能呈現(xiàn)到監(jiān)控服務(wù)器上，一旦數(shù)據(jù)報文出現(xiàn)丟包或者不通情況，監(jiān)控服務(wù)器立即感知到，并幾秒就能確定問題范圍和故障設(shè)備。
其次是ERSPAN(Encapsulated Remote Switch Port Analyzer，跨三層IP傳輸?shù)倪h(yuǎn)程網(wǎng)絡(luò)流量監(jiān)控技術(shù))，ERSPAN的報文基于GRE封裝，并通過以太網(wǎng)轉(zhuǎn)發(fā)到任何IP路由可達(dá)的地方。ERSPAN是將源端口報文復(fù)制一份通過GRE(Generic Routing Encapsulation)發(fā)送到目的服務(wù)器進(jìn)行解析，采集服務(wù)器的物理位置不受限制，這樣我們可以將整個網(wǎng)絡(luò)的關(guān)鍵流量轉(zhuǎn)發(fā)都通過ERSPAN發(fā)送到監(jiān)控服務(wù)器上，流量在哪部分網(wǎng)絡(luò)出現(xiàn)了丟棄，一目了然。第三是sFlow和Netstream，這兩種都是數(shù)據(jù)采樣技術(shù)，Netstream采集的比較完整，但需要有專用的硬件來完成，在網(wǎng)絡(luò)中部署sFlow和Netstream后，可以通過gRPC將監(jiān)控數(shù)據(jù)發(fā)給服務(wù)器，由監(jiān)控服務(wù)器計算和整理，并將結(jié)果圖形化顯示出現(xiàn)，一旦哪部分網(wǎng)絡(luò)有問題，立即可以在監(jiān)控服務(wù)器上顯現(xiàn)。
sFlow和Netstream采集的都是報文頭的主要特征，而不是報文整個內(nèi)容，這個和INT、ERSPAN有較大區(qū)別，應(yīng)對絕大部分網(wǎng)絡(luò)故障排查都沒有問題，除非應(yīng)用報文特征比較特殊，Netstream捕捉不到，這時只能求助INT和ERSPAN。在一個網(wǎng)絡(luò)中，并不介意三種監(jiān)控方案都部署，這樣在故障時，可以從多個角度采集的數(shù)據(jù)去分析問題。
還有一點很重要，盡量要將這些數(shù)據(jù)采集通過管理網(wǎng)發(fā)向監(jiān)控服務(wù)器，否則一旦數(shù)據(jù)網(wǎng)出問題，可能監(jiān)控的數(shù)據(jù)也無法正常達(dá)到監(jiān)控服務(wù)器。大部分情況下，數(shù)據(jù)網(wǎng)絡(luò)故障很少波及到管理網(wǎng)，所有設(shè)備依然可以正常訪問，如果故障時，很多設(shè)備都無法通過管理網(wǎng)進(jìn)行訪問，基本可以判定這臺設(shè)備就是故障點。
有了以上這些網(wǎng)絡(luò)監(jiān)控方法，出現(xiàn)故障時第一時間發(fā)現(xiàn)就不難了，而且完全可以實現(xiàn)自動化，當(dāng)發(fā)現(xiàn)故障時，由監(jiān)控服務(wù)器自動下發(fā)隔離命令，將故障設(shè)備隔離，自動恢復(fù)。這樣在應(yīng)用報障過來之前，就可以找到網(wǎng)絡(luò)故障位置，及時隔離故障設(shè)備，恢復(fù)業(yè)務(wù)，這樣可以極大縮短故障分析時間，對業(yè)務(wù)影響很小，甚至業(yè)務(wù)部分根本感知不到故障。像INT和ERSPAN這些網(wǎng)絡(luò)監(jiān)控的技術(shù)實際應(yīng)用的效果還未知，都是最近總被提及的技術(shù)，還有待實踐的考驗。SFLOW和Netstream技術(shù)比較成熟，但真正在網(wǎng)絡(luò)排障時用到的還不多，需要加大這方面的推廣。
依靠這些監(jiān)控技術(shù)，可以快速排除網(wǎng)絡(luò)故障，這對于數(shù)據(jù)中心運維來說，意義重大，極大地提升了運維效率。
189-0300-8674（林經(jīng)理）