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

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

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

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

　　我們就從 Nexus Insights 的自動(dòng)化層如何實(shí)現大數據收集策略開(kāi)始。

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

　

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

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

　

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

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

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

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

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

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

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

　　答案就在下期 —— INT XD。