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

01、概述

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

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

02、背景

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

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

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

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

03、面臨的挑戰**

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

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

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

04、設計與技術

目標與要求
基於我們面臨的挑戰，具體來說，應該來實現以下兩個目標：
1、在正常情況下，顯示數據包信息及流量路徑，沒絕對的丟包也不代表沒問題的，網絡傳輸的時延抖動也是網絡的常見問題之一，所以還需要分析數據包的傳輸質量；
2、當丟包發生，VTrace需要找到有問題的虛擬網元（由此也能分析出物理網元），並提出根本原因及修復丟包的可能；
在雲網絡系統中，可能有多種方式實施這樣的系統，但是考慮到雲網絡環境，對VTrace系統有以下幾個要求：
1、VTrace能夠基於數據包丟失的用戶現場進行分析；
2、VTrace的部署和使用不會影響正常的網絡功能，對用戶無感知；
3、由於存在數百萬雲用戶，VTrace需要能夠支持不同用戶的併發使用。

現有技術

1. 主動探測技術，如pingmesh，比較普通地適用於網絡監控場景，但很難滿足基於用戶數據報丟失現象進行分析的要求，也很可能因為和用戶數據包的差異性難以還原丟包路徑，所以VTrace無法使用；
2. 被動式網絡監控技術，如VeriFlow，雖無需注入任何探針，但無法避免對用戶有依賴性，無法滿足對用戶無感知的要求；
3. 網絡調試技術，如SDN Traceroute、NetAlytics等，目前對一些雲網絡架構並不適用，也無法做到直觀地給出丟包原因，而一些旁路分析架構，如新提出的INT技術（In-band Network Telemetry），雖可以實現目標，但對網絡設備的要求高，同時由於旁路導致的帶寬消耗，對用戶的網絡功能難以做到無影響。

設計挑戰
很直觀的想法是，我們要做的一定是網絡調試能力，在虛擬轉發網元上嵌入最輕量的探針技術，獲取最關鍵的轉發要素，而帶內染色技術，也是在端到端網絡診斷中比較常用的技術方法，常常用於精準標識感興趣流，利用染色特徵的帶內傳遞，讓虛擬轉發設備的識別動作變得簡單高效，也解決了控制器精準算路的難點，但採集的數據量、多租戶併發的隔離以及探針對轉發的性能損耗等問題，依然對我們提出了很高的要求。

另一方面，由於不想改變數據包長度，又難以預判數據包路徑，那麼就需要採用將分佈式的虛擬轉發網元上採集的數據信息通過匯聚+計算的方式來處理，大數據技術的應用就必不可少了，但是，數據採集的時序問題、以及雲網絡轉發中的多地域和NAT場景，這些都對流量路徑的自動計算有很大的挑戰。

整體架構
基於目標和要求我們設計了VTrace架構如圖所示，整個系統由應用服務，控制器，虛擬轉發設備（VFD），日誌（代理）服務，JStorm流處理引擎及數據庫組成。採用“任務-染色-轉發-採集-分析”的模式來實現能力，由應用服務來生成VTrace任務，控制器給起始轉發節點（VFD1）下發染色規則，起始轉發節點（VFD1）基於流信息與規則進行匹配，對用戶報文進行染色，所有VFD都預定義靜態規則，能夠基於染色標識來採集數據包信息和具體丟包信息，日誌服務藉助日誌代理能力自動同步設備上的採集日誌，而使用Jstorm流處理引擎的目的是抓取VTrace任務和日誌流，最後通過對VTrace任務和日誌流的分析，實現流量路徑的計算、丟包信息的呈現以及時延數據的分析。

設計選型
這套架構如何解決出現的問題和挑戰，是設計選型的關鍵，下面會通過以下四方面進行介紹：

1. 如何解決多網元節點的數據採集和匯聚？
   非常自然的，在採集上我們使用了阿里雲上成熟的日誌服務產品（SLS），無需開發就能快捷完成日誌數據採集、消費等功能，通過其強大的採集能力，將數百萬的VFD（虛擬轉發設備）日誌匯聚到各地域中心，便於後續的分析處理。

由於日誌數據的實時性、分佈式存儲的地域性以及龐大數據量，需要利用大數據技術將所有數據收集以執行流量路徑重建和進一步分析，我們採用了流處理引擎JStorm，JStorm具備千萬級報文數據實時分析能力，其可擴展性和強大的計算能力有助於幫助潛在的大量VTrace任務進行實時的計算分析。
如下圖，利用SLS+JStorm配合來解決採集和匯聚的問題，JStorm流量引擎將各地域的SLS匯聚起來，讓後續的計算無需感知其差異，並且依賴於引擎的強大流計算能力，匯聚後的數據延時很小，為後續的分析和計算打好基礎。

