背景

在我們內(nèi)部產(chǎn)品中，一直有關(guān)于網(wǎng)絡(luò)性能數(shù)據(jù)監(jiān)控需求，我們之前是直接使用 ping 命令收集結(jié)果，每臺(tái)服務(wù)器去 ping (N-1) 臺(tái)，也就是 N^2 的復(fù)雜度，穩(wěn)定性和性能都存在一些問(wèn)題，最近打算對(duì)這部分進(jìn)行重寫，在重新調(diào)研期間看到了 Pingmesh 這篇論文，Pingmesh 是微軟用來(lái)監(jiān)控?cái)?shù)據(jù)中心網(wǎng)絡(luò)情況而開(kāi)發(fā)的軟件，通過(guò)閱讀這篇論文來(lái)學(xué)習(xí)下他們是怎么做的。

數(shù)據(jù)中心自身是極為復(fù)雜的，其中網(wǎng)絡(luò)涉及到的設(shè)備很多就顯得更為復(fù)雜，一個(gè)大型數(shù)據(jù)中心都有成百上千的節(jié)點(diǎn)、網(wǎng)卡、交換機(jī)、路由器以及無(wú)數(shù)的網(wǎng)線、光纖。在這些硬件設(shè)備基礎(chǔ)上構(gòu)建了很多軟件，比如搜索引擎、分布式文件系統(tǒng)、分布式存儲(chǔ)等等。在這些系統(tǒng)運(yùn)行過(guò)程中，面臨一些問(wèn)題：如何判斷一個(gè)故障是網(wǎng)絡(luò)故障？如何定義和追蹤網(wǎng)絡(luò)的 SLA？出了故障如何去排查？

基于這幾點(diǎn)問(wèn)題，微軟設(shè)計(jì)開(kāi)發(fā)了 Pingmesh，用來(lái)記錄和分析數(shù)據(jù)中心的網(wǎng)絡(luò)情況。在微軟內(nèi)部 Pingmesh 每天會(huì)記錄 24TB 數(shù)據(jù)，進(jìn)行 2k 億次 ping 探測(cè)，通過(guò)這些數(shù)據(jù)，微軟可以很好的進(jìn)行網(wǎng)絡(luò)故障判定和及時(shí)的修復(fù)。

數(shù)據(jù)中心網(wǎng)絡(luò)

常見(jiàn)的數(shù)據(jù)中心網(wǎng)絡(luò)拓?fù)洌?/p>

網(wǎng)絡(luò)延時(shí)計(jì)算方式：server A 發(fā)送消息到 server B 接受消息的時(shí)間。最終使用 RTT 時(shí)間，RTT 一個(gè)好處是絕對(duì)時(shí)間，與時(shí)鐘不相關(guān)。

在大多數(shù)情況下，大家不會(huì)去關(guān)心延時(shí)具體是什么導(dǎo)致的，都是直接歸結(jié)于網(wǎng)絡(luò)原因，讓網(wǎng)絡(luò)團(tuán)隊(duì)去排查，實(shí)際上是浪費(fèi)了很多人力成本。延時(shí)變高有很多原因：CPU 繁忙、服務(wù)自身 Bug、網(wǎng)絡(luò)原因等等。往往丟包會(huì)伴隨著延時(shí)升高，因?yàn)閬G包意味著會(huì)發(fā)生重傳，所以丟包也是需要觀察的重點(diǎn)。

因?yàn)?Pingmesh 運(yùn)行在微軟內(nèi)部，所以依托于微軟自己的基礎(chǔ)架構(gòu)，有自動(dòng)化管理系統(tǒng) Autopilot，有大數(shù)據(jù)系統(tǒng) Cosmos，也有類似于 SQL 的腳本語(yǔ)言 SCOPE。

設(shè)計(jì)

根據(jù)上面的需求，Pingmesh 先評(píng)估了現(xiàn)有的開(kāi)源工具，不符合的原因有很多，大多數(shù)工具都是以命令行形式呈現(xiàn)，一般是出現(xiàn)故障了去使用工具排查，而且工具提供的數(shù)據(jù)也不全面，有可能正在運(yùn)行工具問(wèn)題已經(jīng)解決了。當(dāng)然這并不是說(shuō)已有的工具沒(méi)有用，只能說(shuō)不適合 Pingmesh。

