網(wǎng)絡(luò)遙測(cè)（Network Telemetry）技術(shù)如何助力精細(xì)化網(wǎng)絡(luò)運(yùn)維？

基于AI、大數(shù)據(jù)的互聯(lián)網(wǎng)應(yīng)用推動(dòng)了互聯(lián)網(wǎng)數(shù)據(jù)中心產(chǎn)品、技術(shù)的快速升級(jí)。

首先，接入帶寬從傳統(tǒng)的10Gbps升級(jí)到25Gbps/100Gbps，需要基礎(chǔ)網(wǎng)絡(luò)提供高轉(zhuǎn)發(fā)能力保障業(yè)務(wù)的高可用。

其次，基于RDMA（Remote Direct Memory Access，遠(yuǎn)程直接內(nèi)存訪問(wèn)）無(wú)損以太網(wǎng)技術(shù)的普遍應(yīng)用，實(shí)現(xiàn)了計(jì)算節(jié)點(diǎn)到存儲(chǔ)節(jié)點(diǎn)的微秒級(jí)延時(shí)，大大優(yōu)化端到端的業(yè)務(wù)轉(zhuǎn)發(fā)性能，而這也意味著對(duì)網(wǎng)絡(luò)運(yùn)維提出了更高的挑戰(zhàn)——如何在大規(guī)模、復(fù)雜的HPC(High Performance Computing)網(wǎng)絡(luò)中實(shí)現(xiàn)更加精細(xì)的流量可視、可控？如何面向業(yè)務(wù)實(shí)現(xiàn)端到端的秒級(jí)故障定位，并為網(wǎng)絡(luò)的持續(xù)優(yōu)化提供精準(zhǔn)的數(shù)據(jù)支撐？

本文將通過(guò)介紹基于交換機(jī)硬件芯片的Network Telemetry技術(shù)方案（INT+gRPC），實(shí)現(xiàn)整網(wǎng)的流量可視化，為實(shí)現(xiàn)真正的可視化運(yùn)維提供新的思路。

——陳冬林 銳捷網(wǎng)絡(luò)互聯(lián)網(wǎng)系統(tǒng)部行業(yè)咨詢

網(wǎng)絡(luò)運(yùn)維新挑戰(zhàn)

為了保證業(yè)務(wù)的高可靠，基于Scale out方式實(shí)現(xiàn)的分布式計(jì)算和存儲(chǔ)應(yīng)用（Hadoop/ Map reduce/HDFS）得到了大規(guī)模使用，不僅擺脫了單服務(wù)器的計(jì)算、存儲(chǔ)性能的限制，同時(shí)可提供更靈活的擴(kuò)展性，能夠快速響應(yīng)業(yè)務(wù)需求變化，提高系統(tǒng)的可靠性、可用性和存取效率。

然而業(yè)務(wù)本身在網(wǎng)絡(luò)中分布是不可控的，因此在實(shí)際網(wǎng)絡(luò)流量模型中不可避免會(huì)出現(xiàn)多對(duì)一的通信模式，即 Incast模型。下圖即典型的Incast通信模型：

▲ TCP Incast通信模型示意圖

例如，當(dāng)一臺(tái)Master節(jié)點(diǎn)向一組Slave節(jié)點(diǎn)發(fā)起一個(gè)計(jì)算任務(wù)請(qǐng)求時(shí)，所有Slave節(jié)點(diǎn)幾乎會(huì)同時(shí)返回計(jì)算結(jié)果數(shù)據(jù)，對(duì)于Master節(jié)點(diǎn)來(lái)說(shuō)就產(chǎn)生了一個(gè)“微突發(fā)流”。對(duì)于合理的“微突發(fā)流”，可以依靠接入交換機(jī)設(shè)備內(nèi)部的報(bào)文緩存機(jī)制解決微突發(fā)丟包問(wèn)題。

目前，主流交換芯片的片上緩存比較小，一般以Mbyte為單位。下圖是對(duì)應(yīng)1G、10G和25G交換機(jī)常用芯片的緩存容量。

▲ 帶寬提升與緩存提升對(duì)比說(shuō)明