1. 如何解決多租戶併發的隔離以及探針對轉發的性能損耗？
   由於數據包中用於VTrace染色的字段長度受限，難以將任務ID放入染色字段中，那麼必須通過六元組（srcIp+dstIp+srcPort+dstPort+proto+vni）來識別任務信息，VTrace應用來保證任一用戶發起的任務中六元組的唯一性（六元組也是用來染色的流規則），那麼在VFD的採集中，數據包的六元組也是必須要採集出來的關鍵要素，然而由於轉發中可能存在NAT轉換，如果不能識別NAT，將無法識別同個任務的數據，所以要求在匹配採集中將NAT轉換的前後數據分別採集下來，用以同任務判斷。

染色和探針對網絡轉發性能的影響？
首先在我們的設計中，控制器下發規則這個動作只需要起始轉發節點生效，為什麼呢？原因是六元組匹配這個動作本身性能並不高，所以設計了讓起始轉發節點進行報文帶內染色，而其他轉發節點只需支持基於染色標識來進行匹配採集，這個性能損耗就小得多。而針對染色，也做了快慢速分離，類似於數據流的新建連接，針對首包，使用哈希進行規則匹配，匹配成功後在流會話中記錄規則，後續的數據包可直接執行染色動作，直到染色規則失效。而其他虛擬轉發設備是預置規則，沒有動態下發過程，對系統壓力小，而數據採集本身會做一定的限速保護，而持續丟包問題的診斷所需要Trace的包量級也不會很大，在任務中控制好包的數量，那麼整個過程對轉發的性能消耗是非常小的，接著探針覆蓋丟包位置，就可簡單直接地採集到丟包原因。

1. 如何解決分佈式數據採集的時序問題？
   首先設計中有兩種採集器，VTraceTaskSpouts和LogSpouts分別負責實時提取VTrace任務數據庫中的任務流和日誌服務中的日誌流，特別注意由於要實現可追蹤任意雲網絡中的任務數據流，LogSpouts從LogSevice收集的日誌流很可能是散列在不同地域。

Bolt必須要先讀到Task再讀到Log，才能基於任務對Log進行數據過濾，而VTraceTaskSpouts和LogSpouts發送到Bolts數據的時序被是無法保證的，於是，這裡我們在VtraceApp和Jstorm之間引入了一個三次握手過程，具體就是新建VTrace任務時，VtraceApp向任務DB插入狀態為new的一條任務，Jstorm讀到new任務，做初始化操作，並且將new改為JStormReady，告訴VtraceApp我已經準備好了，VtraceApp在收到任務狀態是JStormReady後，像控制器發送下發Vtrace任務的指令，進而“任務-染色-轉發-採集-分析”正式開始了。
當VTraceTaskBolt被任務激活時，就開始收集任務相關的日誌數據，對日誌數據進行預處理（即過濾，轉換，
和分組），然而，不同日誌源的日誌到達Bolt的時間無法保證和轉發的時序性完全一致，由於可能存在NAT轉換，數據時序極可能導致無法匹配而被丟棄，考慮此問題，我們在任務激活後，進行日誌流進行開窗處理，將有一定關聯性但未能匹配任務六元組的數據進行緩存，窗口結束後（一般設定一定的窗口超期時間，若無數據超期則認為窗口結束），根據NAT前後的六元組更新匹配規則，然後再次將緩存的數據需要進入再次匹配，多次處理後，滯後的數據也可以保證不被丟失。
預處理後的數據會根據關鍵信息進行排序、算路、時延分析以及關聯相關物理網元等信息，WriteBolt將結果存儲起來，最後藉助可視化的頁面將結果呈現給用戶，用戶可以一目瞭然的看到問題數據流的流量路徑及丟包詳細信息。

4.如何解決複雜轉發模型下的自動算路？
基於解決了採集的時序問題，算路的核心算法就是：
首節點和尾節點的標識（基於上雲和下雲的邊緣標準，採集的數據中可以給出）、根據同節點數據的時序性以及不同節點的NAT轉換關係來進行算路，這就是一套標準的排序算法了，即使流量經過的設備和設備類型很多，只要虛擬轉發設備安裝了同款採集探針，那麼數據處理部分不需要做任何的開發和調整，按照統一算法就可以實現路徑的自動計算了。

由於探針能採集每個數據包的時間指標，使用路徑中時延計算的標準公式（平均值/最大值/最小值/方差/標準差），結合可視化技術，實現一鍵呈現流量路徑，並分析丟包位置、丟包原因和時延情況。

05、覆蓋場景

1、VPC內的流量訪問，經典場景：企業上雲後，企業生產業務（部署在ECS中）往往需要和雲上其他雲服務如RDS數據庫進行訪問。

2、VPC與公網之間的流量訪問，經典場景：大部分的企業服務都需要被公網訪問，如遊戲服務等。

3、雲上VPC與雲下客戶機房間的訪問，經典場景：很多客戶的部分服務可能有對外聯設備的依賴，會部署在自建機房中，那麼和雲上環境有互通的需要。

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

06、總結

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

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