• 產品與解決方案
  • 行業解決方案
  • 服務
  • 支持
  • 合作夥伴
  • 關於我們

互聯網技術詳解-運維工程師的福音—網絡可視化方案(一)

【發布時間:2021-01-28】

對於網絡工程師來說,網絡可視化是個時常都要接觸的話題;畢竟,能看見的東西才更容易管理。但網絡的可視化並非一蹴而就,伴隨網絡複雜度提升和網絡管理要求的升級,可視化才漸漸從無到有、從少到多、從簡到精。

網絡可視化緣起何處?網絡可視化經曆了幾個階段?目前流行的網絡可視化解決方案有什麼?各自特點如何?網絡可視化未來發展趨勢如何?麵對這一係列問題,本次我們將分為用三篇文章的篇幅為您詳細解讀網絡可視化的來龍去脈、過去和未來。

作為本係列的第一篇,我們將著重解讀網絡可視化的1.0和2.0時代。

網工們的呐喊——網絡可視化之緣起

上圖是網工們在日常工作中經常遇到的問題,每一種問題的解決都可以用費時費力來概括。因此,網工們的訴求也就躍然紙上:將端到端的流量路徑做可視化監控,將出現的問題和告警實時的投入大屏,能基於此快速的分析出具體問題原因並給出解決建議。

網絡運營者需要這一整套方案,該方案能在幫助運維的同時,節約了人力物力和最寶貴的時間,讓網絡真正的智能起來。

說了這麼多,如何落地才是網工們真正關心的事情吧。

網絡可視化的1.0時代——簡單,但遠未完美

我們在傳統運維中已經采用了CLI,SNMP、和Syslog等技術收集設備參數(如下圖),下發具體配置,更有許多網管軟件也基於此做了簡單的可視化界麵:

這裏我們可將其視為可視化1.0方案(其中還包括像Netstream和Sflow等流采樣技術),這套方案雖然解決了基本的運維需求,但其采樣和配置的時效性比較差(分鍾級),批量采集還會加大設備的CPU負擔,還有就是流量可視化僅能做到單機上報簡單的統計,端到端的路徑可視沒有技術支撐,詳細問題的分析和定位需求沒有得到真正解決。

故而可視化2.0的方案在大家的呼喚下,來到了我們身邊,相關代表技術為INT和GRPC

網絡可視化的2.0時代——INT,可視化的全新解

INT(In-band Network Telemetry,帶內遙測)是一項從設備上實時采集數據平麵信息的網絡監控技術,真正解決了流量端到端的可視,達到對網絡設備的性能及網絡運行情況進行實時監控的和問題快速定位的目的。

具體INT是如何實現流量可視的呢?首先我們來看如下這張經典的三層數據中心網絡拓撲圖,其中接入設備(Leaf)用6850表示,彙聚設備(Spine)用9820表示,核心設備(Super-Spine)用125X表示,上述設備均能支持INT能力。現在有一條流量送ServerA向ServerD襲來,此時INT是如何應對的呢?

第一步:頭節點流量複製

  1. 原始報文進入6850時,根據交換機的配置,流量將進行采樣並複製出一份報文送給交換機相關模塊,被複製報文正常轉發,業務不受影響;
  2. 交換機把複製報文添加一個INT HDR,回送給Ingress PIPE,讓報文重新走一遍轉發流程(即報文入端口將保持不變);
  3. 複製報文重新進入轉發流程後,交換機相應模塊會邏輯匹配到INT HDR,動作為添加INT Metadata字段;
  4. 鏡像報文根據目的地址從接入設備(6850)出去後,將攜帶INT HDR和INT Metadata字段;

第二步:中間節點疊加

  1. 由於複製報文經過中間節點時已經帶上了INT HDR,中間節點通過匹配INT HDR字段,識別其為INT報文,經過中間節點設備時會增加MD/TS字段,
  2. 由於複製報文的IP和MAC頭將保持不變,且設備轉發規則不變,所以複製流量將follow原始流量路徑,做到真正的1:1端到端信息采集(時延buffer等細粒度統計)

第三步:尾節點疊加

  1. 當複製報文(攜帶INT HDR和整個路徑的METADATA)到達尾節點進入Ingress邏輯後,尾節點將會為其打上最後一跳芯片的Timestamp;
  2. 當複製報文到達Egress邏輯時,根據配置,複製流量將會送回交換機相應模塊,且其動作為DROP,該報文不會再轉發出去;
  3. 交換機模塊會對複製報文的內容進行重組,把報文中的Timestamp等信息轉換為統一的METADATA封裝,再根據配置,將重組報文的目的地址寫為遠端收集器的IP後,將該報文送回交換機的Ingress邏輯轉發至收集器

講了INT整個的流程,相信大家能夠記住其中的特性關鍵字:複製且不影響現網流量;端到端的流量詳細信息采集;粒度細化到報文;能將經過各設備的時延和端口丟包情況等現網運維密切關心的參數進行收集上報。

