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

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

(2).执行脚本
track_script {
   chk_schedown #执行chk_schedown脚本
}

(3).修改配置文件
master:
[root@master ~]# cat /etc/keepalived/keepalived.conf  
! Configuration File for keepalived
global_defs {
   notification_email {  
     15251076067@163.com  
   }  
   notification_email_from root  
   smtp_server 127.0.0.1  
   smtp_connect_timeout 30  
   router_id LVS_DEVEL  
}
vrrp_script chk_schedown { #定义vrrp执行脚本  
   script "[ -e /etc/keepalived/down ] && exit 1 || exit 0" #查看是否有down文件，有就进入维护模式  
   interval 1 #监控间隔时间  
   weight -5 #降低优先级  
   fall 2 #失败次数  
   rise 1 #成功数次  
}
vrrp_instance VI_1 {
    state MASTER  
    interface eth0  
    virtual_router_id 51  
    priority 101  
    advert_int 1  
    authentication {  
        auth_type PASS  
        auth_pass 1111  
    }  
    virtual_ipaddress {  
        192.168.18.200  
    }  
    track_script { #执行脚本  
        chk_schedown  
    }  
}
virtual_server 192.168.18.200 80 {
    delay_loop 6  
    lb_algo rr  
    lb_kind DR  
    nat_mask 255.255.255.0  
    protocol TCP
    real_server 192.168.18.201 80 {
        weight 1  
        HTTP_GET {  
            url {  
              path /  
          status_code 200  
            }  
            connect_timeout 2  
            nb_get_retry 3  
            delay_before_retry 1  
        }  
    }  
    real_server 192.168.18.202 80 {  
        weight 1  
        HTTP_GET {  
            url {  
              path /  
              status_code 200  
            }  
            connect_timeout 2  
            nb_get_retry 3  
            delay_before_retry 1  
        }  
    }  
   sorry_server 127.0.0.1 80  
}

