一、Keepalived 应用场景
keepalived的研发是针对LVS的，特点是轻量级、配置简洁。正因为这个特点，个人认为其适合应用在资源相对少，且无共享存储的环境下，尤其适合在负载均衡器上使用，如LVS、haproxy、nginx等上，也可以用于轻量级的http环境，作为其高可用组件。当然理论上很多高可用的场景其都可以实现，不过基于keepalived本身的资源切换方式功能并不推荐使用。
二、影响keepalived状态切换的因素
keepalived状态切换主要通过其VRRP协议中的weight值结合健康脚本实现，节点的优先级也会根据脚本的检测状态动态调整。其实keepalived实现根据资源健康情况进行自由切换会根据跑的业务类型会有差别的的，有些情况当master上的资源由于故障切换到backup上时候，那么如果想再切回来就需要关闭keepalived的服务才可以。
1.MASTER、BACKUP、priority(优先级)
设定keepalived的master和backup值主要是在priority(优先级)相同的前提下才有意义，如果优先级不同的话，还是以优先级高的为master，而不管其设定了master还是backup，通常下我们两个节点最好指定不同的优先级。
2.vrrp_script脚本的weight值
这个weight值必须指定，否则有时候重启服务后该节点被显示为fault 状态。
weight值分为正值和负值，假定weight值为W，初始的优先级为P，
当weight值<0时:
- 如果检测脚本返回值=0，则节点最终优先级不改变。
- 如果检测脚本返回值≠0，则节点最终优先级=P-W，优先级会减小
当weight值>0时
- 如果检测脚本返回值=0，则节点最终优先级=P+W，优先级会增加
- 如果检测脚本返回值≠0，则节点最终优先级不改变。
节点优先级的变化和所在节点的业务状态会有很大关系，看下面两个表格：
- 一，当两个节点上的业务服务都处于启动状态，如httpd，那么优先级变化会如下：
节点 设定优先级 weight值 节点正常运行优先级
（两个节点httpd都启动）节点A:服务检测失败 A恢复，且不抢占 A 100 -2 100 100-2=98 100 B 99 -2 99 99 99 状态 A为master A为master A为master 切换到B为master 切换到A为master
- 二，当master节点业务启动，backup节点业务为停止状态，如,haproxy(因为haproxy没有监听的地址是无法启动的，其实很多业务都是两个节点一启一停的)
节点 设定优先级 weight值 节点正常运行时的优先级 节点A业务失败时的优先级 停止A的keepalived后的优先级 重新开启A的keepalived优先级 停止B的keepalived后的优先级 A 100 -2 100 100-2=98 无 100-2=98 98 B 99 -2 99-2=97(因为haproxy停止) 97 97 99 无 状态 A为master A为master A为master A>B,并不切换 切换到B为master A<B,不切换回去 切换回A为master
由上可以看出，如果是第二种情况，那么只有关闭keepalived服务才能进行切换，这就是很多人做实验发现为什么业务停了却不能切换的原因，这种情况下我们可以改编初始优先级和weight值使 A切换到B，但是如果要切换回去，就手动停止keepalived才可以。这也是为什么keepalived不适合做大业务集群的原因，如果只是针对调度器做高可用的话还比较合适。