從表中不難看出，網(wǎng)絡(luò)接口速率從1Gbps發(fā)展到25Gbps，服務(wù)器的吞吐能力增加25倍，而交換機(jī)芯片的緩存容量同比僅增加8倍，同時(shí)可用緩存時(shí)間反而下降65%（按照交換機(jī)全端口公平使用緩存為例）。

因此，25G網(wǎng)絡(luò)架構(gòu)的TCP Incast現(xiàn)象比10G網(wǎng)絡(luò)更加明顯，瞬時(shí)的多打一導(dǎo)致出接口報(bào)文擁塞，出接口緩存用完后會(huì)基于尾部丟棄機(jī)制進(jìn)行丟包，應(yīng)用監(jiān)測(cè)到丟包后發(fā)起TCP重傳，造成數(shù)據(jù)端到端延時(shí)的進(jìn)一步惡化，嚴(yán)重影響業(yè)務(wù)體驗(yàn)。

針對(duì)網(wǎng)絡(luò)丟包引起的業(yè)務(wù)故障，需要網(wǎng)絡(luò)監(jiān)控系統(tǒng)快速定位網(wǎng)絡(luò)中哪臺(tái)交換機(jī)的哪個(gè)端口因緩存不足導(dǎo)致了丟包。同時(shí)，重要業(yè)務(wù)端到端時(shí)延超出預(yù)期時(shí)，也需要定位流量轉(zhuǎn)發(fā)路徑上每個(gè)節(jié)點(diǎn)的轉(zhuǎn)發(fā)時(shí)延。

總結(jié)起來(lái)，需要網(wǎng)絡(luò)監(jiān)控系統(tǒng)實(shí)現(xiàn)如下能力：

●快速定位哪臺(tái)交換機(jī)的哪個(gè)端口發(fā)生丟包；

●實(shí)時(shí)監(jiān)控每臺(tái)交換機(jī)的Buffer使用情況；

●端到端時(shí)延可以定位到具體設(shè)備和鏈路。

運(yùn)維可視化技術(shù)實(shí)現(xiàn)

憑借傳統(tǒng)的網(wǎng)絡(luò)監(jiān)控手段無(wú)法解決“看不見(jiàn)”的問(wèn)題，如時(shí)延、轉(zhuǎn)發(fā)路徑、緩存和丟包。例如，由外部應(yīng)用發(fā)起的請(qǐng)求獲取網(wǎng)絡(luò)狀態(tài)信息的SNMP協(xié)議，就無(wú)法實(shí)時(shí)反映網(wǎng)絡(luò)的狀態(tài)。

為了解決此類難題，業(yè)界廣泛引入Network Telemetry（網(wǎng)絡(luò)遙測(cè)）這一理念，相比于SNMP，Telemetry實(shí)現(xiàn)了網(wǎng)絡(luò)設(shè)備主動(dòng)推送狀態(tài)信息的能力，具有更強(qiáng)的時(shí)效性。

事實(shí)上，Telemetry并不是新發(fā)明，NetFlow和sFlow早已實(shí)現(xiàn)了網(wǎng)絡(luò)流量的采樣和推送，但NetFlow、sFlow推送的是最原始的數(shù)據(jù)采樣信息，數(shù)據(jù)以IP報(bào)文格式呈現(xiàn)給分析工具，而非用戶期望的規(guī)范化數(shù)據(jù)模型，再優(yōu)異的分析工具其擴(kuò)展性能也難以承擔(dān)整個(gè)數(shù)據(jù)中心網(wǎng)絡(luò)的監(jiān)控分析，只能在某一分析任務(wù)中發(fā)揮作用。

另一方面，數(shù)據(jù)流量并非網(wǎng)絡(luò)狀態(tài)的全部，網(wǎng)絡(luò)設(shè)備的 CPU、內(nèi)存、網(wǎng)絡(luò)擁塞信息、網(wǎng)絡(luò)事件的日志信息等也無(wú)法通過(guò)NetFlow或者sFlow實(shí)時(shí)傳遞出來(lái)。

