keepalived介绍和配置
keepalived介绍keepalived通过提供一个浮动的VIP(vrrp虚拟路由协议)，防止单点故障导致业务无法访问，这样可以实现一个简单的双热备高可用功能
keepalived有三种监听模式layer3、4、5，分别工作在TCP/IP、TCP及应用层下
layer3工作时，会定期向服务器群集中发送一个ICMP的数据包(即ping)，如果某台服务器没有响应数据包请求时，keepalived则会视为此台服务器不能提供服务，则在服务器群集里把它剔除，运用场景：来判断某台服务器非法关机
layer4方式工作：keepalived会向服务器群集里发送TCP的数据包，主要监听TCP端口来判断是否在正常状态，如果发现该端口无法访问及没有启动(如80)，则剔除掉这台服务器
layer5工作方式：layer5比layer3、4要复杂，占用带宽也要多一些，根据用户设定检查程序是否正常，如果与用户设定不符。keepalived则剔除这台机器
VIP：在主机上虚拟出来的一个IP，仍然占用网段中的一个ip，用于多台服务器真实IP的映射，通过VIP对外提供服务
当网站访问量很大时，单节点已经支撑不了这么多的流量，为了提高性能实现高可用的稳定性，我们会使用LVS+keepalived的负载均衡解决方案
keepalived功能
keepalived通过VRRP(virtual Router Redundancy Protocl) 来实现高可用
VRRP协议中将多台功能相同的路由器组成一组，组内会有一个master角色和一个或多个backup角色
master角色会通过组播形式向各个backup发送VRRP数据包，当backup收不到master发送来的数据包时，就会认为master宕机，然后会根据多个backup之间的优先级高低顺序来选举新的master
keepalived有三个工作模块，分别是core、check和vrrp，core模块为keepalived的核心，负责主进程启动、维护及全局配置文件的加载和解析，check模块负责健康检查，vrrp模块来实现VRRP路由冗余协议的
用keepalived配置高可用群集
测试环境
主服务器：192.168.1.223
从服务器：192.168.1.220
系统：centos 7
网卡名称:enp0s3
这里以nginx服务作为高可用的对象
其中一台是使用yum安装的nginx服务，主要是用于测试，可以使用systemctl启动
使用yum安装keepalived
安装完成keepalived后，编辑keepalived的配置文件
主服务器角色上配置master和比从服务器高的优先级，这个数值越大优先级越高。使用priority指定优先级
#vim /etc/keepalived/keepalived.conf
global_defs {
notification_email {
linux@linux.com
}
notification_email_from root@linux.com
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id LVS_DEVEL
}
vrrp_script chk_nginx {
script "/usr/local/sbin/nginx.sh" #定义服务检查脚本用于服务异常挂起时尝试启动的操作
interval 3
}
vrrp_instance VI_1 {
state MASTER #备用服务器上为BACKUP
interface eth0 #master上监听的是eth0端口
virtual_router_id 51
priority 100 #优先级，备用服务器上为90
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.130 #虚拟IP，用于两台服务器对外提供访问的虚拟地址
}
track_script {
chk_nginx #加载服务脚本监测的模块，也就是vrrp_script定义的服务重启尝试脚本文件
}
}
virtual_server 192.168.1.130 80 {
delay_loop 6 #每6秒查询realserver状态
lb_algo rr #lvs算法，指定一台服务器接受多少请求
lb_kind DR #Direct Route数据传输的路由模式
persistence_timeout 0 #同一ip的链接60秒内被分配到同一台realserver上
protocol TCP #使用TCP协议来检查realserver
real_server 192.168.1.223 80 {
weight 100 #权重，用于衡量高可用服务器之间分配处理请求的优先级
TCP_CHECK {
connect_timeout 10 #心跳监测，10秒无响应超时
nb_get_retry 3 #心跳网络发生中断后重新连接尝试次数
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.1.220 80 {
weight 100
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
从上拷贝主的配置，修改为slave角色，把优先级设置比主要低，因为如果主发生故障且恢复后，因为主故障后，从服务器会由sbackup变为master。如果优先级没有明确指定或者两边都一致的话，主服务器恢复后，会比较两边的优先级，这时候会发生优先级相同的情况，这就导致master和backup会互相争夺主的角色
从上没有安装nginx服务，使用yum安装nginx，仅用于测试
# vim /etc/keepalived/keepalived.conf
lobal_defs {
notification_email {
linux@linux.com
}
notification_email_from root@linux.com
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id LVS_DEVEL
}
vrrp_script chk_nginx {
script "/usr/local/sbin/nginx.sh"
interval 3
}
vrrp_instance VI_1 {
state BACKUP
interface enp0s3
virtual_router_id 51
priority 90
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.123
}
track_script {
chk_nginx
}
}
virtual_server 192.168.1.123 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 0
protocol TCP
real_server 192.168.1.234 80 {
weight 100
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.1.223 80 {
weight 100
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
vrrp_script指定的检测脚本，下面则使用track_script来加载这个脚本的模块
检查nginx的脚本内容
主上写入脚本内容，nginx启动方式需要结合安装时的方式，是否有nginx的启动脚本，如果没有启动脚本，那么就需要使用systemctl的方式启动
#！/bin/bash
#时间变量，用于记录日志
d=`date --date today +%Y%m%d_%H:%M:%S`
#计算nginx进程数量
n=`ps -C nginx --no-heading|wc -l`
#如果进程为0，则启动nginx，并且再次检测nginx进程数量，
#如果还为0，说明nginx无法启动，此时需要关闭keepalived
if [ $n -eq "0" ]; then
systemctl start nginx
n2=`ps -C nginx --no-heading|wc -l`
if [ $n2 -eq "0" ]; then
echo "$d nginx down,keepalived will stop" >> /var/log/check_ng.log
systemctl stop keepalived
fi
fi
更改脚本权限，让keepalive有权限去启动nginx服务
在主上尝试暂停nginx，因为keepalive监听着nginx服务，一旦nginx服务停止，keepalived则会尝试着启动nginx
# ps -aux |grep nginx
root 6318 0.0 0.2 120812 2092 ? Ss 10:45 0:00 nginx: master process /usr/sbin/nginx
nginx 6319 0.0 0.3 121276 3344 ? S 10:45 0:00 nginx: worker process
root 6366 0.0 0.0 112724 972 pts/1 R+ 10:46 0:00 grep --color=auto nginx
# systemctl stop nginx
# ps -aux |grep nginx
# ps -aux |grep nginx
root 6466 0.0 0.2 120812 2088 ? Ss 10:46 0:00 nginx: master process /usr/sbin/nginx
nginx 6467 0.0 0.3 121276 3128 ? S 10:46 0:00 nginx: worker process
root 6472 0.0 0.0 112724 976 pts/1 R+ 10:46 0:00 grep --color=auto nginx
测试停止主上的keepalived，查看从上是否会主动绑定192.168.1.130这个ip
我们先来看主上监听的ip，然后暂停主上的keepalived服务并再次查看绑定的ip
http://i2.运维网.com/images/blog/201809/06/1a448dadd2e9a953a7d96170824c6d74.png
再从服务器上查看从上的监听情况
http://i2.运维网.com/images/blog/201809/06/70e7eb02dc0ebdd7061b1f756ddd23ba.png
可见监听的绑定ip从主上转移到从服务器，但是主服务器恢复后，keepalived主从之间的从服务器并不会把绑定ip归还给主服务器。原因是keepalived中没有配置主动抢占绑定这个配置，所以主恢复后不会去主动请求绑定VIP192.168.1.130的。恢复时首先需要把主的所有服务启动正常，然后再暂停从上的keepalived，否则会可能造成从keepalived暂停后，而你主服务器上的keepalived还没去启动。这样就出现虚拟的ip没有绑定任何一台服务器，造成业务上的访问中断
页:
[1]