使用keepalived实现高可用服务
拿PHP为例,一般网站都遵循这种部署方式:
- 存储集群:主要是指Mysql与Redis集群,但是存储相关的高可用问题不会在本篇博客讨论。
- 后端集群:由大量机器组成,每台机器是一个完整的nginx+php-fprm的执行环境(本机nginx转发给本机php-fpm),访问任意一台机器都可以浏览完整的网站内容,它们承载了网站的主要计算任务(例如:渲染模板)。
- 前端接入:由少量(通常个位数)高性能机器组成,将用户流量转发给后端集群,主要工作是网络数据的IO传输,计算任务则留给后端集群完成。
- DNS负载均衡:为了实现用户流量均摊到前端接入层的多台机器,需要借助DNS实现流量分发。
对于后端集群的可用性,一般采用如下解决方法:
- 对于后端机器内部,通过superviosr监督进程保证同机的nginx与php-fpm同时存活,整机作为一个最小服务单元。
- 对于后端集群整体,前端接入层利用lvs或者haproxy作为后端集群的反向代理层,他们利用健康检查机制及时发现后端故障机器并停止向其转发流量。
对于前端接入层的可用性,就是本文要讨论的重点,所以在此先抛出问题:
- 配置DNS将域名解析到N台前端机的IP,那么如果恰好其中一台前端机宕机,那么就会有部分流量访问到故障机。
- DNS在互联网上是逐级缓存的,并且中国运营商行为更加不可控,即便我们意识到了IP故障,从我们修改DNS踢出该IP到该修改生效到全网是需要很长一段时间的。
正因为DNS的这种特点,逼迫我们不得不回到前端机的可用性本身,看看能否将单个IP的可用性提高,一个简单的猜想就是:让2台物理机拥有同一个IP地址,但是同一时刻只有其中1台工作,当其宕机后另外一台接管工作。
没错,这就是keepalived做的事情之一。
keepalived原理浅析
keepalived其实提供了2种功能,分别是:
- 基于LVS的负载均衡:免去我们手动配置LVS的麻烦,只需要编写LVS的配置文件,剩下的工作交给keepalived完成。
- 基于VRRP的故障转移:使用主从备份的方式,在主机宕机后由备机接管服务,整个过程基于VRRP协议实现VIP(虚拟IP)漂移实现。
负载均衡
在我看来,我们应该尽量避免使用LVS(如果你不了解LVS可以看这里),Haproxy在7层工作已经可以解决绝大多数需求,为什么这么说呢?我们分析一下就知道了。
- LVS NAT模式
- 过程:当请求到达VIP,LVS需修改目标IP为后端机IP,后端机在应答时需要配置默认网关为LVS的内网地址,这样LVS才有机会将应答的源IP改回VIP。
- 优点:
- 后端机的IP可以是私有IP,不需要对接路由器,只需要和LVS的内网IP在同一物理网内即可。
- 缺点:
- 后端机要改默认网关为LVS的内网IP,这就要求后端机IP和LVS内网IP在一个物理网络中。
- 后端机默认网关改为LVS,那么后端机主动向外网发起请求时,请求只能发给LVS,而LVS是做DNAT反向代理的,压根没有SNAT配置。
- 如果我们给LVS做了主备高可用,那么当主宕机从接管后,后端机的默认网关就必须改为从机的内网IP才可以继续工作,谁来改?
- 请求和应答都必须通过LVS,LVS性能吃紧。
- LVS DR模式:
- 过程:当请求到达VIP,LVS需修改目标MAC地址为后端机MAC,后端机需为网卡增加一个IP,其值等于LVS的VIP,这样后端机误认为包是客户端直接发给自己的,在处理完成后直接向客户端IP应答,而不需要再经过LVS。
- 优点:
- 应答不需要经过LVS,因此不需要修改后端机的默认网关,应答直接发往路由器,节省了LVS的性能。
- 缺点:
- LVS直接改目标MAC再广播给后端机的做法,要求LVS的内网IP和后端机IP在一个物理网内。
- 后端机直接向客户端IP应答而不经过LVS,这意味着后端机不再是藏在LVS后面的私有IP,而是与LVS外网IP在一个物理网段内,对接同一个上级路由器。
- LVS TUNNEL模式:
- 过程:当请求到达VIP,LVS会将整个包重新打包在一个新的IP包里,修改目标IP地址改为后端机。后端机同样需要为网卡增加一个IP,其值等于LVS的VIP,当后端机收到请求后剥开外层IP包,发现内层IP包的目标IP是VIP,就会正常处理,应答会直接发给包的来源IP,也就是客户端IP。
- 优点:
- LVS到后端机是基于IP路由的,后端机应答是直接发往客户端的(直接通过路由器),因此LVS和后端机不必在同一个物理网内,同时应答不经过LVS也降低了LVS的压力。
- 缺点:
- 打包IP和解包IP的过程,额外耗费了性能,安装部署成本太大。
- LVS FULLNAT模式:
- 过程:当请求到达VIP,LVS修改目标IP为后端机IP,修改源IP为LVS内网IP,包按照IP路由到达后端机。当后端机应答时,按照正常IP路由回到LVS的内网IP,之后LVS会将源IP修改为LVS的外网IP,目标IP修改为客户端IP。
- 优点:
- FULLNAT是阿里后来增加的一种模式,官方LVS可能需要打补丁。它是NAT的升级版本,回顾NAT模式发现它是靠后端机默认网关来引导应答回到LVS的,就导致LVS内网IP必须和后端机在一个物理网内,而FULLNAT则是直接修改请求的源IP为LVS内网IP,这样后端机直接按照正常IP路由回包,无论后端机IP是否和LVS内网IP在一个网段内,都可以完成应答。
- 缺点:
- 请求和应答的流量还是要通过LVS,性能有问题。
- FULLNAT模式是补丁,需要重新编译内核!
再来看一下Haproxy,它就简单的多:
- 它工作在TCP/IP的7层,因此全部基于IP路由,不存在跨网限制的问题。
- 支持TCP和HTTP协议的负载均衡与健康检查,足以满足我们的日常需求。
- 不需要为后端机配置默认网关,后端机可以直接通过路由器访问外网。
- 配置简单,无需了解复杂的协议栈,简单即可靠,KISS原则!
因此,在后面的实践过程中,我们不使用keepalived提供的LVS功能,而是使用自己部署Haproxy的方式实现负载均衡。
故障转移
keepalived除了支持LVS外,其实最重要的功能是故障转移,也就是自动的主备切换,实现高可用服务。
简单来说,单点Haproxy存在故障的可能,那么我们可以部署2个Haproxy并配置keepalived进行检测,平时只会有1台提供对外的服务,当其宕机后keepalived会发现并切换服务到另外一台机器。
上面只是举个例子,其实keepalived的备份机可以部署很多,不限于1主1备,那么其原理是什么呢?答案:VRRP( Virtual Router Redundancy Protocol),即虚拟路由冗余协议。
这个协议最初是为了保证路由器的高可用出现的,keepalived只不过是拿来主义,用以解决服务的高可用问题。
VRRP工作原理并不复杂,因此只做一个简单的介绍:
原本VRRP是保证单点路由器高可用,因此会部署N个一样的路由器,它们之间通过VVRP协议互相沟通选出一个老大,这个老大会给自己的网卡绑定一个VIP,客户端通过VIP访问路由器,因此流量将最终到达老大路由器。当老大宕机后,剩余路由器将发现老大心跳停止,因此根据VRRP协议重新选举一个老大,这个新老大也会给自己的网卡绑定VIP,因此后续流量都发给了这个新的老大。
keepalived只不过把路由器这个概念换成了服务,每个服务所在的机器会运行一个Keepalived进程,由它发起VRRP协商选出谁是老大,同时检测本机的服务是否正常工作,当服务故障或者所在服务器直接宕机,其他剩余机器的keepalived会依据VRRP协议选举出新的老大负责接管流量。
关于keepalived基于VRRP工作的流程,可以参考这篇博客做一个基本了解,下面我将进入实践环节,在实践的时候逐步理解原理会更加生动。
keepalived+haproxy高可用部署
下面我将在2台服务器上部署haproxy作为反向代理,并利用keepalived的VRRP故障转移保障高可用。
启动4个虚拟机
我们启动4个centos虚拟机(virtualbox支持复制镜像),它们桥接到物理局域网内,由网关通过DHCP分配动态IP,它们可以互相访问。
取其中2个虚拟机部署haproxy+keepalived作为前端机,它们的IP地址是:
- 172.18.9.137
- 172.18.9.138
另外2个虚拟机分别部署一个nginx作为后端机,它们的IP地址是:
- 172.18.9.75
- 172.18.9.76
后端机运行nginx
给2台后端机通过yum安装nginx,直接启动即可。
之后,我们在前端机172.18.9.137上访问后端机的172.18.9.75上的nginx,确保访问成功:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
[root@dd5b2d11a765 ~]# hostname -i 172.18.9.137 [root@dd5b2d11a765 ~]# curl http://172.18.9.75 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> |
前端机运行haproxy
首先去官网下载最新的stable稳定版本haproxy:
1 |
wget http://www.haproxy.org/download/1.7/src/haproxy-1.7.3.tar.gz |
编译安装:
1 2 3 4 |
# TARGET可以指定编译平台,有一定的优化,我采用通用配置 make TARGET=generic # PREFIX指定安装目录 make install PREFIX=/root/haproxy |
进入/root/haproxy,创建etc目录存放配置文件:
1 2 3 4 5 6 7 8 9 |
[root@dd5b2d11a765 haproxy]# ll total 20 drwxr-xr-x 3 root root 4096 Mar 9 11:51 doc drwxr-xr-x 2 root root 4096 Mar 10 03:42 etc -rw-r--r-- 1 root root 25 Mar 10 03:42 pid drwxr-xr-x 2 root root 4096 Mar 9 11:51 sbin drwxr-xr-x 3 root root 4096 Mar 9 11:51 share [root@dd5b2d11a765 haproxy]# mkdir -p etc [root@dd5b2d11a765 haproxy]# cat etc/haproxy.cfg |
看一下我的haproxy.cfg配置:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
[root@dd5b2d11a765 haproxy]# cat etc/haproxy.cfg # 进程配置 global daemon # 守护进程 nbproc 5 # 启动5个进程服务 pidfile /root/haproxy/pid # 进程ID文件 # 前端haproxy代理80端口 frontend haproxy_80 mode http # http模式 bind 0.0.0.0:80 # 监听端口 timeout client 10000 # 客户端10秒不进行数据读写则超时 option forwardfor # 将客户端IP带到Http header的X-Forwarded-For default_backend nginx_80 # 默认转发的后端 # 后端nginx池 backend nginx_80 mode http # http模式 timeout server 10000 # 服务端10秒不返回任何数据则超时 timeout connect 5000 # 服务端5秒无法完成连接则超时 option httpchk HEAD / # HEAD健康检查nginx的/路径,返回200算健康 retries 3 # 连接后端失败后,重试连接的次数 option redispatch # 连接当前后端失败后,下次重连会换一台服务器(默认是同一台),总次数受retries控制 balance roundrobin # 负载均衡策略: 轮转 server nginx1 172.18.9.75:80 check inter 2000 rise 3 fall 3 # 第一台nginx,执行健康检查,间隔2秒,连续健康3次则恢复,连续失败3次则踢出 server nginx2 172.18.9.76:80 check inter 2000 rise 3 fall 3 # 第一台nginx,执行健康检查,间隔2秒,连续健康3次则恢复,连续失败3次则踢出 # 统计页面 listen stats mode http # http模式 bind 0.0.0.0:8080 # 监听地址 timeout client 10000 # 客户端10秒不进行数据读写则超时 stats refresh 5s # 页面5秒刷新一次数据 stats uri /admin # 访问路径 stats realm haproxy admin # 登录提示 stats auth admin:password # 登录的帐号密码 |
相关说明已经全部注释,这是一份最小化的haproxy配置,至于更多的配置项可以从这2个途径了解:
- 一个配置项说明的博客,快速了解整体面貌。
- 官方的配置文档,详细了解每个配置项。
现在启动haproxy,测试正常与异常访问情况:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
[root@dd5b2d11a765 haproxy]# sbin/haproxy -f etc/haproxy.cfg [root@dd5b2d11a765 haproxy]# curl localhost <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> |
可以尝试杀死一个nginx并立即访问haproxy,会发现仍旧请求正常,这是因为我们配置了合理的重试机制,当一台nginx无法联通时会立即连接另外一台nginx重试;另外,当健康检查连续3次无法访问到这台nginx时,该nginx会被持续屏蔽,直到健康检查连续3次正常访问后才解除屏蔽。
现在,我把配置好的haproxy从172.18.9.137拷贝到另外一台前端机172.18.9.138上并启动:
1 |
[root@dd5b2d11a765 ~]# scp -r haproxy 172.18.9.138:. |
1 |
[root@858e1f6fa4bf haproxy]# sbin/haproxy -f etc/haproxy.cfg |
下面就该轮到keepalived出场了。
前端机搭建keepalived
2个haproxy前端机都要部署一个keepalived,它们各自监督本机的haproxy健康状况,并基于VRRP完成主从切换。
首先安装keepalived的依赖openssl:
1 |
[root@dd5b2d11a765 ~]# yum install openssl-devel |
之后到官网下载keepalived:
1 |
[root@dd5b2d11a765 ~]# wget http://www.keepalived.org/software/keepalived-1.3.4.tar.gz |
编译安装:
1 2 |
[root@dd5b2d11a765 keepalived-1.3.4]# ./configure --prefix=/root/keepalived [root@dd5b2d11a765 keepalived-1.3.4]# make && make install |
接下来要配置keepalived.conf,应该优先参考官方入门文档。
在前面也提到过keepalived支持lvs负载均衡和fallover故障转移共2个功能,我们只会用到fallover故障转移相关的配置。
配置主机172.18.9.137:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
[root@localhost keepalived]# cat etc/keepalived/keepalived.conf ! Configuration File for keepalived # 全局配置, 主从切换时可以发送邮件, 我暂时用不到 global_defs { } # 健康检查脚本的配置 vrrp_script HAPROXY_CHECK { script "/root/keepalived/haproxy_check.sh" # 使用该脚本检查本机haproxy是否正常工作,返回0表示健康,1表示不健康 interval 2 # 健康检查间隔2秒 weight 2 # 优先级浮动大小, fall 3 # 脚本连续失败3次认为不健康 rise 3 # 脚本连续成功3次认为健康 } # 一个VRRP的实例,相当于配置一个虚拟路由器 vrrp_instance HAPROXY_80 { # 角色(一个实例内只能有1个Master,N个Backup) state MASTER # VRRP通过该网卡发送与接收 interface enp0s3 # 每一个虚拟路由器都要有唯一ID标识,这样多个节点才能彼此协商 virtual_router_id 1 # VRRP广播告知自己的真实IP身份 mcast_src_ip 172.18.9.137 # 优先级, 在VRPP组中优先级最高的将成为Master priority 100 # 每1秒广播一次自己的VRRP心跳 advert_int 1 # VRRP的多个节点之间互相认证身份 authentication { auth_type PASS auth_pass mypassword } # 虚拟VIP, 客户端访问该VIP即可到达可用的节点, keepavlied通过VRRP协议在主备间飘移VIP virtual_ipaddress { 172.18.9.240 } # 指定健康检查脚本 track_script { HAPROXY_CHECK } } |
这里配置了一个VRRP实例,它对外以172.18.9.240这个VIP服务。
keepalived定期调用haproxy_check.sh脚本检查本机haproxy是否正常工作,同时脚本也负责haproxy的重新拉起,脚本如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[root@localhost keepalived]# cat haproxy_check.sh #!/bin/bash # 检查haproxy是否存活 killall -0 haproxy if [ $? -eq 0 ];then exit 0 # 健康 fi # 不存活,首先拉起来 /root/haproxy/sbin/haproxy -f /root/haproxy/etc/haproxy.cfg # 不健康 exit 1 |
若连续3次健康检查正常则keepalived会将自己的优先级提高为priority+weight,若连续3次检测异常则将自己的优先级恢复为priority,而优先级决定了在VRPP选举时谁将成为接下来的Master。
现在我们启动172.18.9.137上的keepalived:
1 |
[root@localhost keepalived]# sbin/keepalived -f /root/keepalived/etc/keepalived/keepalived.conf |
看一下启动日志:
1 2 3 4 5 6 |
Mar 10 15:19:37 localhost Keepalived_healthcheckers[3995]: Opening file '/root/keepalived/etc/keepalived/keepalived.conf'. Mar 10 15:19:37 localhost Keepalived_healthcheckers[3995]: Using LinkWatch kernel netlink reflector... Mar 10 15:19:37 localhost Keepalived_vrrp[3996]: VRRP_Script(HAPROXY_CHECK) succeeded Mar 10 15:19:38 localhost Keepalived_vrrp[3996]: VRRP_Instance(HAPROXY_80) Transition to MASTER STATE Mar 10 15:19:38 localhost Keepalived_vrrp[3996]: VRRP_Instance(HAPROXY_80) Changing effective priority from 100 to 102 Mar 10 15:19:39 localhost Keepalived_vrrp[3996]: VRRP_Instance(HAPROXY_80) Entering MASTER STATE |
keepalived调用健康脚本判定haproxy健康后,会上调自己的优先级为100+2=102,之后经过VRRP协商(现在还没有部署备机)确定自己是最高优先级进入Master状态。
查看网卡信息:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
[root@localhost keepalived]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:89:fa:af brd ff:ff:ff:ff:ff:ff inet 172.18.9.137/22 brd 172.18.11.255 scope global dynamic enp0s3 valid_lft 81967sec preferred_lft 81967sec inet 172.18.9.240/32 scope global enp0s3 valid_lft forever preferred_lft forever inet6 fe80::9fe4:6b53:162b:1949/64 scope link valid_lft forever preferred_lft forever |
我们的enp0s3网卡除了原本的IP外,额外绑定了一个VIP:172.18.9.240,因此我们试着请求一下这个VIP的80端口,应当会访问到这台机器上的haproxy:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
liangdongdeMacBook-Pro:test liangdong$ curl 172.18.9.240 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> |
现在,我们给172.18.9.138部署keepalived,修改其配置如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
[root@localhost keepalived]# cat etc/keepalived/keepalived.conf ! Configuration File for keepalived # 全局配置, 主从切换时可以发送邮件, 我暂时用不到 global_defs { } # 健康检查脚本的配置 vrrp_script HAPROXY_CHECK { script "/root/keepalived/haproxy_check.sh" # 使用该脚本检查本机haproxy是否正常工作,返回0表示健康,1表示不健康 interval 2 # 健康检查间隔2秒 weight 2 # 优先级浮动大小, fall 3 # 脚本连续失败3次认为不健康 rise 3 # 脚本连续成功3次认为健康 } # 一个VRRP的实例,相当于配置一个虚拟路由器 vrrp_instance HAPROXY_80 { # 角色(一个实例内只能有1个Master,N个Backup) state BACKUP # VRRP通过该网卡发送与接收 interface enp0s3 # 每一个虚拟路由器都要有唯一ID标识,这样多个节点才能彼此协商 virtual_router_id 1 # VRRP广播告知自己的真实IP身份 mcast_src_ip 172.18.9.138 # 优先级, 在VRPP组中优先级最高的将成为Master priority 99 # 每1秒广播一次自己的VRRP心跳 advert_int 1 # VRRP的多个节点之间互相认证身份 authentication { auth_type PASS auth_pass mypassword } # 虚拟VIP, 客户端访问该VIP即可到达可用的节点, keepavlied通过VRRP协议在主备间飘移VIP virtual_ipaddress { 172.18.9.240 } # 指定健康检查脚本 track_script { HAPROXY_CHECK } } |
和MASTER配置的差别在于:
- 启动后的默认身份是BACKUP
- mcast_src_ip改为自己的网卡IP
- priority优先级改为99,主要是确保VRRP能正常的选主:
- 当master的haproxy不健康时其优先级为100,而backup此时如果健康则优先级为99+2=101,因此backup取代master。
- 当master的haproxy不健康时其优先级为100,而backup此时如果不健康则优先级为99,因此backup不做任何反应。
- 当master的haproxy健康时优先级为100+2=102,backup此时如果健康优先级为99+2=101,因此backup不做任何反应。
- 当master的haproxy健康时优先级为100+2=102,backup此时如果不健康优先级为99,因此backup不做任何反应。
- 综上可以看出,只有master的haproxy不健康或者直接宕机的情况下,backup才会接管VIP对外服务,这正是我们想要的效果。
我们启动这个keepalived,然后在笔记本上启动一个死循环脚本请求VIP,并开始模拟故障现场:
1 |
liangdongdeMacBook-Pro:test liangdong$ while true; do curl 172.18.9.240; done |
- 通过top观察2个前端机,发现一开始流量全部发往了Master。
- 现在模拟Master上的haproxy不健康,方法是将健康检查脚本里的直接杀死haproxy:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
[root@localhost keepalived]# cat haproxy_check.sh #!/bin/bash # 让haproxy永远死亡 killall -9 haproxy # 检查haproxy是否存活 killall -0 haproxy if [ $? -eq 0 ];then exit 0 # 健康 fi # 不存活,首先拉起来 /root/haproxy/sbin/haproxy -f /root/haproxy/etc/haproxy.cfg # 不健康 exit 1 |
不出所料,发现流量全部转移到了Backup,其网卡已绑定VIP:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
[root@localhost keepalived]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:ef:a3:d7 brd ff:ff:ff:ff:ff:ff inet 172.18.9.138/22 brd 172.18.11.255 scope global dynamic enp0s3 valid_lft 80450sec preferred_lft 80450sec inet 172.18.9.240/32 scope global enp0s3 valid_lft forever preferred_lft forever inet6 fe80::efc3:145e:59a4:18b8/64 scope link valid_lft forever preferred_lft forever inet6 fe80::9fe4:6b53:162b:1949/64 scope link tentative dadfailed valid_lft forever preferred_lft forever |
- 现在恢复Master的健康检查脚本,流量很快又回到了Master,说明VIP再次发生了飘移。
- 现在直接杀死Master的keepalived进程,相当于模拟Master机器宕机,观察流量快速转移到了Backup。
其他
keepalived中有一些配置项与原理比较难理解,简单列举一下,希望对你有帮助:
- VRRP协议选举的过程是基于优先级的自荐模式,具体流程可以参考这里。
- state只是初始角色,真正运行时还是依靠优先级决定谁是master谁是backup的。
- vrrp_sync_group是VRRP实例组,将多个VRRP实例放在一起,当任意一个不健康的时候会将其他所有实例都改变为不健康状态,相当于要挂一起挂,需要你提供几个回调脚本,将所有实例都统一处理一下。
- virtual_server是做LVS负载均衡用的配置项,我们压根不用keepalived的负载均衡,而是用它的故障转移,这是完全两码事,所以不用关注这个配置。
- 在vrrp_instance配置中除了track_script可以判定实例健康外,还有track_interface这个配置,它可以指定若干网卡名,只要网卡故障了就判定为不健康,并不神秘。
- 在上面的例子中,Master重启后VIP又飘移了回来,即便Backup正在正常工作,这是因为我们配置Master的优先级更高,并且keepalived默认采用抢占模式工作,并不考虑反复飘移的成本。要解决这个问题,可以给所有keepalived的vrrp_instance配置一个nopreempt选项,这样Master重启后虽然优先级很高,但是已经有其他机器在正常服务,那么就不会再去广播自己的优先级了,可以自己试验一下。
祝玩的愉快
如果文章帮助您解决了工作难题,您可以帮我点击屏幕上的任意广告,或者赞助少量费用来支持我的持续创作,谢谢~

找了好对资料,您这篇博客诠释原理很清楚,谢谢
不客气!
感谢,讲解的很细致
客气。