是一個(gè)介紹如何利用思科先進(jìn)技術(shù)解決客戶難題的欄目。每期聚焦一個(gè)技術(shù)熱點(diǎn)或應(yīng)用場(chǎng)景，邀請(qǐng)資深思科技術(shù)專家深入淺出地介紹，為讀者提供實(shí)用性強(qiáng)的建議。

　　前兩期我們介紹的基于意圖的主動(dòng)運(yùn)維系統(tǒng)，已經(jīng)能讓很多傳統(tǒng)運(yùn)維手段鳳凰涅盤、迸發(fā)出新的生命力，但大數(shù)據(jù)和人工智能的加持還可讓主動(dòng)運(yùn)維能力更上一層樓。在《噩夢(mèng)不再，美夢(mèng)成真—數(shù)據(jù)中心智能主動(dòng)運(yùn)維》中我們把自動(dòng)化層所驅(qū)動(dòng)的大數(shù)據(jù)數(shù)據(jù)收集模式比喻為交通違章的視頻監(jiān)控，帶內(nèi)遙測(cè) INT MX 相當(dāng)于車內(nèi)裝攝像頭，情況反映真實(shí)但能拍到的太少；INT MD 相當(dāng)于狗仔隊(duì)跟著你拍，可以全方位無(wú)死角但資源消耗太大、實(shí)現(xiàn)成本太高。那有沒有功能強(qiáng)大但同時(shí)又足夠輕量化、性價(jià)比能保證現(xiàn)階段端到端部署的 INT 帶內(nèi)遙測(cè)方案呢？想想真實(shí)世界的交通違章罰單都是被什么樣的攝像頭拍攝下來(lái)的，就能夠猜到答案了。

　　

　　不錯(cuò)，上面那樣的攝像頭才是讓老司機(jī)們最害怕的，闖個(gè)紅燈、軋個(gè)實(shí)線都難逃法眼。INT XD 也是這樣的工作方式，由交換機(jī)監(jiān)視來(lái)來(lái)往往的數(shù)據(jù)包并向后臺(tái)實(shí)時(shí)報(bào)告。不過(guò)可能你也會(huì)有疑問(wèn)，攝像機(jī)對(duì)應(yīng)到真實(shí)網(wǎng)絡(luò)中，豈不是每一個(gè)經(jīng)過(guò)交換機(jī)的數(shù)據(jù)包都需要被 “ 拍下來(lái) ” 傳到后臺(tái)，這樣就算交換機(jī)硬件足夠強(qiáng)大，后臺(tái)的數(shù)據(jù)也是大到恐怖吧，INT XD 的輕量化優(yōu)勢(shì)從何而來(lái)呢？其實(shí)和真實(shí)世界查違章必須定位到具體車輛不同，網(wǎng)絡(luò)世界里雖然也需要對(duì)異常發(fā)生的位置、時(shí)間和程度等信息掌握得盡可能精確詳盡，但完全沒有必要定位到具體的某個(gè)數(shù)據(jù)包，只要有足夠細(xì)粒度的統(tǒng)計(jì)信息，大數(shù)據(jù)平臺(tái)的AI就能實(shí)現(xiàn)諸如故障早期預(yù)測(cè)、問(wèn)題的根因分析等智能主動(dòng)運(yùn)維功能。這就是 XD 方法的技術(shù)核心所在——如何巧妙的設(shè)計(jì)算法，按批次生成報(bào)告而非按每一個(gè)包生成報(bào)告，從而具備足夠的統(tǒng)計(jì)細(xì)粒度的同時(shí)盡可能降低軟硬件負(fù)擔(dān)。

　　按時(shí)間周期批量化不難做到，利用硬件把周期縮短到每秒生成報(bào)告都不成問(wèn)題。難在如何生成更有統(tǒng)計(jì)價(jià)值的報(bào)告，比如有意義的延遲統(tǒng)計(jì)至少需要給出 1 秒內(nèi)所有包的平均延遲、平均抖動(dòng)容限、最大最小延遲等，這就需要測(cè)量出每一個(gè)包的延遲數(shù)值來(lái)計(jì)算，例如對(duì)逐跳延遲需要精心設(shè)計(jì)轉(zhuǎn)發(fā)流水線，對(duì)每一個(gè)包 Ingress 打時(shí)間戳，在 Egress 驗(yàn)證時(shí)間戳，而對(duì)端到端延遲則需要Ingress交換機(jī)和 Egress 交換機(jī)之間實(shí)現(xiàn)高精度時(shí)間同步協(xié)議（PTP），而這絕大部分都需要內(nèi)置在轉(zhuǎn)發(fā)芯片內(nèi)，減少 CPU 參與。

