代码改变世界

LVS+Keepalived 实现高可用负载均衡

2020-07-28 18:17  Fururur  阅读(19987)  评论(0编辑  收藏  举报

前言

在业务量达到一定量的时候,往往单机的服务是会出现瓶颈的。此时最常见的方式就是通过负载均衡来进行横向扩展。其中我们最常用的软件就是 Nginx。通过其反向代理的能力能够轻松实现负载均衡,当有服务出现异常,也能够自动剔除。但是负载均衡服务自身也可能出现故障,因此需要引入其他的软件来实现负载均衡服务的高可用。本文就介绍了一种基于 LVS+Keepalived 的方式,来实现高可用 Web 集群。

LVS 与 Keepalived

LVS 是一种预装在 Linux 系统中,基于四层、具有强大性能的反向代理服务器。ipvsadm 是 LVS 的命令行管理工具。

LVS 特点是:

  1. 首先它是基于 4 层的网络协议的,抗负载能力强,对于服务器的硬件要求除了网卡外,其他没有太多要求;
  2. 配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,大大减少了人为出错的几率;
  3. 应用范围比较广,不仅仅对 web 服务做负载均衡,还可以对其他应用(mysql)做负载均衡;
  4. LVS 架构中存在一个虚拟 IP 的概念,需要向 IDC 多申请一个 IP 来做虚拟 IP。

Keepalived 是一个基于 VRRP 协议来实现的服务高可用方案,可以利用其来避免 IP 单点故障,一般与其它负载均衡技术(如 LVS 、HAProxy 、Nginx)一起工作来达到集群的高可用。Keepalived 是 LVS 的扩展项目, 因此它们之间具备良好的兼容性,可直接通过 Keepalived 的配置文件来配置 LVS。

LVS 的工作原理可见参考文献

关于 LVS 和 Keepalived 详细的结构和原理,以及 LVS 和我们常用的 LB 软件 Nginx 的异同,可以阅读末尾提供的参考文献。接下来将介绍如何部署一个高可用的负载均衡集群。

相关术语

  • LB (Load Balancer 负载均衡)
  • HA (High Available 高可用)
  • Failover (失败切换)
  • Cluster (集群)
  • LVS (Linux Virtual Server Linux 虚拟服务器)
  • DS (Director Server),指的是前端负载均衡器节点
  • RS (Real Server),后端真实的工作服务器
  • VIP (Virtual IP),虚拟的 IP 地址,向外部直接面向用户请求,作为用户请求的目标的 IP 地址
  • DIP (Director IP),主要用于和内部主机通讯的 IP 地址
  • RIP (Real Server IP),后端服务器的 IP 地址
  • CIP (Client IP),访问客户端的 IP 地址

测试环境

软件环境:CentOS7、Keepalived1.3.5、ipvsadm1.27

DS1(MASTER):172.17.13.120

DS1(BACKUP):172.17.13.123

RS1:172.17.13.142:80 Nginx

RS1:172.17.13.173:80 Nginx

VIP:172.17.13.252

                              |
             +----------------+-----------------+
             |                                  |
172.17.13.120|----     VIP:172.17.13.252    ----|172.17.13.123
     +-------+--------+                +--------+-------+
     | 	    DS1       |                |       DS2      |
     | LVS+Keepalived |                | LVS+Keepalived |
     +-------+--------+                +--------+-------+
             |			                |
             +----------------+-----------------+
                              |
  +------------+              |               +------------+
  |     RS1    |172.17.13.142 |  172.17.13.173|     RS2    |
  | Web Server +--------------+---------------+ Web Server |
  +------------+                              +------------+

集群的架构图如上图所示。DS1、DS2 为两个 LB 节点,RS1、RS2 为两个真实的服务节点,通过一个虚拟的 IP 地址对外提供服务。

最终我们要达到的目标为:

  1. Client 通过 VIP 访问服务能够将请求根据配置的规则进行分发(LB)
  2. 当 MATSER 的 LB 节点故障时,自动切换到 BACKUP 的 LB 节点上,保证服务正常访问;MASTER 恢复后,再次作为主 LB 负载节点
  3. 当某个 RS 节点故障时,自动剔除该节点;恢复后,再次加入集群

详细配置流程

安装相关软件

[root@localhost ~]# yum install ipvsadm keepalived -y

配置 Keepalived

  1. DS1(MASTER) 节点
[root@localhost ~]# vi /etc/keepalived/keepalived.conf

! Configuration File for keepalived
global_defs {
   router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER            # 两个 DS,一个为 MASTER 一个为 BACKUP
    interface enp1s0        # 当前 IP 对应的网络接口,通过 ifconfig 查询
    virtual_router_id 62    # 虚拟路由 ID(0-255),在一个 VRRP 实例中主备服务器 ID 必须一样
    priority 200            # 优先级值设定:MASTER 要比 BACKUP 的值大
    advert_int 1            # 通告时间间隔:单位秒,主备要一致
    authentication {        # 认证机制,主从节点保持一致即可
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.17.13.252       # VIP,可配置多个
    }
}

# LB 配置
virtual_server 172.17.13.252 80  {
    delay_loop 3                    # 设置健康状态检查时间
    lb_algo rr                      # 调度算法,这里用了 rr 轮询算法
    lb_kind DR                      # 这里测试用了 Direct Route 模式
    persistence_timeout 50          # 持久连接超时时间
    protocol TCP
	real_server 172.17.13.173 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 10   
            retry 3            # 旧版本为 nb_get_retry 
            delay_before_retry 3   
            connect_port 80
        }
    }
	 real_server 172.17.13.142 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 10
            retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}
  1. DS2(BACKUP) 节点

