http://blog.csdn.net/chengxuyuanyonghu/article/details/60779391
keepalived的HA分为抢占模式(默认)和非抢占模式.
抢占模式即MASTER从故障中恢复后，会将VIP从BACKUP节点中抢占过来。
非抢占模式即MASTER恢复后不抢占BACKUP升级为MASTER后的VIP。
http://blog.csdn.net/kkdelta/article/details/39433137
http://www.lampchina.net/ask/MTYzMjEyNg.html
http://qq85609655.iteye.com/blog/1864271
http://blog.163.com/qiantu1986@126/blog/static/3592266920115211149139/
http://my.oschina.net/hncscwc/blog/158746
Keepalived使用的vrrp协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)；
Heartbeat是基于主机或网络的服务的高可用方式；
keepalived的目的是模拟路由器的双机
heartbeat的目的是用户service的双机
lvs的高可用建议用keepalived
业务的高可用用heartbeat
主keepalived关闭，会切换到从，如果主再次重启，那么会漂移到主。
从keepalived
http://blog.csdn.net/catoop/article/details/41351103
两款高可用开源方案：Keepalived和Heartbeat。两者都很流行，但差异还是很大的，现将试用过程中的感受以及相关知识点简单总结一下，供大家选择方案的时候参考。
1）Keepalived使用更简单：从安装、配置、使用、维护等角度上对比，Keepalived都比Heartbeat要简单得多，尤其是Heartbeat2.1.4后拆分成3个子项目，安装、配置、使用都比较复杂，尤其是出问题的时候，都不知道具体是哪个子系统出问题了；而Keepalived只有1个安装文件、1个配置文件，配置文件也简单很多；
2）Heartbeat功能更强大：Heartbeat虽然复杂，但功能更强大，配套工具更全，适合做大型集群管理，而Keepalived主要用于集群倒换，基本没有管理功能；
3）协议不同：Keepalived使用VRRP协议进行通信和选举，Heartbeat使用心跳进行通信和选举；Heartbeat除了走网络外，还可以通过串口通信，貌似更可靠；
4）使用方式基本类似：如果要基于两者设计高可用方案，最终都要根据业务需要写自定义的脚本，Keepalived的脚本没有任何约束，随便怎么写都可以；Heartbeat的脚本有约束，即要支持servicestart/stop/restart这种方式，而且Heartbeart提供了很多默认脚本，简单的绑定ip，启动apache等操作都已经有了；
使用建议：优先使用Keepalived，当Keepalived不够用的时候才选择Heartbeat
通常情况下，利用keepalived做热备，其中一台设置为master，一台设置为backup。当master出现异常后，backup自动切换为master。当backup成为master后，master恢复正常后会再次抢占成为master，导致不必要的主备切换。因此可以将两台keepalived初始状态均配置为backup，设置不同的优先级，优先级高的设置nopreempt解决异常恢复后再次抢占的问题。
然而keepalived只能做到对网络故障和keepalived本身的监控，即当出现网络故障或者keepalived本身出现问题时，进行切换。但是这些还不够，我们还需要监控keepalived所在服务器上的其他业务进程，根据业务进程的运行状态决定是否需要进行主备切换。这个时候，我们可以通过编写脚本对业务进程进行检测监控。
例如编写个简单脚本查看haproxy进程是否存活
|
1
2
3
4
5
6
7
|
#!/bin/bash
count = `psaux |grep-vgrep|grephaproxy |wc-l`
if[ $count > 0 ];then
exit0
else
exit1
fi
|
在keepalived的配置文件中增加相应配置项
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
vrrp_script checkhaproxy
{
script"/home/check.sh"
interval 3
weight -20
}
vrrp_instancetest
{
...
track_script
{
checkhaproxy
}
...
}
|
keepalived会定时执行脚本并对脚本执行的结果进行分析，动态调整vrrp_instance的优先级。
如果脚本执行结果为0，并且weight配置的值大于0，则优先级相应的增加
如果脚本执行结果非0，并且weight配置的值小于0，则优先级相应的减少
其他情况，维持原本配置的优先级，即配置文件中priority对应的值。
这里需要注意的是：
1） 优先级不会不断的提高或者降低
2） 可以编写多个检测脚本并为每个检测脚本设置不同的weight
3） 不管提高优先级还是降低优先级，最终优先级的范围是在[1,254]，不会出现优先级小于等于0或者优先级大于等于255的情况
这样可以做到利用脚本检测业务进程的状态，并动态调整优先级从而实现主备切换。
但是利用该方式会存在一个问题，例如：A,B两台keepalived
A的配置大概为：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
vrrp_script checkhaproxy
{
script"/etc/check.sh"
interval 3
weight -20
}
vrrp_instancetest
{
....
state backup
priority 80
nopreempt
track_script
{
checkhaproxy
}
....
}
|
B的配置大概为：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
vrrp_script checkhaproxy
{
script"/etc/check.sh"
interval 3
weight -20
}
vrrp_instancetest
{
....
state backup
priority 70
track_script
{
checkhaproxy
}
....
}
|
A,B同时启动后，由于A的优先级较高，因此通过选举会成为master。当A上的业务进程出现问题时，优先级会降低到60。此时B收到优先级比自己低的vrrp广播包时，将切换为master状态。那么当B上的业务出现问题时，优先级降低到50，尽管A的优先级比B的要高，但是由于设置了nopreempt，A不会再抢占成为master状态。
所以，可以在检测脚本中增加杀掉keepalived进程（或者停用keepalived服务）的方式，做到业务进程出现问题时完成主备切换。
Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。
iptables -t nat -A PREROUTING -p tcp -d 虚拟服务ip --dport 80 -j REDIRECT
http://blog.chinaunix.net/uid-23078678-id-2554511.html
http://blog.sina.com.cn/s/blog_9e3d56cf0101bpfx.html
ubuntu
1.sudo apt-get install libssl-dev
2.sudo apt-get install openssl
3.sudo apt-get install libpopt-dev
http://blog.sina.com.cn/s/blog_5f54f0be0101eyff.html
http://deidara.blog.51cto.com/400447/302402/
http://bbs.linuxtone.org/thread-20630-1-1.html
主服务器
1 global_defs {
2 router_id NodeA
3 }
4 vrrp_script nginx_pid {
5 script "/root/nginx_pid.sh"
6 interval 3
7 weight -2
8 fall 2
9 rise 1
10 }
11 vrrp_instance VI_1 {
12 state MASTER #设置为主服务器
13 interface wlan0 #监测网络接口
14 virtual_router_id 51 #主、备必须一样
15 priority 100 #(主、备机取不同的优先级，主机值较大，备份机值较小,值越大优先级越高)
16 advert_int 1 #VRRP Multicast广播周期秒数
17 authentication {
18 auth_type PASS #VRRP认证方式，主备必须一致
19 auth_pass 1111 #(密码)
20 }
21
22 virtual_ipaddress {
23 #192.168.1.118/24 #VRRP HA虚拟地址
24 192.168.1.118 #VRRP HA虚拟地址
25 }
26 track_script {
27 nginx_pid
28 }
29 }
从服务器
1 global_defs {
2 router_id NodeB
3 }
4 vrrp_instance VI_1 {
5 state BACKUP #设置为主服务器
6 interface wlan0 #监测网络接口
7 virtual_router_id 51 #主、备必须一样
8 priority 90 #(主、备机取不同的优先级，主机值较大，备份机值较小,值越大优先级越高)
9 advert_int 1 #VRRP Multicast广播周期秒数
10 authentication {
11 auth_type PASS #VRRP认证方式，主备必须一致
12 auth_pass 1111 #(密码)
13 }
14 virtual_ipaddress {
15 #192.168.1.118/24 #VRRP HA虚拟地址
16 192.168.1.118 #VRRP HA虚拟地址
17 }
18 }
启动root@yanisyu-Aspire-E1-571G:~# keepalived -D -f /usr/local/etc/keepalived/keepalived.conf
cat /root/nginx_pid.sh
#!/bin/bash
# varsion 0.0.2
# 根据一网友说这样做不科学，如果nginx服务起来了，但是我把keepalived 杀掉了，我的理由是，如果nginx down了，我觉得就很难在起来，再有就是nagios 当然要给你报警了啊。不过这位同学说的有道理，所以就稍加改了一下脚本
A=`ps -C nginx --no-header |wc -l` ## 查看是否有 nginx进程 把值赋给变量A
#echo $A;exit;
if [ $A -eq 0 ];then ## 如果没有进程值得为 零
killall keepalived ## 则结束 keepalived 进程
/usr/sbin/nginx -c /etc/nginx/nginx.conf
sleep 3
fi
