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

　　在上一期 《 思享家 | 網(wǎng)工歷險記 》中我們?yōu)檎�救網(wǎng)工們的頭發(fā)，祭出了個大殺器 —— 基于意圖的主動運維系統(tǒng)，并小試牛刀，輕松解決了網(wǎng)工們頭疼的 “ 幽靈丟包 ” 問題。具體來講，這個架構(gòu)長得這個樣子：

　　左半部分下方是由自動化引擎構(gòu)成的自動化層，它依據(jù)一定策略從復(fù)雜的多云基礎(chǔ)架構(gòu)中收集足夠的現(xiàn)場數(shù)據(jù)供給它的上一層 —— 由洞見引擎構(gòu)成的洞見層，后者對數(shù)據(jù)進行處理、分析和判斷，輔助人類做出正確的決策（ 我們稱為 “ 意圖 ” ）。這些意圖可能是對數(shù)據(jù)收集策略的調(diào)整，也可能是直接實現(xiàn)某個主動運維的目標(biāo)，總之在形成后都會被發(fā)送給下面的自動化層，它們被轉(zhuǎn)換為具體的執(zhí)行策略，由自動化引擎驅(qū)動執(zhí)行，并同時繼續(xù)收集數(shù)據(jù)反饋給洞見層完成狀態(tài)監(jiān)控，從而最終形成一個不斷自我優(yōu)化的閉環(huán)。“ 幽靈丟包 ” 問題就是通過自動化層的 AppDynamics Agent 探針收集了大量數(shù)據(jù)，在洞見層的洞見引擎 AppDynamics 對這些數(shù)據(jù)分析出應(yīng)用結(jié)構(gòu)和結(jié)構(gòu)內(nèi)每一層應(yīng)用體驗的定量化指標(biāo)，最終找到導(dǎo)致端到端體驗惡化的精確位置（ 即 “ 診斷意圖 ” ），再交給自動化層的自動化引擎 ACI APIC 控制器進行底層精細化監(jiān)測和診斷，從而最終抓獲幽靈丟包元兇。

　　其實我們看到這個例子中 ACI APIC 的故障診斷工具箱內(nèi)還是傳統(tǒng)的端口計數(shù)、差錯統(tǒng)計、Traceroute 等，但有了洞見層明確的診斷意圖加持，立刻功力倍增，瞬間搞定了傳統(tǒng)要幾天才能解決的難題。如果能把自動化層收集數(shù)據(jù)的手段進一步升級，比如引入大數(shù)據(jù)收集手段；把洞見層處理和分析數(shù)據(jù)的手段升級為大數(shù)據(jù)分布式處理、機器學(xué)習(xí)和人工智能，那會是一幅什么圖景呢？不用憑空想象，因為這就是 Cisco 智能主動運維系統(tǒng) Nexus Insights 。

　　我們就從 Nexus Insights 的自動化層如何實現(xiàn)大數(shù)據(jù)收集策略開始。

　　自動化層為什么要加持大數(shù)據(jù)呢？我們常常把網(wǎng)絡(luò)流量比喻為道路交通（ 在英語里甚至是同一個詞 Traffic ），那發(fā)現(xiàn)網(wǎng)絡(luò)異常就相當(dāng)于交警檢查交通違章。傳統(tǒng)收集數(shù)據(jù)的手段往往是一個收集器輪流采集網(wǎng)絡(luò)節(jié)點數(shù)據(jù)，或者發(fā)出探測包沿線探測（ 比如 ping、traceroute 等），這就好比交警輪流到路口檢查闖紅燈和超速，或者騎著摩托在路上巡邏，撞見了就抓、撞不見也沒什么辦法。在網(wǎng)絡(luò)世界中也一樣，在收集器輪詢的空隙、探測包之間的間隔以及探測包沒能覆蓋的路徑上，到處都有可能存在導(dǎo)致用戶體驗惡化的瞬斷、丟包，突發(fā)擁塞、延遲和抖動，也就像沒能親臨現(xiàn)場的警察漏掉交通違章一樣被收集器漏掉了。這種由收集器方發(fā)起的數(shù)據(jù)收集模式被稱為 “ 拉取 ”（ Pull ）。

　

