網路問題排查必備利器：Pingmesh

背景

當今的數字化世界離不開無處不在的網路連線。無論是日常生活中的社交媒體、電子商務，還是企業級應用程式和雲服務，我們對網路的依賴程度越來越高。然而，網路的可靠性和效能往往是一個複雜的問題，尤其是在具有大規模分散式架構的系統中。

在過去，網路監控主要依賴於傳統的點對點（point-to-point）方式，透過單獨的監控工具對網路路徑進行測試。然而，這種方法往往只能提供有限的資訊，並且無法全面評估整個網路的健康狀況。為了更好地瞭解網路的執行情況以及及時發現潛在的問題，Pingmesh 技術應運而生。

Pingmesh 的提出最初是來自微軟，在微軟內部 Pingmesh 每天會記錄 24TB 資料，進行 2000 億次 ping 探測，透過這些資料，微軟可以很好的進行網路故障判定和及時的修復。

下面是 Flashcat Pingmesh 的頁面樣例，可以清晰地看到各個機房之間的網路情況，也可以看到各個機櫃或交換機之間的情況：

業界方案

業界對Pingmesh的實現大都基於微軟的一則論文為基礎，做出了一些改造和升級。原微軟Pingmesh論文地址： 《Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis》。

常見的資料中心網路拓撲：

在這樣的架構中，有多個資料中心，資料中心之間有專線連通，在資料中心內部有多個Spine、Leaf、ToR交換機，在一些架構中，leaf交換機也會直接充當ToR作為伺服器接入交換機，在 ToR 交換機下有大量伺服器連線； 因此，pingmesh 能力就分為3 個級別：

1. 在機架內部，讓所有的 server 互相 ping，每個 server ping 機架內其他 N-1 個 server
2. 在機架之間，則每個機架選幾個 server ping 其他機架的 server，保證 server 所屬的 ToR 不同
3. 在資料中心之間，則選擇不同的資料中心的幾個不同機架的 server 來ping

Pingmesh 架構設計

Controller

Controller 主要負責生成 pinglist 檔案，這個檔案是 XML 格式的，pinglist 的生成是很重要的，需要根據實際的資料中心網路拓撲進行及時更新。 在生成 pinglist 時， Controller 為了避免開銷，分為3 個級別：

1. 在機架內部，讓所有的 server 互相 ping，每個 server ping （N-1） 個 server
2. 在機架之間，則每個機架選幾個 server ping 其他機架的 server，保證 server 所屬的 ToR 不同
3. 在資料中心之間，則選擇不同的資料中心的幾個不同機架的 server 來ping

Controller 在生成 pinglist 檔案後，透過 HTTP 提供出去，Agent 會定期獲取 pinglist 來更新 agent 自己的配置，也就是我們說的“拉”模式。Controller 需要保證高可用，因此需要在 VIP 後面配置多個例項，每個例項的演算法一致，pinglist 檔案內容也一致，保證可用性。

Agent

微軟資料中心的每個 server 都會執行 Agent，用來真正做 ping 動作的服務。為了保證獲取結果與真實的服務一致，Pingmesh 沒有采用 ICMP ping，而是採用的 TCP/HTTP ping。所以每個 Agent 既是 Server 也是 Client。每個 ping 動作都開啟一個新的連線，主要為了減少 Pingmesh 造成的 TCP 併發。 Agent 要保證自己是可靠的，不會造成一些嚴重的後果，其次要保證自己使用的資源要足夠的少，畢竟要執行在每個 server 上。兩個server ping 的週期最小是 10s，Packet 大小最大 64kb。針對靈活配置的需求，Agent 會定期去 Controller 上拉取 pinglist，如果 3 次拉取不到，那麼就會刪除本地已有 pinglist，停止 ping 動作。 在進行 ping 動作後，會將結果儲存在記憶體中，當儲存結果超過一定閾值或者到達了超時時間，就將結果上傳到 Cosmos 中用於分析，如果上傳失敗，會有重試，超過重試次數則將資料丟棄，保證 Agent 的記憶體使用。

網路狀況

根據論文中提到的，不同負載的資料中心的資料是有很大差異的，在 P99.9 時延時大概在 10-20ms，在 P99.99 延時大概在100+ms 。關於丟包率的計算，因為沒有用 ICMP ping 的方式，所以這裡是一種新的計算方式，（一次失敗 + 二次失敗）次數/（成功次數）= 丟包率。這裡是每次 ping 的 timeout 是 3s，windows 重傳機制等待時間是 3s，下一次 ping 的 timeout 時間是 3s，加一起也就是 9s。所以這裡跟 Agent 最小探測週期 10s 是有關聯的。二次失敗的時間就是 （2 * RTT）+ RTO 時間。 Pingmesh 的判斷依據有兩個，如果超過就報警：

• 延時超過 5ms
• 丟包率超過 10^(-3)

在論文中還提到了其他的網路故障場景，交換機的靜默丟包。有可能是 A 可以連通 B，但是不能連通 C。還有可能是 A 的 i 埠可以連通 B 的 j 埠，但是 A 的 m 埠不能連通 B 的 j 埠，這些都屬於交換機的靜默丟包的範疇。Pingmesh 透過統計這種資料，然後給交換機進行打分，當超過一定閾值時就會透過 Autopilot 來自動重啟交換機，恢復交換機的能力。

Flashcat-Pingmesh 方案

業界方案大都實現了各自的ping-agent的能力，但對於controller生成pinglist的能力並未有好的開源方案。同時我們和一些客戶交流，瞭解到目前資料中心架構與傳統的leaf-tor-server架構不太一樣，傳統一個機頂交換機下server都在一個機櫃下，現在資料中心一個交換機下機器可能在不同機櫃，這種情況如果還是按交換機維度進行探測，當server機器探測故障後，無法快速定位到機器位置。因此，我們在開發之前就針對Tor以及機櫃維度進行了設計。

