BigBrother：UCloud 全链路大规模网络连通性检测系统详解
虛擬網絡排查問題困難，傳統(tǒng)的 traceroute 等工具很難起到太大作用，大部分情況下都需要到宿主機、混合云網關上抓包來 troubleshooting，耗時又費力。有些場景中包的傳送路徑比較長（如跨域、混合云等），可能丟包的地方比較多，更增加了故障排查的難度。
為此，我們設計了一款支持全鏈路大規(guī)模的網絡連通性內部檢測系統(tǒng) BigBrother。基于 TCP 報文的染色可將檢測報文和用戶流量區(qū)分開，能支持物理云和跨地域的復雜場景，還打造了完整的檢測框架，幫助運維同事直接定位故障點，或一鍵判斷虛擬網絡是否存在問題。
BigBrother 上線后即用于云主機遷移前后的連通性驗證，保證出現(xiàn)異常后可以及時告警回滾。從 8 月初至今歷時兩個月，共遷移 2000 多臺主機，及時發(fā)現(xiàn)遷移異常近 10 起。
一、第一代網絡連通性工具的不足
在設計 BigBrother 這前，我們也有第一代的網絡連通性檢查工具，原理就是通過 SSH 跳轉到目標宿主機上，利用 ovs 的 packet out 命令將構造的報文發(fā)出去，最后在對端的宿主機上 tcpdump 該報文，從而驗證兩端的連通性。但是從它的原理就不難看出，這種檢測方式有著很大的缺點：
- 檢測效率低下，無論是 ssh、packet out，還是 tcpdump 都無法支持大規(guī)模的快速檢查；
- 適應的場景有限，對于部分 dpdk、p4 網關類產品，無法通過 tcpdump 進行抓包判斷。
因此做一款支持全鏈路大規(guī)模的連通性檢測系統(tǒng)是非常有必要的，我們的目標就是讓運維、NOC 的同學能夠迅速發(fā)現(xiàn)并解決網絡不通的問題，同時為我們的虛擬網絡服務變更保駕護航。
二、BigBrother 的實現(xiàn)原理
BigBrother（下文簡稱 BB）一詞源自喬治奧威爾的小說《1984》，將此檢測系統(tǒng)命名為 BigBrother 寓意就是可以將全網資源連通情況都實時監(jiān)控起來。整個 BB 檢測系統(tǒng)由若干個組件配合完成，mafia 提供 console 進行創(chuàng)建及展示 task 的結果，minitrue 用于將用戶傳入的參數(shù)轉化為注包的范圍，telescreen 用于構造報文及收發(fā)報文。
1、Entrypoint 和 Endpoint
在具體介紹 BB 的原理前，我們先來看兩個概念。在我們的虛擬網絡中，每個實例（uhost、umem、udb 等）都是通過接入點來接入虛擬網絡，接入點由兩部分組成：
- Entrypoint： inbound/outbound 報文都是經由 Entrypoint 進行接受和發(fā)送的。
- Endpoint：連接實例的端點，Endpoint 為最接近實例的網元。
例如在公有云場景中，entrypoint 和 endpoint 都是 openvswitch，而在物理云場景中，entrypoint 是我們的物理云轉發(fā)網關（vpcgw、hybridgw），endpoint 則是物理云主機的上聯(lián) ToR。
以上就是各種場景中的接入點說明，之所以要明確這兩個概念，是因為在 BB 系統(tǒng)中，我們將 Entrypoint 作為注包點，向其發(fā)送 GRE 探測報文，同時將 Endpoint 作為采樣點，Endpoint 會識別并鏡像特殊的探測報文至 BB。
2 、檢測流程
檢測方案如圖所示，可分為兩部分組成，在圖中的流向分為橙色和紫色。
以橙色流向部分為例（SRC->DST）：1）BigBrother 模擬 DST 向 Endpoint 發(fā)送探測報文；2）SRC 端 Entrypoint 收到該探測報文后轉發(fā)給 Endpoint；3）Endpoint 將該報文鏡像至 BigBrother；4）Endpoint 將報文正常轉發(fā)至實例；5）實例回復報文給 Endpoint；6）Endpoint 收到該回復報文后進行 GRE 封裝，然后鏡像至 BigBrother；7）Endpoint 將報文正常轉發(fā)至 Entrypoint；8）SRC Entrypoint 將回復報文發(fā)送至 DST Entrypoint；9）DST Entrypoint 收到回復報文后發(fā)送給 Endpoint；10）DST Endpoint 將回復報文鏡像至 Bigbrother。
至此，單邊的檢測結束。在檢測過程中，BigBrother 發(fā)送了 1 個探測報文，共收到了 3 個采樣報文，通過分析這 3 個采樣點可以確認 SRC->DST 方向是否通信正常。
反之亦然，紫色部分原理相同。全部檢測結束后，BigBrother 共可以收到 6 個探測報文，如果 6 個報文均收到則表示連通性正常。
3 、探測報文設計
上文中介紹了 BB 的檢測流程，下面我們再來看下探測報文及轉發(fā)面的設計實現(xiàn)。公有云和混合云的設計存在很多不同。公有云轉發(fā)面需要在全局 hook 點 (table_1)，分別 hook 探測報文的 request 和 response，然后進行染色、鏡像至 BB 等步驟。而混合云轉發(fā)面則需要 ToR、PE 交換機開啟 ERSPAN 功能，將染色的報文鏡像至 BB 即可。
整體數(shù)據(jù)包交互如下圖所示：
而一個合格的探測報文首先應該具備以下特征：
- 染色信息與主機、OS 無關；
- ovs2.3、ovs2.6 版本（現(xiàn)網主要版本）可以識別并處理此種染色信息。
因此我們詳細比較了如下兩種候選方案。
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；
- Back_0 () 將該報文送回 table_0，進行常規(guī)的轉發(fā)操作。
對于 hook icmp_reply 的 flow 可以簡化為如下邏輯：
cookie=0x20008,table=1,priority=40000,metadata=0x1,icmp,icmp_type=0,icmp_code=0,nw_tos=0x40action 部分主要由四部分組成：?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，進行常規(guī)的轉發(fā)操作。 以上討論的是公有云側 ovs 的染色及鏡像方法，而混合云側就需要交換機 ERSPAN 來進行支持，為了使 ERSPAN 規(guī)則可以鏡像 tos 染色報文，需要 GRE 外層 Ip Header 中的 tos 繼承 overlay Ip Header 中標記的 tos，所以需要全網對 GRE 隧道設置繼承內層 tos 的隧道屬性，執(zhí)行命令如下：
ovs-vsctl set in <gre_iface_name> options:tos=inherit此種方案雖然可以實現(xiàn)染色及鏡像的功能，但是 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，進行常規(guī)的轉發(fā)操作。
以上兩種方案進行對比不難看出，第一種方案依賴較多并且適用場景受限，所以 BB 采用的是第二種方案。但是 tcp 方案也有一定的缺陷，如何選擇染色的 port 并且要與用戶的流量區(qū)分開來，這是一個難點。經過我們幾次踩坑后分析，最后決定使用 tcp 源目 port=11 來進行染色（目前已告知用戶會使用 TCP 端口 11 進行掃描，詳見 https://docs.ucloud.cn/network/unet/faq
），報文如下圖所示。
4、各場景下探測報文的生命周期
BB 被設計為支持多種網絡場景，能應對物理云和跨域互通的網絡復雜性。這章節(jié)我們以探測物理云和跨域為例，詳細分析下 BB 探測報文的生命周期。
- 物理云
公有云互通物理云場景下，探測報文生命周期如下：
公有云 —> 物理云
1）BigBrother 向公有云宿主機發(fā)送探測報文
2）ovs 收到報文后鏡像至 BigBrother3）ovs 將報文送至實例 4）實例回應報文 5）ovs 將回應報文鏡像至 BigBrother6）物理云核心交換機收到報文，并發(fā)送給匯聚交換機 7）8）9）10）物理云匯聚交換機發(fā)送報文給 vpcgw，vpcgw 處理報文后回送至匯聚交換機 11）在物理云匯聚交換機配置 ERSPAN，將報文鏡像至 BigBrother。
物理云 —> 公有云
1）BigBrother 向 vpcgw 發(fā)送探測報文
2）3）vpcgw 處理報文后回送至匯聚交換機 4）在物理云匯聚交換機配置 ERSPAN，將報文鏡像至 BigBrother5）匯聚交換機將報文送至 phost 的上聯(lián) Tor6）Tor 將報文送至 phost7）phost 回應報文 8）在 phost 的上聯(lián) Tor 配置 ERSPAN，將報文鏡像至 BigBrother9）報文送至公有云宿主機 ovs10）ovs 收到報文后鏡像至 BigBrother
- 跨域網關
公有云跨域互通場景下，探測報文生命周期如下：
本地域 —> 地域 B
1）BigBrother 向本域主機發(fā)送探測報文
2）ovs 收到報文后鏡像至 BigBrother3）ovs 將報文送至實例 4）實例回應報文 5）ovs 將回應報文鏡像至 BigBrother6）ovs 將報文送至 sdngw7）sdngw 將報文鏡像至 BigBrother
地域 B—> 本地域
1）BigBrother 向本域 sdngw 發(fā)送探測報文
2）sdngw 收到報文后鏡像至 BigBrother3）sdngw 將報文送至對端 sdngw 進行轉發(fā) 4）本域 sdngw 收到對端回應報文 5）sdngw 將回應報文鏡像至 BigBrother6）sdngw 將報文送至本地域宿主機 7）ovs 將報文鏡像至 BigBrother
三、Bigbrother 服務框架
整個 BB 檢測系統(tǒng)由若干個組件配合完成，minitrue 用于將用戶傳入的參數(shù)轉化為注包的范圍，telescreen 用于構造報文及收發(fā)報文。
1、服務框架圖
API： FE 服務對外提供的 HTTP 接口，用于創(chuàng)建任務和查詢任務進度；
Logic：業(yè)務處理層，?于分析?參并將其轉換為若干源?主機對放入 Disruptor 中；Disruptor：此組件為開源高性能隊列；Sender：將 Disruptor 中 pop 的數(shù)據(jù)組裝成 GRE packet，并發(fā)送給 EntryPoint；Receiver：接收從 EndPoint 上報的 GRE packet；Analysis：將接收的報?存入內存中，同時對報文進?分析。
2、Task 的執(zhí)行及結果分析
1）task
上文中我們詳細介紹了 BB 探測報文的設計和生命周期，但是我們還有一個問題需要解決：提高 BB 的并發(fā)能力。按照上文的介紹，每次 BB 只能執(zhí)行一次探測，順序執(zhí)行才能保證檢測結果的準確性，所以我們設計利用 TCP 報頭中的序列號來提高并發(fā)。
以下是一個 TCP 報文的首部結構：
其中 32 位的 Seq 序列號就是我們要利用的，在 BB 探測過程中每個 Seq 序列號都唯?標識?個 pair 對，然后我們將 Seq 序列號分成了兩部分：
- Task_id：?于標識一個 Task，由于僅有 5 位，所以每次同時進?的 Task 不能超過 32 個 ；
- Pair_id：用于標識在一個 Task 內，待檢測的一個 pair 對。
因此，我們可以將 BB 并發(fā)的任務數(shù)提高到了 32 個，而每個任務支持最大的檢測 pair 對數(shù)可以達到 2 的 27 次方，相當于每個任務都可以支持一個容量為 10000 臺云主機的 VPC 進行 Full Mesh 檢測，足以覆蓋現(xiàn)有用戶的網絡規(guī)模。
2）task 的執(zhí)行
當運維同學在 mafia（任務控制臺）上點擊創(chuàng)建一個 BB task 進行連通性檢查時，會經歷以下幾個過程：
?請求發(fā)送給 minitrue 服務，根據(jù)輸入的參數(shù)來確定探測范圍；?minitrue 將計算得到的探測范圍以源、目節(jié)點列表的形式發(fā)送給 telescreen 服務；?telescreen 構建 Gre 報文，并放入高性能隊列中進行發(fā)包；同時，telescreen 會監(jiān)聽網卡獲取鏡像報文回來的報文并存入內存；?minitrue 的分析程序定時獲取 telescreen 的收包結果并進行分析；?最后運維同學可以在 mafia 上看到最終的探測結果。
3）task 的結果分析
task 執(zhí)行結束后，運維同學可以在 mafia 查看到最后的檢測報告，包括發(fā)送的總 pair 數(shù)、收到的 pair 數(shù)、成功以及失敗的數(shù)量。同時，檢測失敗的源目詳細信息也會展示出來，最終以 bitmap 的方式呈現(xiàn)出來，0 表示沒有收到報文，1 表示收到報文。
我們以下圖的結果為例，解釋其含義。圖中是檢測 ip pair (10.9.88.160<—>10.8.17.169) 的雙向連通性。
我們再回顧下第二章中 BigBrother 檢測的流程圖，首先 BigBrother 會模擬 10.9.88.160 向 10.8.17.169 的宿主機上發(fā)送探測報文，報文的內容為 <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>
上圖 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 規(guī)則將探測報文過濾。
3 、基于活躍 flow 的連通性檢查
上文我們提到，運維同學可以在 mafia 上創(chuàng)建 BB task 來進行連通性的檢查，通過傳入 mac、子網 id、VPC id 來確定檢測的范圍，進而進行全量驗證。但是大多數(shù)場景中，我們不需要進行全互聯(lián)檢查，這樣不僅浪費時間而且還會對控制面造成一定的壓力。我們僅需要針對指定范圍內的活躍 flow 驗證連通性即可，所以我們又引入了活躍 flow 檢測的服務 ——river。river 是虛擬網絡億級別活躍流的分析系統(tǒng)，借助這個系統(tǒng) BB 可以拿到用戶的活躍通信源目，類似于緩存里的熱點數(shù)據(jù)，這樣可以讓 BB 快速精準驗證變更。
與上文全量 BB 探測的區(qū)別在于，minitrue 無須自己計算源、目節(jié)點列表，只需指定范圍后向 river 獲取活躍列表，然后通過常規(guī)的檢測流程將列表傳送給 telescreen 進行發(fā)包即可。
四、投入使用和未來計劃
BigBrother 上線后就參與到了資源整合項目中，用于云主機遷移前后的連通性驗證，保證出現(xiàn)異常后可以及時告警回滾。從 8 月初至今歷時兩個月，共遷移 2000 多臺主機，及時發(fā)現(xiàn)遷移異常近 10 起。
同時，我們對 BigBrother 后續(xù)版本也有著一定的規(guī)劃，例如：
- 除了對連通性的檢測外，還需要有平均時延，最大時延對、丟包率的檢測；
- 打算基于 BigBrother 構建針對指定用戶的內網全天候監(jiān)控。
總結
以上是生活随笔為你收集整理的BigBrother：UCloud 全链路大规模网络连通性检测系统详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 手把手教你解决U盘快捷方式病毒
- 下一篇： FH162儿童电子液晶手写板方案芯片开发