干货 | Keepalived高可用服务配置实例
Keepalived系列导读
前言
在前面的章节中,我们学习了Keepalived简介、原理、以及Keepalived 配置文件的详细解读;今天我们通过几个配置实例来帮助大家掌握Keepalived的高可用性。
Keepalived单实例主备模式实战
配置Keepalived实现单实例单IP自动漂移接管
1、准备两台机器
2、安装 Keepalived软件
yum -y install keepalived
需要在qll251和qll252两台服务器上同时安装Keepalived
3、修改Keepalived配置文件
3.1 qll251为MASTER,配置文件如下:
vim /etc/keepalived/keepalived.conf
配置文件详细说明,参考:
3.2 qll252为BACKUP,配置文件如下:
vim /etc/keepalived/keepalived.conf
4、启动Keepalived服务
systemctl start keepalived
注意:MASTER跟BACKUP节点都要启动Keepalived服务
5、验证虚拟IP自动漂移
由于VI_1实例中,qll251优先级高于qll252,因此qll251为MASTER
在服务器qll251上,可以看到虚拟IP10.43.187.201
而qll252作为Keepalive备节点,无浮动ip:
进行高可用主备服务器切换实验:
(1)将qll251节点Keepalived服务停止,模拟MASTER宕机
(2)关闭qll251节点服务后,备节点接管绑定VIP
(3)通过日志,查看Keepalived主备切换过程
通过日志,发现备节点qll252已经接管绑定了
10.43.187.201
这个VIP,期间备节点发送ARP广播,让所有客户端更新本地的ARP表,以便客户端访问
新接管VIP服务的节点。
此时备节点已接管VIP,若再次启动主节点的Keepalived服务,主节点是否会接管回VIP?我们验证下
(启动主节点qll251 Keepalived服务过程省略,我们通过日志观察切换现象)
通过日志得知:由于主节点优先级高于备节点,因此主节点抢占为MASTER,同时备节点成为BACKUP,并且移除VIP。
以上便实现了单实例Keepalived服务
IP自动漂移接管
;VIP漂移至新机器,用户的访问请求自然就会找新机器了。
Keepalived双实例双主模式配置实战
前面给出的是Keepalived单实例主备模式的高可用演示;Keepalived还支持多实例多业务双向主备模式,即A业务在qll251上是主模式,在qll252上是备模式,而B业务在qll251上是备模式,在qll252上是主模式,下面就以双实例为例讲解不同业务实现双主的配置。
1、准备两台机器
下图为Keepalived双实例双主模式IP及VIP规划表:
2、安装 Keepalived软件
yum -y install keepalived
需要在qll251和qll252两台服务器上同时安装Keepalived
3、修改Keepalived配置文件
3.1 qll251配置文件修改如下:
[root@qll251 ~]# vim /etc/keepalived/keepalived.conf
14 state MASTER
15 interface eth0
16 virtual_router_id 60
17 priority 150
18 advert_int 1
19 authentication {
20 auth_type PASS
21 auth_pass 1111
22 }
23 virtual_ipaddress {
24 10.43.187.201/24 dev eth0 label eth0:1
25 }
26 }
27
28 vrrp_instance VI_2 {
29 state BACKUP
30 interface eth0
31 virtual_router_id 61
32 priority 100
33 advert_int 1
34 authentication {
35 auth_type PASS
36 auth_pass 1111
37 }
38 virtual_ipaddress {
39 10.43.187.202/24 dev eth0 label eth0:2
40 }
41 }
实例
VI_1
在qll251节点上的角色为主
,实例VI_2
在qll251节点上的角色为备
。
3.2 qll252配置文件修改如下:
[root@qll252 ~]# vim /etc/keepalived/keepalived.conf
14 state BACKUP
15 interface eth0
16 virtual_router_id 60
17 priority 100
18 advert_int 1
19 authentication {
20 auth_type PASS
21 auth_pass 1111
22 }
23 virtual_ipaddress {
24 10.43.187.201/24 dev eth0 label eth0:1
25 }
26 }
27
28 vrrp_instance VI_2 {
29 state MASTER
30 interface eth0
31 virtual_router_id 61
32 priority 150
33 advert_int 1
34 authentication {
35 auth_type PASS
36 auth_pass 1111
37 }
38 virtual_ipaddress {
39 10.43.187.202/24 dev eth0 label eth0:2
40 }
41 }
实例
VI_1
在qll252节点上的角色为备
,实例VI_2
在qll252节点上的角色为主
。
如果您是手机阅读的,配置文件查看起来应该不方便吧。这里我们就通过截图对比下主备节点配置文件差别项:
通过对比可以看出,主备节点配置文件实际就两项区别:
-
state(状态) -
priority(优先级,数值越大优先级越高)
4、验证
首先关闭
qll251和qll252的Keepalived服务,然后再进行如下操作:
//在qll251上进行如下操作:
[root@qll251 ~]# systemctl start keepalived
[root@qll251 ~]# ip a | egrep "10.43.187.201|10.43.187.202"
inet 10.43.187.201/24 scope global secondary eth0:1
inet 10.43.187.202/24 scope global secondary eth0:2
//由于qll252还没开服务,主备VIP都绑定在qll01上
//在qll252上进行如下操作:
[root@qll252 ~]# systemctl start keepalived
[root@qll252 ~]# ip a | egrep "10.43.187.201|10.43.187.202"
inet 10.43.187.202/24 scope global secondary eth0:2
//开启qll252服务,由于在实例VI_2中其优先级高于qll251,因此VIP10.43.187.202绑定在qll252
//再次在qll251上进行如下操作:
[root@qll251 ~]# ip a | egrep "10.43.187.201|10.43.187.202"
inet 10.43.187.201/24 scope global secondary eth0:1
//qll251上只有10.43.187.201了
经验证,我们发现qll251,qll252主备节点已经实现了当任意一端宕机时,VIP可以实现互相切换接管。在实际工作中,可以把www.cloud.com解析到VIP 10.43.187.201提供服务,把bbs.cloud.com解析到10.43.187.202提供服务。当然,qll251,qll252也要配置相应服务,例如:Nginx反向代理服务等。
结语
如果您觉得看完本文后有所收获, 还希望您随手帮忙点个在看
、或者分享转发
。您的支持是我坚持分享的最大动力!
往期精彩
◆ !
◆
◆
◆
◆
◆
◆
◆
◆
◆