阿里妹導讀：VTrace 是一個解決雲網絡持續性丟包問題的自動化診斷系統，核心思想是“任務-匹配-染色-採集-分析”，結合大資料技術，旨在實時快速的自動分析出雲網絡端到端的流量拓撲路徑，並給出準確的問題原因和解決方案，讓網路運維不再需要那麼“專業”，那麼“複雜”。

一 概述

近日，SIGCOMM 2020 公佈了今年的入選論文，阿里雲網絡洛神的 “VTrace: Automatic Diagnostic System for Persistent Packet Loss in Cloud-Scale Overlay Network” 是國內歷年來唯一一篇雲網絡方向的入選論文，今年 SIGCOMM 總計收到了 250 篇投稿，成功入選的僅 54 篇，阿里雲網絡洛神平臺的技術實力得到了網路業界頂級會議的認可。

為了方便大家更通俗地理解這篇論文，本文將從技術層面解讀雲網絡面臨的問題，以及介紹 VTrace 系統的整體技術架構。

說明：以下介紹的所有技術都已在論文投稿前申請了專利保護。

二 背景

如果把每天在用的手機 App 當成現實生活裡的商場，電影院，餐館的話，雲網絡就是把這些商場，電影院和餐館連線在一起的高速公路。在現實社會裡，如果駕車去電影院時發現路堵了，可能會導致錯過期待已久的電影。同樣的，在雲網絡的世界裡，當某個裝置發生擁塞或者事故了，會導致各種 APP 應用出現異常、卡頓，視訊打不開等。

而隨著雲網絡拓撲日益複雜，承載的網路業務不斷增多，虛擬網路承載著使用者多種多樣的業務功能，如 NAT、頻寬等，往往要求頻繁更新以滿足使用者業務變化。承載著基礎轉發能力的物理網路在轉發策略中任何一個小小的問題都可能導致使用者在雲網絡中的資料包丟失。而傳統工具如 traceroute 等無法在雲網絡使用，而人為抓包的方式對運維工程師的專業技能和經驗要求較高，排查過程也比較繁瑣耗時，往往最終也只能界定丟包位置而難以得到丟包原因。

面對這樣的問題，雲網絡需要一個”交通警察“，每當網路中間有擁塞或者事故了它需要能夠及時發現具體位置，然後及時處理，來讓整個網路恢復正常。一旦出現卡頓、丟包等問題，雲網絡的交警需要能在幾秒鐘內從這張遍佈全球數百萬的裝置裡找到原因，是非常大的挑戰。

所以，不管是對使用者而言，還是對雲網絡供應商來說，都急需一個可以在高負載、複雜拓撲的雲網絡下能實現快速響應的、可控的、自動化的丟包問題排查工具，而 VTrace 就是阿里雲網絡產品設計並推出的一款解決雲網絡持續性丟包問題的自動化診斷系統，就是我們所說的那個有著超級大腦的超級交警。

三 面臨的挑戰

動態變化的網路資料流

資料在網路裡面的流轉就像我們每天駕駛著車子在城市裡穿梭一樣，唯一的區別是網路裡面的紅綠燈和每個路口的方向會非常多，並且紅綠燈的變化也不固定。使用者可以隨時修改網路的安全組來讓資料包停下來或者通過，也可以通過修改路由來讓某個路口增加一個分叉。想象一下在一個有 1000 個分叉，並且紅綠燈在不停變換的路口時指揮交通就可以感受網路交警每天的工作壓力了。

無處不在的潛在網路丟包點

在資料的傳輸過程中，一旦在某個地方發生擁塞，或者某個地方紅燈了，就停下來無法前進。這個現象在網路裡隨處可見，對於只有幾十個路口的小城鎮，找到堵塞的路口可能不需要太久，但是對於雲網絡，這樣的路口可能有上萬個，想要快速找到擁塞的路口就非常困難了。

最小化效能影響

為了解決上面的問題，傳統的做法會讓資料在經過每個路口的時候都給交警傳送一條簡訊，告訴他到哪了，然後現在是紅燈還是綠燈，前面排隊還有多久。但是這個做法首先成本太高，每天傳送的簡訊可能就需要幾千萬條，另外，如果這個交警就拿著一部手機一條條記錄資訊，他也根本忙不過來。如何讓網路資料包能以最低的成本最小的代價通知到網路交警，並且能快速處理這些資料包的資訊，是需要找到一個很好的解決方法的。

四 設計與技術

目標與要求

基於面臨的挑戰，我們希望實現以下兩個目標：

低損耗資料包資訊、流量路徑和傳輸品質分析：在不影響使用者業務的情況下，分析資料包資訊，流量路徑以及傳輸品質，並精準探測網路傳輸的時延抖動。精準分析丟包原因定位：當丟包發生，VTrace 系統需要快速找到有問題的虛擬網元或物理網元，並提出根本原因及修復丟包的可能。

