keepalived高可用性与heartbeat区别

发布时间:2015-09-04 13:58:24 阅读:1380次

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

如有问题,可以QQ搜索群1028468525加入群聊,欢迎一起研究技术

支付宝 微信

有疑问联系站长,请联系QQ:QQ咨询

转载请注明:keepalived高可用性与heartbeat区别 出自老鄢博客 | 欢迎分享