0
点赞
收藏
分享

微信扫一扫

五月学习之keepalived 综合实践

1、需求案例

业务场景

在实际的工作中,我们的网站服务一般都是以域名的方式对外提供服务,对于这种情况下一般有这么两种现象:

一个域名对应一个ip地址,万一域名解析的ip地址故障,就出现单点故障现象

一个域名可以解析不同的后端服务,我们可以基于同域名解析多个不同服务的ip地址,更精确的响应用户

也就是说,我们在实现keepalived的高可用时候,需要在同一组高可用集群中,设置多个对外的VIP即多组VRRP实例,任意一组失误,都不影响用户的访问体验。

实验需求:

五月学习之keepalived 综合实践_ipad

主机资源

序号

主机角色

ip信息

ip角色

网卡设备

安装软件

1

kpmaster

192.168.8.14

网卡ip

eth0-nat模型

keepalived

192.168.8.100

VIP1-主

eth0别名

192.168.8.200

VIP2-备

eth0别名

2

kpslave

192.168.8.15

网卡ip

eth0-nat模型

keepalived

192.168.8.100

VIP1-备

eth0别名

192.168.8.200

VIP2-主

eth0别名

注意:

在2.3.6 TCP健康检测的基础上进行操作。


2、需求分析

1 准备基本网络环境
2 定制keepalived配置
3 测试

3、关键点分析

1 准备基本网络环境
相对于 2.3.6 实验环境,无需更改
2 定制keepalived配置
后端主机配置
相对于 2.3.6 实践配置文件,增加一套新的VRRP实例即可
3 测试

4、操作实践

1 准备基本网络环境
网络设备和网卡信息与之前效果一致,我们无需变动

2 定制keepalived配置
后端主机配置多vip
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
ifconfig lo:0 192.168.8.100 netmask 255.255.255.255 broadcast 192.168.8.100
ifconfig lo:1 192.168.8.200 netmask 255.255.255.255 broadcast 192.168.8.200
检查效果
~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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
    inet 192.168.8.100/32 brd 192.168.8.100 scope global lo:0
       valid_lft forever preferred_lft forever
    inet 192.168.8.200/32 brd 192.168.8.200 scope global lo:1
       valid_lft forever preferred_lft forever
结果显示:
可以看到,真实主机上有两个VIP地址,都绑定在lo网卡上。

配置多个vrrp示例
# kpmaster主机									                 kpslave主机
global_defs {                                 	global_defs {
   router_id kpmaster                            	router_id kpslave
}                                             		}
vrrp_instance VI_1 {                          	vrrp_instance VI_1 {
    state MASTER                                  	state BACKUP
    interface eth0                                	interface eth0
    virtual_router_id 51                          	virtual_router_id 51
    priority 100                                  	priority 50
    virtual_ipaddress {                           	virtual_ipaddress {
        192.168.8.100 dev eth0 label eth0:0           192.168.8.100 dev eth0 label eth0:0
    }                                             		}
}                                             		}

vrrp_instance VI_2 {                          	vrrp_instance VI_2 {
    state BACKUP                                  	state MASTER
    interface eth0                                	interface eth0
    virtual_router_id 52                          	virtual_router_id 52
    priority 50                                   	priority 100
    virtual_ipaddress {                           	virtual_ipaddress {
        192.168.8.200 dev eth0 label eth0:1           192.168.8.200 dev eth0 label eth0:1
    }                                             		}
}                                             		}

virtual_server 192.168.8.100 80 {             virtual_server 192.168.8.100 80 {
    delay_loop 2                                  	delay_loop 2
    lb_algo rr                                    	lb_algo rr 
    lb_kind DR                                    	lb_kind DR
    protocol TCP                                 	 	protocol TCP
    sorry_server 127.0.0.1 80                     	sorry_server 127.0.0.1 80
    real_server 192.168.8.16 80 {                 	real_server 192.168.8.16 80 {
        TCP_CHECK {                                   	TCP_CHECK {
            connect_timeout 3                             	connect_timeout 3
        }                                             		}
    }                                             		}
    real_server 192.168.8.17 80 {                 	real_server 192.168.8.17 80 {
        TCP_CHECK {                                   	TCP_CHECK {
            connect_timeout 3                             	connect_timeout 3
        }                                             		}
    }                                             		}
}                                             		}

virtual_server 192.168.8.200 80 {             virtual_server 192.168.8.200 80 {
    delay_loop 2                                  	delay_loop 2
    lb_algo rr                                    	lb_algo rr 
    lb_kind DR                                    	lb_kind DR
    protocol TCP                                  	protocol TCP
    sorry_server 127.0.0.1 80                     	sorry_server 127.0.0.1 80
    real_server 192.168.8.16 80 {                 	real_server 192.168.8.16 80 {
        TCP_CHECK {                                   	TCP_CHECK {
            connect_timeout 3                             	connect_timeout 3
        }                                             		}
    }                                             		}
    real_server 192.168.8.17 80 {                 	real_server 192.168.8.17 80 {
        TCP_CHECK {                                   	TCP_CHECK {
            connect_timeout 3                             	connect_timeout 3
        }                                             		}
    }                                             		}
}                                             		}

保证所有依赖服务都处于开启状态
[root@kpmaster ~]# systemctl start httpd
[root@kpslave ~]# systemctl start httpd
[root@lvs-rs1 ~]# systemctl start nginx
[root@lvs-rs2 ~]# systemctl start nginx

3 测试
正常效果
依次启动两台keepalived主机服务
systemctl start keepalived.service

结果显示:
在kpslave结点keepalived服务未启动时候,两个vrrp实例都在kpmaster主机上
当kpslave结点keepalived服务启动时候,VI_2的实例优先级较kpmaster主机高,所以将8.200的VIP枪过来了。


检查ipvs规则
[root@kpmaster ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.8.100:80 rr
  -> 192.168.8.16:80              Route   1      0          4         
  -> 192.168.8.17:80              Route   1      1          4         
TCP  192.168.8.200:80 rr
  -> 192.168.8.16:80              Route   1      0          0         
  -> 192.168.8.17:80              Route   1      0          0
可以看到:
这里存在两个lvs集群,管理的内容是一致的。

访问效果
单独找一台客户端来验证效果
[root@client ~]# for i in {1..8}; do curl 192.168.8.100;done
nginx-RS1
nginx-RS2
nginx-RS1
nginx-RS2
nginx-RS1
nginx-RS2
nginx-RS1
nginx-RS2
[root@client ~]# for i in {1..8}; do curl 192.168.8.200;done
nginx-RS2
nginx-RS1
nginx-RS2
nginx-RS1
nginx-RS2
nginx-RS1
nginx-RS2
nginx-RS1

关闭两台RS的nginx服务
[root@lvs-rs1 ~]# systemctl stop nginx
[root@lvs-rs2 ~]# systemctl stop nginx
查看keepalived的ipvs规则
[root@kpmaster ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.8.100:80 rr
  -> 127.0.0.1:80                 Route   1      0          0         
TCP  192.168.8.200:80 rr
  -> 127.0.0.1:80                 Route   1      0          0

5、实践小结

对于多应用场景或者请求入口高可用的场景,我们可以基于vrrp多实例的样式来完成,完成步骤如下:
    1 规划服务的检测内容
	2 后端服务的正常运行
	3 keepalived使用配置多vrrp实例
	4 效果测试
注意:
		keepalived在配置多vrrp实例的时候,一定要注意:
		同一实例间的优先级和state必须写清楚
		不同实例的名称和VIP一定要合理的规划

举报

相关推荐

0 条评论