Pingmesh 是松耦合設(shè)計(jì)，每個(gè)組件都是可以獨(dú)立運(yùn)行的，分為 3 個(gè)組件。在設(shè)計(jì)的時(shí)候需要考慮幾點(diǎn)：

• 因?yàn)橐\(yùn)行在所有的 server 上，所以不能占用太多的計(jì)算資源或網(wǎng)絡(luò)資源

• 需要是靈活配置的且高可用的的

• 記錄的數(shù)據(jù)需要進(jìn)行合理的匯總分析

Pingmesh 架構(gòu)設(shè)計(jì)：

Controller

Controller 主要負(fù)責(zé)生成 pinglist 文件，這個(gè)文件是 XML 格式的，pinglist 的生成是很重要的，需要根據(jù)實(shí)際的數(shù)據(jù)中心網(wǎng)絡(luò)拓?fù)溥M(jìn)行及時(shí)更新。

在生成 pinglist 時(shí)， Controller 為了避免開(kāi)銷，分為3 個(gè)級(jí)別：

1. 在機(jī)架內(nèi)部，讓所有的 server 互相 ping，每個(gè) server ping （N-1） 個(gè) server

2. 在機(jī)架之間，則每個(gè)機(jī)架選幾個(gè) server ping 其他機(jī)架的 server，保證 server 所屬的 ToR 不同

3. 在數(shù)據(jù)中心之間，則選擇不同的數(shù)據(jù)中心的幾個(gè)不同機(jī)架的 server 來(lái)ping

Controller 在生成 pinglist 文件后，通過(guò) HTTP 提供出去，Agent 會(huì)定期獲取 pinglist 來(lái)更新 agent 自己的配置，也就是我們說(shuō)的“拉”模式。Controller 需要保證高可用，因此需要在 VIP 后面配置多個(gè)實(shí)例，每個(gè)實(shí)例的算法一致，pinglist 文件內(nèi)容也一致，保證可用性。

Agent

微軟數(shù)據(jù)中心的每個(gè) server 都會(huì)運(yùn)行 Agent，用來(lái)真正做 ping 動(dòng)作的服務(wù)。為了保證獲取結(jié)果與真實(shí)的服務(wù)一致，Pingmesh 沒(méi)有采用 ICMP ping，而是采用的 TCP/HTTP ping。所以每個(gè) Agent 即是 Server 也是 Client。每個(gè) ping 動(dòng)作都開(kāi)啟一個(gè)新的連接，主要為了減少 Pingmesh 造成的 TCP 并發(fā)。

Agent 要保證自己是可靠的，不會(huì)造成一些嚴(yán)重的后果，其次要保證自己使用的資源要足夠的少，畢竟要運(yùn)行在每個(gè) server 上。兩個(gè)server ping 的周期最小是 10s，Packet 大小最大 64kb。針對(duì)靈活配置的需求，Agent 會(huì)定期去 Controller 上拉取 pinglist，如果 3 次拉取不到，那么就會(huì)刪除本地已有 pinglist，停止 ping 動(dòng)作。

在進(jìn)行 ping 動(dòng)作后，會(huì)將結(jié)果保存在內(nèi)存中，當(dāng)保存結(jié)果超過(guò)一定閾值或者到達(dá)了超時(shí)時(shí)間，就將結(jié)果上傳到 Cosmos 中用于分析，如果上傳失敗，會(huì)有重試，超過(guò)重試次數(shù)則將數(shù)據(jù)丟棄，保證 Agent 的內(nèi)存使用。

Analysis

拿到了數(shù)據(jù)就要進(jìn)行分析，Pingmesh 會(huì)以 10min，1hour，1天的粒度進(jìn)行統(tǒng)計(jì)匯總，數(shù)據(jù)的實(shí)時(shí)性最快也就是 10min ，Pingmesh 還借助內(nèi)部的基礎(chǔ)設(shè)施能夠拿到 5min 級(jí)別的數(shù)據(jù)結(jié)果，算是一種“實(shí)時(shí)”監(jiān)控吧。