　　更高效的數(shù)據(jù)收集方式一定是 “ 推送 ”（ Push ）而非 “ 拉取 ”（ Pull ）。想象一下不靠交警親臨，而是所有車輛和路口都設(shè)置攝像頭，并實時主動對外報告交通狀態(tài)會是一種什么場面？必然是任何違章都逃不過法眼。所以必須要想辦法讓每一個用戶數(shù)據(jù)包（ 車輛攝像頭 ）、每一個網(wǎng)絡(luò)交換機（ 路口攝像頭 ）都向外報告，這種利用帶內(nèi)數(shù)據(jù)包和帶內(nèi)網(wǎng)絡(luò)設(shè)備主動推送（ Push ）的數(shù)據(jù)收集手段，又稱為帶內(nèi)網(wǎng)絡(luò)遙測（ In-band Network Telemetry，INT ）。當(dāng)然代價就是數(shù)據(jù)量相當(dāng)大（ 所謂 “ 大數(shù)據(jù) ” ），但我們因此獲得的是全時全場景信息，能為洞見層提供全真的場景重現(xiàn)。

　　云基礎(chǔ)架構(gòu)單端口已經(jīng)演進到了 400G ，要想不影響業(yè)務(wù)數(shù)據(jù)流而又逐包的實現(xiàn)全場景重現(xiàn)，就必須依靠設(shè)備的硬件轉(zhuǎn)發(fā)芯片。也就是說，無論廠商宣傳的軟件網(wǎng)管平臺多么酷炫，它的交換機的硬件決定了這個舞臺的天花板。因此著名的交換機、路由器和 NIC 硬件開源標(biāo)準(zhǔn)組織 P4（ p4.org ）對數(shù)據(jù)平面 INT 做了功能定義和分類：

　

　　沒耐心看完本技術(shù)宅絮叨的小伙伴記住上面這三幅圖就可以點贊回家了 （ 手動狗頭 ），但要想洞察各廠數(shù)據(jù)中心交換機內(nèi)部玄機，還是需要耐心看完本文。

　　在用戶的實際業(yè)務(wù)數(shù)據(jù)包內(nèi)嵌入監(jiān)控信息，即所謂 Embed（ 嵌入 ）方式，就好比在路上跑的所有車都加上攝像頭，是最直接的收集路徑狀態(tài)的方法。但路徑信息要想都嵌入進去，勢必會因為附加的延遲、MTU 甚至安全問題而不能被用戶接受，于是分化出兩種解決方案：直接對用戶數(shù)據(jù)包動手，但不碰負載，而是只動包頭的封裝，當(dāng)然包頭字段也只夠嵌入監(jiān)控信令或指令，這稱為 eMbed instruct（X）ions（ MX ）；另一個方案是完全不觸碰用戶數(shù)據(jù)包，而是僅將用戶數(shù)據(jù)包頭單獨復(fù)制而形成一個新數(shù)據(jù)包，由于這個包的包頭和用戶數(shù)據(jù)包頭一樣，因此可以和用戶數(shù)據(jù)流并駕齊驅(qū)，同時它每經(jīng)過一跳，就把相應(yīng)的信息以一段段 Metadata 的方式掛在包頭后面，就像火車車皮，越走掛的越多，最后到終點把所有 Metadata 卸下來封裝到隧道內(nèi)發(fā)給收集器，這稱為 eMbed Data（MD）。MD 不是在用戶車內(nèi)裝攝像頭，而更像是讓狗仔隊跟蹤，一路走一路拍。

　　小伙伴們肯定關(guān)心哪一個最好用，可惜工程上沒有完美的技術(shù)，它們各有優(yōu)缺點。MX 的優(yōu)點是非常輕量化，無須附加流量就能夠無抽樣的監(jiān)測每一個用戶數(shù)據(jù)包，但包頭字段能攜帶的信息很有限，只能附加一些信令或指令，因而需要整個網(wǎng)絡(luò)系統(tǒng)與之配合才能實現(xiàn)相應(yīng)功能，靈活性和擴展性受限。

