您好,歡迎來到網暖!
?
當前位置:網暖 » 站長資訊 » 建站基礎 » 網絡技術 » 文章詳細 訂閱RssFeed

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

來源:網絡整理 瀏覽:319次 時間:2020-02-29

虛擬網絡排查問題困難,傳統的 traceroute 等工具很難起到太大作用,大部分情況下都需要到宿主機、混合云網關上抓包來 troubleshooting,耗時又費力。有些場景中包的傳送路徑比較長(如跨域、混合云等),可能丟包的地方比較多,更增加了故障排查的難度。

為此,我們設計了一款支持全鏈路大規模的網絡連通性內部檢測系統 BigBrother。基于 TCP 報文的染色可將檢測報文和用戶流量區分開,能支持物理云和跨地域的復雜場景,還打造了完整的檢測框架,幫助運維同事直接定位故障點,或一鍵判斷虛擬網絡是否存在問題。

BigBrother 上線后即用于云主機遷移前后的連通性驗證,保證出現異常后可以及時告警回滾。從 8 月初至今歷時兩個月,共遷移 2000 多臺主機,及時發現遷移異常近 10 起。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

一、第一代網絡連通性工具的不足

在設計 BigBrother 這前,我們也有第一代的網絡連通性檢查工具,原理就是通過 SSH 跳轉到目標宿主機上,利用 ovs 的 packet out 命令將構造的報文發出去,最后在對端的宿主機上 tcpdump 該報文,從而驗證兩端的連通性。但是從它的原理就不難看出,這種檢測方式有著很大的缺點:

檢測效率低下,無論是 ssh、packet out,還是 tcpdump 都無法支持大規模的快速檢查;
適應的場景有限,對于部分 dpdk、p4 網關類產品,無法通過 tcpdump 進行抓包判斷。
因此做一款支持全鏈路大規模的連通性檢測系統是非常有必要的,我們的目標就是讓運維、NOC 的同學能夠迅速發現并解決網絡不通的問題,同時為我們的虛擬網絡服務變更保駕護航。

二、BigBrother 的實現原理

BigBrother(下文簡稱 BB)一詞源自喬治奧威爾的小說《1984》,將此檢測系統命名為 BigBrother 寓意就是可以將全網資源連通情況都實時監控起來。整個 BB 檢測系統由若干個組件配合完成,mafia 提供 console 進行創建及展示 task 的結果,minitrue 用于將用戶傳入的參數轉化為注包的范圍,telescreen 用于構造報文及收發報文。

1、Entrypoint 和 Endpoint

在具體介紹 BB 的原理前,我們先來看兩個概念。在我們的虛擬網絡中,每個實例(uhost、umem、udb 等)都是通過接入點來接入虛擬網絡,接入點由兩部分組成:

Entrypoint: inbound/outbound 報文都是經由 Entrypoint 進行接受和發送的。
Endpoint:連接實例的端點,Endpoint 為最接近實例的網元。
例如在公有云場景中,entrypoint 和 endpoint 都是 openvswitch,而在物理云場景中,entrypoint 是我們的物理云轉發網關(vpcgw、hybridgw),endpoint 則是物理云主機的上聯 ToR。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

以上就是各種場景中的接入點說明,之所以要明確這兩個概念,是因為在 BB 系統中,我們將 Entrypoint 作為注包點,向其發送 GRE 探測報文,同時將 Endpoint 作為采樣點,Endpoint 會識別并鏡像特殊的探測報文至 BB。

2 、檢測流程

檢測方案如圖所示,可分為兩部分組成,在圖中的流向分為橙色和紫色。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

以橙色流向部分為例(SRC->DST):1)BigBrother 模擬 DST 向 Endpoint 發送探測報文;2)SRC 端 Entrypoint 收到該探測報文后轉發給 Endpoint;3)Endpoint 將該報文鏡像至 BigBrother;4)Endpoint 將報文正常轉發至實例;5)實例回復報文給 Endpoint;6)Endpoint 收到該回復報文后進行 GRE 封裝,然后鏡像至 BigBrother;7)Endpoint 將報文正常轉發至 Entrypoint;8)SRC Entrypoint 將回復報文發送至 DST Entrypoint;9)DST Entrypoint 收到回復報文后發送給 Endpoint;10)DST Endpoint 將回復報文鏡像至 Bigbrother。

至此,單邊的檢測結束。在檢測過程中,BigBrother 發送了 1 個探測報文,共收到了 3 個采樣報文,通過分析這 3 個采樣點可以確認 SRC->DST 方向是否通信正常。

反之亦然,紫色部分原理相同。全部檢測結束后,BigBrother 共可以收到 6 個探測報文,如果 6 個報文均收到則表示連通性正常。

3 、探測報文設計

