Keepalived介绍 , 配置说明 , 及实际应用

奥德赛F9

　　1. Keepalived介绍
　　Keepalived是一个基于VRRP协议来实现的服务高可用方案，可以利用其来避免IP单点故障，类似的工具还有heartbeat、corosync、pacemaker。但是它一般不会单独出现，而是与其它负载均衡技术（如lvs、haproxy、nginx）一起工作来达到集群的高可用。
　　1.1 VRRP协议
　　VRRP全称 Virtual Router Redundancy Protocol，即 虚拟路由冗余协议。可以认为它是实现路由器高可用的容错协议，即将N台提供相同功能的路由器组成一个路由器组(Router Group)，这个组里面有一个master和多个backup，但在外界看来就像一台一样，构成虚拟路由器，拥有一个虚拟IP（vip，也就是路由器所在局域网内其他机器的默认路由），占有这个IP的master实际负责ARP相应和转发IP数据包，组中的其它路由器作为备份的角色处于待命状态。master会发组播消息，当backup在超时时间内收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，保证路由器的高可用。
　　在VRRP协议实现里，虚拟路由器使用 00-00-5E-00-01-XX 作为虚拟MAC地址，XX就是唯一的 VRID （Virtual Router IDentifier），这个地址同一时间只有一个物理路由器占用。在虚拟路由器里面的物理路由器组里面通过多播IP地址 224.0.0.18 来定时发送通告消息。每个Router都有一个 1-255 之间的优先级别，级别最高的（highest priority）将成为主控（master）路由器。通过降低master的优先权可以让处于backup状态的路由器抢占（pro-empt）主路由器的状态，两个backup优先级相同的IP地址较大者为master，接管虚拟IP。

　　与heartbeat/corosync等比较
　　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是最佳组合。
　　1.2 Keepalived 总体介绍

　　keepalive是由一个主进程(Control Plane) , 生成两个子进程(Checkers & VRRP Stack)
　　VRRP Stack : 是整个keepalive功能实现的核心子进程 ;
　　Checkers : 主要用于检测real server的健康状态 , 可以基于TCP Check , http_get , https_get , misc_get等多种方法;
　　除了上述的两个重要的子进程 , 还有其他辅助组件 :
　　控制组件 : 主进程 (Control Plane) , 主进程除了生成两个子进程工作外 , 其本身也是配置文件分析器 ;
　　ipvs wrapper : 起初keepalive 是为了ipvs而生 , 所以 ipvs wrapper 是用于生成ipvs规则的工具(此处不用安装ipvsadm也能生成ipvs规则)
　　watch dog : 负责替主进程检测两个子进程 ( Checkers 和 VRRP Stack ) 的健康状态
　　1.3 HA Cluster的配置前提
　　(1) 各节点时间必须同步 ; (可使用ntp , chrony 命令 , 与时钟服务器进行时间同步 , 时间可以不是国际时间等实际时间 , 但各HA Cluster的时间必须一样 )
　　(2) 确保iptables 及selinux 不会成为阻碍 ;
　　(3) 各节点之间可以通过主机名互相通信 ( 对KA 并非必须 ) ;
　　(4) 各节点之间的root 用户基于密钥认证的ssh互相通信 ;
　　

　　

　　==========================================================
　　

　　

　　2. keepalived实现LA Cluster高可用
　　

　　

　　2.1 安装
　　~]# yum install -y keepalived
　　~]# keepalived -v
　　Keepalived v1.2.13 (11/20,2015)
　　

　　

　　

