自从和无盘开始打交道,学到了n多知识,无论是软件层面还是硬件层面,无论是理论还是实践层面,之前很多人认为无盘很复杂,而我也受其“误导”认为无盘很复杂,但实际上用下来发现,其实无盘确实很简单,而所谓的无盘复杂,更多的是理论和经验的结合,以前在网上也看到过很多无盘教程,当时不以为然,不当回事,总觉得自己很牛,可实际上真正的去做了之后,发现自己也在传播这些信息,套用以前某人说过的一句名言“现在很多人的不份,不爽,不以为然,只是为了证明前人的经验是正确的。”
而实际上有这句名言,完全是实践,经验,理论最终的结晶,因为很多时候往往是我们自己在实践中撞了南墙,然后总结经验,当长时间经验累计之后开始好奇,于是开始去搜索,最终发现理论中已经描述了你所实践的,和你所总结的东西。所以今天也和大家分享一些理论知识,大部分来自网络,如有错误,还望大家及时纠正。
既然开头我们提到了无盘,那么今天也是说和无盘相关的一项非常重要的内容,那就是网卡参数设置。我们都知道无盘就是客户机没有硬盘,而无盘实际上就是把客户机的硬盘放在了服务器上,通过一种虚拟化技术来工作的,而在这个虚拟过程中,网卡是非常关键的一环,他就好像有盘客户机的数据线。只是这根数据线远远比SATA数据线复杂的多,不只存在接触好不好的问题,还存在设置好不好的问题,设置好了,速度快,稳定,设置不好,问题也会多样,而复杂。ok,废话终了,进入正题!
既然要说网卡相关的内容,这里不得不替一下传说中的IEEE,IEEE是什么?他实际上是一个组织,并且创立了很多互联网通讯标准,IEEE全名:Institute of Electrical and Electronics Engineers,中文翻译:美国电气和电子工程师协会,比如我们之前听过的“网卡汇聚”实际上就是IEEE创建的一个叫做802.3ad链路聚合的标准协议,再比如我们所说的vlan实际上也是IEEE创建的一个名叫802.3q (虚拟局域网Virtual LANs:VLan)标准协议,如果大家感兴趣,可以百度一下IEEE或802.3相信可以了解很多知识。
上面说的都是IEEE做的一些非常靠谱的事情,其实最近他们也做了一件不是很靠谱的事情,就是发明了一个802.3az节能标准,作用是在网卡没有流量时自动降低功耗,只有网络使用率较高时,才会发挥最大功耗,而这个802.3az节能标准的全名就是Energy Efficient Ethernet,简称EEE,中文翻译是:节能高效以太网技术。他的出现给无盘带来了很大麻烦,只要开启网卡参数中的EEE设置,就可能会导致开机速度慢问题,目前市面上比较新的Realtek的8111E网卡(Rev06)就支持这个节能技术,但是可能因为批次原因,会出现某些网卡如果不关闭EEE选项,开机速度就非常慢,xp滚动条需要6圈以上,关闭后可能变成2圈或者1圈,而有些8111E网卡又不会受影响。这就是今天说的第一个网卡参数EEE。由于该技术还比较新,目前只看到了Realtek网卡配合较新的驱动才能看到该选项,而且也在Realtek官网上看到这么一条新闻。
其中红字标出的,有一句是全球首颗……,是的,EEE存在的问题貌似确实只有Realtek网卡才遇到,或许是第一个吃螃蟹的人总是最先品到美味,也是第一个会受伤的人吧……只是我们这些小白用户真的伤不起……下图为一块Realtek 8111E网卡的设置页,如果你的网卡有EEE选项,一定要关闭噢,当然如果没有就不需要理会了,因为没有这个选项,可以认为网卡不支持EEE。
另外“环保节能”、“GreenEthernet”也和EEE差不多,都属于节能功能,所以都建议关闭,总之在无盘上,和节能有关的功能一定不要开,否则不是速度慢,就是不稳定,因为在无盘上,网卡是不存在“没有流量”的情况的,开了一定会出问题。
这个选项基本上所有网卡都会有,但是叫法会有些差别,比如Realtek网卡叫做流控制,Intel网卡叫做流程控制,还有一些网卡选项干脆是英文的,叫做FlowControl,很多交换机上也有这个功能,也叫做FlowControl,而在下面的理论解释中就简称流控制,这样可以少打一个字。
网卡自身支持的流控制和我们所说的Qos不一样,虽然目的可能是一样的。网卡或交换机支持的流控制也是一个IEEE标准,叫做802.3x全双工以太网数据链路层的流控,因为它是个电子电器标准,所以交换机,网卡这类以太网设备是都支持的,而且也都遵循这个802.3x标准,这个标准的核心作用就是防止网络拥堵时导致的“丢包”问题,大致的工作原理就是当链路两端的设备有一端忙不过来了,他会给另外一端的设备发一个暂停发包的命令,通过这种方式来缓解压力,解决丢包问题。举个吃饭的例子,你自己吃饭,实际上就是有“流控制”的体现,因为你并会出现因为太忙或者怎么样,把饭吃到鼻子里的情况。但是如果你给一个人喂饭,就好比是没有“流控制”的情况,你很可能会把饭喂到别人的鼻子里……
看上去流控制应该是个非常好的防止丢包的方法,但是为什么我们还要在无盘上关闭他呢?原因很简单,因为现在的几乎所有无盘软件都支持“数据包重发”功能,也就是说如果客户机发现有丢包情况,或者服务端发现有丢包情况,都会重新请求,根本不需要网卡再从中间狗拿耗子多管闲事,而也正式因为无盘软件有重发机制,当这种重发机制遇到流控制时就上演了这样一出闹剧:
客户机网卡向服务器网卡要数据时,说:Server快给我下一个数据包!
服务器网卡向客户机网卡发数据时,说:Soryy,我忙不过来了,你吖的等一下,于是服务器暂停了一下。
结果此时无盘软件客户端和客户机网卡说:我靠,数据包咋还没发过来?你再不来我就一直拼命发!
而无盘服务端也问服务器网卡说:我把数据包给服务器网卡了,怎么客户机还没回应?客户机不回应一定是丢包了,于是无盘服务端也拼命的发包给客户机……
就这样,因为流控制,出了问题,因为数据等待问题,客户机卡了,因为无盘服务端始终发不出数据包,结果服务端可能也挂了,而这,就是流控制为什么会影响无盘的原因,所以无论是服务器,客户机,交换机,只要有流控制的地方,就一定要关闭掉!
这个网卡参数基本上也是所有网卡上都有,也会因为网卡品牌不同,叫法不同,比如Realtek就叫巨型帧,Intel网卡就叫巨帧数据包,有些老版本的网卡驱动显示的是英文,叫做Jumboframe。下文中也是为了少打字,就叫巨帧了。
前两个网卡参数提到的参数都是由IEEE创立国际标准协议基础上开发的,而这个巨帧并非一个国际标准,而是通讯设备公司之间自己商定的一个非主流标准,所谓巨帧是一种超长帧格式,专门为千兆以太网而设计,以太网标准的最大帧长度为1518字节,而Jumbo Frame的长度各厂商有所不同,一般最小的有2KB,大一点的有9KB左右。那么这个巨帧有什么好处呢?
拿一个现象来和大家解释吧,相信做无盘的人,都熟悉Hd_Speed这个软件,他是一个测速软件,他的测速选项中有个叫做“块大小”的参数,如下图:
细心的同学一定会发现,同样的无盘,同样的网络环境,如果你测速时选择的“块大小”和测试得出的速度也是不一样的,比如一个用64K块测速值为64MB/S速度的网络环境,使用128K或512K则能达到80MB/S,甚至90MB/S的速度,这个现象其实就是巨帧的原理。
使用巨帧可以有效减少网络中数据包的个数,从而提升传输效率,降低网络设备处理“包头”的而外负担。这就是巨帧为什么能提神光网络传输效率的原因。
相信大家关注过交换机有个参数叫做包转发率,但是并没有限制包大小,也就是大包,小包其实并不会严重影响转发效率,因此,如果单位时间内可以传输多个比较大的数据包,传输数据量自然就会多,而最终软件显示的速度也会变快,以刚才的hdspeed测速为例:
64k块的速度有64MB/S,那么实际上这个网络通道每秒可传输64*1024/64=1024个64K的数据包,假如在没有丢包的情况下,每秒能传输1024个128k的数据包时,网络传输速度理论就能达到128MB/S的速度,也就是翻一倍!
说到这里肯定很多人心动了,赶紧去开巨帧,来提升速度,但是不要忘记,这只是理想状态,而实际上再好的网络也会有丢包,在有丢包的情况下,你单个传输的数据包越大,丢失一个数据包造成的影响也就越大,而带来的问题也就是传输速度月不稳定,所以巨帧如果在“理想环境下”是非常好的技术,如果在不理想的环境下,无疑是一种灾难,同时巨帧并非一个行业标准,而是每家的标准都不大一样,如果使用不同厂家提供的硬件设备,就可能因为存在单个帧长度不同而带来的速度波动严重问题。
而实际上,有哪家网吧能够做到网卡,网线,交换机都是一家厂商出的?实际上没有,因此巨帧对于网吧来说还是关闭的好。
这里给大家一个小经验,Intel 82574L网卡做服务器开4K巨帧,Realtek网卡做客户机开2K巨帧,在使用一些傻瓜交换设备时,测速可能会有一些提升噢,不过这些提升一般不足以优化客户体验,如果感兴趣的同学,可以玩一玩,来加强自己的理解!
上面这些网卡参数本身的功能并不一样,但实际上目的都一样的,或者说是互相合作的关系,首先解释一下大量传送减负,这个选项在Realtek网卡上是存在的。
举个例子,大家知道一个PC上是有一个CPU负责运算的,而一个网卡实际本身也是存在具备CPU运算功能的,所谓的网卡吞吐能力,响应能力实际上就是网卡芯片自身的运算能力的体现。但是在早期,网卡芯片的处理能力是很一般的,所以有些网卡上就有后个选项,具体名字忘记了,大致意思就是网卡性能优化时,是以降低CPU为优化指标,还是以IO性能为优化指标,是上这就是和现在说的大量传送减负作用是一样的,那么大量传送减负,减的是谁的负担?实际上是CPU的负担,如果一旦网卡处理的数据过多时,就会耗费一些CPU资源来做运算,为了降低CPU网络传输速度过快而导致的CPU压力上升,也就有了大量传送减负这个功能,开了他,就会在传输速度过高时自动降速,关了他就会发挥网卡最高性能。
而现在CPU的运算能力不要太好,所以没必要为了降低CPU使用率而去放弃高性能的网络传输速度,这完全是一个过时的功能了。实际上标题里的中断节流率、中断模式的作用个人认为和大量传送减负的作用是完全一样的,都是为了防止网络传输速度过快时而导致CPU使用率上升问题而开发的,比如Intel网卡里这个功能参数就叫做“中断节流率”,而在说明中也详细了解释了这个功能的好处和坏处,见下图:
设定控制器调节或延迟中断生成的速率,以优化网络吞吐量和 CPU 的使用。默认设置(适应性)根据通信量类型和网络使用情况动态调节中断速率。选用另一个设置可能会提高某种配置中的网络和系统性能。
在没有中断调节的情况下,由于系统必须处理大量的中断,CPU 的使用量将以更高的数据速率增加。中断调节使网络驱动器能积累中断,并发送单个(而不是一系列的)中断。在较高的数据速率下,高中断调节设置可能会提高系统功能。在低数据速率下,应选用较低的中断调解设置,因为延迟的中断会导致延迟。
当你的服务器最差也用Xeon 3430,好一点在用Xeon 5506,更牛b的都开始双CPU的时候,你觉得还有必要为了降低CPU鸭梨过大问题,而去降低网卡性能吗?我的答案是:不需要。当然话分两头说,如果你的服务器还是比较烂的CPU,那还是默认不去修改的好,以免上做高峰时,出现服务器CPU使用率高而导致全场秒卡问题,甚至服务端挂掉的问题……
根据自己非常不严禁的测试,关闭该参数,至少可以提升5MB/S的网络传输速度。
罗索了几个小时,终于说到最后一个网卡参数了,从网卡参数描述上,基本大家都能明白,这是一个效验功能,他的作用也不用多说,实际上就是为了防止在网络环境不好的情况下,解决数据包损坏,丢帧的问题。在这里又要引入2个概念,就是传说中的TCP和UDP,相信大家对名词非常熟悉,那么他们有什么特点相信不是所有人都了解的,至少正在写文章的我,也不能准确无误的表达清楚,所以百度了一下TCP和UDP的特点:
TCP:传输控制协议,提供的是面向连接、可靠的字节流服务。
当客户和服务器彼此交换数据前,必须先在双方之间建立一个TCP连接,之后才能传输数据。TCP提供超时重发,丢弃重复数据,检验数据,流量控制等功能,保证数据能从一端传到另一端。
UDP—用户数据报协议,是一个简单的面向数据报的运输层协议。
UDP不提供可靠性,它只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接,且没有超时重发等机制,故而传输速度很快。
当然TCP和UDP远远不只上面描述的那么简单,不过我们毕竟不是搞研发的,懂得道理就行,用我自己的话描述就是:
TCP是个非常靠谱的人,和你说话一定要让你从头到尾都听明白,听清楚,确保沟通无误;
而UDP就是个不太靠谱的人,我说我的,你听你的,我说完了就行,至于你听懂还是没听懂,和我一毛钱关系都没有。
所以,TCP因为罗索速度慢,但是可靠,而UDP因为不罗嗦,完成任务就OVER,所以速度快!
那这个TCP、UDP和效验啥关系呢?很简单,TCP协议本身就有效验功能,并不需要网卡在中间搞一道,即便需要效验,也是UDP需要效验,防止传输过程中出现坏包导致的数据损坏问题,TCP完全不需要,而在无盘上来说,只要开机之后,每个数据包都是非常关键的,因此大多数无盘都会采取TCP协议来保证可靠性,所以并不需要这个效验功能,同时,做包效验也是好要耗费资源运算的,说恶劣一点,为了这样一个画蛇添足的功能而去浪费宝贵的资源,纯属一种浪费!所以无盘上,带有效验字样的网卡参数完全可以关闭掉!
不过话说回来,做人做事,不能做的太绝,就像说话一样,也不能说太绝,这个效验功能虽然看上去绝大多数情况下,是百无一用,但是能说它百无一用是在了解他的特性之后,比如,如果是使用UDP协议的软件,可能在网络状况较差的情况下,不开启效验功能,就可能导致出问题!
好了,罗索了这么多,还是要说一句,任何产品的任何功能都是在特定的环境下产生的,为了满足特定的需求产生,所以理论上任何一个功能在功能自身来说都是有用的,至于是否需要用就要取决于环境,打个比方,刀和枪在战争中都会用到,但是在暗杀时,你用枪很容易暴露,但是用刀就一定成都上可以保证不被人发现,额,这个例子有点血腥,你也可以理解为切西瓜,用刀肯定比用枪好……
今天就到此为止了,上面大部分内容是来自网络说明,文案充足由博主完成,当然也带有博主一些非常流氓的比喻,可能不恰当,引起大家误会,所以如果有不懂,或者有说错的地方,希望大家海涵,并提出批评或纠正意见,谢谢!
附上一张来自网维知识库的网卡参数设置说明,这个设置服务器和客户机通用:
原文链接:http://bbs.icafe8.com/forum.php?mod=viewthread&tid=280990&page=1#pid1523072