Keepalived 实现双机热备并对关键进程进行监控

· Read in about 1 min · (91 Words)
network

三连更有木有!(对不起我网文看多了,而且中间其实断过两天的,我不会告诉你其实是我把这事儿给忘了的)

另,这篇照例是工作需要。


使用 Keepalived 实现多机热备(无负载均衡)时,除了对网口状态的监控外,一般还要对系统关键进程(如 Web 服务器的话就是 nginx 或者 httpd 之类的)进行监控,这时就要用到 vrrp_script 配置。网上能找到的 vrrp_script 示例都使用了 weight 选项,以实现基于优先级机制的切换,我在使用中遇到了一点儿问题,总结一下。

一般在使用双机热备时,如果当前主机——假设为 A ——出了问题(关键进程挂掉,优先级降低,低于备机),这时会自动切换到备机——假设为 B ——继续完成工作,同时等待管理员对 A 的问题进行修复。当 A 的问题修复时,我们不希望 A 马上切换为主机,因为这样有可能断掉用户正在使用的连接,体验不好。在 keepalived 中,通过给 A 增加一条 nopreempt 配置,就可以防止 A 主动抢回主机状态。

这时问题就来了。当 A 的问题(关键进程恢复)修复之后,A 的优先级会恢复到原来的值,但由于 nopreempt 的存在,A 并不会立刻抢占。这时就相当于 A 作为备机,却有更高的优先级。如果 B 之后出了问题(关键进程挂掉,优先级降低),却不会导致切换,因为 B 在出问题之前,其优先级就已经比 A 低了。

网上有文章说,遇到这种情况,可以在 B 的进程监控脚本中把 B 的 keepalived 进程杀掉,来强制触发切换动作,这种作法显然并不优雅。有没有更好的方法呢?

注意到,当拔网线触发切换时,被拔网线的机器上,keepalived 并不是降低了自己的优先级,而是进入 FAULT 状态(除 MASTER 和 BACKUP 之外的另一种状态),这时是不会有上述由优先级引起的问题的。所以新的思路就是,当进程监控失败时,不要降低优先级,而是令 keepalived 进入 FAULT 状态,同时在主备两机都加上 nopreempt 选项。

至于怎么令 keepalived 进入 FAULT 状态,也很简单,直接去掉 vrrp_script 中的 weight 选项即可。虽然谁也没说 weight 是必选项,但因为网上能搜到的示例都是配了 weight 的,导致很多人(至少包括我)会主观认为这是必选项,从而无法意识到还有其他方法。当然这也跟 keepalived 的文档不太完善有关。

PS. 让我发现 weight 不是必选项的来源是……找不着了,囧。

Comments