复制之前的配置文件,修改 vrrp_instance VI_1 中的 stateBACKUP

配置完成后,分别重启 Keepalived 服务。

[root@localhost ~]# systemctl restart keepalived

配置 RS

RS 配置主要分两部分,一部分是 web 服务,另一部分是网络转发配置。

web 服务部署不多展开了,根据实际情况来,可以是 Tomcat 也可以是 Nginx,只要能通过 ip:port 能访问到即可。

在网络转发配置上,LVS 支持多种通信模型(NAT、DR、TUN),本文采用 DR 模型来进行通信,大致的流程如下图所示。请求数据包从到达 LB 后,LVS 会将这个数据包的 MAC 地址改成轮询到的 RS 的 MAC 地址,并丢给交换机;RS 收到后进行处理并从网卡的 lo 端口发送出去,响应报文到达交换机后直接转发给 Client。

NAT-3

因此,我们需要在 RS 的网卡上配置 lo 为 VIP。配置脚本如下

#!/bin/bash 
SNS_VIP=172.17.13.252
case "$1" in
start)
       ifconfig lo:0 $SNS_VIP netmask 255.255.255.255 broadcast $SNS_VIP
       /sbin/route add -host $SNS_VIP dev lo:0
       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
       sysctl -p >/dev/null 2>&1
       echo "RealServer Start OK"
       ;;
stop)
       ifconfig lo:0 down
       route del $SNS_VIP >/dev/null 2>&1
       echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignore
       echo "0" >/proc/sys/net/ipv4/conf/lo/arp_announce
       echo "0" >/proc/sys/net/ipv4/conf/all/arp_ignore
       echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce
       echo "RealServer Stoped"
       ;;
*)
       echo "Usage: $0 {start|stop}"
       exit 1
esac
exit 0

本地创建完后,并执行。

[root@localhost ~]# chmod a+x lvs-web.sh
[root@localhost ~]# ./lvs-web.sh start

配置完成后,通过 VIP 就可以访问到 RS 上的服务了。

HA 测试

配置完双机热备后,我们就可以测试下,节点发生故障后以及 LB 切换失败后,能否保证服务的 HA。

在 LB 的主节点上输入 ip a,可以看到 VIP 目前已经正确配置在网卡上。

image-20200728165028112

输入 watch ipvsadm -Ln --stats 可实时看到负载均衡的结果,正常。

image-20200723101409290

接下面我们试着访问一下 VIP。

[root@localhost ~]# while true ; do curl 172.17.13.252; sleep 1;done

看到服务可正常轮询。

image-20200723100952996

此时手动停止一个 RS,再次访问 VIP,LVS 会自动剔除无法访问的服务,重启后,服务会被自动添加。

image-20200723103233100

image-20200723102858257

如果此时,手动停止 MASTER 上的 Keepalived,模拟 LB MASTER 节点挂了,VIP 会自动飘到 BACKUP LB 上。

image-20200723103504355

image-20200723103315113

此时,如果重启 MASTER 后,VIP 又会飘回去。MASTER 的优先级高于 BACKUP,从而实现 HA。

image-20200723103538358

总结

本文介绍了使用 LVS+Keepalived 来实现高可用负载均衡,这能使得我们的服务能够更加的稳定。Keepalived 默认是运行在 LVS 之上的,有较好的兼容性,当然我们也可以使用户 Nginx 作为 LB 的软件,可根据业务和两者的异同进行选择。

参考文献