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