如何通過網路遙測技術實現精細化網路運維？

最新 04-05

基於AI、大數據的互聯網應用推動了互聯網數據中心產品、技術的快速升級。

首先，接入帶寬從傳統的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不足導致丟包，也會實時通知給監控伺服器，實現網路運行數據的可視化。