lvs 核心参数配置. 有端口号,负载转发过程中也会改端口号. lvs原理
lvs的timeout:
ipvsadm --set tcp tcpfin udp查看timeout:
# ipvsadm --list --timeout
Timeout (tcp tcpfin udp): 7200 5 60 这就表明我的tcp session的timeout时间是7200秒。
设置timeout:
#ipvsadm --set 7200 5 60
1. tcp,指的是TCP连接超时时间(空闭时间);
2. tcpfin,表示在客户端发送fin以后,连接还在hash-table中所存在的时间;
3. udp,记录udp连接,超出时间还未收到下一个udp包(udp超时,udp没有连接状态,只能这样写了),则从hash-tabl中删除连接条目。这些值一般也不用改变。不过为什么有这个还是介绍下吧:因为lvs是处在客户端和Real Server之间的,它本身可没有连接状态,数据只是在内核中转出去了而已,根本不会建立连接。那么它怎么知道现在客户端发过来的数据是不是与Real Server已经建立连接了呢,就是靠的这个hash table了。就是通过这张表来查看客户端与Real Server的连接状态的。不然的话,tcp三次握手,第一次给转到Real Server A上去了,A返回确认,第三次握手信息结果给转到B上去了,是不是很糟糕。数据传输那就更糟糕了。所以大概意思就是这么来的。
lvs的 persistent :
客户端是服务器,配置短.否则负载不均衡. 连接池也不应该用,先入后出的连接池.好的连接池存储器应该是队列而不是栈.
客户端是终端用户且是长连接,配置时间要长. 会引发手机切换 ip ,wifi,或者不同基站的问题. 利用 mask 来解决又会有副作用,可能会导致整个美国在线用户都落到一台机器上.
virtual_server 192.168.10.100 8080 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.10.142 8080 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.10.143 8080 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
virtual_server 192.168.10.100 8080 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.10.142 8080 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.10.143 8080 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
[1]
lvs配置persistence_timeout 参数导致数据库负载不均 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20776139&id=5753709
[2] When all ports (VIP:0) are scheduled to be persistent, then requests by a client for services on different ports (e.g.to VIP:telnet, to VIP:http) will go to the same realserver. http://blog.csdn.net/ajigegege/article/details/20165055