gRPC（Google Remote Procedure Calls ，谷歌遠(yuǎn)程過(guò)程調(diào)用）是Google公司開(kāi)源的一個(gè)高性能、跨語(yǔ)言的RPC框架，使用HTTP/2協(xié)議并使用Proto Buffer作為序列化和反序列化的工具。通過(guò)在交換機(jī)中集成gRPC應(yīng)用，定義靈活的數(shù)據(jù)格式以及數(shù)據(jù)推送的閾值來(lái)實(shí)現(xiàn)交換機(jī)自身狀態(tài)的主動(dòng)推送能力，可以實(shí)現(xiàn)周期性推送交換機(jī)Buffer Usage、CPU、Memory等信息給監(jiān)控服務(wù)器。當(dāng)發(fā)生Buffer不足導(dǎo)致丟包，也會(huì)實(shí)時(shí)通知給監(jiān)控服務(wù)器，實(shí)現(xiàn)網(wǎng)絡(luò)運(yùn)行數(shù)據(jù)的可視化。

▲ gRPC交互機(jī)制

上圖展示了其中一種gRPC的交互機(jī)制：

●在交換機(jī)開(kāi)啟gRPC功能后充當(dāng)gRPC 客戶端角色，監(jiān)控服務(wù)器充當(dāng)gRPC服務(wù)器角色；

●交換機(jī)主動(dòng)向監(jiān)控服務(wù)器發(fā)起gRPC通道建連；

●交換機(jī)主動(dòng)上報(bào)Buffer Usage、CPU、內(nèi)存等信息給監(jiān)控服務(wù)器，當(dāng)Buffer發(fā)生丟包，交換機(jī)會(huì)也會(huì)實(shí)時(shí)上報(bào)丟包事件給監(jiān)控服務(wù)器。

gRPC的出現(xiàn)很好的解決了實(shí)時(shí)數(shù)據(jù)無(wú)法有效傳給監(jiān)控服務(wù)器的問(wèn)題。

INT（In-band Network Telemetry）也是一種新型Telemetry協(xié)議，由Barefoot、Arista、Dell、Intel和VMware共同提出。INT的出現(xiàn)解決了轉(zhuǎn)發(fā)路徑和轉(zhuǎn)發(fā)時(shí)延不可見(jiàn)的問(wèn)題。

INT的整體處理流程如下圖所示：

▲ 可視化網(wǎng)絡(luò)

●報(bào)文達(dá)到首節(jié)點(diǎn)，通過(guò)在交換機(jī)上設(shè)置的采樣方式匹配并鏡像出該報(bào)文，并在四層頭部后插入INT頭，將報(bào)文入端口Port ID、出端口 Port ID、入端口時(shí)間、出端口時(shí)間、以及設(shè)備的DEVICE ID封裝成MetaData，將MD插入到INT頭部之后；

●報(bào)文轉(zhuǎn)發(fā)到中間節(jié)點(diǎn)，設(shè)備匹配到INT頭部后，在INT頭部后再插入一層MD；

●報(bào)文轉(zhuǎn)發(fā)到最后一跳，設(shè)備匹配INT頭部后，再插入一層MD，并在報(bào)文外部封裝一個(gè)IP頭（ERSPAN），外層IP為監(jiān)控服務(wù)器地址，這樣INT報(bào)文便轉(zhuǎn)發(fā)到監(jiān)控服務(wù)器。

總結(jié)：針對(duì)面向HPC業(yè)務(wù)的下一代數(shù)據(jù)中心網(wǎng)絡(luò)，基于INT和gRPC的Network Telemetry技術(shù)可以實(shí)現(xiàn)業(yè)務(wù)端到端的網(wǎng)絡(luò)流量可視化，打破“網(wǎng)絡(luò)黑盒”，為精細(xì)化網(wǎng)絡(luò)運(yùn)維提供整體的解決方案和必要的技術(shù)支撐。

銳捷網(wǎng)絡(luò)新一代25G/100G網(wǎng)絡(luò)交換機(jī)產(chǎn)品均已實(shí)現(xiàn)Network Telemetry能力（gRPC和INT），如果您對(duì)網(wǎng)絡(luò)遙測(cè)感興趣，歡迎留言交流。