首先show一下ipvsadm -h对这两个参数的注释

--persistent   -p [timeout]         persistent service //持久服务

--set tcp tcpfin udp        set connection timeout values //链接的超时时间



1. --persistent   -p [timeout]

    持久服务超时时间设置参数,真对一些需要保持状态的应用,例如一些http应用、ftp、ssl等。 在参数的时间范围内同一用户(client IP)的多次访问会被ipvs分配到同一台realserver上。 


2. --set tcp tcpfin udp


   真对链接的超时时间。以tcp为例,一个tcp连接建立后会传输N个报文, 当两个报文相继到达的时间差在超时时间内就会被转发到同一台realserver上进行处理, 若时间差大于超时时间就会根据调度算法重新选择realserver,连接就有可能出现异常。 ipvs是根据client IP  和 client port来识别是不是同一个链接发的报文。



3. 两者的区别与联系


   区别:

       persistent 是提供对有持久服务需要的支撑, 是在超时时间内将同一个client IP的链接分发到同一个realserver上,比较宏观一些;


       set 是针对一次链接两个相继到达报文的超时时间定义, 这个值在单一一次链接内有效,比较微观一些。


   联系:

    persistent值大于等于set时,持久服务分发超时以persistent的设置为准。


       persistent值小于set时,持久服务分发超时会以(s/60)*60 + p%60 + 60为准(当persistent值超时后, 会将persistent自动赋值为60,超时后继续将persistent自动赋值为60....直到set超时persistent再次超时未知)。


TCP的状态 (SYN, FIN, ACK, PSH, RST, URG)

在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN, FIN, ACK, PSH, RST, URG.


其中,对于我们日常的分析有用的就是前面的五个字段。


 它们的含义是:


SYN表示建立连接,


FIN表示关闭连接,


ACK表示响应,


PSH表示有 DATA数据传输,


RST表示连接重置。


 其中,ACK是可能与SYN,FIN等同时使用的,比如SYN和ACK可能同时为1,它表示的就是建立连接之后的响应,


 如果只是单个的一个SYN,它表示的只是建立连接。


TCP的几次握手就是通过这样的ACK表现出来的。


 但SYN与FIN是不会同时为1的,因为前者表示的是建立连接,而后者表示的是断开连接。


RST一般是在FIN之后才会出现为1的情况,表示的是连接重置。


 一般地,当出现FIN包或RST包时,我们便认为客户端与服务器端断开了连接;而当出现SYN和SYN+ACK包时,我们认为客户端与服务器建立了一个连接。


PSH为1的情况,一般只出现在 DATA内容不为0的包中,也就是说PSH为1表示的是有真正的TCP数据包内容被传递。


TCP的连接建立和连接关闭,都是通过请求-响应的模式完成的。


 概念补充-TCP三次握手:


TCP(Transmission Control Protocol)传输控制协议


TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接:


 位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)


第一次握手:主机A发送位码为syn=1,随机产生seq number=1234567的数据包到服务器,主机B由SYN=1知道,A要求建立联机;


 第二次握手:主机B收到请求后要确认联机信息,向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包;


 第三次握手:主机A收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,主机A会再发送ack number=(主机B的seq+1),ack=1,主机B收到后确认seq值与ack=1则连接建立成功。


 完成三次握手,主机A与主机B开始传送数据。


 


 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。  第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;  第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;


 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。完成三次握手,客户端与服务器开始传送数据.




tcp_fin_timeout :INTEGER

默认值是 60

对于本端断开的socket连接,TCP保持在FIN_WAIT_2状态的时间。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。默认值为 60 秒。过去在2.2版本的内核中是 180 秒。您可以设置该值﹐但需要注意﹐如果您的机器为负载很重的web服务器﹐您可能要冒内存被大量无效数据报填满的风险﹐FIN-WAIT-2 sockets 的危险性低于 FIN-WAIT-1 ﹐因为它们最多只吃 1.5K 的内存﹐但是它们存在时间更长。另外参考 tcp_max_orphans。

CLOSE_WAIT状态的生成原因

如果服务器程序APACHE处于CLOSE_WAIT状态的话,说明套接字是被动关闭的!

假设CLIENT端主动断掉当前连接,那么双方关闭这个TCP连接共需要四个packet:

      Client --->  FIN  --->  Server 

      Client <---  ACK  <---  Server 

 这时候Client端处于FIN_WAIT_2状态;而Server 程序处于CLOSE_WAIT状态。

      Client <---  FIN  <---  Server 

这时Server 发送FIN给Client,Server 就置为LAST_ACK状态。

       Client --->  ACK  --->  Server 

Client回应了ACK,那么Server 的套接字才会真正置为CLOSED状态。