slave:
[root@slave ~]# cat /etc/keepalived/keepalived.conf  
! Configuration File for keepalived
global_defs {
   notification_email {  
     15251076067@163.com  
   }  
   notification_email_from root  
   smtp_server 127.0.0.1  
   smtp_connect_timeout 30  
   router_id LVS_DEVEL  
}
vrrp_script chk_schedown {
   script "[ -e /etc/keepalived/down ] && exit 1 || exit 0"  
   interval 1  
   weight -5  
   fall 2  
   rise 1  
}
vrrp_instance VI_1 {
    state BACKUP  
    interface eth0  
    virtual_router_id 51  
    priority 100  
    advert_int 1  
    authentication {  
        auth_type PASS  
        auth_pass 1111  
    }  
    virtual_ipaddress {  
        192.168.18.200  
    }  
    track_script {  
    chk_schedown  
    }
}
virtual_server 192.168.18.200 80 {
    delay_loop 6  
    lb_algo rr  
    lb_kind DR  
    nat_mask 255.255.255.0  
    protocol TCP
    real_server 192.168.18.201 80 {
        weight 1  
        HTTP_GET {  
            url {  
              path /  
          status_code 200  
            }  
            connect_timeout 2  
            nb_get_retry 3  
            delay_before_retry 1  
        }  
    }  
    real_server 192.168.18.202 80 {  
        weight 1  
        HTTP_GET {  
            url {  
              path /  
              status_code 200  
            }  
            connect_timeout 2  
            nb_get_retry 3  
            delay_before_retry 1  
        }  
    }  
    sorry_server 127.0.0.1 80

(4).测试
master:
[root@master keepalived]# touch down #新建一下down文件
[root@master keepalived]# ll
总用量 4  
-rw-r--r-- 1 root root    0 8月  22 13:39 down  
-rw-r--r-- 1 root root 1317 8月  22 13:35 keepalived.conf
[root@master keepalived]# tail -f /var/log/messages #查看一下日志
Aug 22 13:43:52 master Keepalived_vrrp[12003]: VRRP_Instance(VI_1) Entering MASTER STATE  
Aug 22 13:43:52 master Keepalived_vrrp[12003]: VRRP_Instance(VI_1) setting protocol VIPs.  
Aug 22 13:43:52 master Keepalived_vrrp[12003]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.18.200  
Aug 22 13:43:52 master Keepalived_vrrp[12003]: VRRP_Instance(VI_1) Received higher prio advert  
Aug 22 13:43:52 master Keepalived_vrrp[12003]: VRRP_Instance(VI_1) Entering BACKUP STATE  
Aug 22 13:43:52 master Keepalived_vrrp[12003]: VRRP_Instance(VI_1) removing protocol VIPs.  
Aug 22 13:43:52 master Keepalived_healthcheckers[12002]: Netlink reflector reports IP 192.168.18.200 added  
Aug 22 13:43:52 master Keepalived_healthcheckers[12002]: Netlink reflector reports IP 192.168.18.200 removed  
Aug 22 13:43:52 master Keepalived_healthcheckers[12002]: SMTP alert successfully sent.  
Aug 22 13:43:52 master Keepalived_healthcheckers[12002]: SMTP alert successfully sent.  
^C  
[root@master keepalived]# ip add show #查看VIP  
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN   
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00  
    inet 127.0.0.1/8 scope host lo  
    inet6 ::1/128 scope host   
       valid_lft forever preferred_lft forever  
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000  
    link/ether 00:0c:29:4b:a1:85 brd ff:ff:ff:ff:ff:ff  
    inet 192.168.18.208/24 brd 192.168.18.255 scope global eth0  
    inet6 fe80::20c:29ff:fe4b:a185/64 scope link   
       valid_lft forever preferred_lft forever

slave:
[root@slave ~]# ip addr show #查看一下VIP已转移到slave上
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN   
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00  
    inet 127.0.0.1/8 scope host lo  
    inet6 ::1/128 scope host   
       valid_lft forever preferred_lft forever  
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000  
    link/ether 00:0c:29:f9:e6:26 brd ff:ff:ff:ff:ff:ff  
    inet 192.168.18.207/24 brd 192.168.18.255 scope global eth0  
    inet 192.168.18.200/32 scope global eth0  
    inet6 fe80::20c:29ff:fef9:e626/64 scope link   
       valid_lft forever preferred_lft forever

好了，自写监测脚本，完成维护模式切换，到这里就演示成功，下面我们来解决最后一个问题，就是keepalived主从切换的邮件通告。

二、Keepalived详解

1.Keepalived 定义

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

2.VRRP 协议简介

在现实的网络环境中，两台需要通信的主机大多数情况下并没有直接的物理连接。对于这样的情况，它们之间路由怎样选择？主机如何选定到达目的主机的下一跳路由，这个问题通常的解决方法有二种：

• 在主机上使用动态路由协议(RIP、OSPF等)
• 在主机上配置静态路由
  
  

很明显，在主机上配置动态路由是非常不切实际的，因为管理、维护成本以及是否支持等诸多问题。配置静态路由就变得十分流行，但路由器(或者说默认网关default gateway)却经常成为单点故障。VRRP的目的就是为了解决静态路由单点故障问题，VRRP通过一竞选(election)协议来动态的将路由任务交给LAN中虚拟路由器中的某台VRRP路由器。

3.VRRP 工作机制

       在一个VRRP虚拟路由器中，有多台物理的VRRP路由器，但是这多台的物理的机器并不能同时工作，而是由一台称为MASTER的负责路由工作，其它的都是BACKUP，MASTER并非一成不变，VRRP让每个VRRP路由器参与竞选，最终获胜的就是MASTER。MASTER拥有一些特权，比如，拥有虚拟路由器的IP地址，我们的主机就是用这个IP地址作为静态路由的。拥有特权的MASTER要负责转发发送给网关地址的包和响应ARP请求。

       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包使用了加密协议进行加密。

4.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有效，复位主机超时定时器；否则的话，丢弃该通告包；
  
  

5.ARP查询处理

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

一、前言

       这篇文章是前几篇文章的总结，我们先简单的总结一下我们前面讲解的内容，前面我们讲解了，LVS（负载均衡器）、Heartbeat、Corosync、Pacemaker、Web高可用集群、MySQL高可用集群、DRDB、iscsi、gfs2、cLVM等，唯一没有讲解的就是LVS可用，也就是前端高可用，我们这一篇博文主要讲解内容。在说这个之前我们得和大家讨论一个问题，也是好多博友问的问题。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。