首先，接入帶寬從傳統的10Gbps升級到25Gbps/100Gbps，需要基礎網絡提供高轉發能力保障業務的高可用。

其次，基於RDMA（Remote Direct Memory Access，遠程直接內存訪問）無損以太網技術的普遍應用，實現了計算節點到存儲節點的微秒級時延，大大優化端到端的業務轉發性能，而這也意味著對網絡運維提出了更高的挑戰——如何在大規模、復雜的HPC(High Performance Computing)網絡中實現更加精細的流量可視、可控？如何面向業務實現端到端的秒級故障定位，並為網絡的持續優化提供精準的數據支撐？

銳捷網絡認為，通過基於交換機硬件芯片的Network Telemetry技術方案（INT+gRPC），可以實現整網的流量可視化，為實現真正的可視化運維提供新的思路。查找了相關資料整了下，以下是銳捷專家的精彩解讀。

網絡運維新挑戰

為了保證業務的高可靠，基於Scale out方式實現的分布式計算和存儲應用（Hadoop/ Map reduce/HDFS）得到了大規模使用，不僅擺脫了單服務器的計算、存儲性能的限制，同時可提供更靈活的擴展性，能夠快速響應業務需求變化，提高系統的可靠性、可用性和存取效率。

然而業務本身在網絡中分布是不可控的，因此在實際網絡流量模型中不可避免會出現多對一的通信模式，即 Incast模型。下圖即典型的Incast通信模型：

▲ TCP Incast通信模型示意圖

例如，當一臺Master節點向一組Slave節點發起一個計算任務請求時，所有Slave節點幾乎會同時返回計算結果數據，對於Master節點來說就產生了一個“微突發流”。對於合理的“微突發流”，可以依靠接入交換機設備內部的報文緩存機制解決微突發丟包問題。

目前，主流交換機設備緩存比較小，一般以MByte為單位。下圖是對應1G、10G和25G交換機的緩存容量。

▲ 帶寬提升與緩存提升對比說明

從表中不難看出，網絡接口速率從1Gbps發展到25Gbps，服務器的吞吐能力增加25倍，而交換機的緩存容量同比僅增加8倍，同時報文緩存時間反而下降65%（按照交換機全端口公平使用緩存為例）。

因此，25G網絡架構的TCP Incast現象比10G網絡更加明顯，瞬時的多打一導致出接口報文擁塞，出接口緩存用完後會基於尾部丟棄機制進行丟包，應用監測到丟包後發起TCP重傳，造成數據端到端時延的進一步惡化，嚴重影響業務體驗。

針對網絡丟包引起的業務故障，需要網絡監控系統快速定位網絡中哪臺交換機的哪個端口因緩存不足導致了丟包。同時，重要業務端到端時延超出預期時，也需要定位流量轉發路徑上每個節點的轉發時延。

總結起來，需要網絡監控系統實現如下能力：
? 快速定位哪臺交換機的哪個端口發生丟包；
? 實時監控每臺交換機的Buffer使用情況；
? 端到端時延可以定位到具體設備和鏈路。

運維可視化技術實現

憑借傳統的網絡監控手段無法解決“看不見”的問題，如時延、轉發路徑、緩存和丟包。例如，由外部應用發起的請求獲取網絡狀態信息的SNMP協議，就無法實時反映網絡的狀態。

為了解決此類難題，業界廣泛引入Network Telemetry（網絡遙測）這一理念，相比於SNMP，Telemetry實現了網絡設備主動推送狀態信息的能力，具有更強的時效性。

事實上，Telemetry並不是新發明，NetFlow和sFlow早已實現了網絡流量的采樣和推送，但NetFlow、sFlow推送的是最原始的數據采樣信息，數據以IP報文格式呈現給分析工具，而非用戶期望的規範化數據模型，再優異的分析工具其擴展性能也難以承擔整個數據中心網絡的監控分析，只能在某一分析任務中發揮作用。

另一方面，數據流量並非網絡狀態的全部，網絡設備的 CPU、內存、網絡擁塞信息、網絡事件的日誌信息等也無法通過NetFlow或者sFlow實時傳遞出來。

gRPC（Google Remote Procedure Calls ，谷歌遠程過程調用）是Google公司開源的一個高性能、跨語言的RPC框架，使用HTTP/2協議並使用Proto Buffer作為序列化和反序列化的工具。通過在交換機中集成gRPC應用，定義靈活的數據格式以及數據推送的閾值來實現交換機自身狀態的主動推送能力，可以實現周期性推送交換機Buffer Usage、CPU、Memory等信息給監控服務器。當發生Buffer不足導致丟包，也會實時通知給監控服務器，實現網絡運行數據的可視化。

▲ gRPC交互機制

上圖展示了其中一種gRPC的交互機制：
? 在交換機開啟gRPC功能後充當gRPC 客戶端角色，監控服務器充當gRPC服務器角色；
? 交換機主動向監控服務器發起gRPC通道建連；
? 交換機主動上報Buffer Usage、CPU、內存等信息給監控服務器，當Buffer發生丟包，交換機也會實時上報丟包事件給監控服務器。

gRPC的出現很好的解決了實時數據無法有效傳給監控服務器的問題。

INT（In-band Network Telemetry）也是一種新型Telemetry協議，由Barefoot、Arista、Dell、Intel和VMware共同提出。INT的出現解決了轉發路徑和轉發時延不可見的問題。

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

▲ 可視化網絡

? 報文達到首節點，通過在交換機上設置的采樣方式匹配並鏡像出該報文，並在四層頭部後插入INT頭，將報文入端口Port ID、出端口 Port ID、入端口時間、出端口時間、以及設備的DEVICE ID封裝成MetaData，將MD插入到INT頭部之後；
? 報文轉發到中間節點，設備匹配到INT頭部後，在INT頭部後再插入一層MD；
? 報文轉發到最後一跳，設備匹配INT頭部後，再插入一層MD，並在報文外部封裝一個IP頭（ERSPAN），外層IP為監控服務器地址，這樣INT報文便轉發到監控服務器。

總結：針對面向HPC業務的下一代數據中心網絡，基於INT和gRPC的Network Telemetry技術可以實現業務端到端的網絡流量可視化，打破“網絡黑盒”，為精細化網絡運維提供整體的解決方案和必要的技術支撐。銳捷網絡新一代25G/100G網絡交換機產品均已實現Network Telemetry能力（gRPC和INT）。

如何通過網絡遙測（Network Telemetry）技術實現精細化網絡運維？