Server 程序处于CLOSE_WAIT状态,而不是LAST_ACK状态,说明还没有发FIN给Client,那么可能是在关闭连接之前还有许多数据要发送或者其他事要做,导致没有发这个FIN packet。

通常来说,一个CLOSE_WAIT会维持至少2个小时的时间。如果有个流氓特地写了个程序,给你造成一堆的CLOSE_WAIT,消耗资源,那么通常是等不到释放那一刻,系统就已经解决崩溃了。


对ipvsadm 的命令参考,并根据自己使用的经验,进行了一个简单的翻译,希望

对ipvsadm 的使用者有一定的帮助。

为了更好的让大家理解这份命令手册,将手册里面用到的几个术语先简单的介绍

一下:

1,virtual-service-address:是指虚拟服务器的ip 地址

2,real-service-address:是指真实服务器的ip 地址

3,scheduler:调度方法

命令选项解释:

有两种命令选项格式,长的和短的,具有相同的意思。在实际使用时,两种都可

以。

-A --add-service 在内核的虚拟服务器表中添加一条新的虚拟服务器记录。也

就是增加一台新的虚拟服务器。

-E --edit-service 编辑内核虚拟服务器表中的一条虚拟服务器记录。

-D --delete-service 删除内核虚拟服务器表中的一条虚拟服务器记录。

-C --clear 清除内核虚拟服务器表中的所有记录。

-R --restore 恢复虚拟服务器规则

-S --save 保存虚拟服务器规则,输出为-R 选项可读的格式

-a --add-server 在内核虚拟服务器表的一条记录里添加一条新的真实服务器

记录。也就是在一个虚拟服务器中增加一台新的真实服务器

-e --edit-server 编辑一条虚拟服务器记录中的某条真实服务器记录

-d --delete-server 删除一条虚拟服务器记录中的某条真实服务器记录

-L|-l --list 显示内核虚拟服务器表

-Z --zero 虚拟服务表计数器清零(清空当前的连接数量等)

--set tcp tcpfin udp 设置连接超时值

--start-daemon 启动同步守护进程。他后面可以是master 或backup,用来说

明LVS Router 是master 或是backup。在这个功能上也可以采用keepalived 的

VRRP 功能。

--stop-daemon 停止同步守护进程

-h --help 显示帮助信息

其他的选项:

-t --tcp-service service-address 说明虚拟服务器提供的是tcp 的服务

[vip:port] or [real-server-ip:port]

-u --udp-service service-address 说明虚拟服务器提供的是udp 的服务

[vip:port] or [real-server-ip:port]

-f --fwmark-service fwmark 说明是经过iptables 标记过的服务类型。

-s --scheduler scheduler 使用的调度算法,有这样几个选项

rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,

默认的调度算法是: wlc.

-p --persistent [timeout] 持久稳固的服务。这个选项的意思是来自同一个客

户的多次请求,将被同一台真实的服务器处理。timeout 的默认值为300 秒。

-M --netmask netmask persistent granularity mask

-r --real-server server-address 真实的服务器[Real-Server:port]

-g --gatewaying 指定LVS 的工作模式为直接路由模式(也是LVS 默认的模式)

-i --ipip 指定LVS 的工作模式为隧道模式

-m --masquerading 指定LVS 的工作模式为NAT 模式

-w --weight weight 真实服务器的权值

--mcast-interface interface 指定组播的同步接口

-c --connection 显示LVS 目前的连接 如:ipvsadm -L -c

--timeout 显示tcp tcpfin udp 的timeout 值 如:ipvsadm -L --timeout

--daemon 显示同步守护进程状态

--stats 显示统计信息

--rate 显示速率信息

--sort 对虚拟服务器和真实服务器排序输出

--numeric -n 输出IP 地址和端口的数字形式




LVS琐碎记忆:


1、InActConn并不代表错误连接,它是指不活跃连接(Inactive Connections),

我们将处于TCP ESTABLISH状态以外的连接都称为不活跃连接,例如处于SYN_RECV状态的连接,处于TIME_WAIT状态的连接等。

2、用四个参数来关闭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

3、ipvsadm -L -n --stats

Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes

连接数 输入包 输出包 输入流量 输出流量

4、注意事项:

1)在LVS方案中,虚拟ip地址与普通网络接口大大不同,这点需要特别注意。

虚拟ip地址的广播地址是它本身,子网掩码是255.255.255.255。 为什么要这样呢?因为有若干机器要使用同一个ip地址,

用本身做广播地址和把子网掩码设成4个255就不会造成ip地址冲突了,否则lvs将不能正常转发访问请求。