　　只在時(shí)間上分批次是不夠的，因?yàn)檫@樣統(tǒng)計(jì)出的數(shù)據(jù)分不出是哪個(gè)業(yè)務(wù)，對(duì)改善業(yè)務(wù)體驗(yàn)沒有指導(dǎo)意義。要做業(yè)務(wù)流區(qū)分，有經(jīng)驗(yàn)的小伙伴一定想到了五元組流表，不錯(cuò)，Cisco 正是利用江湖上久負(fù)盛名的 Netflow 流表對(duì)所有數(shù)據(jù)進(jìn)行批次劃分，這樣所有的統(tǒng)計(jì)都?xì)w類到具體的流記錄中，從而具備了業(yè)務(wù)的上下文關(guān)聯(lián)。同樣要做到全流量記錄，從流表的匹配、數(shù)據(jù)記錄到數(shù)據(jù)的封裝導(dǎo)出，仍然必須都是全硬件化而不能有 CPU 參與。

　　硬件化 PTP、Netflow 這些特性 Cisco 很多年前就已經(jīng)駕輕就熟的運(yùn)用于幾乎全線的數(shù)據(jù)中心交換機(jī)產(chǎn)品上，因而 INT XD 可以出現(xiàn)在相對(duì)低端的接入層設(shè)備也就不足為奇了。而沒有這些硬件特性的交換機(jī)想要實(shí)現(xiàn)全時(shí)、全路徑、全流量提供路徑遙測(cè)（Path Telemetry）功能，還是只能借助顯得重很多的 MD 方式。正如上期提到的，MD 當(dāng)前只能在相對(duì)高端的 12.8T 以上平臺(tái)實(shí)現(xiàn)，絕大部分企業(yè)的接入層短期內(nèi)都不太可能選用。

　　端到端的全時(shí)、全流量、全路徑的 Path Telemetry 有什么用？讓我們回到《網(wǎng)工歷險(xiǎn)記 - 拿什么拯救你我的頭發(fā)？》那些讓工程師掉頭發(fā)的運(yùn)維煩惱中來(lái)看看吧，不過(guò)這次受影響的不僅是網(wǎng)工，整個(gè)IT部門的工程師們都在撓頭。

　　這次 IT 部門要對(duì)一個(gè)現(xiàn)有應(yīng)用做一次重大升級(jí)以便開展一項(xiàng)關(guān)鍵業(yè)務(wù)。整個(gè)升級(jí)在測(cè)試環(huán)境演練多遍，非常成功。然后在難得的變更窗口中做最終的生產(chǎn)上線時(shí)卻出了大問(wèn)題，大面積的用戶訪問(wèn)異常，網(wǎng)工們 ping 遍了有問(wèn)題的服務(wù)器都沒有查到丟包，眼見窗口時(shí)間快到了，只好讓應(yīng)用部門回退，幸運(yùn)的是降級(jí)后業(yè)務(wù)恢復(fù)如初，但新業(yè)務(wù)上線算是失敗了。接下來(lái)的幾天從應(yīng)用到系統(tǒng)再到網(wǎng)絡(luò)大家查了個(gè)遍，由于變更窗口時(shí)的現(xiàn)場(chǎng)已經(jīng)不復(fù)存在，留下來(lái)的 log 也查不出任何問(wèn)題，而不揪出根因誰(shuí)也不敢貿(mào)然再次升級(jí)，新業(yè)務(wù)上線就一直這么擱置著。業(yè)務(wù)部門當(dāng)然一直在投訴 IT 不給力，IT 工程師們則一邊撓頭一邊嘆息：“ 唉，要有個(gè)時(shí)間機(jī)器就好了，回到問(wèn)題發(fā)生的時(shí)候看看到底怎么回事啊。”

　　具有 INT XD 全場(chǎng)景 Path Telemetry 記錄功能的大數(shù)據(jù)平臺(tái)其實(shí)就是這樣的時(shí)間機(jī)器，只要端到端部署了硬件化 XD，用戶就可以自建這樣的大數(shù)據(jù)平臺(tái)，也可以使用Cisco交鑰匙的一體化平臺(tái) Nexus Insights（NI）系統(tǒng)。下面我們來(lái)看看 NI 是怎么解決這個(gè)問(wèn)題的。

　　NI 作為智能 AI 大數(shù)據(jù)平臺(tái)，它的數(shù)據(jù)源除了來(lái)自交換機(jī)的 INT XD 外，還能夠集成第三方的應(yīng)用性能監(jiān)測(cè)系統(tǒng)，前幾期提到過(guò)的 Cisco AppDynamics 則是天然支持。所以我們第一時(shí)間可以回溯到升級(jí)發(fā)生的那個(gè)時(shí)刻查看 NI 所集成的 AppDynamics 信息，果然發(fā)現(xiàn)了應(yīng)用在那個(gè)時(shí)候的健康出了問(wèn)題。

