首頁 > 系統 > Linux > 正文

Linux高級流量控制tc運用

2022-07-16 17:15:32
字體:
來源:轉載
供稿:網友
  在做MHA測試的時候,有一個重要的環節就是測試MHA Manager節點和Master節點的網絡情況,如果產生了抖動,那么MHA本身提供了一個參數secondary_check來保證,但是如果你的部署環境中是一主一從的話,這個參數就不會起作用了,因為latest slave和oldest slave是同一個庫,簡單來說,連不上就是連不上了,至于切還是不切,這個還不好說。我們測試的場景下,有時候切,有時候不切。所以我們原本測試的MHA0.57版本就降級為了0.56,仔細測試發現,其實也存在這樣的問題,綜合再三,我們就把secondary_check給取消了,直接在MHA的代碼里調整了超時次數的配置(默認是4次)。
 
  接下來的問題來了,如果做更深入的測試,我們勢必需要完整的模擬網絡的抖動情況,這個時候傳統的service network stop ; sleep xxx; service network start的方式就會受限了。潛在的一個原因就是重啟服務以后,VIP就沒有了。
 
  但是基本能夠模擬出MHA的場景,保證在指定的時間范圍內出現抖動而不會誤切。
 
  所以經過全方位的測試,我們心里有底了,那些方面該怎么調整,那些細節需要繼續深究,都有了一些心得和體會。
 
  但是網絡的測試其實感覺還是不夠徹底,畢竟真實的網絡抖動不會網卡不可用,而是網絡超時,丟包等等。
 
  所以如果能夠盡可能模擬出網絡問題,配合MHA來聯調測試,就能夠基本模擬出真實的問題場景了。所以tc這個方案就進入了我的視線。
 
  Linux的網絡流控,控發不控收 , 所以只能對產生瓶頸網卡處的發包速率進行控制 , 流量控制過程分二種(以下內容參考自https://www.ibm.com/developerworks/cn/linux/1412_xiehy_tc/index.html)
 
  隊列控制 即 QOS, 瓶頸處的發送隊列的規則控制,常見的有 SFQ PRIO
  流量控制 即帶寬控制 , 隊列的排隊整形, 一般為 TBF HTB Linux 流量控制算法分二種:
  無類算法 用于樹葉級無分支的隊列,例如:SFQ
  分類算法 用于多分支的隊列,例如:PRIO TBF HTB
  而涉及到的流控算法SFQ和TBF都是需要簡單了解的。
 
  SFQ(Stochastic Fairness Queueing 隨機公平隊列 ) 是公平隊列算法家族中的一個簡單實現 . 它的精確性不如其它的方法 , 但實現了高度的公平 , 需要的計算量亦很少 .
 
  其中SFQ 只會發生在數據發生擁堵 , 產生等待隊列的網卡上,出口網卡若無等待隊列 ,SFQ 也不起作用 ...
 
  令牌桶過濾器 (TBF) 是一個簡單的隊列規定 : 只允許以不超過事先設定的速率到來的數據包通過 , 但可能允許短暫突發流量朝過設定值 .
 
  ping的結果如下:
 
  64 bytes from 192.168.253.129: icmp_seq=278 ttl=64 time=98.3 ms
 
  64 bytes from 192.168.253.129: icmp_seq=279 ttl=64 time=99.1 ms
 
  64 bytes from 192.168.253.129: icmp_seq=280 ttl=64 time=93.4 ms
 
  64 bytes from 192.168.253.129: icmp_seq=281 ttl=64 time=95.5 ms
 
  還有幾類網絡情況需要考慮,比如丟包。在流量劫持的場景中,丟包率是一個需要重點關注的場景。
 
  我們可以玩得大一些,丟包率10%,那是比較嚴重的問題了。
 
  [root@oel642 ~]# tc qdisc add dev eth2 root netem loss 10%
 
  ping的結果如下,可以看到小結的部分,丟包率是基本在10%的基本范圍內,目前是8%。

(編輯:錯新網)

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
金玫玫床戏