拓展:QoS的底层是tc,其目的就是决定先发送哪些包。openwrt默认的规则是hfsc,设计了四个优先级:最高、高、普通、低 。
说到openwrt,就不能不提一下QoS。尤其是如果你需要用P2P软件(目前对迅雷的支持还不大好),基本就不能不开QoS。QoS的全称是Quality of Service,意即服务质量。是专门用于解决拥堵网络上的信号质量一视同仁的问题。例如,我们有一根宽带,两人共用。一个人视频聊天,一个人bt下载(我还不提迅雷个傻X呢)。玩bt的那个一开软件,视频聊天那个立刻没法用了。bt和视频聊天稍微好一点的是,视频聊天消耗的带宽是恒定的。你可以逐步限速,只要给视频聊天留了足够的带宽,两个就都能一起用了。但是,如果另一个人不是视频聊天,而是网络浏览怎么办?网络浏览,视频聊天,p2p下载一起来怎么办?实际上这是很多朋友家中常常碰到的情况。更不说有合租公寓里面你很难监控对方一定限速,软件无法限速甚至恶意抢占带宽(迅雷)。另一个更加技术的问题是,由于上传带宽不足,ACK包回应过慢,导致你的下载速度也不能达到峰值。玩p2p的常常会给上传限速到真实带宽差一点的位置,下载带宽立刻上去,就是这个道理。
怎么办?用QoS,解决你多年老便秘。QoS的底层是tc,其目的就是决定先发送哪些包。openwrt默认的规则是hfsc,设计了四个优先级。Priority最优先,处理22,53,icmp,以及小于128字节的syn,ack包中,不属于bulk类别的。我们可以看到,DNS,syn/ack的优先响应,保证了你的上传不会影响下载。其次是Express,处理5190和小于500字节的UDP包。这个我也不明白是为什么,好像是视频什么的。然后是Normal,包括20,21,25,80,110,443,993,995这些常见端口。涵盖http/https,ftp,邮件系统。最后是Bulk,包括其他包,尤其是ed和bt。
当你启用QoS后,你的p2p软件速度应当不会上升,反而会下降。下载速度不好说,有可能是上升,也有可能下降。因为原来p2p软件抢占了所有带宽,目前他们只能使用普通应用用剩下的带宽,速度当然慢了。然而,当你使用浏览器,收发邮件的时候,速度应当和不使用p2p的时候一样流畅。这才是使用QoS最大的意义。
方法很简单,安装QoS包,然后修改/etc/config/qos,注意修改你的带宽。不修改的话,流量会被无意义的限制死。
另外,打开QoS后,千万记得把你的p2p软件改为不限速。否则不能达到,要完成自定义QOS,需要先把tc,iptable, htb算法, opendpi , xt_recent 这些都搞清楚,起码基本的命令都会用。否则就看看热闹好了。
命令很多人都懂,我就主要讲下思路。tc的流量控制很准确,前提是要对tc,htb有足够的了解。htb的分类主要以openwrt原版qos为基础,上传增加一个第五类。iptables的设置,也是以openwrt的原版为基础,将l7-filter换成opendpi作七层识别,并作了一些小改动来符合我的需求。
这是上传500kbit带宽的分类情况, 1:10是游戏, 1:20是dns, tcp syn,tcp ack ,ssh,QQ语音之类的, 1:30是网页、virtual**、代理、rdp,1:40是BT,迅雷,PPS和其他未分类,包大小小于300的流量,1:50是BT,迅雷,PPS和未分类,包大小大于300的流量。
下载也作了tc和iptable的配置,不过相对来说没那么重要,就不帖了。主要思路跟上传差不多,没用imq而是用了ifb模块,也就是上传和下载都在同一个interface(即出口)上整形。好像ifb是在iptable之前,具体有空测试一下,所以iptable对下行来说也不重要了,但对于七层识别还是有点用,所以也加上了,openwrt的原版QOS在iptable中是不对下行作mark的。
按这个速率设定来用的话,开下载的同时,游戏的延迟是可以保证的。当然最重要的是在iptable 上把流量用mark分好类,我的分类是按端口和七层识别同时用,比如22,80,53都可以按端口来设,虽然有些应用也会用这些端口,但一般没多大影响。除非有特意改端口的,有影响了,那可以都用七层识别来做。opendpi在七层识别方面还是不错的,openwrt的开发者在几个月前已经开始计划用opendpi换掉l7-filter,不知道最近进展如何。不过我们可以自己编译到openwrt里。
另外,很多QOS的设定都会推荐限制连接数,我没有做方面的限制,至少在我这里没有什么问题。测试3M下行,500k上行的时候迅雷开了3个种子,基本满速,上行还有富余,游戏延迟没问题,QQ语音同时连3个人流畅。 测试20M下行,1M上行的时候,迅雷开20个种子,下行不满速,上行已经满了,迅雷上传显示0,游戏延迟没问题,QQ语音同时连3个人流畅。
原文地址:https://www.tinymind.net.cn/articles/98e64d56d38a52
笔者之前也分享过vSAN延伸集群的一些资料。在双活的设计中,站点之间带宽预估、脑列处理等问题,都是需要重点考虑的。本次向大家分享一下vSAN带宽带宽的设计原则。建议读者参照此前我分享过的《VMware的灾备与双活----我在vForum 2015分会场的分享(2)》一起进行阅读,这篇文章中已经包含的内容,本文将不再进行赘述。
一. 总体架构
vSAN延伸集群整体架构如下:一个有三个故障域,两个数据站点分别是一个故障域,仲裁站点是一个故障域。需要注意的是,vSAN延伸的三个故障域都属于是一个vSAN集群,而不是三个。
二.常规建议
两个数据站点之间的带宽很大程度上取决于vSAN承担的负载、总体数据量、可能的故障场景。
通常的建议参考如下:
(1)vSAN的数据站点之间,或者数据站点和仲裁站点之间的网络,二层和三层网络都可以支持,这降低了对大二层的要求。但是,我们推荐在数据站点之间使用二层网络。
(2)数据站点站点之间小于5ms之间的延迟(RTT)。数据站点与仲裁站点之间200的延迟不能超过200ms。
(3)数据站点和仲裁站点之间的带宽最不小于50-100Mbps.
(4)网络划分
管理网络:连接三个站点。二层或者三层网络
vSAN网络:连接三个站点。数据中心之间建议二层网络,与仲裁站点之间使用三层网络。
VM network:连接数据中心。建议二层网络,这样当虚拟机从一个数据站点vMotion或HA到另外一个数据站点时,IP地址不变。
vMotion网络:连接数据中心。二层,三层网络都可以。
三.数据站点之间的带宽需求
1.计算公式
在真实的业务场景中,全读或者全写的情况很少。更多的时候,用读写比率来衡量业务I/O特性是比较格式。以VDI场景的负载举例子。在负载峰值的情况下,读写比率通常是3:7。
例如:业务需要求IOPS的总量是10万,读写比率为3:7。由于vsan延伸集群本地读的特性,读操作不需要跨站点,因此考虑数据站点之间带宽只考虑跨站点写即可。
数据站点带宽计算公式是:
B=Wb md mr
B:Bandwidth。数据站点之间的带宽。
WB:Write Bandwidth数据站点之间的写带宽。
MD: Data Multiplier:数据乘数
MR:Resynchronization multiplier 再同步乘数
其中,数据乘数由vSAN元数据跨站点写开销等相关的操作组成的(除了数据意外,元数据也需要跨站点写)。VMware建议将这个数值设置为1.4。
再同步乘数指的是数据站点之间同步事件(例如vSAN组件的状态信息)的所需要的总开销。这是数值VMware建议设置为1.25。再同步乘数和数据乘数其实都是跨站点写数据的额外开销。这两个数值使用vSAN推荐值即可。
2.案例分析
案例1.
vSAN运行一个IOPS为1万的全写负载业务。写的block为4KB。这需要消耗40MB/s的数据站点间的带宽(4KB*10000),也就是320Mbps。
按照上一小节的计算公式:
B=320Mbps 1.4 1.25=560Mbps
因此,在这个负载情况下,vSAN数据站点之间需要的带宽至少应为560Mbps。
案例2.
vSAN运行负载为3万全写IOPS,4KB block size,这需要120MB/s(960Mbps)跨站点写数据吞吐量。
按照公式:
B=960Mbps 1.4 1.25=1680Mbps约等于1.7Gbps.
因此,在这个案例中,数据站点之间的带宽至少应为1.7Gbps.
四.数据站点与仲裁站点之间的带宽需求
1.计算公式
数据站点并不存放虚拟机的数据,只是用于投票使用,因此数据站点与仲裁站点之间的带宽计算公式与上面的不一样。
我在之前的文章提到过,vSAN是基于策略驱动的分布式存储。数据是以对象的方式存储在vSAN中的,一个VM在vSAN存储中的数据由一个或者多个组件组成,组件有如下类型:
VM Folder
VMware swap file
VMDK
快照
在vSAN中,当一个对象的大小大于255GB的时候,就会被自动划分成多个组件。仲裁站点与数据站点之间的计算公式如下:
1138B*NumComp/5seconds
其中,1138B这个数字是:当主站点down,备站点接管所有组件所需要的时间。我们想象一下,当主站点down,备站点将成为master。仲裁站点将会向新的master发送确认信息,确认master的角色已经发生了变更。从本质上讲,1138B是当主站点down以后,仲裁站点需要从元数据信息中获取主站点上所有组件已经failed并且随后由备站点take ownership的状态信息更新开销。当主站点down以后,仲裁站点与数据站点之间的带宽应足以让集群中所有部件的master ownership变更在5秒内发变更完成。
2.案例分析
案例1:
虚拟机由如下内容组成:
三个对象:
VM namespace
VMKD(小于255GB)
VM Swap file
FTT=1
Stripe width=1
以上配置的虚拟机数量是166个,那么仲裁站点就需要获取到996个组件信息。996=3 2 1*166.
我们用1000进行计算:B=1138B 8 1000/5s=1820800bps=1.82Mbps
VMware推荐预留10%的额外带宽用于信息双向传输:1.82*1.1=2Mbps。因此,在这个场景下,数据站点与仲裁站点的带宽应为2Mbps。
案例2:
虚拟机由如下内容组成:
三个对象:
VM namespace
VMDK(小于255GB)
VM Swapfile
此外:
FTT=1
Stripe width=2
如果具有以上配置的虚拟机数量为1500,那么仲裁站点将会维持18000个组件的状态信息。3 2 2 1 1500=18000
按照案例1中的算法:
B=1138B 8 18000/5s=32.78Mbps
B*1.2=36.05Mbps
因此,在这个场景下,数据站点与仲裁站点之间的带宽需要36.06Bbps。
根据上面的算法,可以提炼一个简单的公式用于在日常的评估,那就是2Mbps带宽可以维系1000个组件的状态信息。因此,在这个场景下,维系18000个组件,所需要的带宽是:18000/1000*2Mbps=36Mbps。
七.2-Node vSAN配置仲裁站点的带宽
在vSAN6.1中,支持2节点的vSAN集群。也就是我在<VMware的灾备与双活----我在vForum 2015分会场的分享(2)>中提到的vSAN延伸集群最小1+1+1,最大15+15+1的配置。
案例1:
2-Node配置中的虚拟机特性如下:虚拟机数量:25;VMDK/VM:1TB;FTT=1;Stripe width=1
上面我们提到过,vSAN中,一个vmdk组件最大为255G,因此每个VMDK由4个组件组成,此外由于FTT=1,在包含副本的情况下,每个vmdk由8个组件组成。加上VM namespace和swap文件(有副本),那么一个虚拟机的组件总数为12=4 2+2 2。25个虚拟机组件总量为300=25 12。
使用通用公式:300/1000 2Mbps=600Kbps。因此,在这种场景下,数据站点与仲裁站点之间的带宽应为600Kbps。
案例2:
在2-Node配置中,每个主机上有100个虚拟机,每个虚拟机有1TB的VMDK,FTT和stripe width均为1。 那么,组件的总量为:(1000/255+1+1) 2 100(VMs) 2(Hosts)=2400
按照通用公式,2400个组件,需要的带宽为2400/1000 2Mbps=4.8Mbps。因此在这个场景中,仲裁站点到数据站点之间的带宽需要4.8Mbps。
需要注意的是,如果一套vSAN延伸集群承担多个类型的业务负载,那么需要把这些业务负载先单独计算其需要的带宽,然后将其累加在一起。
带宽是一个非常有用的概念,在网络通信中的地位十分重要。本文中带宽的实际含义是在给定时间等条件下流过特定区域的最大数据位数。虽然它的概念有点抽象,但是可以用比喻来帮助理解带宽的含义。把城市的道路看成网络,道路有双车道、四车道也许是八车道,人们驾车从出发点到目的地,途中可能经过双车道、四车道也许是单车道。在这里,车道的数量好比是带宽,车辆的数目就好比是网络中传输的信息量。我们再用城市的供水网来比喻,供水管道的直径可以衡量运水的能力,主水管直径可能有2m,而到家庭的可能只有2cm。在这个比喻中,水管的直径好比是带宽,水就好比是信息量。使用粗管子就意味着拥有更宽的带宽,也就是有更大的信息运送能力。假如你单位已经安装了宽带业务,或小区宽带已经连到你家,现在你准备下载一个程序、一个网页或一部电影。也许你认为正在使用服务商声称的全部带宽,其实不然,这就不得不涉及到另一个概念——吞吐量。 吞吐量是指在规定时间、空间及数据在网络中所走的路径(网络路径)的前提下,下载文件时实际获得的带宽值。由于多方面的原因,实际上吞吐量往往比传输介质所标称的最大带宽小得多。
影响网络中带宽和吞吐量的主要因素有:
1)网络设备(交换机、路由器、集线器); 2)拓扑结构(即网络构造形状,如星型、环状); 3)数据类型; 4)用户的数量; 5)客户机与服务器(如系统总线、磁盘性能、网络适配器、硬件防火墙); 6)电力系统和自然灾害引起的故障率。 当设计一个网络时,应该重点考虑带宽的理论值,即在给定的条件下,理论上所具备的最大数据传输位数。设计的网络的速度应与介质所允许的速度相当,让用户使用网络时,应该考虑的是吞吐量,即用户是否满意实际获得的带宽值。当构建网络时应考虑的重要因素是介质的选择,这又和用户所需要的文件下载量有关,文件越大,需要的时间越多。有一个公式:预计下载时间=传输文件尺寸/带宽。在不考虑影响带宽的各种因素下,根据此公式可以粗略估计已选择的介质传输文件所需要的时间。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)