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=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 ^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

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

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2017-11-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏james大数据架构

零代码如何打造自己的实时监控预警系统

概要 为什么要做监控 线上发布了服务,怎么知道它一切正常,比如发布5台服务器,如何直观了解是否有请求进来,访问一切正常。 当年有一次将线上的库配置到了Beta,...

7226
来自专栏Python研发

linux入门总结

linux的核心概念知识:      linux软件是开源免费的,而linux是由Unix演变而成,Unix是由MINIX演变而成。 2000年以后,linu...

1712
来自专栏IT技术精选文摘

如何实现系统的可扩展性和高可用性

概述 可扩展性,高可用性和性能 可扩展性,高可用性,性能和关键任务这些术语对不同组织或组织内的不同部门来说意味着不同的事情。它们经常被互换,造成混乱,导致管理...

98510
来自专栏Android 开发者

[译] 如何用 Android vitals 解决应用程序的质量问题

对于一个应用开发者来说,没有比开心的用户更好的衡量成功的标准,而且最好是有很多这样的用户。实现这一目标的最佳方式是拥有一个人人都想用的优秀应用,不过我们所说的“...

1381
来自专栏张善友的专栏

MongoDB新版本特性

MongoDB 2.4已经发布,该版本增加了一些新特性,如文本搜索、基于哈希的分片、更好的地理空间功能、支持GeoJSON以及一些性能和工具方面的提升。我们还和...

2265
来自专栏Spark学习技巧

解惑:这个SPARK任务是数据倾斜了吗?

健身回来的路上,看到微信群里聊技术,一群有问了一个神奇的问题,具体可以看如下截图:

1742
来自专栏散尽浮华

web cache server方案比较:varnish、squid、nginx

linux运维中,web cache server方案的部署是一个很重要的环节,选择也有很多种比如:varnish、squid、nginx。 下面就对当下常用的...

58510
来自专栏Golang语言社区

系统架构之二(棋牌类游戏常用架构)

棋牌类游戏常用架构: ? 我从事过4年的棋牌类游戏开发,使用过的架构大致如上,各模块解释如下。 LoginServer: 登陆服务器,主要负责player 的登...

6247
来自专栏JAVA高级架构

微服务架构选型实践

背景 随着公司一年多的成长,我们已经开发了数十个项目了,后台有 JAVA 的有 PHP 的,为了更好地提升开发与管理效率,各技术大牛小牛们时常进行激烈的 PK,...

5316
来自专栏社区的朋友们

漫谈分布式集群的负载均衡—口水篇

为了理解分布式集群这个概念,我们先说说这两个概念:“集群”和“分布式”。艺术来源于生活,计算机科学亦是如此。

1.2K0

扫码关注云+社区

领取腾讯云代金券