上文中介紹了 BB 的檢測流程,下面我們再來看下探測報文及轉發面的設計實現。公有云和混合云的設計存在很多不同。公有云轉發面需要在全局 hook 點 (table_1),分別 hook 探測報文的 request 和 response,然后進行染色、鏡像至 BB 等步驟。而混合云轉發面則需要 ToR、PE 交換機開啟 ERSPAN 功能,將染色的報文鏡像至 BB 即可。

整體數據包交互如下圖所示:

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

而一個合格的探測報文首先應該具備以下特征:

染色信息與主機、OS 無關;
ovs2.3、ovs2.6 版本(現網主要版本)可以識別并處理此種染色信息。
因此我們詳細比較了如下兩種候選方案。

1)icmp + tos 方案

第一種方案以 icmp 報文為載體,使用 tos 對 icmp_request 進行染色,采集時將此 tos 的 icmp 報文鏡像至 BB 即可。

cookie=0x20008,table=1,priority=40000,metadata=0x1,icmp,icmp_type=8,icmp_code=0,nw_tos=0x40 actions=Send_BB(),Learn(),Back_0()
對于 hook icmp_request 的 flow 可以簡化為如下邏輯:action 部分主要由三部分組成:

Send_BB () 將報文鏡像給 BB;
Learn () 通過 icmp_request 報文學習到一條用于匹配 icmp_reply 報文的 flow,該條 flow 的主要動作包括:染色、鏡像至 BB;

1. REG3 64200# (global hook) reg3 load:64200->NXM_NX_REG3[], # 2. learn action learn(table=31,idle_timeout=2,hard_timeout=4,priority=30000,dl_type=0x0800,ip_proto=1,icmp_type=0,icmp_code=0,NXM_OF_IP_SRC[]=NXM_OF_IP_DST[],NXM_OF_IP_DST[ ]=NXM_OF_IP_SRC[],Stain(),Send_BB()),# 3. REG3 0load:0->NXM_NX_REG3[]

Back_0 () 將該報文送回 table_0,進行常規的轉發操作。
對于 hook icmp_reply 的 flow 可以簡化為如下邏輯:

cookie=0x20008,table=1,priority=40000,metadata=0x1,icmp,icmp_type=0,icmp_code=0,nw_tos=0x40
action 部分主要由四部分組成:?Save (in_port, tun_src) 將報文中的 in_port 和 tun_src 保存下來;?Resubmit (table=31) 跳轉至 table31,匹配 icmp_request learn 生成的 flow;?Restore (in_port, tun_src) 恢復 in_port 和 tun_src;?Back_0 () 將該報文送回 table_0,進行常規的轉發操作。 以上討論的是公有云側 ovs 的染色及鏡像方法,而混合云側就需要交換機 ERSPAN 來進行支持,為了使 ERSPAN 規則可以鏡像 tos 染色報文,需要 GRE 外層 Ip Header 中的 tos 繼承 overlay Ip Header 中標記的 tos,所以需要全網對 GRE 隧道設置繼承內層 tos 的隧道屬性,執行命令如下:

ovs-vsctl set in <gre_iface_name> options:tos=inherit
此種方案雖然可以實現染色及鏡像的功能,但是 hook 點預埋的 flow 過于復雜,不容易維護,最關鍵的一點在于,混合云網絡中,該方案無法支持 learn flow,所以無法對反向的流量進行染色。

2)tcp 方案

第二種方案以 tcp 報文為載體,使用特定的端口作為染色條件,采集時將此源目端口的 tcp 報文鏡像至 BB 即可。

cookie=0x20008,table=1,priority=40000,tcp,metadata=0x1,tp_src=[port],tp_dst=[port] actions=Send_BB(),Back_0()
對于 hook tcp_request 的 flow 可以簡化為如下邏輯:

action 部分主要由兩部分組成:?Send_BB () 將報文鏡像給 BB;?Back_0 () 將該報文送回 table_0,進行常規的轉發操作。

以上兩種方案進行對比不難看出,第一種方案依賴較多并且適用場景受限,所以 BB 采用的是第二種方案。但是 tcp 方案也有一定的缺陷,如何選擇染色的 port 并且要與用戶的流量區分開來,這是一個難點。經過我們幾次踩坑后分析,最后決定使用 tcp 源目 port=11 來進行染色(目前已告知用戶會使用 TCP 端口 11 進行掃描,詳見 https://docs.ucloud.cn/network/unet/faq

),報文如下圖所示。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

4、各場景下探測報文的生命周期

BB 被設計為支持多種網絡場景,能應對物理云和跨域互通的網絡復雜性。這章節我們以探測物理云和跨域為例,詳細分析下 BB 探測報文的生命周期。

物理云

公有云互通物理云場景下,探測報文生命周期如下:

公有云 —> 物理云

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

