# 基于keepalived的LVS高可用搭建
# 学习keepalived之前的一些思考
学习keepalived之前：
问题：
1）LVS会挂掉，单点故障，业务下线
2）RS会挂掉，一部分用户会请求异常，LVS还存有这个RS的负载记录
解决问题：
单点故障的解决方式：它是一个，一个有问题，那么我们就用一堆：一变多~！
2个思路：多点：形式：a)主备 b)主主
结论：先讨论主备。
方向性：
1）Backup在一定的频率向Master发送心跳包，缺点：Master既要接受正常的业务数据包也要接受Backup的心跳包，多少会影响Master的业务处理效率
2）Master主动通告，优点：不会影响Master的业务处理效率
主备：只有一个节点提供服务，主(单点->主备)从：主、从节点一起协作提供服务，而且Master要是单点通常也要进行主备
RS挂了怎么确定？要解决这个问题，先问个其它问题：你如何确定百度挂了？
回答：ping 不对 因为ping只是网络层 只能确定网络层是通的，但是百度网页服务是应用层的
所以要浏览器访问一下百度，而底层原理就是验证应用层的http协议->发送请求，判断返回 200 ok
-------------------------------------------------------------------------------------------------------------------------------------
那么说回LVS，现在Linux内核中有模块：ipvs
解决以上问题：
修改内核源码，再编译安装，但是要是拿不到源码怎么办呢？
人为实现，但是弊端很大，响应速度慢，有时很不靠谱的
外挂程序实现，企业追求自动化，把人解耦出去，用程序替代 -> keepalived -> 代替人自动运维，解决单点故障，实现HA(高可用)
主要实现逻辑：
监控自己的服务
Master通告自己还活着，Backup监听Master状态，Master挂了，一堆Backup推举出一个新的Master
配置: VIP，添加ipvs，keepalived是有配置文件
对后端server做健康检查
keepalived是一个通用的工具，主要作为HA实现；
Nginx，可以作为公司的负载均衡来用，Nginx成为了单点故障，也可以用keepalived来解决
# DR模型HA：keepalived实验拓补图
# 主机规划
| 用户名/密码 | 主机名称 | 备注 | 主机规划(内) | 安装软件 |
|---|---|---|---|---|
| root/root123 | lvs-master01 | LVS服务器(主) | 192.168.0.11 192.168.0.100(虚拟IP) | keepalived ipvsadm |
| root/root123 | nginx01 | Nginx服务器1 | 192.168.0.12 192.168.0.100(lo回环接口) | nginx |
| root/root123 | nginx02 | Nginx服务器2 | 192.168.0.13 192.168.0.100(lo回环接口) | nginx |
| root/root123 | lvs-backup02 | LVS服务器(备) | 192.168.0.14 192.168.0.100(虚拟IP) | keepalived ipvsadm |
# 实验步骤
keepalived实验：
主机： lvs-master01、lvs-backup02、nginx01、nginx02
lvs-master01: 将之前的DR模型实验清理
# 删除ipvs的入包及出包规则
ipvsadm -C
# 将ens33:8下线
ifconfig ens33:8 down
----------------------------
lvs-master01,lvs-backup02:
yum install keepalived ipvsadm -y
配置：
# 进入目录
cd /etc/keepalived/
# 备份一下
cp keepalived.conf keepalived.conf.bak
# 查看配置文件帮助文档
man 5 keepalived.conf
# 修改配置
vim keepalived.conf
# vi 小技巧1：删除3行 光标到开始行，按3dd
# vi 小技巧2：复制指定行并粘贴 光标到开始行，按:.,$-1y -> :进入修改模式.代表光标所在行$代表末行y 代表复制，然后回车 光标选择要粘贴的行，按p进行粘贴
lvs-master01:
vrrp：虚拟路由冗余协议！
vrrp_instance VI_1 {
state MASTER # lvs-backup02 BACKUP 角色
interface ens33 # 选定哪块网卡
virtual_router_id 51 # 虚拟路由标识号 标识一组keepalived
priority 100 # lvs-backup02 50 权重
advert_int 1 # 认证相关
authentication { # 认证相关
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.100/24 brd 192.168.0.255 dev ens33 label ens33:8
# 等价于之前ifconfig ens33:8 192.168.0.100/24
}
}
virtual_server 192.168.0.100 80 {
delay_loop 6 # 延迟循环
lb_algo rr # 调度策略
lb_kind DR # 采用DR直接路由模型 NAT、TUN
nat_mask 255.255.255.0
persistence_timeout 0 # 会话保持时间 用于同一个客户端保持之前的RS的时间
protocol TCP # 协议
real_server 192.168.0.12 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.0.13 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
# keepalived配置nginx集群的时候无法ping通虚拟virtual_ipaddress（已经关闭防火墙和selinux）
# 无法ping通virtual_ipaddress，也就无法实现Nginx集群的高可用了，因为主、从服务器之间根本无法通信。
# 造成这个问题的原因很可能是开启了vrrp_strict，将这行注释掉。（至少我这是这个原因，也有其他的可能，这个问题弄了很久）
! Configuration File for keepalived
global_defs {
notification_email {
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id LVS_DEVEL
#vrrp_skip_check_adv_addr
#vrrp_strict
#vrrp_garp_interval 0
#vrrp_gna_interval 0
}
# 远程复制到lvs-backup02的相同目录下
scp ./keepalived.conf root@lvs-backup02:`pwd`
# 启动keepalived
systemctl status keepalived
systemctl start keepalived
systemctl enable keepalived
# 模拟故障，验证keepalived
# 1、下线lvs-MASTER服务，查看BACKUP上是否新建VIP
lvs-master01:
# 下线lvs-MASTER服务-> 将ens33网卡下线
ifconfig ens33 down
lvs-master02:
# 查看BACKUP上是否新建VIP
ifconfig
ens33:3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.100 netmask 255.255.255.0 broadcast 0.0.0.0
ether 00:0c:29:f8:a9:f4 txqueuelen 1000 (Ethernet)
# 是否实际负载数据包
ipvsadm -lnc
[root@lvs-backup02 /etc/keepalived]# ipvsadm -lnc
IPVS connection entries
pro expire state source virtual destination
TCP 01:57 FIN_WAIT 192.168.0.1:52840 192.168.0.100:80 192.168.0.13:80
TCP 01:58 FIN_WAIT 192.168.0.1:52841 192.168.0.100:80 192.168.0.12:80
TCP 14:58 ESTABLISHED 192.168.0.1:52844 192.168.0.100:80 192.168.0.13:80
TCP 01:57 FIN_WAIT 192.168.0.1:52839 192.168.0.100:80 192.168.0.12:80
TCP 01:58 FIN_WAIT 192.168.0.1:52843 192.168.0.100:80 192.168.0.12:80
TCP 01:58 FIN_WAIT 192.168.0.1:52842 192.168.0.100:80 192.168.0.13:80
# 2、上线lvs-MASTER服务，查看MASTER是否抢占成功，查看BACKUP是否删除VIP
lvs-master01:
# 上线lvs-MASTER服务-> 将ens33网卡上线
ifconfig ens33 up
# 是否实际负载数据包
ipvsadm -lnc
lvs-master02:
# 查看BACKUP是否删除VIP
ifconfig
# 是否实际负载数据包
ipvsadm -lnc
[root@lvs-master01 ~]# ipvsadm -lnc
IPVS connection entries
pro expire state source virtual destination
TCP 01:57 FIN_WAIT 192.168.0.1:52877 192.168.0.100:80 192.168.0.12:80
TCP 01:57 FIN_WAIT 192.168.0.1:52868 192.168.0.100:80 192.168.0.12:80
TCP 14:58 ESTABLISHED 192.168.0.1:52885 192.168.0.100:80 192.168.0.13:80
TCP 01:57 FIN_WAIT 192.168.0.1:52872 192.168.0.100:80 192.168.0.12:80
TCP 01:57 FIN_WAIT 192.168.0.1:52870 192.168.0.100:80 192.168.0.13:80
TCP 01:58 FIN_WAIT 192.168.0.1:52879 192.168.0.100:80 192.168.0.13:80
TCP 01:58 FIN_WAIT 192.168.0.1:52883 192.168.0.100:80 192.168.0.12:80
TCP 01:57 FIN_WAIT 192.168.0.1:52875 192.168.0.100:80 192.168.0.13:80
TCP 10:44 ESTABLISHED 192.168.0.1:52835 192.168.0.100:80 192.168.0.13:80
# 思考1：并不是所有的主备模式的集群，MASTER都能抢占的，例如HDFS的主备模式下，由于涉及数据同步的问题，若主机重新上线后抢占备机时，就一定要实现数据的同步阻塞(会造成业务卡顿)，所以一般这种主机重新上线不会抢占备机的，但是keepalived只是数据包转发，不涉及数据同步问题，所以它可以让主机抢占
# 3、下线Nginx01服务，查看MASTER的负载条目是否剔除Nginx01
nginx01:
# 下线Nginx01服务
systemctl stop nginx
lvs-master01:
# 查看MASTER的负载条目是否剔除Nginx01
ipvsadm -ln
[root@lvs-master01 ~]# 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.0.100:80 rr
-> 192.168.0.13:80 Route 1 2 3
# 4、重新上线Nginx01服务，查看MASTER的负载条目是否加上Nginx01
nginx01:
# 重新上线Nginx01服务
systemctl start nginx
lvs-master01:
# 查看MASTER的负载条目是否加上Nginx01
ipvsadm -ln
[root@lvs-master01 ~]# 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.0.100:80 rr
-> 192.168.0.12:80 Route 1 0 4
-> 192.168.0.13:80 Route 1 1 4
# 思考2：如果keepalived突然意外挂掉，它还没来得及删除VIP，这样会造成后端负载的数据包失去原子性，怎么解决keepalived突然意外挂掉？以后可以考虑用Zookeeper集群来进行分布式协调
# 模拟keepalived突然意外挂掉
lvs-master01:
ps -ef|grep keepalived
kill -9 父进程id
kill -9 子进程id1
kill -9 子进程id2
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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182