2)假如两台VS之间使用的互备关系,那么当一台VS接管LVS服务时,可能会网络不通,这时因为路由器的MAC缓存表里关于vip这个地址的MAC地 址还是被替换的VS的MAC,有两种解决方法,一种是修改新VS的MAC地址,另一种是使用send_arp 命令(piranha软件包里带的一个小工具) 格式如下:

send_arp:

send_arp [-i dev] src_ip_addr src_hw_addr targ_ip_addr tar_hw_addr

这个命令不一定非要在VS上执行,只+要在同一VLAN即可。

/sbin/arping -f -q -c 5 -w 5 -I eth0 -s $WEB_VIP -U $GW

5.Virtual Server via Direct Routing(VS/DR)

VS/DR通过改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。同VS/TUN技术一样,VS/DR技术可极大地

提高集群系统的伸缩性。这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,但是要求调度器与真实服务器都有一块网卡连

在同一物理网段上。

6. LVS 经验:

1). LVS调度的最小单位是“连接”。

2). 当apache的KeepAlive被设置成Off时,“连接”才能被较均衡的调度。

3). 在不指定-p参数时,LVS才真正以“连接”为单位按“权值”调度流量。

4). 在指定了-p参数时,则一个client在一定时间内,将会被调度到同一台RS。

5). 可以通过”ipvsadm –set tcp tcpfin udp”来调整TCP和UDP的超时,让连接淘汰得快一些。

6). 在NAT模式时,RS的PORT参数才有意义。

7). DR和TUN模式时,InActConn 是没有意义的(Thus the count in the InActConn column for LVS-DR, LVS-Tun is

inferred rather than real.)

/sbin/arping -f -q -c 5 -w 5 -I eth0 -s $WEB_VIP -U $GW

三、LVS 性能调优

Least services in System or Compile kernel.

Performace Tuning base LVS:

LVS self tuning( ipvsadm Timeout (tcp tcpfin udp)).

ipvsadm -Ln --timeout

Timeout (tcp tcpfin udp): 900 120 300

ipvsadm --set tcp tcpfin udp

Improving TCP/IP performance

net.ipv4.tcp_tw_recyle=1

net.ipv4.tcp_tw_reuse=1

net.ipv4.tcp_max_syn_backlog=8192

net.ipv4.tcp_keepalive_time=1800

net.ipv4.tcp_fin_timeout=30

net.core.rmem_max=16777216

net.core.wmem_max=16777216

net.ipv4.tcp_rmem=4096 87380 16777216

net.ipv4.tcp_wmem=4096 65536 16777216

net.core.netdev_max_backlog=3000

项目实施案例及经验分享:

1、机房无法实时刷新MAC,LVS+Heartbeat方案无法正常随机切换IP?

假如两台VS之间使用的互备关系,那么当一台VS接管LVS服务时,可能会网络不通,这时因为路由器的MAC缓存表里无法及时刷新MAC.关于vip这个

地址的MAC地址还是替换的VS的MAC,有两种解决方法,一种是修改新VS的MAC地址,另一种是使用send_arp /arpiing命令.

以arping命令为例.

/sbin/arping -I eth0 -c 3 -s ${vip}${gateway_ip} > /dev/null 2>&1

Eg:

/sbin/arping -I eth0 -c 3 -s 192.168.1.6192.168.1.1

【注】07年部署某大型商业网站项目时,263机房遇到此问题,最好让机房调整路由

MAC缓存表的刷新频率;同朋公司移动机房实施相关项目时发现切换IP后还是无法

访问VIP,最后利用上面的arping一个命令搞定.

【附】如果采用Piranha/keealived方案切换的时候会内置自动发送send_arp命令.

UltraMonkey方案经测试也会自动发送此命令.如用heartbeat方案,需要写一个send_arp或者arping相关的脚本当作

heartbeat一个资源切换服务的时候自动发送

相关命令脚本.

2、某台机器down掉以后,IPVS列表中权值已经置0了,为什么还轮询到这台机器上?

配置 ldirectord.conf

quiescent=no或 echo 1 >/proc/sys/net/ipv4/vs/expire_nodest_conn

【注】经如上设置某台Realserver服务down掉以后如何从IPVS列表自动中删除恢复时如何自动添加.

3、为什么做压力测试的时候,LVS不能负载均衡多部分连接只到某一台机器上?

难道是LVS不能实现真正的负载均衡?

这和LVS脚本里指定-p参数有关,如果指定了一个client在一定的时间内,将会被调度到同一台RS上。所以你在从来源来做压力测试的时候大部分连接

会调度到同一台机器上,这样就出现了负载不均衡的状况。很多人经常问我这个问题,仍后我叫他们多从几个点去同时向LVS服务器做压力测试的时候就发现负载

很均衡了。