Tag: lvs

2.6.29 – 2.6.39 之间的 kernel 不要在 LVS Director 的网卡开启 GRO

我之前开发了一个传图系统,直接使用了 @agentzh 的 lua_resty_upload (其实这里不应该用 nginx_lua 做的),但发现其在 LVS 下,POST 请求总是 socket timeout ,而直接 POST 到 real server 没有问题。无奈我当时只好用 DNS 轮训的方式,终于在最近找到原因了。

Linux 在 2.6.29 的时候,引入了一个 GRO (Generic receive offload) 。

MTU 一般都是 1500 字节,如果一个包超过了 MTU ,就会被分片。1500 这个数字,估计是基于当时的网络环境制定的,而现在,10Gbps 的网卡都普遍使用了,可能就不太适用了。如果 10Gbps 的网卡满载地来跑,一个完整的数据包会被分片 800w 片。我们可以通过调整 client 和 server 端的 MTU 令到分片尽可能减少,提高吞吐量。但是,如果 client 端(例如用户)不受我们控制呢,那我们就无法提高性能了。于是有人想到通过网卡的行为来间接实现相当于提高 MTU 的作用,这就是 GRO [1] 。

GRO 就是在网卡中将满足一定的条件(比较严格)的包,将分片的包组装合并了,才一次性交给上面的协议栈。现在的网卡一般都支持了,除了网卡支持,还要驱动也支持才可以。如果网卡和驱动都支持,那么在 2.6.29 以后的 kernel ,都会默认开启。

ethtool -k eth0 ,来查看是否有 generic-receive-offload: on ,如果是 off ,也不一定是不支持,可以通过 ethtool -K eth0 gro on 来尝试开启。

但是 GRO 和 LVS 协作得并不好,具体表现就是,POST 数据到 LVS 很慢。

抓包看我的 POST 请求,握手阶段用了较长时间,出现了数次 incorrect 后才真正开始传输。POST 小于 MTU 的数据,并不会触发这个问题,而 POST 大于 MTU 的数据,就会。证明了这里肯定是 GRO 惹的祸。

没有 google 到最根本的原因,但也有一些说法 [2] ,就是 GRO 和 LVS 之间的兼容没有做好,知道 2.6.39 已经修复了这个问题。

经验主义一点,就是 LVS 的 director 一律关闭网卡的 GRO 。

ethtool -K eth0 gro off

这个情况我遇到的,一般发生在内网 POST 的时候,而用户 POST 给我的情况太慢的不太多,也有可能是他们网络根本就慢,手机的网络环境变数太多,而我暂时也没有办法把他们过滤出来一一查看。我猜想,是因为内网的网络环境正好符合了 GRO 的 merge 的条件,GRO 起作用了,所以我的 POST 很慢。而用户的请求不符合条件,所以还是比较正常的。

 

 

Reference:

[1] http://lwn.net/Articles/358910/

[2] http://archive.linuxvirtualserver.org/html/lvs-users/2011-05/msg00004.html

ubuntu 下的lvs tunnel real server 配置注意

来个速记。

以前就因为一次内网调整,使用了一次lvs 的tunnel 模式,后来都没有配置过了,今天因为要配置外网的lvs ,再次弄了一下,才发现要注意一下了。

DR 模式下的rs 配置一般如下:

/sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
echo “1” >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/lo/arp_announce
echo “1” >/proc/sys/net/ipv4/conf/all/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/all/arp_announce
tunnel 的话,可以改成这样:
/sbin/ifconfig tunl0 $VIP broadcast $VIP netmask 255.255.255.255 up
echo “1” >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/lo/arp_announce
echo “1” >/proc/sys/net/ipv4/conf/all/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/all/arp_announce
直接执行的话,可能会出现以下错误(反正那个死人坑爹的ubuntu 出现了!!!还是得找机会换了它。。。)
SIOCSIFADDR: No such device
tunl0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
竟然不能建立tun 设备!!
好吧,tun 设备作为module 了,没有编译进去内核@@
modprobe ipip 即可。