　　2.2 编辑配置文件 /etc/keepalived/keepalived.conf
　　首先需要说明一下keepalived.conf的配置语法
　　配置虚拟路由器：
　　vrrp_instance  {
　　....
　　}
　　
　　专用参数：
　　state MASTER|BACKUP：当前节点在此虚拟路由器上的初始状态；只能有一个是MASTER，余下的都应该为BACKUP；
　　interface IFACE_NAME：绑定为当前虚拟路由器使用的物理接口；
　　virtual_router_id VRID：当前虚拟路由器的惟一标识，范围是0-255；
　　priority 100：当前主机在此虚拟路径器中的优先级；范围1-254；
　　advert_int 1：vrrp通告的时间间隔；
　　authentication {
　　auth_type AH|PASS
　　auth_pass
　　}
　　virtual_ipaddress {
　　/ brd  dev  scope  label
　　192.168.200.17/24 dev eth1
　　192.168.200.18/24 dev eth2 label eth2:1
　　}
　　-track_interface {
　　eth0
　　eth1
　　...
　　}
　　配置要监控的网络接口，一旦接口出现故障，则转为FAULT状态；
　　nopreempt：定义工作模式为非抢占模式；
　　preempt_delay 300：抢占式模式下，节点上线后触发新选举操作的延迟时长；
　　
　　定义通知脚本：
　　notify_master |：当前节点成为主节点时触发的脚本；
　　notify_backup |：当前节点转为备节点时触发的脚本；
　　notify_fault |：当前节点转为“失败”状态时触发的脚本；
　　
　　notify |：通用格式的通知触发机制，一个脚本可完成以上三种状态的转换时的通知；
　　虚拟服务器：
　　配置参数：
　　virtual_server IP port |
　　virtual_server fwmark int
　　{
　　...
　　real_server {
　　...
　　}
　　...
　　}
　　
　　常用参数：
　　 delay_loop ：服务轮询的时间间隔；
　　 lb_algo rr|wrr|lc|wlc|lblc|sh|dh：定义调度方法；
　　 lb_kind NAT|DR|TUN：集群的类型；
　　 persistence_timeout ：持久连接时长；
　　 protocol TCP：服务协议，仅支持TCP；
　　sorry_server  ：备用服务器地址；
　　real_server   {
　　 weight
　　 notify_up |
　　 notify_down |
　　 HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... }：定义当前主机的健康状态检测方法；
　　}
　　
　　HTTP_GET|SSL_GET(需要定义在real server配置段中) {
　　url {
　　path ：定义要监控的URL；
　　status_code ：判断上述检测机制为健康状态的响应码；
　　digest ：判断上述检测机制为健康状态的响应的内容的校验码；
　　}
　　nb_get_retry ：重试次数；
　　delay_before_retry ：重试之前的延迟时长；
　　connect_ip ：向当前RS的哪个IP地址发起健康状态检测请求
　　connect_port ：向当前RS的哪个PORT发起健康状态检测请求
　　bindto ：发出健康状态检测请求时使用的源地址；
　　bind_port ：发出健康状态检测请求时使用的源端口；
　　connect_timeout ：连接请求的超时时长；
　　}
　　
　　 TCP_CHECK (需要定义在real server配置段中) {
　　connect_ip ：向当前RS的哪个IP地址发起健康状态检测请求
　　connect_port ：向当前RS的哪个PORT发起健康状态检测请求
　　bindto ：发出健康状态检测请求时使用的源地址；
　　bind_port ：发出健康状态检测请求时使用的源端口；
　　connect_timeout ：连接请求的超时时长；
　　}
　　在第一台director配置keepalived.conf , 第一个vrrp中state为master , 第二个vrrp中state为backup , 以达到互为主备状态

　　将配置文件复制给第二台 , 当然state , 以及 priority 中的值需要调整过来 ;
　　两边服务均启动
　　第一台director日志 , 如下图 :





　　从日志文件中可以看出 , 进程会先读取配置文件 , 人后调整状态为master , 继而发送arp广播
　　第二台director日志  :

　　从日志可看出 , 读取配置文件 , 由于检测到从组播地址中获取到优先级比它高的心跳信息 , 所以status转为BACKUP
　　回看director no:1 的 IP 地址可知道 (使用命令 ip a l   或者 ifconfig )
　　vip已按照在配置文件所设定的进行配置了

　　

　　

　　

　　

　　

　　2.3 编写通知脚本,并将通知脚本添加到vrrp配置段中 :

　　编写通知脚本 , 当vrrp发生变化时 , 以邮件方式通知管理人员(在实际生产环境 , contact可填写实际的邮箱地址)

　　通知脚本直接添加在vrrp定义配置文中
　　当运行命令停止或者启动keepalived.service时 , 都会触发脚本 , 通知管理员

　　

　　

　　

　　

　　2.4 添加real server
　　准备两real server (web1 : 10.1.252.3 ; web2 : 10.1.35.11 ) , 分别安装httpd已作web应用 ,两web服务上的页面分别标编辑不同内容 , 以便检测测试效果
　　
　　

　　

　　编辑keepalived.conf文件 , 添加real server配置段
　　
　　

　　

　　real server 要事前设置好vip等配置 , 以及限制arp广播及禁止arp响应(特别重要)

　　
　　配置好则再次启动( 注意keepalived.service 不支持 reloa , 必须先stop 然后再start ,以达到重启服务来再次读取配置文件 )
　　

　　安装ipvsadm来查看ipvs规则生成
　　  ~]# yum install -y ipvsadm

　　  ~]# ipvsadm -Ln

　　

　　在客户机检测调度效果
　　
　　关闭第一台director的keepalived.service , 第二台direc 便会检测不到第一台director的keepalived.service的心跳信息 , 会立即将资源抢占过来 :

　　但是web服务丝毫不受影响

　　而且两台director也会受到邮件通知
　　

　　

　　

　　2.5 添加脚本 , 监控director
　　在配置文件中 , 脚本定义以及调用脚本的语法 ( 切记 : 使用脚本的顺序为 : 先定义 , 后使用 )
　　vrrp_script  {
　　script ""
　　interval INT
　　weight -INT
　　}
　　
　　track_script {
　　SCRIPT_NAME_1
　　SCRIPT_NAME_2
　　...
　　}
　　

　　脚本的意思为 :
　　每隔1秒钟(interval 1) , 检测 /etc/keepalived/down 文件是否存在 , 存在退出码为1 , 且权重值减5(weight -5) ; 否则正常退出
　　实例 :

　　当touch down 文件的时候 , 权重值减5 , 比backup的权重值要小 , 也因为之前已经定义了notify_backup通知机制 , 会立即收到邮件通知 , 而且ip也发生了转移

　　将down文件删除后 , 权重值恢复 , 资源回抢 , 可实现无需stop 后又 start 将服务进行上下线 ;
　　最后在vrrp_instance 实例中调用脚本 ; 日常维护工作量的大小 , 有时候取决于脚本的强大与否 ;