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

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

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

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

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

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

　

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

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

　

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

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

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

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

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

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

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

　　答案就在下期 —— INT XD。