是一個介紹如何利用思科先進(jìn)技術(shù)解決客戶難題的欄目。每期聚焦一個技術(shù)熱點或應(yīng)用場景，邀請資深思科技術(shù)專家深入淺出地介紹，為讀者提供實用性強(qiáng)的建議。
前兩期我們介紹的基于意圖的主動運維系統(tǒng)，已經(jīng)能讓很多傳統(tǒng)運維手段鳳凰涅盤、迸發(fā)出新的生命力，但大數(shù)據(jù)和人工智能的加持還可讓主動運維能力更上一層樓。在《噩夢不再，美夢成真—數(shù)據(jù)中心智能主動運維》中我們把自動化層所驅(qū)動的大數(shù)據(jù)數(shù)據(jù)收集模式比喻為交通違章的視頻監(jiān)控，帶內(nèi)遙測 INT MX 相當(dāng)于車內(nèi)裝攝像頭，情況反映真實但能拍到的太少；INT MD 相當(dāng)于狗仔隊跟著你拍，可以全方位無死角但資源消耗太大、實現(xiàn)成本太高。那有沒有功能強(qiáng)大但同時又足夠輕量化、性價比能保證現(xiàn)階段端到端部署的 INT 帶內(nèi)遙測方案呢？想想真實世界的交通違章罰單都是被什么樣的攝像頭拍攝下來的，就能夠猜到答案了。
不錯，上面那樣的攝像頭才是讓老司機(jī)們最害怕的，闖個紅燈、軋個實線都難逃法眼。INT XD 也是這樣的工作方式，由交換機(jī)監(jiān)視來來往往的數(shù)據(jù)包并向后臺實時報告。不過可能你也會有疑問，攝像機(jī)對應(yīng)到真實網(wǎng)絡(luò)中，豈不是每一個經(jīng)過交換機(jī)的數(shù)據(jù)包都需要被 “ 拍下來 ” 傳到后臺，這樣就算交換機(jī)硬件足夠強(qiáng)大，后臺的數(shù)據(jù)也是大到恐怖吧，INT XD 的輕量化優(yōu)勢從何而來呢？其實和真實世界查違章必須定位到具體車輛不同，網(wǎng)絡(luò)世界里雖然也需要對異常發(fā)生的位置、時間和程度等信息掌握得盡可能精確詳盡，但完全沒有必要定位到具體的某個數(shù)據(jù)包，只要有足夠細(xì)粒度的統(tǒng)計信息，大數(shù)據(jù)平臺的AI就能實現(xiàn)諸如故障早期預(yù)測、問題的根因分析等智能主動運維功能。這就是 XD 方法的技術(shù)核心所在——如何巧妙的設(shè)計算法，按批次生成報告而非按每一個包生成報告，從而具備足夠的統(tǒng)計細(xì)粒度的同時盡可能降低軟硬件負(fù)擔(dān)。
按時間周期批量化不難做到，利用硬件把周期縮短到每秒生成報告都不成問題。難在如何生成更有統(tǒng)計價值的報告，比如有意義的延遲統(tǒng)計至少需要給出 1 秒內(nèi)所有包的平均延遲、平均抖動容限、最大最小延遲等，這就需要測量出每一個包的延遲數(shù)值來計算，例如對逐跳延遲需要精心設(shè)計轉(zhuǎn)發(fā)流水線，對每一個包 Ingress 打時間戳，在 Egress 驗證時間戳，而對端到端延遲則需要Ingress交換機(jī)和 Egress 交換機(jī)之間實現(xiàn)高精度時間同步協(xié)議（PTP），而這絕大部分都需要內(nèi)置在轉(zhuǎn)發(fā)芯片內(nèi)，減少 CPU 參與。
只在時間上分批次是不夠的，因為這樣統(tǒng)計出的數(shù)據(jù)分不出是哪個業(yè)務(wù)，對改善業(yè)務(wù)體驗沒有指導(dǎo)意義。要做業(yè)務(wù)流區(qū)分，有經(jīng)驗的小伙伴一定想到了五元組流表，不錯，Cisco 正是利用江湖上久負(fù)盛名的 Netflow 流表對所有數(shù)據(jù)進(jìn)行批次劃分，這樣所有的統(tǒng)計都?xì)w類到具體的流記錄中，從而具備了業(yè)務(wù)的上下文關(guān)聯(lián)。同樣要做到全流量記錄，從流表的匹配、數(shù)據(jù)記錄到數(shù)據(jù)的封裝導(dǎo)出，仍然必須都是全硬件化而不能有 CPU 參與。
硬件化 PTP、Netflow 這些特性 Cisco 很多年前就已經(jīng)駕輕就熟的運用于幾乎全線的數(shù)據(jù)中心交換機(jī)產(chǎn)品上，因而 INT XD 可以出現(xiàn)在相對低端的接入層設(shè)備也就不足為奇了。而沒有這些硬件特性的交換機(jī)想要實現(xiàn)全時、全路徑、全流量提供路徑遙測（Path Telemetry）功能，還是只能借助顯得重很多的 MD 方式。正如上期提到的，MD 當(dāng)前只能在相對高端的 12.8T 以上平臺實現(xiàn)，絕大部分企業(yè)的接入層短期內(nèi)都不太可能選用。
端到端的全時、全流量、全路徑的 Path Telemetry 有什么用？讓我們回到《網(wǎng)工歷險記 - 拿什么拯救你我的頭發(fā)？》那些讓工程師掉頭發(fā)的運維煩惱中來看看吧，不過這次受影響的不僅是網(wǎng)工，整個IT部門的工程師們都在撓頭。
這次 IT 部門要對一個現(xiàn)有應(yīng)用做一次重大升級以便開展一項關(guān)鍵業(yè)務(wù)。整個升級在測試環(huán)境演練多遍，非常成功。然后在難得的變更窗口中做最終的生產(chǎn)上線時卻出了大問題，大面積的用戶訪問異常，網(wǎng)工們 ping 遍了有問題的服務(wù)器都沒有查到丟包，眼見窗口時間快到了，只好讓應(yīng)用部門回退，幸運的是降級后業(yè)務(wù)恢復(fù)如初，但新業(yè)務(wù)上線算是失敗了。接下來的幾天從應(yīng)用到系統(tǒng)再到網(wǎng)絡(luò)大家查了個遍，由于變更窗口時的現(xiàn)場已經(jīng)不復(fù)存在，留下來的 log 也查不出任何問題，而不揪出根因誰也不敢貿(mào)然再次升級，新業(yè)務(wù)上線就一直這么擱置著。業(yè)務(wù)部門當(dāng)然一直在投訴 IT 不給力，IT 工程師們則一邊撓頭一邊嘆息：“ 唉，要有個時間機(jī)器就好了，回到問題發(fā)生的時候看看到底怎么回事啊。”
具有 INT XD 全場景 Path Telemetry 記錄功能的大數(shù)據(jù)平臺其實就是這樣的時間機(jī)器，只要端到端部署了硬件化 XD，用戶就可以自建這樣的大數(shù)據(jù)平臺，也可以使用Cisco交鑰匙的一體化平臺 Nexus Insights（NI）系統(tǒng)。下面我們來看看 NI 是怎么解決這個問題的。
NI 作為智能 AI 大數(shù)據(jù)平臺，它的數(shù)據(jù)源除了來自交換機(jī)的 INT XD 外，還能夠集成第三方的應(yīng)用性能監(jiān)測系統(tǒng)，前幾期提到過的 Cisco AppDynamics 則是天然支持。所以我們第一時間可以回溯到升級發(fā)生的那個時刻查看 NI 所集成的 AppDynamics 信息，果然發(fā)現(xiàn)了應(yīng)用在那個時候的健康出了問題。
然后我們點擊 AppDynamics 展示面板中出問題的應(yīng)用，立刻呈現(xiàn)出應(yīng)用健康值偏低的應(yīng)用層級（Tier）。
我們把處于最上游的那個 Tier 的通信連接展開（上游的健康問題很可能是下游問題的根因），它立刻展示出了和這個 Tier 有關(guān)的數(shù)據(jù)流：
我們只要點擊 Browse Network Flow 按鈕，所有 INT XD 記錄的這個 Tier 的數(shù)據(jù)流就都會展現(xiàn)在你的面前：
這時候我們就可以開始操縱這個 “ 時間機(jī)器 ” 了，先把時間調(diào)到升級之前：
瀏覽當(dāng)時升級前正常流量的情況：
用同樣的方法我們再把時間拉到升級之后看這些流的情況，這套系統(tǒng)忠實的記錄了這個流的每一個包在當(dāng)時的統(tǒng)計狀態(tài)：
咦？怎么升級的前后短短 1 分鐘內(nèi)，流的路徑就和以前不一樣了。網(wǎng)工們繼續(xù)挖掘，NI 還智能關(guān)聯(lián)了這 1 分鐘里其他的重大異常事件：
結(jié)果發(fā)現(xiàn)了頻率非常低、逃過了網(wǎng)絡(luò)自身檢測的不正常 EP 移動，很有可能是間歇性的主機(jī)路由回送造成的。于是追查這個回送路由的接口，發(fā)現(xiàn)連接著互聯(lián)網(wǎng)出口防火墻——一個外部防火墻當(dāng)時在做著內(nèi)部通信的網(wǎng)關(guān)！
診斷到此時網(wǎng)工們拍著微禿的腦門已經(jīng)開始恍然大悟了，原來在正常情況下 Tier 之間通信屬于內(nèi)網(wǎng)通信，會命中數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)的分布式網(wǎng)關(guān)；去互聯(lián)網(wǎng)的流量將使用默認(rèn)路由，指向出口防火墻。在那天升級應(yīng)用時卸載舊應(yīng)用組件的步驟會刪去一些邏輯網(wǎng)絡(luò)接口，操作系統(tǒng)會把與之綁定的內(nèi)部分布式網(wǎng)關(guān)的路由也一并移去，而新應(yīng)用安裝后并沒有重設(shè)這些被自動移除的路由，于是內(nèi)部業(yè)務(wù)流量就會命中默認(rèn)路由，發(fā)往了出口防火墻。防火墻本身有指向內(nèi)部的路由，一般的流量會被路由回來，所以像 ping 這樣的檢測工具察覺不到丟包，防火墻也不對 trace 提供正確的信息響應(yīng)，網(wǎng)工們自然查不出異常，但新業(yè)務(wù)卻會因為只有一個方向的流量經(jīng)過防火墻引起路徑不對稱而被攔截，導(dǎo)致最終的業(yè)務(wù)故障。正是因為 NI 有 AppDynamics 輔助對應(yīng)用層級健康提供洞見，再對自己收集到的全時、全流量、全路徑的 Path Telemetry 記錄進(jìn)行針對性聚焦，用戶才有機(jī)會對當(dāng)時故障實現(xiàn)全場景復(fù)現(xiàn)并找到根因，最終通過修改應(yīng)用部署腳本讓新業(yè)務(wù)成功上線，IT 部門也憑此卸下業(yè)務(wù)部門的壓力重?fù)?dān)，大家都松了口氣。
數(shù)據(jù)中心主動運維我們連講了三期，到此告一段落。限于篇幅，我們僅涉及了 Cisco AIOps 的一小部分，基于意圖的主動運維方法論框架以及 Nexus Dashboard / Nexus Insights / AppDynamics 解決方案我們也只淺嘗輒止。還是那句老話，欲知詳情，請繼續(xù)關(guān)注 “ 思科聯(lián)天下 ”、“思科渠道微情報 ” 以及思科的 DEVNET 和 dCloud 網(wǎng)站，在那里你不僅可以獲取 Cisco AIOps 的詳細(xì)信息，還可以自己親手一試。
