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。
二、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的案例。
一、健康检查方式
keepalived对后端realserver的健康检查方式主要有以下几种
TCP_CHECK:工作在第4层,keepalived向后端服务器发起一个tcp连接请求,如果后端服务器没有响应或超时,那么这个后端将从服务器池中移除。
HTTP_GET:工作在第5层,向指定的URL执行http请求,将得到的结果用md5加密并与指定的md5值比较看是否匹配,不匹配则从服务器池中移除;此外还可以指定http返回码来判断检测是否成功。HTTP_GET可以指定多个URL用于检测,这个一台服务器有多个虚拟主机的情况下比较好用。
SSL_GET:跟上面的HTTP_GET相似,不同的只是用SSL连接
MISC_CHECK:用脚本来检测,脚本如果带有参数,需将脚本和参数放入双引号内。脚本的返回值需为:
0) 检测成功
1) 检测失败,将从服务器池中移除
2-255)检测成功;如果有设置misc_dynamic,权重自动调整为 退出码-2,如退出码为200,权重自动调整为198=200-2。
SMTP_CHECK:用来检测邮件服务的smtp的
二、相关配置:
delay_loop 隔多长时间做一次健康检测,单位为秒
connect_timeout 连接超时时间,单位为秒
nb_get_retry 检测失败后的重试次数,如果达到重试次数仍然失败,将后端从服务器池中移除。
delay_before_retry 失败重试的间隔时间,单位为秒
Keepalived健康检查方式配置
HTTP_GET|SSL_GET
HTTP_GET | SSL_GET
{
url {
path /# HTTP/SSL 检查的url 可以是多个
digest # HTTP/SSL 检查后的摘要信息 用工具genhash生成
status_code 200# HTTP/SSL 检查返回的状态码
}
connect_port 80 # 连接端口
bindto
connect_timeout 3 # 连接超时时间
nb_get_retry 3 # 重连次数
delay_before_retry 2 #连接间隔时间
}
# END OF HTTP_GET|SSL_GET
TCP健康检查方式
TCP_CHECK {
connect_timeout 5 #连接超时时间
nb_get_retry 3#重连次数
delay_before_retry 3 #重连间隔时间
connect_port 80 #健康检查的端口
} # TCP_CHECK
SMTP健康检查方式
SMTP_CHECK {
host {
connect_ip
connect_port # 默认检查端口25
}
connect_timeout
retry
delay_before_retry
helo_name | # "请求命令参数,可选
} #SMTP_CHECK
MISC
MISC_CHECK {
misc_path |# 外部程序或者脚本路径
misc_timeout # 执行脚本的超时时间
misc_dynamic#如果设置了misc_dynamic,healthchecker程序的退出状态码会用来动态调整服务器的权重(weight).
#返回0:健康检查OK,权重不被修改
#返回1:健康检查失败,权重设为0
#返回2-255:健康检查OK,权重设置为:退出状态码-2,比如返回255,那么weight=255-2=253
}
工具genhash使用
[root@localhost bin]# ./genhash -h
genhash v1.0.0 (18/11, 2002)
Usage:
./genhash -s server-address -p port -u url
./genhash -S -s server-address -p port -u url
./genhash -h
./genhash -r
Commands:
Either long or short options are allowed.
./genhash --use-ssl-SUse SSL connection to remote server.
./genhash --server-sUse the specified remote server address.
./genhash --port-pUse the specified remote server port.
./genhash --url-uUse the specified remote server url.
./genhash --use-virtualhost -VUse the specified virtualhost in GET query.
./genhash --verbose-vUse verbose mode output.
./genhash --help-hDisplay this short inlined help screen.
./genhash --release-rDisplay the release number
工具产生结果如下:
[root@localhost bin]# ./genhash -s10.7.11.12 -p 80 -u http://10.7.11
.40/index.html
MD5SUM = b7bd8391367e4cf9e4e85263ce313ae8
配置如下:
real_server 10.7.11.12 80 {
weight 1
TCP_CHECK {
connect_timeout 5
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
HTTP_GET {
url {
path /
digest b7bd8391367e4cf9e4e85263ce313ae8
status_code 200
}
#url {
#path /mrtg/
#digest 9b3a0c85a887a256d6939da88aabd8cd
#}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
TCP健康检查方式配置例子:
real_server 192.168.191.130 80 {
weight 3
inhibit_on_failure #在服务器健康检查失效时,将其设为0
TCP_CHECK {
connect_timeout 5 #连接超时时间
nb_get_retry 3#重连次数
delay_before_retry 3 #重连间隔时间
connect_port 80 #健康检查的端口
}
}
SSL健康检查方式同HTTP,例子如下:
virtual_server 192.168.200.100 443 {
delay_loop 6
lb_algo rr
lb_kind NAT
persistence_timeout 50
protocol TCP
real_server 192.168.201.100 443 {
weight 1
SSL_GET {
url {
path /
digest ff20ad2481f97b1754ef3e12ecd3a9cc
}
url {
path /mrtg/
digest 9b3a0c85a887a256d6939da88aabd8cd
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
SNMP方式例子:
real_server 172.16.1.12 25 {
weight 1
SMTP_CHECK {
connect_timeout 10
retry 2
delay_before_retry 5
helo_name "foo.bar.com"
host {
connect_ip 172.16.1.12
connect_port 25
bindto 172.16.1.2
}
host {
connect_ip192.168.155.11
connect_port 25
bindto 192.168.155.2
}
host {
connect_ip64.233.167.100
connect_port 587
}
}
}
MISC方式脚本带参数例子:
real_server 192.168.200.6 1358 {
weight 1
MISC_CHECK {
misc_path "/usr/local/bin/script.sh arg1 arg2"
}
}
MISC方式脚本不带参数例子:
real_server 192.168.200.6 1358 {
weight 1
MISC_CHECK {
misc_path /usr/local/bin/script.sh
!misc_dynamic
}
}