Linux高级流量控制tc使用

清疚 2022-01-31 07:39 175阅读 0赞

在做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=**101**ms

64 bytes from 192.168.253.129: icmp\_seq=3 ttl=64 time=**101**ms

64 bytes from 192.168.253.129: icmp\_seq=4 ttl=64 time=**101**ms

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

\--- 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

当然上面的场景都需要在测试环境先模拟一下，要不出现意料之外的问题就得不偿失了。

Linux高级流量控制tc使用

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 nginx 流量控制

相关拥塞控制 vs 流量控制

相关 TCP 流量控制

相关 nginx 流量控制

相关流量控制Sentinel

相关 linux 高级路由及流量控制总结

相关控制 Egress 流量

相关 TCP流量控制

相关 Linux下利用TC工具控制网络流量

相关 Linux高级流量控制tc使用