L10 keepalived 基本使用(主备模式)

冰镇可乐

配置keepalive基本主备模式

配置说明：



要求默认情况下由节点node1提供服务，当节点node1不可用时，由节点node2提供服务(即虚拟IP漂移至节点node2)。
　　节点node1 192.168.0.20 (主节点)
节点node2 192.168.0.21(备用节点)
虚拟IP(对外提供服务的IP 192.168.0.60
ping node 192.168.0.22（用于节点自身状态监测）
内容：
1，节点node1上的配置文件
2，节点node2配置
3，使用脚本防止脑裂。
4，总结

　　

1，节点node1上的配置文件

注意：centos 6.4（含6.4）以后base提供keepalived安装包，直接使用yum安装即可。
vim /etc/keepalived/keepalived.conf
global_defs {
   notification_email {
     root@localhost
   }
   notification_email_from root@local host
   smtp_server localhost
   smtp_connect_timeout 30
   router_id  K1
}
默认的配置文件中，使用第三方smtp服务器，但这在现实中几乎没有意义（需要验证的原因），我们将其指定为localhost, 将通知信息的发送交给本地sendmail服务处理。查阅说明文档得知route_id配置是为了标识当前节点，我将其设置为K1。当然两个节点的此项设置可相同，也可不相同。
vrrp_instance VI_1 {
    state MASTER   #指定A节点为主节点 备用节点上设置为BACKUP即可
    interface eth0   #绑定虚拟IP的网络接口
    virtual_router_id 51  #VRRP组名，两个节点的设置必须一样，以指明各个节点属于同一VRRP组
    priority 100   #主节点的优先级（1-254之间），备用节点必须比主节点优先级低,优先级数字越大优先级越高。
    advert_int 1   #组播信息发送间隔，两个节点设置必须一样
    authentication {   #设置验证信息，两个节点必须一致
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {   
         192.168.0.60/24 #指定虚拟IP, 两个节点设置必须一样
    }
}

　　vim编辑：当前行到最后一行，开头加#号。
　　:.,$s/^/#/g
vim取消高亮
:nohl


　　默认的配置文件中，竟然没有子网掩码，从而导致使用了默认子网掩码255.255.255.255，有可能导致无法从其它机器访问虚拟IP（keepalived虚拟IP无法ping通）所以尽量指定子网掩码/24即可。
　　

按同样的方法配置节点node2并修改配置文件，可将node1节点的配置文件复制到node2节点，并修改以下几项：
2，节点node2配置

router_id  NodeB
state   BACKUP
priority   99
其它项不必修改。
测试及验证：拔掉节点node1的网线，就发现虚拟IP已经绑定到节点node2上，再恢复node1节点的网线，虚拟IP又绑定回节点node1之上。
启动keepalived，查看网卡信息：排错可以使用日志：/var/log/message.

3，使用脚本防止脑裂。
目的，当两个节点 ，哪个不能ping通网关的时候，必然不会成为主节点。
这种方式存在恼裂的可能，即两个节点实际都处于正常工作状态，但是无法接收到彼此的组播通知，这时两个节点均强行绑定虚拟IP，导致不可预料的后果。
这时就需要设置仲裁，即每个节点必须判断自身的状态（应用服务状态及自身网络状态），要实现这两点可使用自定义shell脚本实现，通过周期性地检查自身应用服务状态，并不断ping网关（或其它可靠的参考IP）均可。当自身服务异常、或无法ping通网关，则认为自身出现故障，就应该移除掉虚拟IP(停止keepalived服务即可）。


假设节点node1和node2组成主备关系，node1为备用节点，B为主节点，那么当在图标黄叉位置发生网络故障时，节点node1接收不到节点node2的组播通知，将抢占虚拟IP。这时出现的后果就是节点Ａ和节点B均拥有虚拟IP，就可能导致了脑裂。所以我们以网关IP连通性作为参考，可避免此问题产生。




主要借助keepalived提供的vrrp_script及track_script实现：
在keepalived的配置文件最前面加入以下代码，定义一个跟踪脚本：
vrrp_script check_local { #定义一个名称为check_local的检查脚本
    script "/usr/local/keepalived/bin/check_local.sh" #shell脚本的路径
    interval 5  #运行间隔
}
再在vrrp_instance配置中加入以下代码使用上面定义的检测脚本：
track_script {
check_local
}
我们在/usr/local/keepalived/bin/check_local.sh定义的检测规则是：
1. 　自身web服务故障（超时，http返回状态不是200）
2.  无法ping通网关
3.  产生以上任何一个问题，均应该移除本机的虚拟IP(停止keepalived实例即可)
但这里有个小问题，如果本机或是网关偶尔出现一次故障，那么我们不能认为是服务故障。更好的做法是如果连续N次检测本机服务不正常或连接N次无法ping通网关，才认为是故障产生，才需要进行故障转移。另一方面，如果脚本检测到故障产生，并停止掉了keepalived服务，那么当故障恢复后，keepalived是无法自动恢复的。我觉得利用独立的脚本以秒级的间隔检查自身服务及网关连接性，再根据故障情况控制keepalived的运行或是停止。


示例：当192.168.0.22不能PING通，自动取消绑定的VIP。

脚本：

　　配置ping网关：192.168.0.22
　　设置其中node2 不能ping通。

　　这样以后，即使node1主节点故障，node2也不会替代。

4，总结：
1，node1主节点，node2备用节点，node1节点故障，node2成为主节点；
2，为防止脑裂，即node1主节点和node2备节点，因为某种原因比如网络故障，不能彼此交换信息，这样，备用节点node2将也会绑定VIP，如此即node1，node2都绑定了VIP，将造成未知故障，因此使用脚本方式能够自身判断自己的情况，依据脚本判断自身是否替代主节点。