高可用软件keepalived详解

一、高可用软件阐述

在高可用软件领域，我们可能常会听到Heartbeat、Corosync、Pacemaker、keepalived等软件。常见有人问Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好呢？首先我想说明的是，Heartbeat、Corosync是属于同一类型，Keepalived与Heartbeat、Corosync，根本不是同一类型的。Keepalived使用的vrrp协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)；Heartbeat或Corosync是基于主机或网络服务的高可用方式；简单的说就是，Keepalived的目的是模拟路由器的高可用，Heartbeat或Corosync的目的是实现Service的高可用。所以一般Keepalived是实现前端高可用，常用的前端高可用的组合有，就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是实现服务的高可用，常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。总结一下，Keepalived中实现轻量级的高可用，一般用于前端高可用，且不需要共享存储，一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用，且需要共享存储，一般用于多节点的高可用。

这个问题我们说明白了，又有人会问了，那heartbaet与corosync我们又应该选择哪个好啊，我想说我们一般用corosync，因为corosync的运行机制更优于heartbeat，就连从heartbeat分离出来的pacemaker都说在以后的开发当中更倾向于corosync，所以现在corosync+pacemaker是最佳组合。但说实话我对于软件没有任何倾向性，所以我把所有的集群软件都和大家说了一下，我认为不管什么软件，只要它能存活下来都有它的特点和应用领域，只有把特定的软件放在特定的位置才能发挥最大的作用，那首先我们得对这个软件有所有了解。学习一种软件的最好方法，就是去查官方文档。好了说了那么多希望大家有所收获，下面我们来说一说keepalived。

二、Keepalived详解

Keepalived是什么？

Keepalived是集群管理中保证集群高可用的一个服务软件，用来防止单点故障。Keepalived起初就是为了LVS调度节点高可用而设计的，专门用来监控集群系统中各个服务节点的状态。如果某个服务节点出现异常，或工作出现故障，Keepalived将检测到，并将出现故障的服务节点从集群系统中剔除，也就是替LVS做了对后端realserver的健康状态监测。而当故障节点恢复正常后，Keepalived又可以自动将此服务节点重新加入到服务器集群中。这些工作全部自动完成，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。

Keepalived后来实现了VRRP协议的功能，基于VRRP协议来实现的LVS服务高可用方案，可以利用其来避免单点故障。一个LVS服务会有2台服务器运行Keepalived，一台为主服务器（MASTER），一台为备份服务器（BACKUP），但是对外表现为一个虚拟IP，主服务器会发送特定的消息给备份服务器，当备份服务器收不到这个消息的时候，即主服务器宕机的时候，备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。Keepalived是VRRP的完美实现，因此在介绍keepalived之前，先介绍一下VRRP的原理。

VRRP工作机制？

先看两个概念：VRRP路由器和VRRP虚拟路由器

1. VRRP路由器

就是一台物理路由器，只不过上面运行了VRRP协议实现的程序，一台VRRP物理路由器可以位于多个虚拟路由器。

2 .VRRP虚拟路由器

所谓虚拟就是说并不是实际存在的，虚拟路由器通常由多台物理的VRRP路由器通过某种方式组成的，就好比这些物理的路由器都丢到一个池里面去，整个pool对外看起来就像是一台路由器，其实内部有多台虚拟路由器。

然后再来看一下VRRP的工作机制？

VRRP全称Virtual Router Redundancy Protocol，即虚拟路由冗余协议。可以认为是实现路由器高可用的协议，目的就是为了解决静态路由单点故障。VRRP通过一种竞选协议来动态的将路由任务交给LAN中的虚拟路由器的某台VRRP路由器。将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip（该路由器所在局域网内其他机器的默认路由为该vip），master会发组播，当backup收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。Keepalived就是巧用VRRP协议来实现高可用性(HA)的。

