keepalived概述：
是Linux下一个轻量级别的高可用解决方案。高可用(High Avalilability,HA)，其实两种不同的含义：广义来讲，是指整个系统的高可用行，狭义的来讲就是之主机的冗余和接管，
1.节点（node）
运行HA进程的一个独立主机，称为节点，节点是HA的核心组成部分，每个节点上运行着操作系统和高可用软件服务，在高可用集群中，节点有主次之分，分别称之为主节点/备份节点，每个节点拥有唯一的主机名，并且拥有属于自己的一组资源，例如，磁盘，文件系统，网络地址和应用服务等，主节点上一般运行着一个或多个应用服务，而备节点一般处于监控状态
2.资源（resource）
资源是一个节点可以控制的实体，并且当节点发生故障时，这些资源能够被其他节点接管，HA集群软件中，可以当做资源的实体有：
（1）磁盘分区、文件系统
（2）IP地址VIP
（3）应用程序服务
（4）NFS文件系统
3.事件（event）
也就是集群中可能发生的事情，例如节点系统故障，网络连通故障，网卡故障，应用程序故障等，这些事情都会发生节点资源发生转移，HA的测试也是基于这些事情来进行的
4.动作（action）
事件发生时HA的响应方式，动作是由shell脚本控制的，例如当某个节点发生故障后，备份节点将通过事先设定好的执行脚本进行服务的关闭或启动，进而接管故障节点的资源*
用途：
keepalived起初是为lvs设计的，专门用来监控集群系统中各个服务节点的状态，它根据layer3,4 & 5交换机制检测每个服务节点的状态，如果某个服务节点出现异常，或工作出现故障，keepaived将检测到，并将出现故障的服务节点从集群系统中剔除，而在故障节点恢复正常后，keepalived又可以自动将此服务节点重新加入到集群中，这些工作全部自动完成，不需要人工干预，需要人工完成的只是修复故障节点。
vrrp协议与工作原理：
在现实的网络环境中，主机之间的通信都是通过配置静态路由完成的，而主机之间的路由器一旦出现故障，通信就会失败，因此在这种通信模式中，路由器就成了一个单点瓶颈，为了解决这个问题就引入了VRRP协议
VRRP协议是一种主备模式的协议，通过VRRP可以在网络发生故障时透明地进行设备切换不影响主机间的数据通信，这其中涉及两个概念：物理路由器和虚拟路由器
VRRP可以将两台或者多台物理路由器设备虚拟成一个虚拟路由器，这个虚拟路由器通过虚拟IP（一个或多个）对外提供服务，二在虚拟路由器内部，是多个物理路由器协同工作，同一时间只有一台物理路由器对外提供服务，这台物理路由器被称之为主路由器（处于master状态角色）。它拥有对外提供的虚拟ip，提供各种网络功能，比如arp请、icmp、数据转发等，二其他物理路由器不拥有对外提供的虚拟ip，也不提供对外网络功能，仅仅接收master的vrrp状态通告信息，这些路由器被统称为备份路由器（处于backup角色）。当主路由器失效时，处于backup角色的备份路由器将重新进行选举，产生一个新的主路由器进入master角色继续对外服务，整个切换过程对于用户来说完全同名
在一个虚拟路由器中，只有处于master角色的路由器会一直发送vrrp数据包，处于backup角色的路由器只接受master发过来的报文信息，用来监控master运行状态，因此，不会发生master抢占的现象，除非它的优先级更高，而当master不可用时，backup也就无法收到master发过来的报文信息，于是就认定master出现故障，接着多台backup就会进行选举，优先级最高的backup将成为新的master，这种选举并进行角色的过程非常快，因此也就保证了服务的持续可用性
注意：这里有一个误区，由于keepalived可以和ipvs一起很好的工作，所以很多初学者都认为keepalived是一个负载均衡的软件，这种理解是错误的。
内核模块:
IPVS:主要用于通过IPVS跟lvs进行整合，是lvs的核心模块，跟lvs一块使用的
NETLINK:主要实现一些网络的功能
用户模块:主要用于高可用
checker:检查服务状态
vrrp stack:用于DS高可用
二、安装配置
1、yum -y install keepalived
2、准备两台相同网段的主机，一台模拟主节点，一台模拟备用节点。
vrrp测试
主节点配置如下：
vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 2 } virtual_ipaddress { 192.168.253.7 } }
备用节点配置：
vrrp_instance VI_1 { #名称自定义但相同 state BACKUP #备用 interface ens33 virtual_router_id 51 #自定义，但要和主节点相同 priority 99 #备用节点通常优先级小于主节点 advert_int 1 authentication { auth_type PASS auth_pass 2 #自定义密码 } virtual_ipaddress { 192.168.253.7 #主备都用相同的虚拟ip地址 } } #注意花括号不能少
综上来说，主备只有状态和优先级不同。
3.测试（一）：主备节点的自动转移
主：systemctl stop keepalived
备 ：systemctl start keepalived
ip a --->inet 192.168.253.7/32 scope global ens33 ,主节点ip地址漂移到备用节点上
以上实验证明keepalived的高可用利用vrrp协议将宕掉的主机ip转移到备用节点上，从而提高可用性。
测试（二）：主节点恢复，IP地址重新漂移回主节点
主：systemctl restart keepalived
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:0c:29:e4:3d:3a brd ff:ff:ff:ff:ff:ff inet 192.168.253.146/24 brd 192.168.253.255 scope global dynamic ens33 valid_lft 1673sec preferred_lft 1673sec inet 192.168.253.7/32 scope global ens33 #发现ip地址回到主节点上
测试（三）：让漂移后的主节点ip不回到恢复后的主节点上。
vrrp_instance VI_1 { state BACKUP #状态与备用节点改为一样的backup interface ens33 virtual_router_id 51 priority 100 advert_int 1 nopreempt #添加无法抢占的命令，因为默认抢占 authentication { auth_type PASS auth_pass 2 } virtual_ipaddress { 192.168.253.7 } }
如果主节点重启服务并且执行ip a命令而没有显示ip的话就证明测试成功。
测试（四）：让两个节点互为备用，节约资源（注意：同一个节点比较修改比在同一个配置文件下的比较修改要清晰。例如v1_1master与v1_1backup）
节点一：（设为v1_1的主节点，v1_2的备用节点）
vrrp_instance VI_1 { state MASTER interface ens33 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 2 } virtual_ipaddress { 192.168.253.7 } } vrrp_instance VI_2 { state BACKUP interface ens33 virtual_router_id 52 priority 99 advert_int 1 authentication { auth_type PASS auth_pass 3 } virtual_ipaddress { 192.168.253.8 } }
节点二：（设为v1_1的备用节点，v1_2的主节点）
vrrp_instance VI_1 { state BACKUP interface ens33 virtual_router_id 51 priority 99 advert_int 1 priority 99 advert_int 1 authentication { auth_type PASS auth_pass 2 } virtual_ipaddress { 192.168.253.7 } } vrrp_instance VI_2 { state MASTER interface ens33 virtual_router_id 52 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 3 } virtual_ipaddress { 192.168.253.8 } }
此设置可使两节点之间任意一台节点宕机，另一台都能顶上，提高高可用性（HA）。
checker测试
作用：在真实提供服务的主机宕机后，能够自动剔除而不是继续发送报文请求。
1.保持上面的配置不变。
2.添加两台real-server（192.168.253.10，192.168.253.147）
3.在两台real-server上都写下以下内容：
vim r1.sh
v#!/bin/bash case $1 in start) echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce ifconfig ens33:0 192.168.253.7/32 broadcast 192.168.253.7 up if [ $? -eq 0 ];then route add -host 192.168.253.7 dev ens33:0 #指定253.7的虚拟ip，此ip为v1_1的主ip,v1_2的备用ip。 fi echo "启动成功" ;; stop) echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce ifconfig ens33:0 down route del -host 192.168.253.7 echo "删除成功" ;; *) echo "usage start|stop" ;;
esac
执行 bash r1.sh #启动
执行route -n #查看此虚拟ip是否被添加
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.253.2 0.0.0.0 UG 100 0 0 ens33
192.168.253.0 0.0.0.0 255.255.255.0 U 100 0 0 ens33
192.168.253.7 0.0.0.0 255.255.255.255 UH 0 0 0 ens3 #发现已添加
此步骤作用在于指定唯一的虚拟路由,arp请求都优先通过这个路由。
4.在两个节点的配置文件中配置real_server。
节点一：
virtual_server 192.168.253.7 80 { delay_loop 3 lb_algo rr lb_kind DR protocol TCP real_server 192.168.253.147 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.253.10 80 { weight 1 HTTP_GET { url { path / status_code 200 } connect_timeout 3 nb_get_retry 3
delay_before_retry 3
}
}
}
节点二:
virtual_server 192.168.253.8 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
real_server 192.168.253.10 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200 #此步骤有错的话不会与后端节点建立lvs联系。就无法通过ipvsadm -L -n查看到realserver的信息。
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.253.147 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
将节点2的虚拟ip指定为192.168.253.8，也就是说通过2节点没有办法check到real-server的损坏与否，因为real-server脚本里指定唯一的虚拟ip为192.168.253.7。
如果尝试会报错timeout。
5.关闭防火墙，开启web服务。
6.在cmd界面curl 192.168.253.7 （real-server指定的虚拟地址），如果能抓取到，再将一台real-server停止web服务，在节点1上执行ipvsadm -L -n如果显示没有这台real-server的ip地址，则证明checker组件自动剔除了宕机的real-server，实验成功。
7.有时候出现curl 虚拟ip只会有一台rea_server做出回应，原因有两个：
1）节点配置出现错误，status_code或者NAT模式没改等。
2）real_server的添加的虚拟出现错误。
8.如果出现 Failed to connect to 192.168.253.250 port 80: Connection refused 的报错
1）real_server端路由添加错误
2）节点配置文件错误比如statu状态的拼写错误
3）appache服务没开启（最有可能）
