- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- 關於我們
上一期，我們詳細介紹了網絡可視化技術的需求根源以及早期的1.0和2.0時代。通過gRPC等網絡可視化技術，網絡工程師已經可以實現應用層麵的網絡流量感知和一定程度的主動監控。但伴隨網絡在業務中的比重越來越高，業務的網絡的依賴和要求也水漲船高。由此，我們進入了網絡可視化的3.0時代。
由圖中我們看到了可視化3.0的關鍵技術點有大象流老鼠流檢查、MOD、TCP增強、Packet Trace和Telemetry。
通過可視化2.0，設備已經具備了主動告警的能力，依靠gRPC和INT我們也能做到簡單的應用感知，端到端數據每節點的延遲，相關接口buffer的監控我們也能開始初步把控。相比可視化1.0，這給網絡問題的定位和流量轉發的優化帶來了長足的幫助。那麼此時我們可能會有advance的要求：現網發生問題時能不能直接告訴我們確切原因，我們能不能準確的複現問題，並在修複問題後直接模擬問題是否複現，對流量對buffer我們能不能有更細力度的把控？
還記得我們《我看見，我管理（一）——網絡可視化，網絡工程師們的福音》開篇那張圖嗎？
如果把可視化2.0方案比作網工解決問題的引路人的話，那麼可視化3.0將是現網運維人員的直通車，他將主動的告訴你問題所在，讓我們更高效的解決問題，更高效的優化網絡。
那麼，接下來就讓我們換擋，進入可視化3.0時代。
老鼠流和大象流是網絡可視化3.0當中兩個逃不開的概念。
大象流，類似於數據備份流量，在網絡中占用帶寬很大，但對時延要求較低，如數據中心常見的數據批量備份和虛擬機遷移等業務：
老鼠流，類似於業務查詢流量，流量很小，但對要求快速響應，如大家常用的web搜索和MapReduce並行計算等業務：
在傳統數據中心Spine-leaf網絡架構中，流量一般是按照負載分擔（ECMP）的方式進行調度，這裏難免出現兩個問題：
1. ECMP僅能根據報文中的特征值進行hash，所以難免出現將多條大象流調度至同一線路，將多條老鼠流調度至其他線路的現象，進而出現因負載分擔導致的網絡擁塞問題
2. 傳統的設備不支持區分大象流和老鼠流的能力，當老鼠流和大象流在一條鏈路上出現擁塞時，無法有效的進行流量優先級調度。
如果不能有效的解決數據中心網絡中這兩種流量的調度問題，難免會降低數據中心的網絡性能。
那麼我們應該如何解決呢？這裏我們就來談一下BOB登陆 的網絡解決方案，也就是mice-elephant功能，如下圖：
先讓我來詳細解釋一下上述配置的效果：流量到達設備後，首先進行acl匹配，符合acl3000（上圖中第9-10行配置）的流量將進入Flow group1的模板配置，進入該模板的流量會根據目的ip進行再進行細化統計（第11-12行配置），而其中速率為20kbp或流量大小為100kbytes的流量將定義為大象流（第15-16行配置），將其流量優先級（第17-18行配置，丟棄優先級dp設置為2，）降低。
這樣就完美的解決了老鼠低延時而大象希望大帶寬的訴求，各取所需。
不過基於此，我們引入了一個新的概念telemetry flow group，他又是做什麼的呢？Flow Group是一種流表模板，用戶可以為Flow Group指定流表的生成規則，設備依據流表生成規則提取流量特征，生成更詳細的流表，如下圖：
流量進入設備時，將進行telemetry flow group的ACL匹配，符合ACL的流量會根據Flow Group中template的配置進行更進一步的流表生成。如上圖將根據五元組中的（源/目的IP和源/目的端口）進行重新表項生成和存儲，並記錄match該表項的流量詳情（如aging time和通過的報文數量等），進而被更精細化的調度，如上文中提到的大象流和老鼠流功能。並且template中不僅能定義5元組，他還支持vxlan的表項匹配，以便更切合數據中心的網絡業務。
flow group支持3種模式：MOD模式、簡化MOD模式和大小流模式。其中大小流模式就是我們上文所說的大象流和老鼠流模式。
那麼，MOD又是什麼功能？
可視化3.0——MOD
在講MOD的之前，我們不得不提運維網工們的另一個頭疼問題——微量丟包。
我們可以做到24小時監控業務的流量運行情況，可以不間斷收集鏈路質量的數據，但要解決流量的瞬時丟包問題，我們可能要排查上很長時間。究其原因就是定位難，24小時大量數據同步運行中的幾百或幾千個報文丟失原因的排查，猶如大海撈針。
在此，我來介紹一下MOD（Mirror On Drop），即丟包鏡像功能，他可以檢測報文在設備內部轉發過程中是否發生丟包。當發生丟包時，設備會將丟包原因及丟棄報文的特征發送給采集器。這難道不是咱們運維人員的福音嗎？
那MOD具體是怎麼實現的呢？話不多說，上幹貨：
上圖中詳細的介紹了如何運用MOD解決現網中丟包定位難的問題，根據Flow group的細化表項統計能力，聚焦於問題業務段地址進行詳細排查，先根據template中的配置進行流表學習，將新學習到的流表首包上送CPU，CPU生成相應表項下發給轉發芯片，然後芯片進行存儲。後續CPU即會周期性的獲取流表信息，保證同步，芯片上的流表也會根據配置的采樣比將報文上送CPU；若流表老化周期到達，且沒有新的報文經過，即將相應流表進行刪除，有效節約存儲空間。
下麵我們來一套具體配置（含具體配置解釋），這樣我們就一目了然了：
在此，BOB登陆 為現網問題量身定製了8大原因（上圖右側）聚焦於定位問題，如其中的IPv4 DIP miss就是目的地址不可達的問題描述，IPv4 L3 header error即為報文的IPv4三層頭部有問題，相關問題原因直接呈現給運維人員，做到真正的深度問題原因可視。而且BOB登陆 的MOD功能還分為MOD和簡化MOD兩種模式，方便客戶部署。MOD 1.0模式節約CPU能力；簡化MOD模式節省硬件資源。
現在，我們知道流量優化和問題定位BOB登陆 能做到可管可視了，那麼如果更深度的buffer問題，BOB登陆 有何建樹呢？那麼請讓我來介紹一下可視化3.0的又一重要功能——TCB
上一節，我們提到了buffer的問題，很多同學也許會有困惑：管控buffer有這麼重要嗎？那我們就當下比較熱門的RDMA技術為例，詳細的說明一下buffer管控在數據中心組網的重要性吧。
RDMA，遠程直接內存訪問技術。這裏我們要主要提的是RoCE（基於以太網的RDMA技術）特性的如何保障。眾所周知，RoCE的關鍵技術諸如PFC，ECN，ETS和DCBX等均為保障RDMA業務端到端無損而推出，關鍵訴求就是通過合理的buffer來保障端到端的業務流量不丟包：
而RDMA雖然能帶來良好的業務體驗同時，但其對網絡設備運維的要求也提高了，因為業務的故障可能不止是設備表項級或業務報文級的問題，還可能是接口或芯片buffer級的問題。
這時傳統的定位或可視化手段就滿足不了當今數據中心網絡運維的需求了。這裏就需要一套自動化可視分析管理係統配合使用，也就是BOB登陆 的先知係統，這點我們暫且按下不表，先說一下網絡設備如何支持吧。而這也正是之前提到的TCB功能。
TCB（Transient Capture Buffer，瞬時抓包緩存）是一種用來監控MMU（Memory Management Unit，緩存管理單元）隊列丟包的技術。開啟TCB功能後，係統將持續監控隊列。當隊列發生丟包時，係統將收集丟包時間、丟包原因、丟包特征（源/目的IP地址，源/目的端口號，協議號等），丟包相關接口隊列和被丟棄報文的原始數據等信息，並通過gRPC的方式將分析後的數據上報網管，方便網絡管理員及時知曉設備上發生的丟包事件。
下麵我們就來詳細介紹一下TCB的狀態機，如下圖：
詳細流程如下：
1. TCB功能被開啟，設備相應接口進入待觸發狀態，開始檢測；
2. 當流量隊列長度大於start-threshold-value門限時，TCB狀態機由待觸發狀態進入預觸發狀態，並使用pre-sample-rate對隊列進行采樣抓包；
3. 當流量隊列發生丟包時，TCB狀態機由預觸發狀態進入觸發狀態，並使用post-sample-rate對隊列進行采樣抓包；
4. 當流量隊列長度小於stop-threshold-value門限時，設備停止抓包，TCB狀態機由觸發狀態進入待觸發狀態；
5. 當TCB狀態機處於待觸發狀態下，接口流量隊列長度再次大於start-threshold-value門限時，重複步驟2；
6. 當抓包數量達到frozen-number或抓包時間達到timer-value時，TCB狀態機由觸發狀態進入凍結狀態；
7. TCB進入凍結狀態後，相關模塊會對丟包原因及丟棄報文特征等信息進行分析，並將分析結果發送給gRPC模塊，由gRPC上報網管；
8. 上報後，TCB狀態機將由凍結狀態進入待觸發狀態，如此循環
這裏總結一下TCB給網絡運維帶來的好處，如下圖：
TCB功能補足傳統可視化方案中基於buffer監控的能力，使數據中心網絡更智能更細化的管理（接口或芯片buffer級），使諸如RDMA等業務更平穩的運行和管控。當問題發生時，詳細原因和抓包的收集分析和上報，讓問題第一時間可視，並可結合相關分析管理係統的能力（BOB登陆 先知係統），做到自動化網絡保障。
網絡可視化3.0，故事仍將繼續
到這裏，對於BOB登陆 可視化3.0方案的流量深度優化和定位的能力，大家應該get到了。
那麼網絡問題複現和確認問題是否修複？
對於能夠支持未來網絡自查自愈的功能，BOB登陆 又有哪些獨到之處呢？
關於網絡可視化的3.0時代，故事遠未結束。下周，我們將繼續網絡可視化3.0的討論；來看看 Packet trace、硬件Telemetry Stream以及即將到來的網絡可視化5.0。
歡迎持續關注！
