說明：以下介紹的所有技術都已論文投稿前申請了專利保護
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需要能夠支援不同使用者的并發使用。
現有技術
- 主動探測技術，如pingmesh，比較普通地适用于網絡監控場景，但很難滿足基于使用者資料報丢失現象進行分析的要求，也很可能因為和使用者資料包的差異性難以還原丢包路徑，是以VTrace無法使用；
- 被動式網絡監控技術，如VeriFlow，雖無需注入任何探針，但無法避免對使用者有依賴性，無法滿足對使用者無感覺的要求；
- 網絡調試技術，如SDN Traceroute、NetAlytics等，目前對一些雲網絡架構并不适用，也無法做到直覺地給出丢包原因，而一些旁路分析架構，如新提出的INT技術（In-band Network Telemetry），雖可以實作目标，但對網絡裝置的要求高，同時由于旁路導緻的帶寬消耗，對使用者的網絡功能難以做到無影響。
設計挑戰
很直覺的想法是，我們要做的一定是網絡調試能力，在虛拟轉發網元上嵌入最輕量的探針技術，擷取最關鍵的轉發要素，而帶内染色技術，也是在端到端網絡診斷中比較常用的技術方法，常常用于精準辨別感興趣流，利用染色特征的帶内傳遞，讓虛拟轉發裝置的識别動作變得簡單高效，也解決了控制器精準算路的難點，但采集的資料量、多租戶并發的隔離以及探針對轉發的性能損耗等問題，依然對我們提出了很高的要求。
另一方面，由于不想改變資料包長度，又難以預判資料包路徑，那麼就需要采用将分布式的虛拟轉發網元上采集的資料資訊通過彙聚+計算的方式來處理，大資料技術的應用就必不可少了，但是，資料采集的時序問題、以及雲網絡轉發中的多地域和NAT場景，這些都對流量路徑的自動計算有很大的挑戰。
整體架構
基于目标和要求我們設計了VTrace架構如圖所示，整個系統由應用服務，控制器，虛拟轉發裝置（VFD），日志（代理）服務，JStorm流處理引擎及資料庫組成。采用“任務-染色-轉發-采集-分析”的模式來實作能力，由應用服務來生成VTrace任務，控制器給起始轉發節點（VFD1）下發染色規則，起始轉發節點（VFD1）基于流資訊與規則進行比對，對使用者封包進行染色，所有VFD都預定義靜态規則，能夠基于染色辨別來采集資料包資訊和具體丢包資訊，日志服務借助日志代理能力自動同步裝置上的采集日志，而使用Jstorm流處理引擎的目的是抓取VTrace任務和日志流，最後通過對VTrace任務和日志流的分析，實作流量路徑的計算、丢包資訊的呈現以及時延資料的分析。
設計選型
這套架構如何解決出現的問題和挑戰，是設計選型的關鍵，下面會通過以下四方面進行介紹：
-
如何解決多網元節點的資料采集和彙聚？
非常自然的，在采集上我們使用了阿裡雲上成熟的日志服務産品（SLS），無需開發就能快捷完成日志資料采集、消費等功能，通過其強大的采集能力，将數百萬的VFD（虛拟轉發裝置）日志彙聚到各地域中心，便于後續的分析處理。
由于日志資料的實時性、分布式存儲的地域性以及龐大資料量，需要利用大資料技術将所有資料收集以執行流量路徑重建和進一步分析，我們采用了流處理引擎JStorm，JStorm具備千萬級封包資料實時分析能力，其可擴充性和強大的計算能力有助于幫助潛在的大量VTrace任務進行實時的計算分析。
如下圖，利用SLS+JStorm配合來解決采集和彙聚的問題，JStorm流量引擎将各地域的SLS彙聚起來，讓後續的計算無需感覺其差異，并且依賴于引擎的強大流計算能力，彙聚後的資料延時很小，為後續的分析和計算打好基礎。
-
如何解決多租戶并發的隔離以及探針對轉發的性能損耗？
由于資料包中用于VTrace染色的字段長度受限，難以将任務ID放入染色字段中，那麼必須通過六元組（srcIp+dstIp+srcPort+dstPort+proto+vni）來識别任務資訊，VTrace應用來保證任一使用者發起的任務中六元組的唯一性（六元組也是用來染色的流規則），那麼在VFD的采集中，資料包的六元組也是必須要采集出來的關鍵要素，然而由于轉發中可能存在NAT轉換，如果不能識别NAT，将無法識别同個任務的資料，是以要求在比對采集中将NAT轉換的前後資料分别采集下來，用以同任務判斷。
染色和探針對網絡轉發性能的影響？
首先在我們的設計中，控制器下發規則這個動作隻需要起始轉發節點生效，為什麼呢？原因是六元組比對這個動作本身性能并不高，是以設計了讓起始轉發節點進行封包帶内染色，而其他轉發節點隻需支援基于染色辨別來進行比對采集，這個性能損耗就小得多。而針對染色，也做了快慢速分離，類似于資料流的建立連接配接，針對首包，使用哈希進行規則比對，比對成功後在流會話中記錄規則，後續的資料包可直接執行染色動作，直到染色規則失效。而其他虛拟轉發裝置是預置規則，沒有動态下發過程，對系統壓力小，而資料采集本身會做一定的限速保護，而持續丢包問題的診斷所需要Trace的包量級也不會很大，在任務中控制好包的數量，那麼整個過程對轉發的性能消耗是非常小的，接着探針覆寫丢包位置，就可簡單直接地采集到丢包原因。
-
如何解決分布式資料采集的時序問題？
首先設計中有兩種采集器，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帶來的極速網絡排障能力。