tcp 内核参数对NAT 用户的影响

非原创,前同事参详出来的,我知道一下原因,但今天遇到了,决定mark 一下。

故障现象:

NAT 用户,也就是使用同一个出口ip 的那些用户,例如,使用办公网络的用户。NAT 用户访问网站时,表现为连接不上,技术一点说,就是建立不了tcp 握手。

很奇怪吧?同一个网络的用户,我可以访问,旁边的同学就不能访问。难道是RPWT 吗?

在网上可以搜到一个很普遍的系统优化方法,修改/etc/sysctl.conf ,添加

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_tw_reuse = 1

sysctl -p 让内核参数生效。

以前大家通常会遇到netstat 看到很多 TIME-WAIT 状态的连接,于是就会添加以上两句,加速回收TIME-WAIT 的资源。

但是这个优化现在已经行不通了。

为了提高TCP的性能,“RFC1323 – TCP Extensions for High Performance”提出了 一个机制(http://tools.ietf.org/html/rfc1323#page-29)来替代TIME- WAIT状 态的功能。linux 实现了它。这个机制通过记录来自每台主机的每个连接的分组时间戳来实现,要求 来自同一主机的同一连接的分组所携带的时间戳要比之前记录 的时间戳新,以便 “防止回绕的序号PAWS机制“ (http://tools.ietf.org/html/rfc1323#page-17) 丢弃接收属于旧连接的延时分组。这依赖于来自每个主机的每个 TCP连接分组所携 带的时间戳要单调递增才能实现。然而经过NAT的连接,其分组携带时间戳每个用户都不同的(甚至有人写了个论文,利用这个分组的时间戳来计算NAT 后端有多少台主机 http://phrack.org/issues.html?issue=63&id=3#article),也就是说同一个ip ,携带的时间戳不会单调递增。服务器端对同一个ip 过来的包的timestamp 做一个验证,导致这些连接分组被认为是属于旧 连接的延时分组而被丢弃。

具体有多少被drop 的包呢??请看 netstat -s 的其中一行

7439 packets rejects in established connections because of timestamp

为了防止这种情况呢,也很简单,修改一下内核参数,把 /proc/sys/net/ipv4/tcp_tw_{reuse,recycle} 的值都置为 0 吧。

kernel 2.6.32 的服务器作为lvs 的rs 无法建立tcp 连接的问题

最近用xen 的虚拟机作为lvs 的rs 组了一下lvs ,发现上线以后,无法与client 建立tcp 连接,开始还以为是xen 的bridge 网络的问题,后来才把问题定位到系统内核。其实之前也出现过类似的问题的,但当时急着上线,没去研究了,这回太忙,连测试环境都搭出来了,也都没空去深究,今天同事帮我测试了一下,倒是完全明白了。

问题描述:

LVS 用dr 的方式组起来以后,访问vip 时,无法与real server 建立tcp 连接。tcpdump 看到只有client 过来的syn 包,rs 并不返回ack 包,根本无法完成tcp 握手。用curl 来模拟访问测试的话,会看到这样的返回 curl: (7) couldn’t connect to host 。

看看我的配置吧。

lvs director :

采用dr 的调度方式,通过内网把请求分配到real server

lvs 的 real server :

内核为 2.6.32-5-amd64 (2.6.32 这个内核很普遍了,debian 6 和 rhel 6 默认都这个了),不响应arp 配置

echo “1” >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/lo/arp_announce
echo “1” >/proc/sys/net/ipv4/conf/all/arp_ignore
echo “2” >/proc/sys/net/ipv4/conf/all/arp_announce

其它基本的配置就不说了,如果就这样子起服务后,就会出现我描述的问题了。

原因在于内核的这个参数 : reverse path filtering,这个是啥,我摘抄一下:

Reverse Path Filtering (RPF) is a technology that is used on InternetProtocol routers to try and prevent source address spoofing, which is often used for DenialOfService attacks. RPF works by checking the source IP of each packet received on an interface against the routing table. If the best route for the source IP address does not use the same interface that the packet was received on the packet is dropped. There are some situations where this feature will obviously not be the desired behaviour and will need to be disabled. In general if you are not multi-homed then enabling RPF on your router will not be a problem.

简单地说,就是如果从eth1 接收到包,就不会从eth0 返回,内核把这个包丢弃。

正好我们的LVS 就是这样的服务模式,lvs director 接收到client 对vip 的访问,经过包的重写通过内网把包分配给rs ,rs 直接使用外网返回这个client 的请求。正好就会被rp_filter 给干掉了。

但是,为什么我们以前并没有出现过类似的问题呢??看看rp_filter 的默认内核配置

net.ipv4.conf.eth1.rp_filter = 1

net.ipv4.conf.eth0.rp_filter = 1

net.ipv4.conf.lo.rp_filter = 0

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.all.rp_filter = 0

rp_filter 的值的意义是:

814 rp_filter – INTEGER

815 0 – No source validation.

816 1 – Strict mode as defined in RFC3704 Strict Reverse Path

817 Each incoming packet is tested against the FIB and if the interface

818 is not the best reverse path the packet check will fail.

819 By default failed packets are discarded.

820 2 – Loose mode as defined in RFC3704 Loose Reverse Path

821 Each incoming packet’s source address is also tested against the FIB

822 and if the source address is not reachable via any interface

823 the packet check will fail.

0 就是对进来的包完全不作检查,这样有被dos 攻击的风险。

1 就是严格检查,只要不是这个interface 的包,就不返回。

2 就是不太严格,只要本机配置了这个ip ,还是可以返回的。

对于lvs 来说,用2 也是可以的。

只要把eth1 的 rp_filter 的值置为 0 ,lvs 的服务就能正常了。

从这里可以找到答案:http://www.spinics.net/lists/linux-net/msg17162.html

The first patch changed rp_filter from a boolean to an integer, and the

second patch changed the way the interface-specific value and the “all”

value are combined to produce a functional value from a logical AND to

an arithmetic MAX.

Before patches : functional value = interface AND all

After patches  : functional value = MAX(interface, all)

So now if net.ipv4.conf.all.rp_filter=1, source validation is enabled on

all interfaces as their functional value is at least 1. You may either

set net.ipv4.conf.all.rp_filter to 0 (to disable it) or 2 (to enable

loose mode globally), or set net.ipv4.conf.$interface.rp_filter to 2 (to

enable loose mode on $interface).

I guess that the patch suggested by Dave Miller is related to another

(apparently incomplete) change that occured in 2.6.32 :

在2.6.31 , 对于rp_filter 的最终值,有了不同的计算方法。

之前,是只要设置了all.rp_filter 为0 ,那么就是0 了。

之后,看具体的interface 和 all 的值的最大值来取最终值。

默认是 net.ipv4.conf.eth1.rp_filter = 1 和 net.ipv4.conf.all.rp_filter = 0 ,因此,组lvs 的时候,就会丢弃包了。

问题解决!!下次调一下内核参数吧。

PS:可以通过设置这个内核参数来查看一下log

echo 1 >/proc/sys/net/ipv4/conf/<interfacename>/log_martians

LVS hash size

LVS 有个 connection hash table ,默认的 size 为 4096,可以通过以下命令得到:

# ipvsadm -ln
IP Virtual Server version 1.0.12 (size=4096)

简单地说,这个hash table 用于记录每个进来的连接及路由去向的信息。面对庞大的连接时,这个4096是远远不够的,这时就会产生冲突,然后hash table  就不断置换table 中的数据,系统的负荷就这样上来了。所以,很多调优文章都说,要把这个值调大。至于如何调大呢,好像必须重编译内核了。。。

我的是 centos 5.4 final ,利用 srpm 去重编译吧,使用当前系统的 config ,这样编译后的内核只不过是改变了 hash table 的值,并没有改变其它的东西。

下一个 kernel 的 srpm :http://mirrors.163.com/centos/5.4/os/SRPMS/kernel-2.6.18-164.el5.src.rpm

重编内核时,把原来的 config(/boot/config-2.6.18-164.el5) copy 覆盖 SOURCES/kernel-2.6.18-x86_64.config .

把第一行的

#

改为

# x86_64

同时,修改 CONFIG_IP_VS_TAB_BITS=12 (2的12次方,4096)为 CONFIG_IP_VS_TAB_BITS=20 。

然后 rpmbuild -ba –target=`uname -m` kernel-2.6.spec ,新编译出来的kernel-2.6.18-164.el5.x86_64.rpm 就在 RPMS/x86_64/ 里了。

rpm -Uvh 吧。

reboot 后,再 ipvsadm -ln 就可以看到

IP Virtual Server version 1.2.1 (size=1048576)

成功!
lvs 调优的文章通常会说,如果你的并发连接数是 200,keep alive 是200秒,那么hash table size 就应该设置为不要低于 200×200=40000 太多,2的15次方32768 就差不多了。不过,谁知道我们的需求是否会变呢?我一般都懒得算,直接开到最大,20 就是最大的了。

还需要注意一点,就是每个连接是要占用内存的,印象中是每个连接占用136 bytes ,尽管说 lvs 可以抗百万级别的连接,也要注意有没有足够的内存哦,呵呵。

利用 piranha 快速搭建 lvs

最近为那个公司很重视的项目搭建 lvs ,在这里 log 一下吧。

利用red hat 提供的 piranha ,简单快捷。

我选择的是 centos 5.4 ,安装 piranha ,很简单

yum install piranha

此时,它还需要你安装 ipvsadm , php , php-cli , php-common , httpd ,piranha 是一个 web 管理的工具,没办法,虽然我不用web 界面,但这些在yum 下还是必须装上的。

装完以后,/etc/sysconfig/ha/lvs.cf 还是空的,我去抄一份过来。

serial_no = 1
primary = 60.12.227.1
service = lvs
backup_active = 1
backup = 60.12.227.2
heartbeat = 1
heartbeat_port = 10001
keepalive = 6
deadtime = 18
network = direct
debug_level = NONE
virtual vs[1] {
    active = 1
    address = 60.12.227.200 eth0:200
    vip_nmask = 255.255.255.0
    port = 80
    send = "GET / HTTP/1.0\r\n\r\n"
    expect = "HTTP"
    use_regex = 0
    load_monitor = none
    scheduler = wlc
    protocol = tcp
    timeout = 6
    reentry = 15
    quiesce_server = 0
    server rs[1] {
    address = 192.168.0.1
        active = 1
        weight = 2
    }
    server rs[2] {
    address = 192.168.0.2
        active = 1
        weight = 2
    }
}

到此,lvs 的 director 端,算是安装完成了。

有人会问了,为什么我没有修改 /proc/sys/net/ipv4/ip_forward 为1 。其实,这里我也还不是很懂,理论上,转发是必须设为1 的,但我发现,貌似不设,也可以正常工作,难道是 piranha 的关系??

然后就是配置 real server 端了。

我又抄一个shell 过来

#!/bin/sh
 
VIP=60.12.227.200
/sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
 
echo "1"  > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2"  > /proc/sys/net/ipv4/conf/lo/arp_announce
echo "1"  > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "2"  > /proc/sys/net/ipv4/conf/all/arp_announce

由于我的director 端配置的是 dr 模式,所以必须关闭arp 响应。

执行一下这个shell,real server 端也算是完成了。

启动 director 端:

# /etc/init.d/pulse start
Starting pulse:                                            [  OK  ]

查看服务状态:

# ipvsadm -ln
 
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  60.12.227.200:80 wlc
-> 192.168.0.1:80             Route   2      326        172
-> 192.168.0.2:80             Route   2      326        192

搭建完成了,算是比较快速的了,呵呵。还有一点知识点的,下回再说吧。