揭秘阿里云網(wǎng)絡(luò)洛神 VTrace 系統(tǒng)

阿里妹導(dǎo)讀：VTrace是一個解決云網(wǎng)絡(luò)持續(xù)性丟包問題的自動化診斷系統(tǒng)，核心思想是“任務(wù)-匹配-染色-采集-分析”，結(jié)合大數(shù)據(jù)技術(shù)，旨在實時快速的自動分析出云網(wǎng)絡(luò)端到端的流量拓?fù)渎窂?，并給出準(zhǔn)確的問題原因和解決方案，讓網(wǎng)絡(luò)運(yùn)維不再需要那么“專業(yè)”，那么“復(fù)雜”。

一 概述

近日，SIGCOMM 2020公布了今年的入選論文，阿里云網(wǎng)絡(luò)洛神的“VTrace:Automatic Diagnostic System for Persistent Packet Loss in Cloud-Scale Overlay Network”是國內(nèi)歷年來唯一一篇云網(wǎng)絡(luò)方向的入選論文，今年SIGCOMM總計收到了250篇投稿，成功入選的僅54篇，阿里云網(wǎng)絡(luò)洛神平臺的技術(shù)實力得到了網(wǎng)絡(luò)業(yè)界頂級會議的認(rèn)可。

為了方便大家更通俗地理解這篇論文，本文將從技術(shù)層面解讀云網(wǎng)絡(luò)面臨的問題，以及介紹VTrace系統(tǒng)的整體技術(shù)架構(gòu)。

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

二 背景

如果把每天在用的手機(jī)App當(dāng)成現(xiàn)實生活里的商場，電影院，餐館的話，云網(wǎng)絡(luò)就是把這些商場，電影院和餐館連接在一起的高速公路。在現(xiàn)實社會里，如果駕車去電影院時發(fā)現(xiàn)路堵了，可能會導(dǎo)致錯過期待已久的電影。同樣的，在云網(wǎng)絡(luò)的世界里，當(dāng)某個設(shè)備發(fā)生擁塞或者事故了，會導(dǎo)致各種APP應(yīng)用出現(xiàn)異常、卡頓，視頻打不開等。

而隨著云網(wǎng)絡(luò)拓?fù)淙找鎻?fù)雜，承載的網(wǎng)絡(luò)業(yè)務(wù)不斷增多，虛擬網(wǎng)絡(luò)承載著用戶多種多樣的業(yè)務(wù)功能，如NAT、帶寬等，往往要求頻繁更新以滿足用戶業(yè)務(wù)變化。承載著基礎(chǔ)轉(zhuǎn)發(fā)能力的物理網(wǎng)絡(luò)在轉(zhuǎn)發(fā)策略中任何一個小小的問題都可能導(dǎo)致用戶在云網(wǎng)絡(luò)中的數(shù)據(jù)包丟失。而傳統(tǒng)工具如traceroute等無法在云網(wǎng)絡(luò)使用，而人為抓包的方式對運(yùn)維工程師的專業(yè)技能和經(jīng)驗要求較高，排查過程也比較繁瑣耗時，往往最終也只能界定丟包位置而難以得到丟包原因。

面對這樣的問題，云網(wǎng)絡(luò)需要一個”交通警察“，每當(dāng)網(wǎng)絡(luò)中間有擁塞或者事故了它需要能夠及時發(fā)現(xiàn)具體位置，然后及時處理，來讓整個網(wǎng)絡(luò)恢復(fù)正常。一旦出現(xiàn)卡頓、丟包等問題，云網(wǎng)絡(luò)的交警需要能在幾秒鐘內(nèi)從這張遍布全球數(shù)百萬的設(shè)備里找到原因，是非常大的挑戰(zhàn)。

所以，不管是對用戶而言，還是對云網(wǎng)絡(luò)供應(yīng)商來說，都急需一個可以在高負(fù)載、復(fù)雜拓?fù)涞脑凭W(wǎng)絡(luò)下能實現(xiàn)快速響應(yīng)的、可控的、自動化的丟包問題排查工具，而VTrace就是阿里云網(wǎng)絡(luò)產(chǎn)品設(shè)計并推出的一款解決云網(wǎng)絡(luò)持續(xù)性丟包問題的自動化診斷系統(tǒng)，就是我們所說的那個有著超級大腦的超級交警。

