一 概述
近日，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 帶來的極速網絡排障能力。