1)BigBrother 向公有云宿主機發送探測報文

2)ovs 收到報文后鏡像至 BigBrother3)ovs 將報文送至實例 4)實例回應報文 5)ovs 將回應報文鏡像至 BigBrother6)物理云核心交換機收到報文,并發送給匯聚交換機 7)8)9)10)物理云匯聚交換機發送報文給 vpcgw,vpcgw 處理報文后回送至匯聚交換機 11)在物理云匯聚交換機配置 ERSPAN,將報文鏡像至 BigBrother。

物理云 —> 公有云

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

1)BigBrother 向 vpcgw 發送探測報文

2)3)vpcgw 處理報文后回送至匯聚交換機 4)在物理云匯聚交換機配置 ERSPAN,將報文鏡像至 BigBrother5)匯聚交換機將報文送至 phost 的上聯 Tor6)Tor 將報文送至 phost7)phost 回應報文 8)在 phost 的上聯 Tor 配置 ERSPAN,將報文鏡像至 BigBrother9)報文送至公有云宿主機 ovs10)ovs 收到報文后鏡像至 BigBrother

跨域網關

公有云跨域互通場景下,探測報文生命周期如下:

本地域 —> 地域 B

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

1)BigBrother 向本域主機發送探測報文

2)ovs 收到報文后鏡像至 BigBrother3)ovs 將報文送至實例 4)實例回應報文 5)ovs 將回應報文鏡像至 BigBrother6)ovs 將報文送至 sdngw7)sdngw 將報文鏡像至 BigBrother

地域 B—> 本地域

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

1)BigBrother 向本域 sdngw 發送探測報文

2)sdngw 收到報文后鏡像至 BigBrother3)sdngw 將報文送至對端 sdngw 進行轉發 4)本域 sdngw 收到對端回應報文 5)sdngw 將回應報文鏡像至 BigBrother6)sdngw 將報文送至本地域宿主機 7)ovs 將報文鏡像至 BigBrother

三、Bigbrother 服務框架

整個 BB 檢測系統由若干個組件配合完成,minitrue 用于將用戶傳入的參數轉化為注包的范圍,telescreen 用于構造報文及收發報文。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

1、服務框架圖

API: FE 服務對外提供的 HTTP 接口,用于創建任務和查詢任務進度;

Logic:業務處理層,?于分析?參并將其轉換為若干源?主機對放入 Disruptor 中;Disruptor:此組件為開源高性能隊列;Sender:將 Disruptor 中 pop 的數據組裝成 GRE packet,并發送給 EntryPoint;Receiver:接收從 EndPoint 上報的 GRE packet;Analysis:將接收的報?存入內存中,同時對報文進?分析。

2、Task 的執行及結果分析

1)task

上文中我們詳細介紹了 BB 探測報文的設計和生命周期,但是我們還有一個問題需要解決:提高 BB 的并發能力。按照上文的介紹,每次 BB 只能執行一次探測,順序執行才能保證檢測結果的準確性,所以我們設計利用 TCP 報頭中的序列號來提高并發。

以下是一個 TCP 報文的首部結構:

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

其中 32 位的 Seq 序列號就是我們要利用的,在 BB 探測過程中每個 Seq 序列號都唯?標識?個 pair 對,然后我們將 Seq 序列號分成了兩部分:

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

Task_id:?于標識一個 Task,由于僅有 5 位,所以每次同時進?的 Task 不能超過 32 個 ;
Pair_id:用于標識在一個 Task 內,待檢測的一個 pair 對。
因此,我們可以將 BB 并發的任務數提高到了 32 個,而每個任務支持最大的檢測 pair 對數可以達到 2 的 27 次方,相當于每個任務都可以支持一個容量為 10000 臺云主機的 VPC 進行 Full Mesh 檢測,足以覆蓋現有用戶的網絡規模。

2)task 的執行

當運維同學在 mafia(任務控制臺)上點擊創建一個 BB task 進行連通性檢查時,會經歷以下幾個過程:

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

?請求發送給 minitrue 服務,根據輸入的參數來確定探測范圍;?minitrue 將計算得到的探測范圍以源、目節點列表的形式發送給 telescreen 服務;?telescreen 構建 Gre 報文,并放入高性能隊列中進行發包;同時,telescreen 會監聽網卡獲取鏡像報文回來的報文并存入內存;?minitrue 的分析程序定時獲取 telescreen 的收包結果并進行分析;?最后運維同學可以在 mafia 上看到最終的探測結果。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

3)task 的結果分析

task 執行結束后,運維同學可以在 mafia 查看到最后的檢測報告,包括發送的總 pair 數、收到的 pair 數、成功以及失敗的數量。同時,檢測失敗的源目詳細信息也會展示出來,最終以 bitmap 的方式呈現出來,0 表示沒有收到報文,1 表示收到報文。