Pimgesh應具備哪些能力？

1. 具備最基礎的Ping探測能力，即ICMP協議支援，同時也應支援TCP、UDP等協議的埠探測；
2. 簡化頁面使用者配置，使用者只需配置資料中心名字、交換機CIDR值，資料中心支援的探測協議和埠等關鍵資訊；
3. 資料中心會有很多機櫃、交換機和機器，如何避免ping風暴，因此需支援配置選取部分機櫃、交換和機器進行探測，及探測比例配置，使用者可靈活配置資料中心參與探測的交換機或機櫃比例數，以及每個交換機或機櫃下參與探測的Server比例數；
4. 每個資料中心內部、預設所有機櫃或交換機之間進行探測(Server比例數依舊生效)
5. 每個資料中心之間，使用者可配置預設規則，即兩兩資料中心之間，按照配置的協議進行探測。當然，使用者也可自定義哪些資料中心之間按照所選協議進行探測，此時機櫃或交換機以及Server比例數依舊生效；
6. 探測結果進行有效聚合展示，多個資料中心有很多機櫃或交換機以及機器，分三層結構展示探測結果，第一層展示所有資料中心之間的探測鏈路拓撲以及探測值、第二層展示資料中心內部每個機櫃或交換機之間的探測拓撲和結果、第三層展示機櫃或交換機下面所選Server之間的探測拓撲和結果；
7. Ping故障一鍵停止探測的止損能力；
8. 探測機器故障後，自動重新選替補機器能力；
9. 資料中心配置變更後，能及時自動以新配置重新生成pinglist；
10. 支援簡便地配置報警規則；
11. 探測結果寫入支援prometheus協議的時序庫中；

交換機和機櫃模式配置差異

1. 交換機模式，頁面使用者只需配置交換CIDR值即可，無需手動註冊Server IP，我們會藉助 Categraf 的心跳功能，自動判斷出server ip應歸屬哪個交換機。
2. 機櫃模式，這種方式一般適用於客戶環境中有自己的CMDB系統，可將其CMDB系統中的資料中心、機櫃和機器關係透過OpenApi註冊到Pingmesh系統中。

Pingmesh 架構設計：

Apiserver

提供OpenApi:

1. 用於註冊、變更、查詢資料中心原資訊、探測規則(如：資料中心、探測協議、Tor交換機CIDR/機櫃名、機器IP和機器名(機櫃方式)、 探測百分比設定、資料中心之間探測規則設定 )。
2. 資料中心三層結構拓撲圖展示，以及歷史探測曲線圖、報警規則配置、一鍵降級等API。
3. 提供給Categraf使用的查詢pinglist介面。

Controller

生成pinglist的核心控制器邏輯，它需要定時從DB中查詢最新的配置和規則，判斷是否有發生變更，如果發生變更則重新執行pinglist生成邏輯。 從DB中查到配置後，判斷是機櫃模式還是交換機模式，因為這兩種方式，其篩查Server IP的邏輯會有差異，之後需計算出每個資料中心，待探測的機櫃或交換機是哪些，以及其下的Server Ip分別是多少，做好資料準備工作。接下來檢視探測規則（資料中心內、資料中心之間），根據這些規則我們對每一臺發起探測的Server 生成探測配置，並記錄到DB中(因為我們底層真正執行探測任務的是Categraf Agent，需根據不同協議所使用的外掛，生成不同的配置檔案)。

此外，我們需新起一個協程，定時去對比新使用者配置和已生成的pinglist是否一致，因為可能在我們生成新的pinglist後的一段時間內，使用者變更或新增、刪除了資料中心配置和規則，那需要將已生成的pinglist進行對比清理，避免使用者配置變更後，依舊使用老的配置去探測，導致資料不准問題。

實現過程中還需要考慮另一個問題，資料中心有很多機器，但不是所有機器都裝有categraf，或裝有categraf但程序退出了等情況，如果我們只是單純地按所有的機器數量去篩選一堆Server IP，那很有可能選出的機器都沒有裝agent，那也就無法進行探測和發現問題了，因此我們需要結合categraf自身的心跳上報的能力，來過濾出可用的Server IP。到了這裡，我們可能會想到另一個問題，因為我們是按比例篩選機器的，而當某臺機器down掉後，原本選了10臺，現在只有9臺可用機器了，這就會和使用者配置的參與探測的伺服器比例出現diff。出現這種情況，那我們就需要重新選一臺可用機器補上去。當選擇出來這批機器後，後面都需要一直用這些機器，除非遇到重新選的情況，這樣可以保障我們指標量是固定的，同時也能滿足探測的比例需求。

探測Agent

Pingmesh底層真正執行探測邏輯的是我們的Categraf，它是一個開源的專案，外掛豐富、配置簡單，這裡就不做過多介紹了，大家可在github上搜尋下即可。Categraf 會定時來中心端拉取本機的採集外掛配置，當然，可能部署categraf的叢集很多，這裡中心端會將配置檔案快取到Redis中，降低對DB的查詢壓力，並提升介面查詢效率。最終categraf會拿到最新的外掛配置並進行探測，之後將探測結果上報給中心端，用於資料展示和報警配置使用。

額外說一點，如果存在邊緣機房，那categraf可以將探測結果上報給邊緣機房的 n9e-edge 模組，之後報警就可在這邊緣機房內部閉環了，而且edge 會自動將指標轉發給時序庫，用於頁面展示使用。

小結

Pingmesh 在複雜網路問題的排查中發揮了巨大的作用，本文分享了 Pingmesh 的實現思路，歡迎大家 聯絡我們試用。