VRRP所有的协议报文都是通过IP多播(multicast)包(多播地址224.0.0.18)形式发送的。虚拟路由器由VRID(范围0-255)和一组IP地址组成，对外表现为一个周知的MAC地址。所以，在一个虚拟路由器中，不管谁是MASTER，对外都是相同的MAC和IP(称之为VIP)。客户端主机并不需要因为MASTER的改变而修改自己的路由配置，对客户端来说，这种主从的切换是透明的。

在一个虚拟路由器中，只有作为MASTER的VRRP路由器会一直发送VRRP通告信息(VRRPAdvertisement message)，BACKUP不会抢占MASTER，除非它的优先级(priority)更高。当MASTER不可用时(BACKUP收不到通告信息)，多台BACKUP中优先级最高的这台会被抢占为MASTER。这种抢占是非常快速的(<1s)，以保证服务的连续性。由于安全性考虑，VRRP包使用了加密协议进行加密。

VRRP工作流程？

1) 初始化

路由器启动时，如果路由器的优先级是255(最高优先级，路由器拥有路由器地址)，要发送VRRP通告信息，并发送广播ARP信息通告路由器IP地址对应的MAC地址为路由虚拟MAC，设置通告信息定时器准备定时发送VRRP通告信息，转为MASTER状态；否则进入BACKUP状态，设置定时器检查定时检查是否收到MASTER的通告信息。

2) Master

设置定时通告定时器；
用VRRP虚拟MAC地址响应路由器IP地址的ARP请求；
转发目的MAC是VRRP虚拟MAC的数据包；
如果是虚拟路由器IP的拥有者，将接受目的地址是虚拟路由器IP的数据包，否则丢弃；
当收到shutdown的事件时删除定时通告定时器，发送优先权级为0的通告包，转初始化状态；
如果定时通告定时器超时时，发送VRRP通告信息；
收到VRRP通告信息时，如果优先权为0，发送VRRP通告信息；否则判断数据的优先级是否高于本机，或相等而且实际IP地址大于本地实际IP，设置定时通告定时器，复位主机超时定时器，转BACKUP状态；否则的话，丢弃该通告包；

3）Backup

设置主机超时定时器；
不能响应针对虚拟路由器IP的ARP请求信息；
丢弃所有目的MAC地址是虚拟路由器MAC地址的数据包；
不接受目的是虚拟路由器IP的所有数据包；
当收到shutdown的事件时删除主机超时定时器，转初始化状态；
主机超时定时器超时的时候，发送VRRP通告信息，广播ARP地址信息，转MASTER状态；
收到VRRP通告信息时，如果优先权为0，表示进入MASTER选举；否则判断数据的优先级是否高于本机，如果高的话承认MASTER有效，复位主机超时定时器；否则的话，丢弃该通告包；

VRRP ARP查询处理？

当内部主机通过ARP查询虚拟路由器IP地址对应的MAC地址时，MASTER路由器回复的MAC地址为虚拟的VRRP的MAC地址，而不是实际网卡的 MAC地址，这样在路由器切换时让内网机器觉察不到；而在路由器重新启动时，不能主动发送本机网卡的实际MAC地址。如果虚拟路由器开启的ARP代理 (proxy_arp)功能，代理的ARP回应也回应VRRP虚拟MAC地址。

keepalived架构

keepalived也是模块化设计不同模块负责不同的功能，下面是keepalived的相关模块：core、check、vrrp、libipfwc、libipvs-2.4、libipvs-2.6。

core：是keepalived的核心，负责主进程的启动和维护及全局配置文件的加载解析等。

check：负责healthchecker(健康检查)，包括了各种健康检查方式以及对应的配置的解析（包括LVS的配置解析）。

vrrp：VRRPD子进程就是来实现VRRP协议的。

libipfwc：liipfwc库是配置LVS时会用到的。

libipvs*：配置LVS时会用到。

PS：注意keepalived和LVS完全是两码事只不过他们各负其责相互配合而已。

三、keepalived配置文件

先简单介绍一下Keepalived的安装，一般使用YUM安装即可：

$ yum install keepalived

1	$ yum install keepalived

