一 概述
近日，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 任務進行實時的計算分析。
2 如何解決多租戶併發的隔離以及探針對轉發的性能損耗？
為了降低性能損耗，我們設計讓控制器下發規則時，只需要起始轉發節點生效，進行報文帶內染色，而其他轉發節點只需支持基於染色的匹配採集，另外也做了染色的快慢速分離和首包的規則匹配。針對虛擬轉發設備則是預置規則，沒有動態下發過程，對系統壓力小。而在數據採集過程中，做一定的限速保護，並在任務中控制好包的數量，整體過程對轉發的性能消耗降到最低，接著探針覆蓋丟包位置，就可簡單直接地採集到丟包原因。
3 如何解決分佈式數據採集的時序問題？
在採集數據時，常會遇到日誌流散列在不同地域，時序也無法保證的問題。因此我們在 VTraceApp 和 Jstorm 之間設計了一個三次握手過程，建立了“任務-染色-轉發-採集-分析”的體系，確保大量分佈式數據採集的正確性和時效性：
新建 VTrace 任務時，VTraceApp 向任務 DB 插入狀態為 new 的一條任務。
Jstorm 讀到 new 任務，將 new 改為 JStormReady。
VTraceApp 收到 JStormReady 後，向控制器發送下發 VTrace 任務的指令。
4 如何解決複雜轉發模型下的自動算路？
首先，我們基於上雲和下雲的邊緣標準設計出一套標準的排序算法，包含首尾節點標識、根據同節點數據的時序性以及不同節點的 NAT 轉換關係。這樣即使流量經過的設備和設備類型很多，只要虛擬轉發設備安裝了同款採集探針，不需做任何數據開發和調整，按照統一算法就可以實現路徑的自動計算了。再利用安裝的探針來採集每個數據包的時間指標，使用路徑中時延計算的標準公式，結合可視化技術，實現一鍵呈現流量路徑，快速分析丟包位置、丟包原因和時延情況。
五 覆蓋場景
1 VPC 內的流量訪問
經典場景：企業上雲後，企業生產業務（部署在 ECS 中）往往需要和雲上其他雲服務如 RDS 數據庫進行訪問。
2 VPC 與公網之間的流量訪問
經典場景：大部分的企業服務都需要被公網訪問，如遊戲服務等。
3 雲上 VPC 與雲下客戶機房間的訪問
經典場景：很多客戶的部分服務可能有對外聯設備的依賴，會部署在自建機房中，那麼和雲上環境有互通的需要。
4 不同 VPC 之間的訪問（可能涉及跨域）
經典場景：大企業級組網，一般有多地域部署的需要，也會考慮生產環境/日常環境/運維管理區的隔離性，會把不同的環境部署在不同的 VPC 上，不同 VPC 之間互相訪問的需要也是比較常見的。
六 總結
目前 VTrace 系統已經在阿里雲網絡內部大規模普及，效果顯著，大大減少了診斷時間，從人為處理的平均幾小時下降到分鐘級的耗時，現在它已經成為雲網絡故障排查必不可少的工具，未來將會逐步開放給阿里雲用戶，讓阿里雲用戶也能體驗到 VTrace 帶來的極速網絡排障能力。