　　MD 能攜帶大量信息，所以功能擴展強大，但工程上也有很多問題，比如要用多高的頻率復(fù)制用戶數(shù)據(jù)包頭呢？1:1 復(fù)制相當(dāng)于把網(wǎng)上負載增加一倍，太稀疏的抽樣又導(dǎo)致不能反映用戶數(shù)據(jù)流瞬間的真實情況，相當(dāng)于狗仔隊跟丟了。另外攜帶信息的效率也是問題，網(wǎng)絡(luò)異常發(fā)生的位置和時間非常隨機，如果很長時間沒有變化，而每一個包都攜帶著大量完全沒什么變化的狀態(tài)就顯得非常浪費，而一些異常突然發(fā)生卻不一定剛好有數(shù)據(jù)包經(jīng)過，會耽誤信息的收集，所以要想全面收集信息，硬件資源投入就非常巨大，這同時也帶來的第三個問題，即硬件實現(xiàn)難度。當(dāng)前主流商業(yè)芯片廠商只在非常高端的芯片上做了部分實現(xiàn)，但即便是這樣，為了平衡成本和復(fù)雜度，在需要最復(fù)雜操作的入口和出口交換機還是無法全硬件化完成，全時全景信息捕捉很容易造成資源過載，很多廠商不建議全時開啟，致使 MD 功能名存實亡。

　　Cisco 的工程實現(xiàn)要比 P4 的標(biāo)準(zhǔn)分類早很多，比如早在第一代 ACI 開始就已經(jīng)廣泛部署的 Atomic Counter 其實就是一種 MX 的實現(xiàn)。利用 VXLAN 發(fā)明者和自研 ASIC 轉(zhuǎn)發(fā)芯片的優(yōu)勢，Cisco 在 VXLAN 封裝的頭部設(shè)置了特殊的比特位用于傳遞 MX 的信令，又借助 Nexus 系列交換機在整體硬件設(shè)計上的優(yōu)勢實現(xiàn)了硬件化的 PTP（ 高精度時間同步協(xié)議 ）和皮秒級時間戳封裝能力，使得用戶進行正常業(yè)務(wù)流傳輸?shù)耐瑫r，就在極為精確的測量所有端到端路徑上每一個包的延遲、抖動和丟包，并把信息按每 30 秒為屆進行匯集，報告給自動化引擎（ SDN控制器APIC ），整個過程在 ASIC 上實現(xiàn)，用戶毫無感知，像是運行在 ACI 上的用戶業(yè)務(wù)流與生自帶的特性一樣。某大型知名互聯(lián)網(wǎng)平臺就是利用這個特性，密切監(jiān)控其最關(guān)鍵的數(shù)十個端到端數(shù)據(jù)流健康狀態(tài)（ 主要是Proxy/LoadBalancer ），只要延遲、抖動和丟包數(shù)超過閾值，就會在 ACI 控制器對應(yīng)的應(yīng)用健康分值上減去相應(yīng)分?jǐn)?shù)（ 對，因為 ACI 控制器有這樣的應(yīng)用健康分值核算功能，其實它也是一個很好的洞見引擎 ）。

　　在 MD 方面，Cisco 兩年前就在其 Nexus 3000 系列 400G 平臺上以純硬件方式實現(xiàn)了完整的 MD 功能，MD 功能不再名存實亡。而一些用戶廣泛使用的商業(yè)芯片，預(yù)計要到 2022 年左右開始才能提供類似全硬件實現(xiàn)的功能。但無論采用 MD 的哪種選擇，端到端交換機的產(chǎn)品形態(tài)都會是單芯片 12.8T 以上、端口帶寬 400G 的平臺，這在近幾年內(nèi)對絕大部分企業(yè)的柜頂接入交換機都不太可能成為現(xiàn)實。

　　那么問題來了，如果用戶需求超出了 MX/Atomic Counter 規(guī)定的功能（ 比如需要知道具體的丟包、延遲的位置和原因 ），而普通企業(yè)又無法短期內(nèi)端到端部署能提供更詳細信息的 MD 方式，有沒有一種功能強大但同時又足夠輕量化、性價比高到能端到端部署的帶內(nèi)遙測方案呢？

　　答案就在下期 —— INT XD。