2021-05-12 14:32:11
Linux高階流量控制工具TC使用方法
2020-06-16 16:58:24
在做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的網路流控，控發不控收 , 所以只能對產生瓶頸網絡卡處的發包速率進行控制 , 流量控制過程分二種
- 佇列控制 即 QOS, 瓶頸處的傳送佇列的規則控制，常見的有 SFQ PRIO
- 流量控制 即頻寬控制 , 佇列的排隊整形， 一般為 TBF HTB
Linux 流量控制演算法分二種：
- 無類演算法 用於樹葉級無分支的佇列，例如：SFQ
- 分類演算法 用於多分支的佇列，例如：PRIO TBF HTB
而涉及到的流控演算法SFQ和TBF都是需要簡單了解的。
SFQ(Stochastic Fairness Queueing 隨機公平佇列 ) 是公平佇列演算法家族中的一個簡單實現 . 它的精確性不如其它的方法 , 但實現了高度的公平 , 需要的計算量亦很少 .
其中SFQ 只會發生在資料發生擁堵 , 產生等待佇列的網絡卡上，出口網絡卡若無等待佇列 ,SFQ 也不起作用 ...
令牌桶過濾器 (TBF) 是一個簡單的佇列規定 : 只允許以不超過事先設定的速率到來的封包通過 , 但可能允許短暫突發流量朝過設定值 .
首先簡單模擬網路超時100ms
使用如下的命令，網絡卡的情況具體對待，修改設定即可。
# tc qdisc add dev eth1 root netem delay 100ms
如果在本機ping測試。延時還是很低的。0.0x級別。
[root@oel642 ~]# ping 192.168.253.129
PING 192.168.253.129 (192.168.253.129) 56(84) bytes of data.
64 bytes from 192.168.253.129: icmp_seq=1 ttl=64 time=0.011 ms
64 bytes from 192.168.253.129: icmp_seq=2 ttl=64 time=0.044 ms
64 bytes from 192.168.253.129: icmp_seq=3 ttl=64 time=0.051 ms
而如果設定了超時選項，就會很均勻的產生指定的延時。
[root@oel643 ~]# ping 192.168.253.129
PING 192.168.253.129 (192.168.253.129) 56(84) bytes of data.
64 bytes from 192.168.253.129: icmp_seq=1 ttl=64 time=202 ms
64 bytes from 192.168.253.129: icmp_seq=2 ttl=64 time=101ms
64 bytes from 192.168.253.129: icmp_seq=3 ttl=64 time=101ms
64 bytes from 192.168.253.129: icmp_seq=4 ttl=64 time=101ms
64 bytes from 192.168.253.129: icmp_seq=5 ttl=64 time=100 ms
取消tc的設定，可以使用
tc qdisc del dev eth1 root netem
如下的方式會產生一個範圍的延時，比如預設延時100毫秒，上下浮動10毫秒。
[root@oel642 ~]# tc qdisc add dev eth1 root netem delay 100ms 10ms
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 eth1 root netem loss 10%
ping的結果如下，可以看到小結的部分，丟包率是基本在10%的基本範圍內，目前是8%。
64 bytes from 192.168.253.129: icmp_seq=421 ttl=64 time=0.486 ms
64 bytes from 192.168.253.129: icmp_seq=422 ttl=64 time=0.413 ms
64 bytes from 192.168.253.129: icmp_seq=423 ttl=64 time=0.616 ms
^C
--- 192.168.253.129 ping statistics ---
426 packets transmitted, 390 received, 8% packet loss, time 425724ms
rtt min/avg/max/mdev = 0.144/64.257/120.621/49.069 ms
如果封包有重複的情況下，該如何處理。比如重複包的比例，我們設定為50%。
>tc qdisc add dev eth1 root netem duplicate 50%
使用ping的結果如下：
PING 192.168.253.128 (192.168.253.128) 56(84) bytes of data.
64 bytes from 192.168.253.128: icmp_seq=1 ttl=64 time=0.402 ms
64 bytes from 192.168.253.128: icmp_seq=1 ttl=64 time=0.409 ms (DUP!)
64 bytes from 192.168.253.128: icmp_seq=2 ttl=64 time=0.788 ms
64 bytes from 192.168.253.128: icmp_seq=3 ttl=64 time=0.887 ms
64 bytes from 192.168.253.128: icmp_seq=4 ttl=64 time=0.721 ms
64 bytes from 192.168.253.128: icmp_seq=4 ttl=64 time=0.757 ms (DUP!)
64 bytes from 192.168.253.128: icmp_seq=5 ttl=64 time=1.33 ms
比如產生壞包的情況。
tc qdisc add dev eth1 root netem corrupt 50%
ping的結果如下：
64 bytes from 192.168.253.128: icmp_seq=51 ttl=64 time=0.468 ms
64 bytes from 192.168.253.128: icmp_seq=52 ttl=64 time=0.822 ms
wrong data byte #23 should be 0x17 but was 0x15
#16 10 11 12 13 14 15 16 15 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
#48 30 31 32 33 34 35 36 37
64 bytes from 192.168.253.128: icmp_seq=53 ttl=64 time=1.71 ms
wrong data byte #53 should be 0x35 but was 0x37
#16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
#48 30 31 32 33 34 37 36 37
64 bytes from 192.168.253.128: icmp_seq=54 ttl=64 time=0.000 ms
64 bytes from 192.168.253.128: icmp_seq=56 ttl=64 time=0.000 ms
如果包是亂序的，我們可以加入隨機性，25%的包立即傳送，其他的包延時10毫秒，系數為50%
[root@oel641 ~]# tc qdisc change dev eth1 root netem delay 10ms reorder 25% 50%
ping的結果如下所示：
64 bytes from 192.168.253.128: icmp_seq=200 ttl=64 time=1.24 ms
64 bytes from 192.168.253.128: icmp_seq=201 ttl=64 time=0.587 ms
64 bytes from 192.168.253.128: icmp_seq=202 ttl=64 time=1.01 ms
64 bytes from 192.168.253.128: icmp_seq=203 ttl=64 time=0.790 ms
64 bytes from 192.168.253.128: icmp_seq=204 ttl=64 time=0.998 ms
64 bytes from 192.168.253.128: icmp_seq=205 ttl=64 time=0.285 ms
64 bytes from 192.168.253.128: icmp_seq=206 ttl=64 time=0.882 ms
如果更複雜的場景呢，比如我們可以考慮加入流量的限制，網速控制在256k，最大延遲為50ms
[root@oel641 ~]# tc qdisc add dev eth1 root handle 1:0 netem delay 100ms
[root@oel641 ~]# tc qdisc add dev eth1 parent 1:1 handle 10: tbf rate 256kbit burst 10000 latency 50ms
速率 256kbit 突發傳輸 10k 最大延遲 50ms
如果不做流量控制，預設的情況下，傳輸可以達到90M美妙。
[root@oel642 ~]# scp 192.168.253.128:~/Percona-Server-5.6.14-rel62.0-483.Linux.x86_64.tar.gz .
Percona-Server-5.6.14-rel62.0-483.Linux.x86_64.tar.gz 100% 93MB 92.9MB/s 00:01
而如果設定了流量控制的場景，就絕對保持在一個指定範圍內。
[root@oel642 ~]# scp 192.168.253.128:~/Percona-Server-5.6.14-rel62.0-483.Linux.x86_64.tar.gz .
Percona-Server-5.6.14-rel62.0-483.Linux.x86_64.tar.gz 0% 208KB 16.8KB/s 1:34:05 ETA
當然上面的場景都需要在測試環境先模擬一下，要不出現意料之外的問題就得不償失了。
本文永久更新連結地址：http://www.linuxidc.com/Linux/2017-12/149703.htm
相關文章