　　然后我們點(diǎn)擊 AppDynamics 展示面板中出問(wèn)題的應(yīng)用，立刻呈現(xiàn)出應(yīng)用健康值偏低的應(yīng)用層級(jí)（Tier）。

　

　　我們把處于最上游的那個(gè) Tier 的通信連接展開（上游的健康問(wèn)題很可能是下游問(wèn)題的根因），它立刻展示出了和這個(gè) Tier 有關(guān)的數(shù)據(jù)流：

　

　　我們只要點(diǎn)擊 Browse Network Flow 按鈕，所有 INT XD 記錄的這個(gè) Tier 的數(shù)據(jù)流就都會(huì)展現(xiàn)在你的面前：

　　這時(shí)候我們就可以開始操縱這個(gè) “ 時(shí)間機(jī)器 ” 了，先把時(shí)間調(diào)到升級(jí)之前：

　　瀏覽當(dāng)時(shí)升級(jí)前正常流量的情況：

　　用同樣的方法我們?cè)侔褧r(shí)間拉到升級(jí)之后看這些流的情況，這套系統(tǒng)忠實(shí)的記錄了這個(gè)流的每一個(gè)包在當(dāng)時(shí)的統(tǒng)計(jì)狀態(tài)：

　　咦？怎么升級(jí)的前后短短 1 分鐘內(nèi)，流的路徑就和以前不一樣了。網(wǎng)工們繼續(xù)挖掘，NI 還智能關(guān)聯(lián)了這 1 分鐘里其他的重大異常事件：

　　

　　結(jié)果發(fā)現(xiàn)了頻率非常低、逃過(guò)了網(wǎng)絡(luò)自身檢測(cè)的不正常 EP 移動(dòng)，很有可能是間歇性的主機(jī)路由回送造成的。于是追查這個(gè)回送路由的接口，發(fā)現(xiàn)連接著互聯(lián)網(wǎng)出口防火墻——一個(gè)外部防火墻當(dāng)時(shí)在做著內(nèi)部通信的網(wǎng)關(guān)！

　　診斷到此時(shí)網(wǎng)工們拍著微禿的腦門已經(jīng)開始恍然大悟了，原來(lái)在正常情況下 Tier 之間通信屬于內(nèi)網(wǎng)通信，會(huì)命中數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)的分布式網(wǎng)關(guān)；去互聯(lián)網(wǎng)的流量將使用默認(rèn)路由，指向出口防火墻。在那天升級(jí)應(yīng)用時(shí)卸載舊應(yīng)用組件的步驟會(huì)刪去一些邏輯網(wǎng)絡(luò)接口，操作系統(tǒng)會(huì)把與之綁定的內(nèi)部分布式網(wǎng)關(guān)的路由也一并移去，而新應(yīng)用安裝后并沒有重設(shè)這些被自動(dòng)移除的路由，于是內(nèi)部業(yè)務(wù)流量就會(huì)命中默認(rèn)路由，發(fā)往了出口防火墻。防火墻本身有指向內(nèi)部的路由，一般的流量會(huì)被路由回來(lái)，所以像 ping 這樣的檢測(cè)工具察覺不到丟包，防火墻也不對(duì) trace 提供正確的信息響應(yīng)，網(wǎng)工們自然查不出異常，但新業(yè)務(wù)卻會(huì)因?yàn)橹挥幸粋�(gè)方向的流量經(jīng)過(guò)防火墻引起路徑不對(duì)稱而被攔截，導(dǎo)致最終的業(yè)務(wù)故障。正是因?yàn)?NI 有 AppDynamics 輔助對(duì)應(yīng)用層級(jí)健康提供洞見，再對(duì)自己收集到的全時(shí)、全流量、全路徑的 Path Telemetry 記錄進(jìn)行針對(duì)性聚焦，用戶才有機(jī)會(huì)對(duì)當(dāng)時(shí)故障實(shí)現(xiàn)全場(chǎng)景復(fù)現(xiàn)并找到根因，最終通過(guò)修改應(yīng)用部署腳本讓新業(yè)務(wù)成功上線，IT 部門也憑此卸下業(yè)務(wù)部門的壓力重?fù)?dān)，大家都松了口氣。

　　數(shù)據(jù)中心主動(dòng)運(yùn)維我們連講了三期，到此告一段落。限于篇幅，我們僅涉及了 Cisco AIOps 的一小部分，基于意圖的主動(dòng)運(yùn)維方法論框架以及 Nexus Dashboard / Nexus Insights / AppDynamics 解決方案我們也只淺嘗輒止。還是那句老話，欲知詳情，請(qǐng)繼續(xù)關(guān)注 “ 思科聯(lián)天下 ”、“思科渠道微情報(bào) ” 以及思科的 DEVNET 和 dCloud 網(wǎng)站，在那里你不僅可以獲取 Cisco AIOps 的詳細(xì)信息，還可以自己親手一試。