三 面臨的挑戰(zhàn)

動態(tài)變化的網(wǎng)絡(luò)數(shù)據(jù)流

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

無處不在的潛在網(wǎng)絡(luò)丟包點

在數(shù)據(jù)的傳輸過程中，一旦在某個地方發(fā)生擁塞，或者某個地方紅燈了，就停下來無法前進(jìn)。這個現(xiàn)象在網(wǎng)絡(luò)里隨處可見，對于只有幾十個路口的小城鎮(zhèn)，找到堵塞的路口可能不需要太久，但是對于云網(wǎng)絡(luò)，這樣的路口可能有上萬個，想要快速找到擁塞的路口就非常困難了。

最小化性能影響

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

四 設(shè)計與技術(shù)

目標(biāo)與要求

基于面臨的挑戰(zhàn)，我們希望實現(xiàn)以下兩個目標(biāo)：

· 低損耗數(shù)據(jù)包信息、流量路徑和傳輸質(zhì)量分析：在不影響用戶業(yè)務(wù)的情況下，分析數(shù)據(jù)包信息，流量路徑以及傳輸質(zhì)量，并精準(zhǔn)探測網(wǎng)絡(luò)傳輸?shù)臅r延抖動。

· 精準(zhǔn)分析丟包原因定位：當(dāng)丟包發(fā)生，VTrace系統(tǒng)需要快速找到有問題的虛擬網(wǎng)元或物理網(wǎng)元，并提出根本原因及修復(fù)丟包的可能。

考慮到云網(wǎng)絡(luò)環(huán)境，對VTrace系統(tǒng)有以下幾個要求：

· VTrace能夠基于數(shù)據(jù)包丟失的用戶現(xiàn)場進(jìn)行分析。

· VTrace的部署和使用不會影響正常的網(wǎng)絡(luò)功能，對用戶無感知。

· 由于存在數(shù)百萬云用戶，VTrace需要能夠支持不同用戶的并發(fā)使用。

技術(shù)挑戰(zhàn)

· 主動探測技術(shù)如pingmesh，適用于網(wǎng)絡(luò)監(jiān)控場景，但很難滿足基于用戶數(shù)據(jù)丟失現(xiàn)象進(jìn)行分析的要求，也很可能因為和用戶數(shù)據(jù)包的差異性難以還原丟包路徑。

· 被動式網(wǎng)絡(luò)監(jiān)控技術(shù)如VeriFlow，對用戶有依賴性，無法滿足對用戶無感知的要求。

· 網(wǎng)絡(luò)調(diào)試技術(shù)如SDN Traceroute、NetAlytics等，目前不適用一些云網(wǎng)絡(luò)架構(gòu)，也無法做到直觀地給出丟包原因。而一些旁路分析架構(gòu)，如新提出的INT技術(shù)（In-band Network Telemetry），雖可以實現(xiàn)目標(biāo)，但對網(wǎng)絡(luò)設(shè)備的要求高，同時由于旁路導(dǎo)致的帶寬消耗，會影響對用戶的網(wǎng)絡(luò)功能。

設(shè)計思路

1 如何解決多網(wǎng)元節(jié)點的數(shù)據(jù)采集和匯聚？

在采集上我們使用了阿里云上成熟的日志服務(wù)產(chǎn)品（SLS），無需開發(fā)就能快捷完成日志數(shù)據(jù)采集、消費(fèi)等功能，通過其強(qiáng)大的采集能力，將數(shù)百萬的VFD（虛擬轉(zhuǎn)發(fā)設(shè)備）日志匯聚到各地域中心，便于后續(xù)的分析處理。

由于日志數(shù)據(jù)的實時性、分布式存儲的地域性以及龐大數(shù)據(jù)量，需要利用大數(shù)據(jù)技術(shù)將所有數(shù)據(jù)收集以執(zhí)行流量路徑重建和進(jìn)一步分析，我們采用了流處理引擎JStorm，JStorm具備千萬級報文數(shù)據(jù)實時分析能力，其可擴(kuò)展性和強(qiáng)大的計算能力有助于幫助潛在的大量VTrace任務(wù)進(jìn)行實時的計算分析。

2 如何解決多租戶并發(fā)的隔離以及探針對轉(zhuǎn)發(fā)的性能損耗？

