LVS DR模式+keepalived架构搭建
LVS DR模式+keepalived架构搭建
为什么不使用IP TUNNEL模式呢？
在生产环境中用的比较多的情况就是DR模式，NAT模式用的也不是太多，因为我们也说到了NAT的瓶颈问题。
如果规模在10台以内访问量不是很大且硬件配置+网络环境都可以的话建议使用NAT模式，可以节省公网IP，因为公网IP的成本也比较高。
另外一种方案就是搭建内网的LVS，全部的server均使用内网IP，我们使用一个公网IP端口映射到内网VIP的80端口即可，从而达到节省IP资源。
一、准备工作：
1.1 三台模拟服务器：
主机名 | IP 地址 | 角色 |
|---|---|---|
zhdy-01 | 192.168.59.129 | Load Balancer |
zhdy-02 | 192.168.59.130 | Real server1 |
zhdy-03 | 192.168.59.131 | Real server2 |
192.168.59.200 | vip |
确保每台机器已经安装了ipvsadm服务
# yum install -y ipvsadm1.1 在Load Balancer上面编写脚本：
vim /usr/local/sbin/lvs_dr.sh
#! /bin/bash
echo 1 > /proc/sys/net/ipv4/ip_forward
ipv=/usr/sbin/ipvsadm
vip=192.168.59.200
rs1=192.168.59.130
rs2=192.168.59.131
#注意这里的网卡名字
ifdown ens33
ifup ens33
ifconfig ens33:2 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip dev ens33:2
$ipv -C
$ipv -A -t $vip:80 -s wrr
$ipv -a -t $vip:80 -r $rs1:80 -g -w 1
$ipv -a -t $vip:80 -r $rs2:80 -g -w 1[[email protected]01 ~]# sh /usr/local/sbin/lvs_dr.sh
成功断开设备 'ens33'。
成功激活的连接（D-Bus 激活路径：/org/freedesktop/NetworkManager/ActiveConnection/3）1.2 每台real server上面也要配置脚本：
vim /usr/local/sbin/lvs_rs.sh
#! /bin/bash
vip=192.168.59.200
#把vip绑定在lo上，是为了实现rs直接把结果返回给客户端
ifdown lo
ifup lo
ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip lo:0
#以下操作为更改arp内核参数，目的是为了让rs顺利发送mac地址给客户端
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参考文档： www.cnblogs.com/lgfeng/archive/2012/10/16/2726308.html
两台Real server分别执行脚本
[[email protected] ~]# sh /usr/local/sbin/lvs_rs.sh查看一下两台real server的router -n
[[email protected]02 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.59.2 0.0.0.0 UG 100 0 0 ens33
192.168.59.0 0.0.0.0 255.255.255.0 U 100 0 0 ens33
192.168.59.200 0.0.0.0 255.255.255.255 UH 0 0 0 lo查看IP是否已经绑在lo卡上
[[email protected]02 ~]# ip addr
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
inet 192.168.59.200/32 brd 192.168.59.200 scope global lo:01.3 测试
在测试前一定要全部关闭iptables
# systemctl stop firewalld
# systemctl disable firewalld
查看活动的连接
[[email protected]01 ~]# 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.59.200:80 wrr
-> 192.168.59.130:80 Route 1 1 9
-> 192.168.59.131:80 Route 1 1 8二、配置keepalived
其实之前就有说过其实keepalived就已经内置了LVS的功能，怎么内置的呢？或者是如何实现的呢？
其实LVS有个关键的角色，也是致命点。所有的请求都会通过Load Balancer去转发到Real server 如果Load Balancer 宕机，我们的所有服务均会被停止掉。所以我们会把keepalived放在这儿，这样就会完美的解决问题！
假如我们要是停掉某个Real server的nginx再来测试下：
[[email protected] ~]# /etc/init.d/nginx stop
Stopping nginx (via systemctl): [ 确定 ]当再次转发到宕机的服务器是不是服务就不可达了，但是LVS不晓得啊，他还是会转发。就会导致如下情况：
看一下Load server的情况吧：
[[email protected]01 ~]# 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.59.200:80 wrr
-> 192.168.59.130:80 Route 1 1 6
-> 192.168.59.131:80 Route 1 0 6还是在不停的分发数据到宕机的服务器！
当我们再次使用keepalived的时候，他会时刻检查服务器有没有宕机的情况，这样就避免了宕机还会继续分发请求。
完整架构需要两台服务器（角色为dir）分别安装keepalived软件，目的是实现高可用，但keepalived本身也有负载均衡的功能，所以本次实验可以只安装一台keepalived。
keepalived内置了ipvsadm的功能，所以不需要再安装ipvsadm包，也不用编写和执行那个lvs_dir的脚本
2.1 编辑keepalived配置文件
vim /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
#备用服务器上为 BACKUP
state MASTER
#绑定vip的网卡为ens33，你的网卡和阿铭的可能不一样，这里需要你改一下
interface ens33
virtual_router_id 51
#备用服务器上为90
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass zhangduanya
}
virtual_ipaddress {
192.168.59.200
}
}
virtual_server 192.168.59.200 80 {
#(每隔10秒查询realserver状态)
delay_loop 10
#(lvs 算法)
lb_algo wlc
#(DR模式)
lb_kind DR
#(同一IP的连接60秒内被分配到同一台realserver)
persistence_timeout 0
#(用TCP协议检查realserver状态)
protocol TCP
real_server 192.168.59.130 80 {
#(权重)
weight 100
TCP_CHECK {
#(10秒无响应超时)
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.59.131 80 {
weight 100
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}[[email protected]01 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn2.2 启动keepalived服务：
[[email protected]01 ~]# systemctl start keepalived
[[email protected]01 ~]# ps aux | grep keep
root 3639 0.0 0.1 111708 1300 ? Ss 17:39 0:00 /usr/sbin/keepalived -D
root 3640 0.0 0.3 120572 3220 ? S 17:39 0:00 /usr/sbin/keepalived -D
root 3641 0.0 0.2 120444 2400 ? S 17:39 0:00 /usr/sbin/keepalived -D2.3 查看real server启动情况：
[[email protected]01 ~]# 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.59.200:80 wlc
-> 192.168.59.130:80 Route 100 0 0
-> 192.168.59.131:80 Route 100 0 0两个服务都已经正常服务，现在我们来模拟一下宕机的情况：
停掉 一台server的nginx：
[[email protected] ~]# /etc/init.d/nginx stop
Stopping nginx (via systemctl): [ 确定 ]再次从zhdy-01上面去查看：
[[email protected]01 ~]# 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.59.200:80 wlc
-> 192.168.59.130:80 Route 100 0 0现在是不是就只有一台了，也就是当某台服务器宕机后dir服务器（Load Balancer）就不会再次转发请求到宕机的server了吧！
如果故障恢复，再次启动宕机的server我们再次去检查dir服务器是不是也会再次检测到：
[[email protected] ~]# /etc/init.d/nginx start
Starting nginx (via systemctl): [ 确定 ]很快就检测到了。
[[email protected]01 ~]# 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.59.200:80 wlc
-> 192.168.59.130:80 Route 100 0 0
-> 192.168.59.131:80 Route 100 0 0然后我们在浏览器去访问vip主机，不停的刷新就会发现dir服务器已经开始分发不同的请求给不同的Real server！