就好比,租房子的时候,本来合租共享WIFI,但是一个人疯狂下电影,导致Wifi速度下,从而网上不去
在云平台上,利用流量控制的技术,实现Qos,保障大多数用户的服务质量
对于控制一台机器的网络Qos,分两个方向,一个入方向,一个出方向
我们能控制的只有出方向,通过Shaping,将出的流量控制成自己想要的模样,,进入的方向无法控制,只能通过Policy将包丢弃
常见的Qos方式
在Linux下,可以通过Linux的TC控制网络的Qos,但是实质上是利用了队列
无类别排队规则:
第一种为无类别排队规则,我们之前说ip_addr时候,说过pfifo_fast,这是一种不把网络包进行分类的技术
pfifo_fast分为三个先进先出的队列,称为三个Band,根据网络包里面的TOS,看这个包应该进哪个队列,TOS总共四位,总共十六种类型
通过命令行 tc qdisc show dev eth0,可以输出结果priomap,也是十六个数字,在0到2之间,和TOS的十六种类型对应起来,表示不同的TOS对应的不同的队列,其中Band 0优先级最高,然后是Band1,最后是Band2
另外一种无类别的队列规则叫做随机公平队列
建立很多的FIFO队列,TCP Session会计算hash值,通过hash值分配到某个队列中发送,不会有一个Session占据所有的流量
如果两个Session的hash是一样,会共享一个队列,也可能互相影响,hash函数经常改变,不然session不会总互相影响
另一种无类别的队列规则被称为令牌桶规则,TBF Token Bucket Filte
所有的网络包排成队列去发送,但是并不是即时发送,而是必须拿到了令牌才能发送,
令牌根据设定的速度生成,即时队列很长,也是按照一定的速度进行发送的
当没有包在队列的时候,令牌还是一如既往的生成,但不是无限累计的,而是放满了桶为止,设置桶的大小是为了避免下面的情况,当长时间没有网络包发送,积累了大量令牌,而突然来了大量的网络包,如果没有桶的上限,可能导致人人都能得到令牌,流量暴涨
基于类别的队列规则
或者我们基于类别的队列规则
分层令牌桶规则 HTB是其中的佼佼者
HTB往往是一棵树,我将举一个具体的列子,通过TC如何构造一个HTB树来理解
使用TC可以为某个网卡 eth0创建一个HTB的队列规则,付给他一个句柄(1:)
这就是这个树的根节点,可以在下面创建子节点,分别赋给句柄为 (:10) (:11) (:12)
tc qdisc add dev eth0 root handle 1: htb default 12
最后的参数 default 12,表示默认发送 1:12
对于这个网卡,规定发送的速度,可以配置的参数有两个,一个是Rate,表示一般情况下的速度,一个是ceil,表示最高情况下的速度,对于根节点来说,这两个速度是一样的,于是创建一个root class,速度为 rate=100kbps,ceil=100kbps
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
创建分支,也就是创建几个子class,每个子class统一有两个速度,三个分支为
rate = 30 kbps,ceil = 100kbps
rate = 60 kbps,ceil = 100kbps
rate = 10 kbps,ceil = 100kbps
三个rate相加,为整个网卡的最大速度,这就必须要说到HTB的一个特性,一个root class下的子类可以互相借流量,如果不直接在队列规则下创建一个root class,而是直接创建三个class,之间没法互相借流量
我们创建了叶子队列规则,分别为fifo和sfq
| tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5 tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10 |
基于这个队列规则,我们通过TC设定发送规则,从1.2.3.4f发来的包,发送给port 80 的包,从分支1:10走,其他从1.2.3.4发送过来的包从分支1:11,其他走默认分支
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 flowid 1:11
如何控制Qos呢?
OpenvSwitch支持两种
对于进入的流量,可以设置策略Ingress policy
| ovs-vsctl set Interface tap0 ingress_policing_rate=100000
ovs-vsctl set Interface tap0 ingress_policing_burst=10000 |
对于发出的流量,可以设置Qos规则Egress shaping,支持HTB
我们看一下OpenvSwtich的Qos如何工作的
首先,在port上创建Qos规则,一个Qos规则可以有多个Queue
ovs-vsctl set port first_br qos=@newqos — –id=@newqos create qos type=linux-htb other-config:max-rate=10000000 queues=0=@q0,1=@q1,2=@q2 — –id=@q0 create queue other-config:min-rate=3000000 other-config:max-rate=10000000 — –id=@q1 create queue other-config:min-rate=1000000 other-config:max-rate=10000000 — –id=@q2 create queue other-config:min-rate=6000000 other-config:max-rate=10000000
上面的命令创建了一个Qos规则,对应三个Queue,min-rate就是上面的rate,max-rate就是上面的ceil,通过交换机的网络报,要通过流表规则,匹配后进入不同的队列,我们添加流表规则Flow(first_br 是br0上的port 5)
| ovs-ofctl add-flow br0 “in_port=6 nw_src=192.168.100.100 actions=enqueue:5:0”
ovs-ofctl add-flow br0 “in_port=7 nw_src=192.168.100.101 actions=enqueue:5:1” ovs-ofctl add-flow br0 “in_port=8 nw_src=192.168.100.102 actions=enqueue:5:2” |
我们将不同的虚拟机绑上了不同的Queue
三个一起测试,狂发网络包,会发现是按照3:1:6的比例进行的,
按照配置的队列带宽比例分配的
并且 192.168.100.100 和 192.168.100.102一起测试,发现带宽的测试比例为 1:2
这按照了带宽的配置来进行发包的
本章小结:
云中的流量控制通过队列进行的,队列分为两大类,无类别队列规则和基于类别的队列规则
在云中网络OpenvSwitch中,主要使用的是分层令牌规则HTB,将总的带宽在一棵树上按配置的比例来进行分配,并且在一个分支不使用的时候,借给别的分支,增强带宽的利用率
课后思考:
1.入口流量没有办法控制,出口流量没有办法控制,出口流量可以很好的控制的,如何控制云中的虚拟机的入口流量?
2.安全性和流量控制已经解决了,但是不同的用户在物理网络的隔离还是没有解决,怎么办?
1.通过ingress qdisc策略将入口流量重定向到虚拟网卡ifb,然后对ifb的egress进行出口限速,变通实现入口流控,说到底还是使用了SDN的技术
而且,在云平台中,可以限制一个租户的默认带宽,配置点对点的流量控制
在发送方的OVS上,统计发送方虚拟机的网络统计数据,上报给管理面,在接收方的OVS上,收集接收方的虚拟机网络统计数据,上报给管理面
当流量的过大的时候,虽然不能控制接收方的入口流量,但是可以再管理面下发一个策略,控制发送方的出口流量
很多的网关都提供了基于令牌桶的限流,比如Spring cloud gateway
在虚拟机的前一级控制出口流量,前一级的出口流量得到了控制,虚拟机的入口流量也就自然被控制住了
2.对于借出去的HTB流量,能够再抢回来吗?
3:1:6的时候,假如一开始是2个节点疯狂发包占满了带宽,假如第一个和第二个一开始在发,带宽利用率是3:1,后来第三个节点回来了,能够回到3:1:6吗?
自然可以,在一个HTB的树上,有三个分支,在一开始,三个分支都在发送数据,
然后,1的发送停止了.速率匀给了B C,
然后,1的发送重启了,B,C返还了1的流量
这就说明可以进行返还流量的