alibaba / LVS

A distribution of Linux Virtual Server with some advanced features. It introduces a new packet forwarding method - FULLNAT other than NAT/Tunneling/DirectRouting, and defense mechanism against synflooding attack - SYNPROXY.
2k stars 682 forks source link

流量统计自动清零 #13

Open gfei713 opened 8 years ago

gfei713 commented 8 years ago

我们部署了几台lvs集群,使用fullnat模式,其中有一台lvs的流量统计(ipvsadm --stats)会自动清零:每隔5分钟就清零了,而这几台机器上没有调用--zero来清零流量数据。请问可能是什么原因导致的?

cnnbcza commented 8 years ago

VIP的重新添加删除会导致流量清零。

RS的重新添加删除(人为 and 健康检查触发)也会导致流量清零。

你们是否使用keepalived + rs 非inhibit_on_failure方式配置ipvs?

2015-12-24 17:16 GMT+08:00 gfei713 notifications@github.com:

我们部署了几台lvs集群,使用fullnat模式,其中有一台lvs的流量统计(ipvsadm --stats)会自动清零:每隔5分钟就清零了,而这几台机器上没有调用--zero来清零流量数据。请问可能是什么原因导致的?

— Reply to this email directly or view it on GitHub https://github.com/alibaba/LVS/issues/13.

-- Cz.

gfei713 commented 8 years ago

thank you ! 我们找到原因了,有个兄弟写了个定时清0的脚本所致。。。 我们使用的是非inhibit_on_failure方式配置ipvs,我看了下inhibit_on_failure,用这种配置方式是否可以避免RS的重新添加删除(人为 and 健康检查触发)导致的流量清零?

cnnbcza commented 8 years ago

inhibit_on_failure (iof) 的目的不是用来防止流量清零。iof一般用来友好的上下线。

某些rs通过健康检查的方式达到人为的上下线。当需要人为下线某一台RS,移除某一个健康检查文件,健康检查随即失败。配置iof的rs,weight会置为0,ipvs内核中的rs状态不会被标识为unavailable,去往这台rs的数据包还是可达(因为人为下线操作,PE不会关停业务),之前的业务还是可用,新的新建因为w=0不会调度上去。当这台rs的连接数没有时,就可以做关机等。

2015-12-29 16:11 GMT+08:00 gfei713 notifications@github.com:

thank you ! 我们找到原因了,有个兄弟写了个定时清0的脚本所致。。。 我们使用的是非inhibit_on_failure方式配置ipvs,我看了下inhibit_on_failure,用这种配置方式是否可以避免RS的重新添加删除(人为 and 健康检查触发)导致的流量清零?

— Reply to this email directly or view it on GitHub https://github.com/alibaba/LVS/issues/13#issuecomment-167742846.

-- Cz.

tanxi commented 5 years ago

inhibit_on_failure (iof) 的目的不是用来防止流量清零。iof一般用来友好的上下线。

某些rs通过健康检查的方式达到人为的上下线。当需要人为下线某一台RS,移除某一个健康检查文件,健康检查随即失败。配置iof的rs,weight会置为0,ipvs内核中的rs状态不会被标识为unavailable,去往这台rs的数据包还是可达(因为人为下线操作,PE不会关停业务),之前的业务还是可用,新的新建因为w=0不会调度上去。当这台rs的连接数没有时,就可以做关机等。

2015-12-29 16:11 GMT+08:00 gfei713 notifications@github.com:

thank you ! 我们找到原因了,有个兄弟写了个定时清0的脚本所致。。。 我们使用的是非inhibit_on_failure方式配置ipvs,我看了下inhibit_on_failure,用这种配置方式是否可以避免RS的重新添加删除(人为 and 健康检查触发)导致的流量清零? — Reply to this email directly or view it on GitHub #13 (comment).

-- Cz.

hi,能更快速下线 rs 吗?使用这种方式,要等到 rs 的连接数没有时,流量才会完全没有,我们线上的一台 rs(都是内网服务,QPS 1~2w),LVS 上看 InActConn 的连接数是好几万,使用这种方式摘流量耗时非常久(1小时了都还有很大流量)。 但是如果不配置 inhibit_on_failure 的话,下线的那段时间,client 端又会有大量的报错。

tanxi commented 5 years ago

inhibit_on_failure (iof) 的目的不是用来防止流量清零。iof一般用来友好的上下线。 某些rs通过健康检查的方式达到人为的上下线。当需要人为下线某一台RS,移除某一个健康检查文件,健康检查随即失败。配置iof的rs,weight会置为0,ipvs内核中的rs状态不会被标识为unavailable,去往这台rs的数据包还是可达(因为人为下线操作,PE不会关停业务),之前的业务还是可用,新的新建因为w=0不会调度上去。当这台rs的连接数没有时,就可以做关机等。 2015-12-29 16:11 GMT+08:00 gfei713 notifications@github.com:

thank you ! 我们找到原因了,有个兄弟写了个定时清0的脚本所致。。。 我们使用的是非inhibit_on_failure方式配置ipvs,我看了下inhibit_on_failure,用这种配置方式是否可以避免RS的重新添加删除(人为 and 健康检查触发)导致的流量清零? — Reply to this email directly or view it on GitHub #13 (comment).

-- Cz.

hi,能更快速下线 rs 吗?使用这种方式,要等到 rs 的连接数没有时,流量才会完全没有,我们线上的一台 rs(都是内网服务,QPS 1~2w),LVS 上看 InActConn 的连接数是好几万,使用这种方式摘流量耗时非常久(1小时了都还有很大流量)。 但是如果不配置 inhibit_on_failure 的话,下线的那段时间,client 端又会有大量的报错。

好吧,LVS 上的 tcp 超时时间没有修改,使用的是默认值 Timeout (tcp tcpfin udp): 900 120 300 我需要再研究下这个配置