Linux高階流量控制tc使用

在做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）

1. 佇列控制 即 QOS, 瓶頸處的傳送佇列的規則控制，常見的有 SFQ PRIO

2. 流量控制 即頻寬控制 , 佇列的排隊整形， 一般為 TBF HTB

   Linux 流量控制演算法分二種：

3. 無類演算法 用於樹葉級無分支的佇列，例如：SFQ

4. 分類演算法 用於多分支的佇列，例如：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

當然上面的場景都需要在測試環境先模擬一下，要不出現意料之外的問題就得不償失了。