我们在数据库前面加了lvs + keepalived 做vip 切换, 实现数据库ha .

整套流程也是很成熟的了.

近期遇到了一个问题.

lvs 的 master 与backup 节点之间 vip 可以自由的飘来飘去 , 对应用端是透明的.

但是最近遇到一个问题 , vip 在飘逸后, 一部分应用是可以访问数据库的,一部分应用是无法访问数据库的,报错就是网络超时.

应用服务器也ping 不通 vip , 做过一次抓包分析, 发现应用服务器发出的包的目标地址是错的.

由此怀疑 vip 飘逸后, vip 的arp 广播包可能没有到达应用服务器所在的网段.

由于局域网比较大, 分了几个网段.

目前还不清楚 , 是什么原因导致的 arp 广播包没有到达远端.

这个问题可以重现, 但是无法模拟, 只能等, 目前真正的原因也没有找到.

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

问题终于解决了．　　ｌｖｓ　在发生ｖｉｐ　切换后，悔自动发送ａｒｐ　广播．　

　在实际操作中,我们发现有时候(偶尔) arp 广播没有被交换机学习到.

自己在代码里加了一个arping 的命令手工发送arp 广播,由于同事的代码有一定的逻辑问题, 在vip 飘逸后,导致arping 命令变成里的damon 进程, 会一直发送完指定个数的arp包.

这个时候, vip 已经漂移到另一个lvs 机器上,那个机器也会发送arpping 广播包, 这个两个进程会同时发送 , 直到第一个daemon 进程完成后,系统才会正常.

为什么不会总是出现呢, 因为有时候 arping 代码会在随着vip 的漂移会成功推出,有时候又无法被kill 变成daemon 进程了.

至此问题原因找到, 我们优化了这部分代码的业务逻辑.问题解决.

ITPub博客

lvs 负载均衡遇到的一个问题. (问题解决）

最新文章