流量统计自动清零

[gfei713]

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

[cnnbcza]

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
#13.

-- Cz.

[gfei713]

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

[cnnbcza]

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.

[tanxi]

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]

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