我們以下圖的結果為例,解釋其含義。圖中是檢測 ip pair (10.9.88.160<—>10.8.17.169) 的雙向連通性。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

我們再回顧下第二章中 BigBrother 檢測的流程圖,首先 BigBrother 會模擬 10.9.88.160 向 10.8.17.169 的宿主機上發送探測報文,報文的內容為 <flag=SYN, nw_src=10.9.88.160, nw_dst=10.8.17.169>。如果 10.8.17.169 —>10.9.88.160 單向連通性正常的話,BigBrother 最終會收到 3 個報文:

(1)<flag=SYN, nw_src=10.9.88.160,

nw_dst=10.8.17.169>

(2)<flag=ACK, nw_src=10.8.17.169,

nw_dst=10.9.88.160>

(3)<flag=ACK, nw_src=10.8.17.169,

nw_dst=10.9.88.160>

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

上圖 bitmap 后三位的結果為 111,表示這 3 個報文都收到了,即 10.8.17.169 —>10.9.88.160 單向的連通性正常。

反之亦然,前三位則表示 10.9.88.160 —> 10.8.17.169 單向的連通性情況,結果為 100,(2)(3) 報文沒有收到,即表示 10.9.88.160 —> 10.8.17.169 單向的連通性異常,虛機 10.9.88.160 沒有回復報文,可以斷定虛機內部異常或虛機內部存在 iptables 規則將探測報文過濾。

3 、基于活躍 flow 的連通性檢查

上文我們提到,運維同學可以在 mafia 上創建 BB task 來進行連通性的檢查,通過傳入 mac、子網 id、VPC id 來確定檢測的范圍,進而進行全量驗證。但是大多數場景中,我們不需要進行全互聯檢查,這樣不僅浪費時間而且還會對控制面造成一定的壓力。我們僅需要針對指定范圍內的活躍 flow 驗證連通性即可,所以我們又引入了活躍 flow 檢測的服務 ——river。river 是虛擬網絡億級別活躍流的分析系統,借助這個系統 BB 可以拿到用戶的活躍通信源目,類似于緩存里的熱點數據,這樣可以讓 BB 快速精準驗證變更。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

與上文全量 BB 探測的區別在于,minitrue 無須自己計算源、目節點列表,只需指定范圍后向 river 獲取活躍列表,然后通過常規的檢測流程將列表傳送給 telescreen 進行發包即可。

四、投入使用和未來計劃

BigBrother 上線后就參與到了資源整合項目中,用于云主機遷移前后的連通性驗證,保證出現異常后可以及時告警回滾。從 8 月初至今歷時兩個月,共遷移 2000 多臺主機,及時發現遷移異常近 10 起。

同時,我們對 BigBrother 后續版本也有著一定的規劃,例如:

除了對連通性的檢測外,還需要有平均時延,最大時延對、丟包率的檢測;
打算基于 BigBrother 構建針對指定用戶的內網全天候監控。

BigBrother:UCloud 全鏈路大規模網絡連通性檢測系統詳解

推薦站點

  • 騰訊騰訊

    騰訊網(www.QQ.com)是中國瀏覽量最大的中文門戶網站,是騰訊公司推出的集新聞信息、互動社區、娛樂產品和基礎服務為一體的大型綜合門戶網站。騰訊網服務于全球華人用戶,致力成為最具傳播力和互動性,權威、主流、時尚的互聯網媒體平臺。通過強大的實時新聞和全面深入的信息資訊服務,為中國數以億計的互聯網用戶提供富有創意的網上新生活。

    www.qq.com
  • 搜狐搜狐

    搜狐網是全球最大的中文門戶網站,為用戶提供24小時不間斷的最新資訊,及搜索、郵件等網絡服務。內容包括全球熱點事件、突發新聞、時事評論、熱播影視劇、體育賽事、行業動態、生活服務信息,以及論壇、博客、微博、我的搜狐等互動空間。

    www.sohu.com
  • 網易網易

    網易是中國領先的互聯網技術公司,為用戶提供免費郵箱、游戲、搜索引擎服務,開設新聞、娛樂、體育等30多個內容頻道,及博客、視頻、論壇等互動交流,網聚人的力量。

    www.163.com
  • 新浪新浪

    新浪網為全球用戶24小時提供全面及時的中文資訊,內容覆蓋國內外突發新聞事件、體壇賽事、娛樂時尚、產業資訊、實用信息等,設有新聞、體育、娛樂、財經、科技、房產、汽車等30多個內容頻道,同時開設博客、視頻、論壇等自由互動交流空間。

    www.sina.com.cn
  • 百度一下百度一下

    百度一下,你就知道

    www.baidu.com
?
陕西11选5走势图前3直