考慮到雲網絡環境，對 VTrace 系統有以下幾個要求：

VTrace 能夠基於資料包丟失的使用者現場進行分析。VTrace 的部署和使用不會影響正常的網路功能，對使用者無感知。由於存在數百萬雲使用者，VTrace 需要能夠支援不同使用者的併發使用 。

技術挑戰

主動探測技術如 pingmesh，適用於網路監控場景，但很難滿足基於使用者資料丟失現象進行分析的要求，也很可能因為和使用者資料包的差異性難以還原丟包路徑。被動式網路監控技術如 VeriFlow，對使用者有依賴性，無法滿足對使用者無感知的要求。網路除錯技術如 SDN Traceroute、NetAlytics 等，目前不適用一些雲網絡架構，也無法做到直觀地給出丟包原因。而一些旁路分析架構，如新提出的 INT 技術（In-band Network Telemetry），雖可以實現目標，但對網路裝置的要求高，同時由於旁路導致的頻寬消耗，會影響對使用者的網路功能 。

設計思路

1 如何解決多網元節點的資料採集和匯聚？

在採集上我們使用了阿里雲上成熟的日誌服務產品（SLS），無需開發就能快捷完成日誌資料採集、消費等功能，通過其強大的採集能力，將數百萬的 VFD（虛擬轉發裝置）日誌匯聚到各地域中心，便於後續的分析處理。

由於日誌資料的實時性、分散式儲存的地域性以及龐大資料量，需要利用大資料技術將所有資料收集以執行流量路徑重建和進一步分析，我們採用了流處理引擎 JStorm，JStorm 具備千萬級報文資料實時分析能力，其可擴充套件性和強大的計算能力有助於幫助潛在的大量 VTrace 任務進行實時的計算分析。

為了降低效能損耗，我們設計讓控制器下發規則時，只需要起始轉發節點生效，進行報文帶內染色，而其他轉發節點只需支援基於染色的匹配採集，另外也做了染色的快慢速分離和首包的規則匹配。針對虛擬轉發裝置則是預置規則，沒有動態下發過程，對系統壓力小。而在資料採集過程中，做一定的限速保護，並在任務中控制好包的數量，整體過程對轉發的效能消耗降到最低，接著探針覆蓋丟包位置，就可簡單直接地採集到丟包原因。

3 如何解決分散式資料採集的時序問題？

在採集資料時，常會遇到日誌流雜湊在不同地域，時序也無法保證的問題。因此我們在 VTraceApp 和 Jstorm 之間設計了一個三次握手過程，建立了“任務-染色-轉發-採集-分析”的體系，確保大量分散式資料採集的正確性和時效性：

新建 VTrace 任務時，VTraceApp 向任務 DB 插入狀態為 new 的一條任務。Jstorm 讀到 new 任務，將 new 改為 JStormReady。VTraceApp 收到 JStormReady 後，向控制器傳送下發 VTrace 任務的指令。

首先，我們基於上雲和下雲的邊緣標準設計出一套標準的排序演算法，包含首尾節點標識、根據同節點資料的時序性以及不同節點的 NAT 轉換關係。這樣即使流量經過的裝置和裝置型別很多，只要虛擬轉發裝置安裝了同款採集探針，不需做任何資料開發和調整，按照統一演算法就可以實現路徑的自動計算了。再利用安裝的探針來採集每個資料包的時間指標，使用路徑中時延計算的標準公式，結合視覺化技術，實現一鍵呈現流量路徑，快速分析丟包位置、丟包原因和時延情況。

五 覆蓋場景

1 VPC 內的流量訪問

經典場景：企業上雲後，企業生產業務（部署在 ECS 中）往往需要和雲上其他雲服務如 RDS 資料庫進行訪問。

2 VPC 與公網之間的流量訪問

經典場景：大部分的企業服務都需要被公網訪問，如遊戲服務等。

3 雲上 VPC 與雲下客戶機房間的訪問

經典場景：很多客戶的部分服務可能有對外聯裝置的依賴，會部署在自建機房中，那麼和雲上環境有互通的需要。

4 不同 VPC 之間的訪問（可能涉及跨域）

經典場景：大企業級組網，一般有多地域部署的需要，也會考慮生產環境/日常環境/運維管理區的隔離性，會把不同的環境部署在不同的 VPC 上，不同 VPC 之間互相訪問的需要也是比較常見的。

六 總結

目前 VTrace 系統已經在阿里雲網絡內部大規模普及，效果顯著，大大減少了診斷時間，從人為處理的平均幾小時下降到分鐘級的耗時，現在它已經成為雲網絡故障排查必不可少的工具，未來將會逐步開放給阿里雲使用者，讓阿里雲使用者也能體驗到 VTrace 帶來的極速網路排障能力。