什麼是微突發？

什麼是微突發？
微突發的定義
微突發是指端口在很是短的時間（毫秒級別）內收到很是多的突發數據，以致於瞬時突發速率達到平均速率的數十倍、數百倍，甚至超過端口帶寬的現象。
網管設備或網絡性能監測軟件一般是基於比較長的時間(數秒到數分鐘)計算網絡實時帶寬。在這種狀況下，看到流量速率一般是一條比較平穩的曲線（如圖22-121所示）。可是，一秒鐘對於一個高速收發數據包的接口來講是很是長的一個時間段。若是將數據更改成毫秒級進行觀察，流量速率極可能是帶鋸齒的（如圖22-122所示）。若是鋸齒突變很大，就稱爲微突發。
舉個極端的微突發的例子：假設一個10GE鏈路上有平均1Gbps速率的流量，極端狀況下能夠是前100毫秒有10Gbps的流量，後面900毫秒的流量爲0。這時，前100毫秒的10Gbps的流量對於設備而言就是微突發。
圖22-121 宏觀流量速率

圖22-122 微觀流量速率

微突發的常見誤解
對於微突發的檢測，一般有以下幾種理解誤區：
爲何微突發的流量在交換機端口統計計數的Input peak rate中沒有體現呢？
這是由於交換機上任何報文速率的計算，都是用一段時間內的總報文數除以統計時間獲得的。對於CE系列交換機而言，Input peak rate和Last 300 seconds input rate默認都是按照300s的週期計算的平均值，其中Input peak rate記錄的是歷史上的全部統計週期的平均速率中的最大值。端口統計計數的週期能夠配置，可是最小也只能配置爲10s。
所以，秒級的端口統計計數週期，沒法捕獲到毫秒級的微突發流量，並在端口統計計數的Input peak rate中體現出來。
那麼，爲何端口統計計數的週期最小隻能是10s呢？若是交換機按照10ms的週期統計端口流量，不就能夠捕獲到微突發了嗎？
這是由於端口的報文統計計數須要CPU去輪詢芯片才能得到。交換機的端口數量可能很是可觀（好比多機堆疊+40GE/100GE端口拆分），10ms的週期將致使輪詢很是頻繁，這將極大消耗CPU性能，從而致使交換機響應慢，甚至無響應。
爲何出現微突發時交換機沒有上報緩存超限告警呢？
這是由於交換機要獲取緩存的使用狀況，只能依賴CPU的輪詢機制，這就面臨和端口速率計算相似的問題，CPU不能輪詢太頻繁，不然CPU利用率會升高，從而致使交換機響應慢，甚至無響應。
網管7*24小時不停地監控端口流量，爲何網管上看到的流量曲線很平滑，沒有看到微突發現象呢？
這是由於交換機上報數據的精度、網管監控流量的週期都是秒級，所以精度爲秒級的流量圖沒法展現出毫秒級的微突發流量。
端口當前的利用率不高，速率不大，所以當前的突發也很小。
這是錯誤的理解。平均速率和突發速率的關係，就如同速度與加速度，雖然名字很類似，但並無簡單的線性比例關係。端口的利用率不高，當前速率低，並不表示突發速率就小。
交換機記錄了擁塞丟包計數，因此是交換機引發了突發或擁塞丟包。
這是錯誤的理解。突發流量是由業務終端產生的，除了少許協議報文外交換機不產生其餘流量。可是，突發可能在交換機上加重，例如多端口同時向單端口發送數據，收斂比不合理，致使突發的峯值疊加。因此要從流量來源和組網上着手，尋找突發的源頭。
終端服務器的業務是很隨機的，不會有多大的突發。
業務的隨機性在微觀程度可能體現出很是極端的兩面性。一個極端是時時刻刻都有業務流量，流量整體平穩；另外一個極端是一下子有大量流量高速發送，一下子又空閒下來沒有數據發送，突發嚴重。
業務的隨機性也不等同於TCP發包的隨機性。傳統的TCP在有數據發送且發送窗口未滿的時候，老是想要儘快搶佔帶寬把數據發送完，因此傳統的TCP發包在微觀上突發性廣泛很強。同時服務器的端口帶寬越高，每每突發也就越強。
微突發的影響
當微突發流量的瞬時速率超過交換機的轉發能力時，交換機會將突發的數據進行緩存以便稍後發送。若是交換機沒有足夠的緩存，那麼超出的數據只能丟棄，這就產生了擁塞丟包。
圖22-123 微突發影響