網(wǎng)絡(luò)狀況

根據(jù)論文中提到的，不同負(fù)載的數(shù)據(jù)中心的數(shù)據(jù)是有很大差異的，在 P99.9 時(shí)延時(shí)大概在 10-20ms，在 P99.99 延時(shí)大概在100+ms 。關(guān)于丟包率的計(jì)算，因?yàn)闆](méi)有用 ICMP ping 的方式，所以這里是一種新的計(jì)算方式，（一次失敗 + 二次失?。┐螖?shù)/（成功次數(shù)）= 丟包率。這里是每次 ping 的 timeout 是 3s，windows 重傳機(jī)制等待時(shí)間是 3s，下一次 ping 的 timeout 時(shí)間是 3s，加一起也就是 9s。所以這里跟 Agent 最小探測(cè)周期 10s 是有關(guān)聯(lián)的。二次失敗的時(shí)間就是 （2 * RTT）+ RTO 時(shí)間。

Pingmesh 的判斷依據(jù)有兩個(gè)，如果超過(guò)就報(bào)警：

• 延時(shí)超過(guò)?5ms

• 丟包率超過(guò)?10^(-3)

在論文中還提到了其他的網(wǎng)絡(luò)故障場(chǎng)景，交換機(jī)的靜默丟包。有可能是 A 可以連通 B，但是不能連通 C。還有可能是 A 的 i 端口可以連通 B 的 j 端口，但是 A 的 m 端口不能連通 B 的 j 端口，這些都屬于交換機(jī)的靜默丟包的范疇。Pingmesh 通過(guò)統(tǒng)計(jì)這種數(shù)據(jù)，然后給交換機(jī)進(jìn)行打分，當(dāng)超過(guò)一定閾值時(shí)就會(huì)通過(guò) Autopilot 來(lái)自動(dòng)重啟交換機(jī)，恢復(fù)交換機(jī)的能力。

經(jīng)驗(yàn)學(xué)習(xí)

1. 找到可信數(shù)據(jù)，只有數(shù)據(jù)來(lái)源可信，那么分析才是有效的

2. 讓服務(wù)作為 daemon 運(yùn)行，保證持續(xù)的收集數(shù)據(jù)

3. 松耦合設(shè)計(jì)，每個(gè)組件都可以獨(dú)立工作

總結(jié)

其實(shí)我們自己的系統(tǒng)是有 Prometheus 這樣的監(jiān)控系統(tǒng)的，但是當(dāng)遇到交換機(jī)級(jí)別的間歇性故障時(shí)，Prometheus 也是故障的狀態(tài)，所以也就不會(huì)收集 exporter 匯報(bào)的數(shù)據(jù)，也就更沒(méi)辦法產(chǎn)生告警了。所以如果遇到那種長(zhǎng)時(shí)間持續(xù)的故障反而是好事，至少我們有一個(gè)足夠的狀態(tài)去排查哪里出了問(wèn)題，否則真的是間歇性故障僅僅依靠 ping, traceroute, iperf, netstat 之類的工具去排查是沒(méi)什么效果的，只有我們知道過(guò)去一段時(shí)間的網(wǎng)絡(luò)情況，才能去排查。

參考鏈接

• https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p139.pdf

• http://ninjadq.com/2017/04/01/linux-rto

• https://yi-ran.github.io/2019/03/27/Pingmesh-SIGCOMM-2015/

本文轉(zhuǎn)載自：論文閱讀 《Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis》（https://zdyxry.github.io/2020/03/26/%E8%AE%BA%E6%96%87%E9%98%85%E8%AF%BB-Pingmesh-A-Large-Scale-System-for-Data-Center-Network-Latency-Measurement-and-Analysis/）

如果您需要 Pingmesh 的產(chǎn)品，可以?聯(lián)系我們（?https://flashcat.cloud/contact/ ）。