Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

流量统计自动清零 #13

Open
gfei713 opened this issue Dec 24, 2015 · 5 comments
Open

流量统计自动清零 #13

gfei713 opened this issue Dec 24, 2015 · 5 comments

Comments

@gfei713
Copy link

gfei713 commented Dec 24, 2015

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

@cnnbcza
Copy link
Member

cnnbcza commented Dec 29, 2015

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

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

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

2015-12-24 17:16 GMT+08:00 gfei713 [email protected]:

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


Reply to this email directly or view it on GitHub
#13.

-- Cz.

@gfei713
Copy link
Author

gfei713 commented Dec 29, 2015

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

@cnnbcza
Copy link
Member

cnnbcza commented Dec 29, 2015

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 [email protected]:

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.

@tanxi
Copy link

tanxi commented Mar 27, 2019

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 [email protected]:

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
Copy link

tanxi commented Mar 27, 2019

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 [email protected]:

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
我需要再研究下这个配置

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants