了解了一下几款开源反向代理/负载均衡器，如Nginx、HAProxy、Tengine（淘宝开源）等。而LVS主要实现高性能的四层负载均衡，本次的目标主要是需要测试七层负载均衡的场景，即支持http层的解析转发。

另外为微服务、云原生而生的，支持动态配置的envoy、traefik暂未进行研究，但这些网关产品是结合上述场景的趋势。

其实目前各款开源负载均衡器性能方面差异并不是特别大，因此也基本没有通过性能方面来过多考虑，主要是功能上来做选择。

通过对比目前用的商用硬件负载均衡F5，考虑到以下几个功能是必须项：

1. 较丰富的负载均衡算法

2. 能够基于插入cookie的会话保持功能

3. 能够支持主动健康检查（负载均衡主动探测后台服务器，down的情况下主动踢掉）

4. 支持frontend、backend详细的会话信息统计

基于以上的考虑，很多社区免费版的开源负载均衡软件都不支持以上功能，这些功能都放在了它们商业付费版本里。但社区版的HAProxy默认都支持以上功能，而且同时支持四层、七层的负载均衡，所以是比较符合需求的。

针对传统的负载均衡场景，以下是使用HAProxy结合Keepalived高可用的实验记录。

实验环境

准备4台Rocky Linux 8.5系统，分别作为负载均衡器和web服务器。

虚拟机及IP规划如下：

主机名

IP

1

LB-01

10.1.1.101

2

LB-02

10.1.1.102

3

VIP:10.1.1.254

4

Web-01

10.1.1.201

5

Web-02

10.1.1.202

安装web测试服务器

通过部署2台Web服务器，作为被代理的2台后台服务器，用于对反向代理/负载均衡的测试。

web测试服务器用一个最近流行的caddy来部署。

安装caddy

通过dnf安装

dnf install 'dnf-command(copr)'dnf copr enable @caddy/caddydnf install caddy

配置caddy web服务器

修改caddy的配置文件，当访问80端口时返回响应内容，caddy配置文件位置/etc/caddy/Caddyfile

vim /etc/caddy/Caddyfile# Web-01服务器配置:80respond "This is Web server 01..."# Web-02服务器配置:80respond "This is Web server 02..."

启动caddy web服务器

caddy start --config /etc/caddy/Caddyfile

可以通过此命令确认web服务是否已正常启动：

netstat -lnp|grep caddy

最后可以通过浏览器或者通过curl命令测试2台web服务器是否可以正常打开和访问，并返回正确的内容。

安装负载均衡器HAProxy及Keepalived

HAProxy作为负载均衡器，Keepalived则作为两台负载均衡器的高可用组件，其原理就是网络工程师熟悉的VRRP协议。

打开IP转发

首先，Linux默认只会处理目标IP地址为自己的数据包，否则会丢弃。服务器作为反向代理/负载均衡器需要打开IP转发功能，才能处理转发目标地址非自己的数据包。

# 修改/etc/sysctl.conf配置文件vim /etc/sysctl.confnet.ipv4.ip_forward=1# 使生效sysctl -pcat /proc/sys/net/ipv4/ip_forward

由于通过dnf或yum安装的版本太老，通过源码的方式进行安装。

下载及解压

# 先安装依赖dnf install -y gcc openssl-develcd /usr/local/srcwget  zxvf keepalived-2.0.20.tar.gz

编译及安装

cd /usr/local/src/keepalived-2.0.20./configure --prefix=/usr/local/keepalived-2.0.20make && make install

创建软连接，方便后续软件升级

ln -s /usr/local/keepalived-2.0.20/ /usr/local/keepalived

将keepalived注册为系统服务

# 拷贝配置文件mkdir -p /etc/keepalived/cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/# 拷贝启动文件到/etc/rc.d/init.d目录中cp /usr/local/src/keepalived-2.0.20/keepalived/etc/init.d/keepalived /etc/rc.d/init.d/或ln -s /usr/local/src/keepalived-2.0.20/keepalived/etc/init.d/keepalived /etc/rc.d/init.d/# 拷贝环境变量文件cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/或ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/# 在bash中使用keepalived命令cp /usr/local/keepalived/sbin/keepalived  /usr/local/sbin/或vim /etc/profileexport PATH=/usr/local/keepalived/sbin:$PATHsource /etc/profile

编写配置文件

cd /etc/keepalivedcp keepalived.conf keepalived.conf.bakvim keepalived.conf# MASTER配置：! Configuration File for keepalivedglobal_defs {   router_id HA-01   vrrp_skip_check_adv_addr   # vrrp_strict   vrrp_garp_interval 0   vrrp_gna_interval 0}vrrp_instance VI_1 {    state MASTER    interface ens160    virtual_router_id 10    priority 150    advert_int 1    authentication {        auth_type PASS        auth_pass 1111    }    virtual_ipaddress {        10.1.1.254        # 可以配置多个VIP    }}# BACKUP配置! Configuration File for keepalivedglobal_defs {   router_id HA-02   vrrp_skip_check_adv_addr   # vrrp_strict   vrrp_garp_interval 0   vrrp_gna_interval 0}vrrp_instance VI_1 {    interface ens160    virtual_router_id 10    priority 100    advert_int 1    authentication {        auth_type PASS        auth_pass 1111    }    virtual_ipaddress {        10.1.1.254        # 可以配置多个VIP    }}

配置文件里优先级（priority）高的那台服务器会正为MASTER，较低的会成为BACKUP。

以下是对部分参数的说明：

router-id，唯一，自定义

vrrp_instance VI_1，一个VRRP组

virtual_router_id 50，一个组内的路由器的值要一样

advert_int 1，每隔一秒发一次包

priority，优先级高的为MASTER

virtual_ipaddress，虚拟的IP地址，也就是我们实际发布服务的IP地址

nopreempt，不抢占，在MASTER节点down掉又恢复后不会强制抢占回MASTER状态

启动keepalived

systemctl enable keepalivedsystemctl start keepalived# 检查是否已启动ps -ef|grep keepalived

正常启动后，可以通过ip addr查看VIP地址是否已在MASTER节点的网卡显示。

安装HAProxy

下载及解压

# 安装依赖dnf install make gcc gcc-c++ openssl openssl-devel -ydnf install lua -ycd /usr/local/srcwget  zxvf haproxy-2.2.19.tar.gz

编译及安装

如果要支持ssl卸载，需要加入这两个编译参数，USE_OPENSSL=1 ADDLIB=-lz 。

cd haproxy-2.2.19make PREFIX=/usr/local/haproxy-2.2.19 TARGET=linux-glibc USE_OPENSSL=1 ADDLIB=-lzldd haproxy | grep sslmake install PREFIX=/usr/local/haproxy-2.2.19

创建软连接，方便后续软件升级

ln -s /usr/local/haproxy-2.2.19/ /usr/local/haproxy

编写配置文件

mkdir /etc/haproxyvim /etc/haproxy.cfg# 两台负载均衡服务器配置需要一致global        daemon        maxconn 4000        pidfile /usr/local/haproxy/haproxy.pid        tune.ssl.default-dh-param 2048defaults        timeout connect 10s        timeout client 1m        timeout server 1m        log global        option httploglisten admin_stats        bind 0.0.0.0:1080        mode http        option httplog        #log 127.0.0.1 local0 err        maxconn 10        stats refresh 30s        stats uri /status        stats realm XingCloud\ Haproxy        stats auth admin:admin        #stats hide-version        stats  admin if TRUEfrontend http_80443    bind 0.0.0.0:80    bind 0.0.0.0:443 ssl crt /home/certs/test.aaa.com.server.pem    mode http    option httpclose    option forwardfor    http-request set-header X-Forwarded-Proto https if !{ ssl_fc }    http-request set-header X-Forwarded-Port 443 if !{ ssl_fc }    default_backend Web_serverbackend Web_servermode httpbalance roundrobin    cookie SERVER-COOKIE insert indirect nocache    server web01 10.1.1.201:80 cookie web01 check inter 3000 fall 3 rise 5    server web02 10.1.1.202:80 cookie web02 check inter 3000 fall 3 rise 5

defaults块里配置的参数是默认参数，如frontend未配置相关参数则会继承defaults里的。如果frontend里对相关参数进行了重新配置，则frontend里的配置会优先于defaults的配置。

配置里还对http头插入了让后端服务器能够获取客户端真实IP、前端协议和前端端口的x-forwarded字段。x-forwarded-for、x-forwarded-proto和x-forwarded-port。

另外还有一个比较常用的功能，基于cookie的会话保持。通过插入cookie来让来自同一个客户端都分发到同一台后端服务器上。

下面列举一下HAProxy支持的负载均衡算法：

roundrobin：基于权重进行的轮询算法，在服务器的性能分布经较均匀时这是一种最公平的，最合量的算法。

static-rr：也是基于权重时行轮询的算法，不过此算法为静态方法，在运行时调整其服务权重不会生效。

source：是基于请求源IP的算法，此算法对请求的源IP时行hash运算，然后将结果与后端服务器的权理总数相除后转发至某台匹配的后端服务器，这种方法可以使用一个客户端IP的请求始终转发到特定的后端服务器。

leastconn：此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法。例如数据库负载均衡等。此算法不适合会话较短的环境，如基于http的应用。

uri：此算法会对部分或整个URI进行hash运算，再经过与服务器的总权重要除，最后转发到某台匹配的后端服务器上。

uri_param：此算法会椐据URL路径中的参数时行转发，这样可以保证在后端真实服务器数量不变时，同一个用户的请求始终分发到同一台机器上。

hdr：此算法根据httpd头时行转发，如果指定的httpd头名称不存在，则使用roundrobin算法进行策略转发。

rdp-cookie(name)：根据cookie(name)来锁定并哈希每一次TCP请求。

注：以上配置样例中，还发布了https，即ssl offload（ssl请求终结在haproxy，与后端的请求通过普通的http）。需要提前准备服务器ssl pem证书。正式使用的话是跟CA机构申请，如果只是想作为实验环境的测试，可以自行颁发自签名证书进行测试，网上可以找到很多生成自签名证书的脚本。

将haproxy注册为系统服务

# 配置环境变量vim /etc/profileexport PATH=/usr/local/haproxy/sbin:$PATHsource /etc/profile# 注册为系统服务vim /usr/lib/systemd/system/haproxy.service[Unit]Description=HAProxyAfter=network.target[Service]User=rootType=forkingExecStart=/usr/local/haproxy/sbin/haproxy -f /etc/haproxy/haproxy.cfgExecStop=/usr/bin/kill `/usr/bin/cat /usr/local/haproxy/haproxy.pid`[Install]WantedBy=multi-user.target

启动haproxy

systemctl enable haproxysystemctl start haproxy

验证是否已正常启动

netstat -lnp|grep haproxy

通过浏览器访问VIP地址，分别验证http服务及https服务。https访问会报不信任是因为本次实验用到的是自签名证书。

通过CURL或者浏览器调试模式，可以看到请求已经插入cookie用于会话保持。

[root@HAProxy-01 ~]# curl -I  200 OKserver: Caddydate: Wed, 08 Dec 2021 01:25:13 GMTcontent-length: 24set-cookie: SERVER-COOKIE=web01; path=/cache-control: privateconnection: close

另外，haproxy自带了监控页面，非常详细好用。已经在配置文件中配置，可以通过访问查看。

场景测试keepalived节点本身网络故障倒换测试

默认的keepalived配置，MASTER节点在LB-01上，BACKUP节点在LB-02上。所以访问VIP地址10.1.1.254都由LB-01这台服务器转发。

为了验证keepalived的可用性，我们测试将LB-01这台服务器的网卡连接给断开，模拟网络或服务器故障的场景，验证VIP是否能自动切换到LB-02这个节点上。

由于实验环境为虚拟机，把虚拟网卡连接断开即可。在断开之前，在物理机上发起一个长ping 10.1.1.254，观察节点切换的情况。

ping 10.1.1.254 -t

可以看到，在断开LB-01的网卡连接后，在丢了1个包后ping即恢复。此时可以查看VIP 10.1.1.254已经漂移到了LB-02上。

接下来恢复LB-01的网络，由于没有配置抢占，所以MASTER节点仍然会在LB-02上。不配置抢占的好处是当故障节点恢复后不会导致抖动。

HAProxy进程故障倒换测试

除了Keepalived本身的故障外，HAProxy进程可能也会出现故障，如果keepalived无法判断haproxy是否异常，那么就无法进行故障切换。

因此，需要增加一个探测脚本，以判断haproxy服务是否正常。当退出码为0，keepalived就会认为探测成功，如退出码为1，keepalived就会认为探测失败，就会进入FAULT状态并把VIP给移除。

vim /etc/keepalived/haproxy_check.sh

#!/bin/bashcount=`ps -C haproxy --no-header | wc -l`if [ $count -gt 0 ]; then    exit 0else    exit 1fi

在keepalived配置文件中，加入以下脚本检测

vrrp_script chk_haproxy {    script "/etc/keepalived/haproxy_check.sh"    interval 2    timeout 2    fall 3}vrrp_instance VI_1 {    track_script {        chk_haproxy    }}

然后停掉haproxy的进程，模拟进程故障。

systemctl stop haproxy

此时LB-01节点的keepalived进入FAULT状态，VIP被移除，备机接管了VIP。

后端服务器故障倒换测试

由于cookie会话保持我们请求到的都是web01这台服务器，接下来模拟一下当web01故障能否重新把请求分发到web02上。

直接通过断开web01的网络连接，再通过浏览器发起请求。

可以看到已经切换到web02上了。

通过登录HAProxy自带的监控页面，可以看到健康检查web01已经down掉，所以负载均衡直接把web01剔除了。

小结

通过本次实验可以基本验证到基于HAProxy的七层负载均衡的功能，以及通过Keepalived搭建的高可用，还是非常好用的。但本次实验未体现HAProxy的转发策略的部分，后面可以单独对HAProxy的基于url、域名等等的策略转发功能进行测试，另外HAProxy还需要涉及到很多优化的配置。

另外一个问题就是，通过keepalived实现的高可用，MASTER节点只能在一台服务器上，即同时只能一个节点工作，如果需要横向扩展，又是需要另外一种实现高可用的方式。比如说不采用Keepalived的方式，在HAPorxy前面再部署LVS或者硬件F5，用这种L4+L7的架构来实现L7负载均衡的横向扩展和高可用。