$ rpm -ql keepalived
/etc/keepalived
/etc/keepalived/keepalived.conf
/etc/sysconfig/keepalived
/usr/bin/genhash
/usr/lib/systemd/system/keepalived.service
/usr/libexec/keepalived
/usr/sbin/keepalived

$ rpm -ql keepalived

/etc/keepalived

/etc/keepalived/keepalived.conf

/etc/sysconfig/keepalived

/usr/bin/genhash

/usr/lib/systemd/system/keepalived.service

/usr/libexec/keepalived

/usr/sbin/keepalived

keepalived只有一个配置文件keepalived.conf，里面主要包括以下几个配置区域，分别是：

global_defs {
    .....
}

vrrp_script {
    ....
}

vrrp_sync_group VG_1 {
     group {
          VI_1
     }
}

vrrp_instance VI_1 {
    .....
    virtual_ipaddress {
      .....
    }
    track_script {
      ....
    } 
}

virtual_server IP:PORT {
    ....
    real_server {
      ....
    }
    real_server {
      ....
    }
    sorry_server 127.0.0.1 80
}

global_defs {

.....

}

vrrp_script {

....

}

vrrp_sync_group VG_1 {

group {

VI_1

}

vrrp_instance VI_1 {

.....

virtual_ipaddress {

.....

}

track_script {

....

}

virtual_server IP:PORT {

....

real_server {

....

}

real_server {

....

}

sorry_server 127.0.0.1 80

}

global_defs区域

主要是配置故障发生时的通知对象以及机器标识。

global_defs {
   notification_email {   //故障发生时给谁发邮件通知;
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc    //通知邮件从哪个地址发出;
   smtp_server 192.168.200.1    //通知邮件的smtp地址;
   smtp_connect_timeout 30      //连接smtp服务器的超时时间;
   router_id LVS_DEVEL          //标识本节点的字条串,通常为hostname,但不一定非得是hostname,故障发生时,邮件通知会用到;
}

global_defs {

notification_email { //故障发生时给谁发邮件通知;

acassen@firewall.loc

failover@firewall.loc

sysadmin@firewall.loc

}

notification_email_from Alexandre.Cassen@firewall.loc //通知邮件从哪个地址发出;

smtp_server 192.168.200.1 //通知邮件的smtp地址;

smtp_connect_timeout 30 //连接smtp服务器的超时时间;

router_id LVS_DEVEL //标识本节点的字条串,通常为hostname,但不一定非得是hostname,故障发生时,邮件通知会用到;

}

vrrp_script区域

提供keepalived维护状态，我们一般进行主从切换测试时都是关闭keepalived或关闭网卡接口，有没有一种方法能实现在不关闭keepalived下或网卡接口来实现维护呢？方法肯定是有的，在keepalived新版本中，支持脚本vrrp_srcipt，具体如何使用大家可以man keepalived.conf查看。下面我们来演示一下具体怎么实现。

vrrp_srcipt chk_schedown { 
     script "[ -e /etc/keepalived/down ] && exit 1 || exit 0"  
     interval 1    //监控间隔;
     weight -5     //减小优先级;  
     fall 2        //监控失败次数;  
     rise 1        //监控成功次数 ; 
}

vrrp_srcipt chk_schedown {

script "[ -e /etc/keepalived/down ] && exit 1 || exit 0"

interval 1 //监控间隔;

weight -5 //减小优先级;

fall 2 //监控失败次数;

rise 1 //监控成功次数 ;

}

然后在vrrp_instance区域使用track_script调用这个脚本，如下：

vrrp_instance VI_1 { 
    ....
    track_script {  
      chk_schedown  
    }
    notify_stop /path/to/to_stop.sh      #表示当master出现问题时,要执行的脚本;
    notify_master /path/to/to_master.sh  #表示当切换到master状态时,要执行的脚本;
    notify_backup /path_to/to_backup.sh  #表示当切换到backup状态时,要执行的脚本;
    notify_fault "/path/fault.sh VG_1"
    notify /path/to/notify.sh
}

vrrp_instance VI_1 {

....

track_script {

chk_schedown

}

notify_stop /path/to/to_stop.sh #表示当master出现问题时,要执行的脚本;

notify_master /path/to/to_master.sh #表示当切换到master状态时,要执行的脚本;

notify_backup /path_to/to_backup.sh #表示当切换到backup状态时,要执行的脚本;

notify_fault "/path/fault.sh VG_1"

notify /path/to/notify.sh

}

然后测试时就可以建立/etc/keepalived/down文件，就会完成维护模式切换。

vrrp_instance区域

用来定义对外提供服务的VIP区域及其相关属性。

vrrp_instance VI_1 {       //实例名称;
    state MASTER           //可以是MASTER或BACKUP,不过当其他节点keepalived启动时会将priority比较大的节点选举为MASTER,因此该项其实没有实质用途;
    interface eth0         //节点固有IP（非VIP）的网卡,用来发VRRP包做心跳检测;
    virtual_router_id 51   //虚拟路由ID,取值在0-255之间,用来区分多个instance的VRRP组播,同一网段内ID不能重复,主备必须为一样;
    priority 100           //用来选举master的,要成为master那么这个选项的值最好高于其他机器50个点,该项取值范围是1-255（在此范围之外会被识别成默认值100）;
    advert_int 1           //检查间隔默认为1秒,即1秒进行一次master选举（可以认为是健康查检时间间隔）;
    authentication {       //认证区域,认证类型有PASS和HA（IPSEC）,推荐使用PASS（密码只识别前8位）;
        auth_type PASS     //默认是PASS认证;
        auth_pass 1111     //PASS认证密码;
    }
    virtual_ipaddress {    //虚拟VIP地址,允许多个,需要配置在interface指定的接口上;
        192.168.200.100
        192.168.200.200
    }
}

vrrp_instance VI_1 { //实例名称;

state MASTER //可以是MASTER或BACKUP,不过当其他节点keepalived启动时会将priority比较大的节点选举为MASTER,因此该项其实没有实质用途;

interface eth0 //节点固有IP（非VIP）的网卡,用来发VRRP包做心跳检测;

virtual_router_id 51 //虚拟路由ID,取值在0-255之间,用来区分多个instance的VRRP组播,同一网段内ID不能重复,主备必须为一样;

priority 100 //用来选举master的,要成为master那么这个选项的值最好高于其他机器50个点,该项取值范围是1-255（在此范围之外会被识别成默认值100）;

advert_int 1 //检查间隔默认为1秒,即1秒进行一次master选举（可以认为是健康查检时间间隔）;

authentication { //认证区域,认证类型有PASS和HA（IPSEC）,推荐使用PASS（密码只识别前8位）;

auth_type PASS //默认是PASS认证;

auth_pass 1111 //PASS认证密码;

}

virtual_ipaddress { //虚拟VIP地址,允许多个,需要配置在interface指定的接口上;

192.168.200.100

192.168.200.200

}

virtual_server区域

在virtual_server区域外还可以设置virtual_server_group，一般在超大型的LVS中用到，一般LVS用不到这东西，因此不多说。

virtual_server 192.168.200.100 443 {
    delay_loop 6             //延迟轮询时间（单位秒）;
    lb_algo rr               //后端调度算法（load balancing algorithm）;
    lb_kind DR               //LVS工作模式NAT/DR/TUN;
    nat_mask 255.255.255.0
    persistence_timeout 50   //会话保持时间,秒为单位,即同一个用户在50秒内被分配到同一个后端realserver;
    protocol TCP             //健康检查用的是TCP还是UDP;

    real_server 192.168.200.200 80 {    //后端RealServer的IP和端口(可以有多个real_server);
        weight 1                        //后端RealServer的权重,数值越大,权重越高,接收的请求越多;
        HTTP_GET {                      //后端监控检查方法为SSL_GET/HTTP_GET;
            url {                       //URL的方式检查后端监控状态;
              path /testurl/test.jsp    //path表示请求RealSerserver上的路径;
              digest ff20ad2481f97b1754ef3e12ecd3a9cc   //表示用genhash算出的结果进行比较;
              #status_code 200                          //也可以使用请求状态码;
            }
            connect_timeout 3           //连接超时时间;
            nb_get_retry 3              //重连次数;
            delay_before_retry 3        //重连间隔时间;
            connect_port 80             //连接的端口;
        }
    }
    sorry_server 127.0.0.1 80
}

virtual_server 192.168.200.100 443 {

delay_loop 6 //延迟轮询时间（单位秒）;

lb_algo rr //后端调度算法（load balancing algorithm）;

lb_kind DR //LVS工作模式NAT/DR/TUN;

nat_mask 255.255.255.0

persistence_timeout 50 //会话保持时间,秒为单位,即同一个用户在50秒内被分配到同一个后端realserver;

protocol TCP //健康检查用的是TCP还是UDP;

real_server 192.168.200.200 80 { //后端RealServer的IP和端口(可以有多个real_server);

weight 1 //后端RealServer的权重,数值越大,权重越高,接收的请求越多;

HTTP_GET { //后端监控检查方法为SSL_GET/HTTP_GET;

url { //URL的方式检查后端监控状态;

path /testurl/test.jsp //path表示请求RealSerserver上的路径;

digest ff20ad2481f97b1754ef3e12ecd3a9cc //表示用genhash算出的结果进行比较;

#status_code 200 //也可以使用请求状态码;

}

connect_timeout 3 //连接超时时间;

nb_get_retry 3 //重连次数;

delay_before_retry 3 //重连间隔时间;

connect_port 80 //连接的端口;

}

sorry_server 127.0.0.1 80

}

这里需要重点说几个参数：

persistence_timeout

会话保持时间，单位是秒，这个选项对动态网页是非常有用的，为集群系统中的session共享提供了一个很好的解决方案。有了这个会话保持功能，用户的请求会被一直分配到某个服务节点，直到超过这个会话的保持时间。需要注意的是，这个会话保持时间是最大无响应超时时间，也就是说，用户在操作动态页面时，如果在50秒内没有执行任何操作，那么接下来的操作会被分发到另外的节点，但是如果用户一直在操作动态页面，则不受50秒的时间限制。另外当Keepalived配合LVS一起工作时，关于会话保持还要结合LVS的超时时间（ipvsadm -Ln –timeout）。

HTTP_GET

常用的健康检查方式健康检查方式一共有HTTP_GET、SSL_GET、TCP_CHECK、SMTP_CHECK和MISC_CHECK等。如果使用TCP_CHECK的话配置如下：

TCP_CHECK { 
   connect_timeout 5
   nb_get_retry 3
   delay_before_retry 3
   connect_port 80
}

TCP_CHECK {

connect_timeout 5

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

sorry_server

如果所有realserver都down机，怎么处理？是不是用户就没法打开，还是提供一下维护页面呢？sorry_server就是用来干这个事情的，当后端realserver都挂掉了之后，就会访问sorry_server定义的主机地址，一般在负载均衡开一个web即可。

四、注意事项

在配置keepalived.conf时，需要特别注意配置文件的语法格式以及出现重复的VIP，因为keepalived在启动时并不检测配置文件的正确性，即使没有配置文件，keepalived也能照样启动，所以一定要保证配置文件的正确性。本人曾经在线上业务就配置过重复的VIP地址和端口，Reload keepalived之后就覆盖了原来的VIP地址和端口从而导致业务出问题了。当发现后立马把此VIP的端口改掉（作用恢复原来的地址），再次reload时发现此操作无法生效，不得以进行了restart操作。

在默认情况下，keepalived在启动时会查找/etc/keepalived/keepalived.conf配置文件，如果配置文件放在了其他路径下，可以通过“keepalived -f”参数指定配置文件的路径即可。

如果您觉得本站对你有帮助，那么可以支付宝扫码捐助以帮助本站更好地发展，在此谢过。