1.简介
keepalive起初是为LVS设计的,专门用来监控lvs各个服务节点的状态,后来加入了vrrp的功能,因此除了lvs,也可以作为其他服务(nginx,haproxy)的高可用软件。VRRP是virtual router redundancy protocal(虚拟路由器冗余协议)的缩写。VRRP的出现就是为了解决静态路由出现的单点故障,它能够保证网络可以不间断的稳定的运行。所以keepalive一方面具有LVS cluster node healthcheck功能,另一方面也具有LVS director failover。
keepalive的两大功能:
healthcheck和failover
LVS cluster node healthcheck
- keepalived.conf里配置就可以实现LVS的功能
- keepalive可以对LVS下面的集群节点做健康检查。
health功能:负载均衡定期检查RS的可用性决定是否分给其分发请求。负载均衡器会自动的检查服务器的服务是否可用,若服务不可用则会移除服务地址池,若目标服务修好之后则会将服务重新加入地址池。
keepalive高可用服务原理介绍:
keepalive director高可用之间的故障切换转移,是通过VRRP协议实现的。
在keepalive director工作时,主节点会不断的向备节点发送心跳消息,告知自己还活着,当主节点故障时,备节点无法接收主节点的心跳消息,此时就会启用自身的服务接管程序将主节点的IP和服务资源接管过来。当主节点恢复工作之后,又会释放IP资源和服务,恢复至备节点的角色。
VRRP协议原理简单介绍:
VRRP是通过一种竞选协议协议机制来将路由的任务交给VRRP的路由器。在一VRRP的虚拟路由中,有多台物理的VRRP路由器,但是这多台路由器不同时工作,而是由一台Master负责路由工作,其他的都是backup,master是由backup竞争而来的,当master失去响应时,会从余下的backup中选出master来接管IP地址和服务资源。
VRRP协议的所有报文都是通过IP多播的形式传递消息,在一个虚拟路由器中,只有作为Master的VRRP路由器会一直发送VRRP广播包,当其他backup没有收到广播包时候,会迅速抢占master(谁的有限级高,谁就会抢占成功),处于安全性考虑VRRP协议传输数据时候进行了加密。
VRRP是virtual router redundancy protocal(虚拟路由器冗余协议)的缩写。
小结:
1,VRRP是virtual router redundancy protocal(虚拟路由器冗余协议)的缩写。
2,VRRP是通过一种竞选协议协议机制来将路由的任务交给VRRP的路由器。
3,VRRP协议的所有报文都是通过IP多播的形式传递消息
4,处于安全性考虑VRRP协议传输数据时候进行了加密。
官方网站:http://www.keepalived.org/
2.安装配置keepalive
编译安装yum安装都可
3.配置
全局配置:
global_defs {
notification_email {
[email protected] #发送主从切换的时候发送email通知的地址,可写多个
[email protected]
}
notification_email_from [email protected] #表示发送邮件的源地址是谁
smtp_server 192.168.100.1 #表示发送email时使用的smtp服务器地址这里可以用本地的sendmail来实现
smtp_connect_timeout 30 #连接smtp的超时时间
lvs_id node1 #HA的机器标识
}
VRRPD 配置:
virtual_server
virtual_server IP PORT{ #定义一个虚拟服务器,这个ip是virtual_ipaddress中定义的其中一个
delay_loop num#延迟的轮询时间
lb_algo rr|wrr|lc|wlc|sh|dh|lblc #调度算法
lb_kind NAT|DR|TUN #调度类型
(nat_mask @IP)
persistence_timeout num
persistence_granularity @IP
virtualhost string
protocol TCP|UDP
sorry_server @IP PORT #备份的机器,当所有的server宕机,sorry_server代替
real_server @IP PORT {
weight num #权重
TCP_CHECK {
connect_port PORT #check端口号
connect_timeout num #超时时长
}
}
real_server @IP PORT {
weight num
MISC_CHECK { #自定义脚本检测方式
misc_path /path_to_script/script.sh
(or misc_path “ /path_to_script/script.sh ”)
}
}
real_server @IP PORT {
weight num
HTTP_GET|SSL_GET {
url { #HTTP_GET健康检查配置方式有2种:摘要 和 状态。摘要digest值的获取方法:>genhash -s 192.168.36.99 -p 80 -u /index.html
path /index.html
digest alphanum #或者status_code 200
}
connect_port 3
connect_timeout 3
retry 3
delay_before_retry 3
}
}
VRRP同步组
两个vrrp_instance同属于一个vrrp_rsync_group,那么其中一个vrrp_instance发生故障切换时,另一个vrrp_instance也会跟着切换(即使这个instance没有发生故障)。
vrrp_sync_group VG1 {
group {
web
}
notify_master /path_to_script/script_master.sh #切换至master需要执行的脚本
(or notify_master “ /path_to_script/script_master.sh ”)
notify_backup /path_to_script/script_backup.sh #切换至backup需要执行的脚本
(or notify_backup “/path_to_script/script_backup.sh ”)
notify_fault /path_to_script/script_fault.sh #keepalive故障需要执行的脚本
(or notify_fault “ /path_to_script/script_fault.sh ”)
smtp_alert #切换的时候给全局配置里的邮箱发送邮件
}
VRRP实例
vrrp_instance web {
state MASTER|BACKUP #初始状态的角色,但是还是要根据priority来判定,所以Master的priority一定要大于backup
interface eth0 #添加VIP的网卡
mcast_src_ip IP #修改vrrp组播包的源地址,默认源地址为master的IP,发送VRRP通告的时候就是选择的这个IP地址,应该选较为稳定的网卡接口IP,若不指定则端口为interface所指定的网卡。
lvs_sync_daemon_interface eth1 #绑定lvs syncd的网卡,心跳线的网卡
virtual_router_id 1#取值在0-255之间,用来区分多个instance的VRRP组播。
priority 100 #选举优先级,Master越大
advert_int #发VRRP包的时间间隔,即多久进行一次master选举(可以认为是健康查检时间间隔)。
smtp_alert #切换发邮件
nopreempt #禁止抢占服务。默认情况,当MASTER服务挂掉之后,BACKUP自动升级为MASTER并接替它的任务,当MASTER服务恢复后,升级为MASTER的BACKUP服务又自动降为BACKUP,把工作权交给原MASTER。当配置了nopreempt,MASTER从挂掉到恢复,不再将服务抢占过来
authentication {
auth_type PASS|AH #推荐使用PASS
auth_pass 123456 #密码
}
virtual_ipaddress { # 虚地址限制在20以内
@IP
@IP
@IP
}
virtual_ipaddress_excluded { # 发送的VRRP包里不包含的IP地址,为减少回应VRRP包的个数。在网卡上绑定的IP地址比较多的时候用。
@IP
@IP
@IP
}
notify_master /path_to_script/script_master.sh
(or notify_master “ /path_to_script/script_master.sh ”)
notify_backup /path_to_script/script_backup.sh
(or notify_backup “ /path_to_script/script_backup.sh ”)
notify_fault /path_to_script/script_fault.sh
(or notify_fault “ /path_to_script/script_fault.sh ”)
}
4.IPVS的调度算法
1,Round-robin(RR)轮询:当新请求到达时候,从服务列表中选择一个Real Server,将请求重定向给这台Real Server。
2,Weighted round-robin(WRR)加权轮询:给每台Real Server分配一个权重/位列,权重越大,分到的请求数越多。
3,Destination hashing (DH)目标散列:来自于同一个IP地址的请求都被重定向到同一台Real Server上(保证目标地址不变)。
4,Source hashing(SH)源地址散列:Director必须确保响应的数据包必须通过请求数据包所经过的路由器或者防火墙(保证原地址不变)。
动态调度算法:通过检查服务器上当前连接的活动状态来重新决定下一步调度方式该如何实现。
5,Lease Connection (LC) 最少连接 哪一个Real Server上的连接数少就将下一个连接请求定向到那台Real Server上去。
【算法:连接数=活动连接数256+非活动连接数】
6,Weight Least-Connection(WLC) 加权最少连接 在最少连接的基础上给每台Real Server分配一个权重。
【算法:连接数=(活动连接数256+非活动连接数)÷权重】 一种比较理想的算法。
7,Shortest Expected Delay (SED) 最短期望延迟 不再考虑非活动连接数
【算法:连接数=(活动连接数+1) *256 ÷权重】
8,Never Queue (NQ) 永不排队算法,对SED的改进,当新请求过来的时候不仅要取决于SED算法所得到的值,还要取决于Real Server上是否有活动连接。
9,Locality-Based Least-Connection (LBLC) 基于本地状态的最少连接,在DH算法的基础上还要考虑服务器上的活动连接数。
10,Locality-Based Least-Connection with Replication Scheduling (LBLCR) 带复制的基于本地的最少连接 LBLC算法的改进
5.IPVS支持的协议
TCP
UDP
ESP (Encapsulation Security Payload)
IPsec 封装安全负载
AH (Authentication Header)
keepalived是实现服务器级别的接管,服务不可用无法切换keepalive,所以需要做好应用层的监控
参考链接:
https://www.cnblogs.com/qq78292959/archive/2012/05/31/2528524.html
http://www.keepalived.org/