标签：lvs keepalived 实现
一、Keepalived简介及VRRP原理
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包使用了加密协议进行加密。
二、LVS+Keepalived实现前端高可用实现
1、 实验环境
[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
2、配置Keepalived
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
3、配置realserver
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类似操作
4、验证
启动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的日志
5、Keepalived的健康检测
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"
}
}6、实验中遇到的问题
实验中用当所有配置都配置完成后，有浏览器访问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能看出效果,在此先做个记录。
本文出自 “淡淡的咸” 博客，请务必保留此出处http://psemily.blog.51cto.com/2970036/1972175
标签：lvs keepalived 实现
原文地址：http://psemily.blog.51cto.com/2970036/1972175