圖22-123是一個典型的毫秒級微突發場景。假設Port一、Port2都以10Gbps的線速速率分別向Port3發送5MB的數據，則總髮送速率爲20Gbps。而Port3的速率爲10Gbps，僅爲總髮送速率的一半，所以只能將一半的數據（5MB）發送出去，另外一半數據（5MB）則須要先緩存起來，待Port3有空閒能力時再發送。這時，因爲交換機只有1MB的緩存，所以會有4MB的數據因爲緩存不足而丟棄。在不考慮幀間隙、前導碼、幀校驗和、報文頭等開銷數據的狀況下，這個突發持續的時間爲5MB/10Gbps = 4ms。
當前交換機整機緩存大小通常爲1～20MB。這樣，對於上述10GE端口線速二打一的場景，最大可承受的突發持續時間 < 16ms（20MB/10Gbps）。在實際的網絡中，不少場景不是二打一而是多打一，所以對緩存的消耗會更嚴重，微突發時產生的擁塞丟包也就會更多。
微突發的檢測方法
能夠藉助捕獲報文軟件和Wireshark軟件來檢測網絡中是否存在微突發。
如圖22-124所示，使用Wireshark軟件打開捕獲報文軟件記錄的捕獲到的報文文件，選擇「統計 > I/O圖表」，就能夠看到流量圖。
圖22-124 使用Wireshark軟件查看流量圖

如圖22-125所示，在IO圖表中，須要將Y軸單位改成Bits，並將間隔改成1毫秒，這樣就能看到毫秒級流量的突發。
圖22-125 Wireshark IO圖表

微突發的應對措施
能夠經過以下幾種方法，來下降微突發的發生，緩解微突發的影響：
針對傳統TCP擁塞控制機制中存在的突發嚴重、過分消耗網絡交換機緩存、有損線路上性能不佳、延時抖動大等問題，採用業界經常使用的改進技術，確保服務器不會過分、過快、突發過強地發包，從根源上減小微突發。
在網絡業務流量規劃時，儘可能避免多打一場景，避免收斂比太高的場景，及時擴容突發嚴重的出端口，消除突發瓶頸。
對於CE12800E、CE5850EI、CE5855EI、CE5850HI、CE5880EI、CE6800系列交換機、CE7800系列交換機、CE8800系列交換機，在轉發設備發生擁塞時，能夠在發生擁塞的接口下執行qos burst-mode enhanced命令配置接口下緩存管理的突發模式爲加強模式，以嘗試緩解網絡擁塞。
在延時可控和緩存充足的狀況下，在發生擁塞的轉發設備的上游交換機下行接口經過qos queue queue-index shaping { percent cir cir-percent-value [ pir pir-percent-value ] | cir cir-value [ kbps | mbps | gbps ] [ cbs cbs-value [ bytes | kbytes | mbytes ] | pir pir-value [ kbps | mbps | gbps ] [ cbs cbs-value [ bytes | kbytes | mbytes ] pbs pbs-value [ bytes | kbytes | mbytes ] ] ] }命令開啓流量×××功能，削弱流量的瞬時波峯，能夠控制突發的程度。須要注意的是，此方案會致使報文轉發時延加大。
網絡中全部設備的接口均經過dcb pfc enable [ pfc-profile-name ] [ mode { auto | manual } ]命令開啓流量控制功能，從而在轉發設備發生擁塞時，通知上游設備下降發包速率甚至中止發包，待擁塞解除之後再恢復報文的正常發送。須要注意的是，此方案會致使報文轉發時延加大。

參考連接：https://support.huawei.com/enterprise/zh/doc/EDOC1000052631/df738486