為了降低性能損耗，我們設(shè)計讓控制器下發(fā)規(guī)則時，只需要起始轉(zhuǎn)發(fā)節(jié)點生效，進(jìn)行報文帶內(nèi)染色，而其他轉(zhuǎn)發(fā)節(jié)點只需支持基于染色的匹配采集，另外也做了染色的快慢速分離和首包的規(guī)則匹配。針對虛擬轉(zhuǎn)發(fā)設(shè)備則是預(yù)置規(guī)則，沒有動態(tài)下發(fā)過程，對系統(tǒng)壓力小。而在數(shù)據(jù)采集過程中，做一定的限速保護(hù)，并在任務(wù)中控制好包的數(shù)量，整體過程對轉(zhuǎn)發(fā)的性能消耗降到最低，接著探針覆蓋丟包位置，就可簡單直接地采集到丟包原因。

3 如何解決分布式數(shù)據(jù)采集的時序問題？

在采集數(shù)據(jù)時，常會遇到日志流散列在不同地域，時序也無法保證的問題。因此我們在VTraceApp和Jstorm之間設(shè)計了一個三次握手過程，建立了“任務(wù)-染色-轉(zhuǎn)發(fā)-采集-分析”的體系，確保大量分布式數(shù)據(jù)采集的正確性和時效性：

新建VTrace任務(wù)時，VTraceApp向任務(wù)DB插入狀態(tài)為new的一條任務(wù)。

Jstorm讀到new任務(wù)，將new改為JStormReady。

VTraceApp收到JStormReady后，向控制器發(fā)送下發(fā)VTrace任務(wù)的指令。

4 如何解決復(fù)雜轉(zhuǎn)發(fā)模型下的自動算路？

首先，我們基于上云和下云的邊緣標(biāo)準(zhǔn)設(shè)計出一套標(biāo)準(zhǔn)的排序算法，包含首尾節(jié)點標(biāo)識、根據(jù)同節(jié)點數(shù)據(jù)的時序性以及不同節(jié)點的NAT轉(zhuǎn)換關(guān)系。這樣即使流量經(jīng)過的設(shè)備和設(shè)備類型很多，只要虛擬轉(zhuǎn)發(fā)設(shè)備安裝了同款采集探針，不需做任何數(shù)據(jù)開發(fā)和調(diào)整，按照統(tǒng)一算法就可以實現(xiàn)路徑的自動計算了。再利用安裝的探針來采集每個數(shù)據(jù)包的時間指標(biāo)，使用路徑中時延計算的標(biāo)準(zhǔn)公式，結(jié)合可視化技術(shù)，實現(xiàn)一鍵呈現(xiàn)流量路徑，快速分析丟包位置、丟包原因和時延情況。

五 覆蓋場景

1 VPC內(nèi)的流量訪問

經(jīng)典場景：企業(yè)上云后，企業(yè)生產(chǎn)業(yè)務(wù)（部署在ECS中）往往需要和云上其他云服務(wù)如RDS數(shù)據(jù)庫進(jìn)行訪問。

2 VPC與公網(wǎng)之間的流量訪問

經(jīng)典場景：大部分的企業(yè)服務(wù)都需要被公網(wǎng)訪問，如游戲服務(wù)等。

3 云上VPC與云下客戶機(jī)房間的訪問

經(jīng)典場景：很多客戶的部分服務(wù)可能有對外聯(lián)設(shè)備的依賴，會部署在自建機(jī)房中，那么和云上環(huán)境有互通的需要。

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

經(jīng)典場景：大企業(yè)級組網(wǎng)，一般有多地域部署的需要，也會考慮生產(chǎn)環(huán)境/日常環(huán)境/運(yùn)維管理區(qū)的隔離性，會把不同的環(huán)境部署在不同的VPC上，不同VPC之間互相訪問的需要也是比較常見的。

六 總結(jié)

目前VTrace系統(tǒng)已經(jīng)在阿里云網(wǎng)絡(luò)內(nèi)部大規(guī)模普及，效果顯著，大大減少了診斷時間，從人為處理的平均幾小時下降到分鐘級的耗時，現(xiàn)在它已經(jīng)成為云網(wǎng)絡(luò)故障排查必不可少的工具，未來將會逐步開放給阿里云用戶，讓阿里云用戶也能體驗到VTrace帶來的極速網(wǎng)絡(luò)排障能力。