Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案,可以利用其来避免单点故障。一个LVS服务会有2台服务器运行Keepalived,一台为主服务器(MASTER),一台为备份服务器(BACKUP),但是对外表现为一个虚拟IP,主服务器会发送特定的消息给备份服务器,当备份服务器收不到这个消息的时候,即主服务器宕机的时候, 备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性。Keepalived是VRRP的完美实现,因此在介绍keepalived之前,先介绍一下VRRP的原理。
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包使用了加密协议进行加密。
[root@localhost ~]# uname -r
2.6.32-696.el6.x86_64
[root@localhost ~]# rpm -q keepalived
keepalived-1.2.13-5.el6_6.x86_64
时间同步:
[root@node2 ~]# ntpdate 192.168.1.200
各主机添加host能相互解析
关闭iptables及selinux
1)、在192.168.1.200及192.168.1.201上安装Keepalived(yum install keepalived -y)
2)、配置Keepalived
192.168.1.200配置文档:
global_defs { //全局配置段
notification_email { //管理员通知邮箱,可不填写
}
notification_email_from root
smtp_server 127.0.0.1 //邮件服务器地址
smtp_connect_timeout 30
router_id LVS_10 //主调度路由器名称,需和备份服务器保持一致
}
vrrp_instance VI_1 { //VRRPD配置段
state MASTER //设置MASTER或BACKUP
interface eth0 //设置VIP物理地址的接口
virtual_router_id 51 //虚拟路由ID号,每组需保持一致
priority 100 //优先级,越大越有限
advert_int 1 //心跳频率(秒)
authentication {
auth_type PASS //组播认证方式
auth_pass 1111
}
virtual_ipaddress {
192.168.1.250/24 dev eth0 label eth0:1 //VIP配置,可以有多个VIP
}
}
virtual_server 192.168.1.250 80 { //LVS段配置,注意端口
delay_loop 3 //健康检测时间
lb_algo wrr //算法rr,wrr,lc,wlc等
lb_kind DR //集群工作模式(nat、dr、tunl、fullnat)
persistence_timeout 0 //会话保持时间
protocol TCP //协议
real_server 192.168.1.202 80 { //realserver配置
weight 1 //权重
TCP_CHECK { //健康检查(多种方式)
connect_port 80 //检测端口
connect_timeout 3 //超时时间
nb_get_retry 3 //重试次数
delay_before_retry 3 //重试间隔
}
}
real_server 192.168.1.203 80 {
weight 1
TCP_CHECK {
connect_port 80
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
192.168.1.201配置与上面类似更改state及priority
192.168.1.202配置:
DR realserver脚本:
#!/bin/bash
#
#script to start LVS DR real server.
# description: LVS DR real server
#
. /etc/rc.d/init.d/functions
VIP=192.168.1.250 #修改你的VIP
host=`/bin/hostname`
case "$1" in
start)
# Start LVS-DR real server on this machine.
/sbin/ifconfig lo down
/sbin/ifconfig lo up
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
/sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
/sbin/route add -host $VIP dev lo:0
;;
stop)
# Stop LVS-DR real server loopback device(s).
/sbin/ifconfig lo:0 down
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
;;
status)
# Status of LVS-DR real server.
islothere=`/sbin/ifconfig lo:0 | grep $VIP`
isrothere=`netstat -rn | grep "lo:0" | grep $VIP`
if [ ! "$islothere" -o ! "isrothere" ];then
# Either the route or the lo:0 device
# not found.
echo "LVS-DR real server Stopped."
else
echo "LVS-DR real server Running."
fi
;;
*)
# Invalid entry.
echo "$0: Usage: $0 {start|status|stop}"
exit 1
;;
esac
执行脚本:
[root@node2 ~]# chmod +x realserver.sh
[root@node2 ~]# ./realserver.sh start
检查相关脚本配置是否正确
ifconfig及cat
在node2上安装httpd后添加测试网页
echo "<h1>node2.psemily.com</h1>" > /var/www/html/index.html
node3类似操作
启动192.168.1.200及192.168.1.201上keepalived后访问VIP:192.168.1.250
下图:图一:调度情况,图二为正常访问,图三为192.168.1.202停止httpd后的访问,图四为停止192.168.1.200后,192.168.1.201的日志
HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK
1)HTTP_GET|SSL_GET
这里有几个要点:
a、两者都有两种检测方式,一种是简单的基于返回码确认;另一种是基于确认后端页面内容hash值,确认前后是否发生变化(是不是感觉有点高端,还有简单的防止页面被篡改的作用,当然,动态页面显然不行);
b、两者都是处理简单的GET请求,基于post返回值确认是否正常,这种方法显然不适用 ,不过POST方式是可以通过MISC_CHECK方式进行支持检测的;
c、两者配置语法上相同,只不过类型名不同而已 。同属于大的web请求范畴,只不过一个走的HTTP协议,一个走的HTTPS协议;
基于状态码检测,配置如下:
real_server 192.168.1.250 80 {
weight 1
HTTP_GET {
url {
path /index.html
status_code 200 #http://192.168.1.250/index.html的返回状态码
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
基于后端页面内容检测,配置如下:
real_server 192.168.1.250 80 {
weight 1
HTTP_GET {
url {
path /index.html
digest 1366dcc22ca042f5e6a91232bc8f4c9f #http://192.168.1.202/index.html的digest值
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
digest是由genhash(通过该命令可以获取页面的hash串)生成,语法如下:
[root@localhost keepalived]# genhash -s 192.168.1.202 -p 80 -u /index.html
MD5SUM = 1366dcc22ca042f5e6a91232bc8f4c9f
2)TCP_CHECK
基于TCP的检测,配置如下:
real_server 192.168.1.250 80 {
weight 100
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80 //检测端口
}
}
3)MISC_CHECK
调用外部配置文件进行检测,配置如下:
MISC_CHECK {
misc_path <STRING>|<QUOTED-STRING># 外部程序或者脚本路径
misc_timeout <INT># 执行脚本的超时时间
misc_dynamic #如果设置了misc_dynamic,healthchecker程序的退出状态码会用来动态调整服务器的权重(weight).
#返回0:健康检查OK,权重不被修改
#返回1:健康检查失败,权重设为0
#返回2-255:健康检查OK,权重设置为:退出状态码-2,比如返回255,那么weight=255-2=253
}
脚本是可以选择传参数还是不传参数的,示例如下:
#不传参配置
real_server 192.168.1.250 80 {
weight 1
MISC_CHECK {
misc_path /usr/local/bin/script.sh
}
}
#传参配置
real_server 192.168.1.250 80 {
weight 1
MISC_CHECK {
misc_path "/usr/local/bin/script.sh arg1 arg2"
}
}
实验中用当所有配置都配置完成后,有浏览器访问VIP时,出现了只调度到一个realserver上的情景,过一段时间后能调度到另外一个realserver上,停止其中一个httpd,浏览器访问时出现不能访问,过段时间才能访问运行的另一个realserver上。
查找网上资料后有以下两种方案:
1、修改persistence_timeout 0 将连接保持时间设置为0,修改后用浏览器访问还是没能解决。用curl可以看出效果
2、ipvsadm的时间
[root@localhost keepalived]# ipvsadm -l --timeout
Timeout (tcp tcpfin udp): 900 120 300
修改时间后访问仍然不行
[root@localhost keepalived]# ipvsadm --set 1 1 1
上述两种方法均不能解决浏览器访问调度到一个realserver上的问题,但是用curl能看出效果,在此先做个记录。