下一步我們來詳細了解一下INT具體的報文格式,讓大家更深入的了解該項技術能做到什麼. INT報文主要有三塊:INT HDR、MD和TS,下麵我們先來介紹一下INT HDR和MD的格式。

INT HDR格式:

報文頭部詳細字段解釋:

MD格式:

報文頭部詳細字段解釋:

講了格式,大家可能會考慮下一步:INT報文如何封裝的呢?

他包括如下兩種形式,在UDP/TCP頭部後添加(INT HDR和MD) 或在幀尾添加封裝(TS),如下圖:

第一種:INT HDR和MD(METADATA)封裝:

第二種:TS封裝(全稱Timestamp,包含節點的Ingress時間戳和Egress時間戳):

講到這,大家應該對INT有了詳細的了解,那麼我們再來介紹可視化2.0的第二個關鍵技術gRPC。

網絡可視化的2.0時代——gPRC,高效,強大,但仍有進化空間

文章伊始,我們介紹了傳統網絡的網絡管理技術,也介紹了這些技術的瓶頸,諸如實時性統計效果不佳,傳遞信息顆粒度不夠,頻繁采集使CPU占用率增高等。

麵對上圖這樣的情況,我們不禁感慨:要是他們有基於gRPC的telemetry,查看圖中紅圈圈就能get到真相,客戶的投訴不都可以規避了嗎?!

Ok,我覺得現在大家初步get到了gRPC的作用,那麼我現在來詳細介紹一下gRPC是啥吧:

gRPC(Google Remote Procedure Call,Google遠程過程調用),基於HTTP 2.0傳輸層協議承載的高性能開源軟件框架;通信雙方可以基於該軟件框架進行二次開發。

gRPC使設備能通過推模式(Push Mode)周期性的主動向采集器上送設備的被訂閱數據源(例如:接口流量統計、CPU或內存數據等信息),相對傳統拉模式(Pull Mode)的一問一答式交互,提供了更實時更高速的數據采集功能。

gRPC的協議棧分層和優點如下圖所示:

從圖中可以看出,gRPC層是承載在HTTP2.0層之上的,該層定義了RPC的協議交互格式。公共RPC方法定義在公共proto文件中,例如grpc_dialout.proto。

講到gRPC就不得講他使用的高效Protocol Buffers編碼,該編碼方式與XML、JSON編碼類似,不同之處在於Protocol Buffers是一種二進製編碼,性能更高。例如下圖:

理解了協議,下麵我們來看看gRPC有哪些工作模式:

gRPC分為Dial-in 模式和Dial-out 模式,如下圖:

Dial-in 模式:設備作為gRPC 服務器,采集器作為gRPC 客戶端。由采集器主動向設備發起gRPC 連接並訂閱需要采集的數據信息。Dial-in 模式適用於小規模網絡和采集器需要向設備下發配置的場景。

Dial-out 模式:設備作為gRPC 客戶端,采集器作為gRPC 服務器。設備主動和采集器建立gRPC 連接,將設備上配置的訂閱數據推送給采集器。Dial-out 模式適用於網絡設備較多的情況下向采集器提供設備數據信息

注:H3C為Dial-in模式和Dial-out模式分別提供了proto文件。

講到此,大家應該已經get到了gRPC這種先進的管道技術的優勢,但可視化管控的需求是靠設備提供關鍵采樣參數落地的。所以H3C基於常年的網絡實踐,為客戶量身打造了一整套的參數,幫助客戶有效的運維,下麵給出一些關鍵的采樣信息模板以供參考。

其中包括運維關心的統計和告警信息的周期性采樣和事件觸發上報,各主要表項信息的彙總諸如路由,ACL等,各接口的丟包信息和buffer大小等,甚至包括RDMA的相關參數信息,如圖中PFC統計等。

兩大關鍵技術點INT和gRPC已經介紹完畢,估計大家此時可能會好奇一件事:可視化2.0到底是怎麼實現的呢?他的全景圖是怎樣的呢?

在此BOB登陆 提供了一整套可視化2.0的解決方案,如下圖:

基於新一代的Telemetry技術,通過訂閱/通知的機製(gRPC)將設備的關鍵信息高效傳遞給采集器,采集器進行彙總後發送給SNA Center進行再分析和呈現,實現真正的網絡內在可視,讓客戶用著安心,讓現網問題無所遁形。再加上整網INT功能,使業務流量也能做到端到端的路徑隊列可視。這裏尤其要說的是像現階段的熱點應用如:RDMA無損網絡RoCE,BOB登陆 也在設備側落地了相關參數(如下圖),保障業務端到端的業務可管可視可控。

可視化方案2.0介紹到此結束,相信大家也許有躍躍欲試的衝動吧。

結語:

以gPRC為代表的網絡可視化2.0時代已經能夠比較方便的解決很多網絡監控與管理中的實際問題。但這並非工程師們理想中的網絡可視化解決方案。

因此,在下一篇文章中,我們將繼續沿著網絡可視化技術的發展路線,為您詳解網絡可視化3.0時代的技術、原理及優勢。

BOB登陆
官網
聯係我們