【翻译】Netscaler真实表现性能调整

时间:2024-10-19 20:06:02

源地址:https://msandbu.wordpress.com/2014/10/31/netscaler-and-real-performance-tuning/

作者显然不是以英语为母语的,所以有些地方我看着也比较费劲,但是十分感谢原作者。

=========翻译内容开始=========

昨儿我跟Citrix User Group在挪威一起就Netscaler和性能调整开了个会,45分钟的时间里我也没法说太多关于性能调整的,但是我觉得我还是搞了个大差不离。

下面是会议日程:

TCP概述,多路TCP,路径最大传输单元

SSL概述和调整

自动协商和双工

Netscaler VPX

超大帧和LACP

最后但不是最不重要的移动数据流

除了移动数据流(Mobilestream)和Netscaler后端feature更紧密结合之外,这篇文章的绝大多数是关于Netscaler优化的核心feature。所以我也会写一篇关于移动数据流的博客。

首先是TCP属性。默认情况下,1999年之前,TCP属性是没有被修改过的。所以Netscaler默认情况下是遵循兼容性原则而不是高性能,但是理所当然,这里有很多不同的因素掺和在这里头。比如说,你用的是什么样的架构,丢包的情况,带宽,网络抖动,防火墙等等。

但是主要的事情是,默认的TCP属性是不包含一下几点的:

*激活Window Scaling (Window Scaling对于发送更多的包是很有用的,因为调整窗口大小意味着我们可以更容易的发更多的数据)

*激活Selective Acknowledgement(意味着发生丢包之后,我们不用重传所有的数据,比如,如果你想传的包是12345,但是接收者没有收到3,那就只重传3,而不是345)

*激活Nagle algorithm(先收集更多的数据,直到数据大小达到了MTU上限,然后再发送数据)

举例来说,ICA架构的协议是不那么正式的,它使用比较小的包(使用很多包头)意味着这不适用于常规TCP属性。

nstcp_xa_xd_profile(所有我上面提到的所有feature在这个策略里都被激活)但是当然你也有移动用户在不同WLAN之间跳转或者由于天线问题导致丢包。在默认TCP属性里,会使用TCP reno,当检测到丢包时TCP reno将把拥塞窗口减小一半,这对移动用户没什么好处。

因此Citrix部署了一系列的TCP拥塞处理feature,叫做Westwood+,它将尝试和设备确定当前的带宽,然后根据带宽缩减拥塞窗口。这意味着移动用户可以(在拥塞后)更快的得到更高的传输速度。

现在10.5版本有个选项是激活MTCP(multiple TCP),那么这是什么意思呢,这是针对你的能支持两种天线的设备(一个是移动数据流量一个是WIFI, 你可以同时使用这两个天线),我们可以对同一个设备同时准备两种TCP连接。这就是个策略设置,很容易搞定。

问题是你需要有明确的应用被写入来更改MTCP。

所以进入System –> Profiles –> TCP Profiles (你可以用已有的,也可以创建一个新的)

【翻译】Netscaler真实表现性能调整

勾选Window Scaling

【翻译】Netscaler真实表现性能调整

同时这里也有MTCP(如果你需要的话)SACK还有Nagle。

当然Nagle也有个坏处就是,它会一直等到数据达到MTU的最大值之后,才会通过有线发送(译者:所以移动用户就别用这feature咯?),这样移动用户就会产生丢包,理论上讲,会有很多数据需要被重传。所以对于SQL来说,也不要用Nagle :)

比较cool的是,策略针对各个vServer和service使用,取决于服务的种类大家自行取舍用何种策略。

另外一个事儿是SSL调整, 依然有好几个tips。第一个是quantum size, 默认大小是8KB,意味着Netscaler以8KB为一个单位传送数据到SSL芯片进行加密。我们也可以把这个值调整成16KB,意味着让更多的数据一起被加密。

【翻译】Netscaler真实表现性能调整

所以,对于下载大量文件的时候,16KB的quantum size是比较推荐的。常规的网页(译者:有别于下载页)有很多的小数据在上面,这种情况依然是推荐8KB。

另外还要说一下自动协商和双工, 这玩意儿每个人都盼着它别出事儿,但是...

在一些特定的设备上,依然会出问题,所以你经常得在Netscaler上和交换机/路由器/防火墙上手动设置速率啊双工啊啥的

在VPX上有很多的tips可供调整,但是MPX上就...(译者:作者的意思是在MPX上就特么的呵呵了)

比如说,在VPX上,它支持多包引擎(multiple packet engine),意味着你可以拥有一个特定的引擎专门运行所有不通的策略、处理加密事务等等。对于一个常规的VPX来说,默认有两个虚拟CPU(一个用于管理,另一个用于包处理),所以如果你有一台VPX3000的话(两个虚拟CPU和2GB内存可能不太够用),如果你在用XenServer或者VMware的话,你可以给它加更多CPU和内存来获取更多的包处理引擎。(注意:Hyper-v不支持这个feature,它的上限就是两个虚拟CPU和2GB内存和两个虚拟网卡,也没法加第三个网卡)

当然,如果你正在用Hyper-V和VPX的话,确保你用的是最新的驱动并确保你的VMQ(Virtual Machine Queing)

VMQ的意思是,一个虚拟机在物理网卡上有专门的给VPX使用的队列(queue),如果这个专门的队列挂了,才使用默认的队列,默认的队列平时是和其他虚拟机(译者:估计就是其他平常虚机的意思,比如虚拟的Win7啥的)混在一起的。很多Broadcom的网卡驱动不支持VMQ。

还有要说的就是LACP(网卡teaming,port channel,802.3ad),能使你聚合并你冗余备份你的多张物理网卡(注意这需要在交换机上做设置,并且只有MPX和SDX支持)

还有一些10.5的支持巨型帧(Jumbo frames)的新feature(译者:妈呀!啥又是Jumbo frame), 它允许你把MTU设到9000,这样头部变得相对更小,帧的数据空间更大,节省ACK的次数。

【翻译】Netscaler真实表现性能调整

这个也仅仅支持MPX和SDX,因为VPX依赖你的hypervisor是哪家提供的(译者:比如ESXi就是一种hypervisor)

这个可以在每个接口上设置。但是注意这个需要你的交换机、服务器支持巨型帧,但是注意当进入广域网的时候,这个特性可能就没法正常工作了,因为它可能终结在了运营商的路由器上(绝大多数运营商支持的是默认MTU大小)

但是注意Netscaler也有Path MTU的feature,这让Netscaler可以提前去探测到它要走的路径里最小的MTU是多少。这个feature使用ICMP来确定下一跳最低MTU。问题在于因为它使用ICMP,但是下一跳有可能是防火墙,因此有可能它也没法正常发挥作用。这个特性主要是为了避免网络中的IP分片。

就先说这些,仍然在调试更多的Netscaler特性。 :)

=========翻译内容结束=========

原作者英语也是各种生硬,有很多地方直接意译了,但是十分感谢这个作者。