Linux服务器负载均衡实现_Linux LVS与HAProxy配置教程

lvs和haproxy是linux服务器负载均衡的两种主流方案。1.lvs在内核层面提供高性能四层负载均衡，适用于高并发、大流量场景，其dr模式通过直接路由实现高效转发；2.haproxy在用户空间提供灵活的四层和七层负载均衡，支持http路由、ssl卸载等功能，适合web服务等需智能流量管理的场景；3.两者可通过keepalived实现高可用，避免单点故障；4.lvs有nat、dr、tun三种工作模式，分别适用于不同网络环境与性能需求。选择时应根据性能要求、协议层级及功能需求进行权衡。

Linux服务器的负载均衡，通常我们会考虑LVS（Linux Virtual Server）和HAProxy这两种主流方案。它们各有侧重，LVS在内核层面提供高性能的四层负载均衡，而HAProxy则在用户空间提供更灵活的四层和七层负载均衡能力。选择哪一个，往往取决于你的应用场景对性能、功能和复杂度的具体需求。

解决方案

实现Linux服务器负载均衡，我们通常会结合LVS或HAProxy来构建。

LVS的实现与配置

LVS作为内核级别的负载均衡器，其性能优势在于直接在IP层转发数据包，开销极低。我个人在处理高并发、纯粹的TCP/UDP转发场景时，LVS的Direct Routing（DR）模式几乎是首选。

1. 环境准备：

   
   • Director Server (负载均衡器)：安装

     ipvsadm

     登录后复制
     工具。
   • Real Servers (后端服务器)：配置回环接口（lo）上的虚拟IP（VIP），并抑制ARP广播。

2. LVS-DR模式配置：

   • Director端：

     # 启用IP转发
     echo 1 > /proc/sys/net/ipv4/ip_forward
     
     # 清空现有规则
     ipvsadm -C
     
     # 添加虚拟服务：-A 添加服务，-t TCP协议和VIP:端口，-s 调度算法（rr: 轮询，lc: 最少连接）
     ipvsadm -A -t 192.168.1.100:80 -s rr
     
     # 添加真实服务器：-a 添加真实服务器，-t 虚拟服务，-r 真实服务器IP:端口，-g DR模式
     ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101:80 -g
     ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.102:80 -g
     
     # 保存规则（可选，系统重启后需要重新加载）
     # ipvsadm -S > /etc/sysconfig/ipvsadm
     # systemctl enable ipvsadm (如果使用systemd)

     登录后复制

   • Real Server端： 为了解决DR模式下的ARP问题，需要配置每个真实服务器，让它知道VIP是它自己的，但不对外广播ARP。

     # 配置回环接口上的VIP，掩码为255.255.255.255
     # 假设VIP是192.168.1.100
     ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 broadcast 192.168.1.100 up
     
     # 抑制ARP广播
     echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
     echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
     echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
     echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

     登录后复制

     这些配置通常会写入

     /etc/sysctl.conf

     登录后复制
     或启动脚本中以实现持久化。

HAProxy的实现与配置

HAProxy则是一款非常强大的用户空间负载均衡器，尤其在HTTP/HTTPS等应用层协议处理上表现出色。它的配置相对灵活，功能也更丰富，比如SSL卸载、会话保持、内容路由等。

1. 安装HAProxy：

   yum install haproxy -y # CentOS/RHEL
   apt-get install haproxy -y # Debian/Ubuntu

   登录后复制

2. 配置HAProxy (

   /etc/haproxy/haproxy.cfg

   登录后复制
   )： 以下是一个典型的HTTP负载均衡配置示例：

   global
       log /dev/log    local0 notice
       chroot /var/lib/haproxy
       stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
       stats timeout 30s
       user haproxy
       group haproxy
       daemon
       # maxconn 20000 # 最大并发连接数，根据服务器性能调整
   
   defaults
       mode http # 默认模式为HTTP，也可以是tcp
       log global
       option httplog
       option dontlognull
       timeout connect 5000ms # 连接超时
       timeout client 50000ms # 客户端超时
       timeout server 50000ms # 服务器超时
       errorfile 400 /etc/haproxy/errors/400.http
       errorfile 403 /etc/haproxy/errors/403.http
       errorfile 408 /etc/haproxy/errors/408.http
       errorfile 500 /etc/haproxy/errors/500.http
       errorfile 502 /etc/haproxy/errors/502.http
       errorfile 503 /etc/haproxy/errors/503.http
       errorfile 504 /etc/haproxy/errors/504.http
   
   frontend http_front
       bind *:80 # 监听80端口
       mode http
       default_backend http_back
   
   backend http_back
       mode http
       balance roundrobin # 负载均衡算法：roundrobin（轮询）、leastconn（最少连接）、source（源IP哈希）
       option httpchk GET /healthz # 健康检查，请求/healthz路径
       server web1 192.168.1.101:80 check inter 2000 rise 2 fall 3 # 后端服务器1，2秒检查一次，2次成功上线，3次失败下线
       server web2 192.168.1.102:80 check inter 2000 rise 2 fall 3 # 后端服务器2
       # server web3 192.168.1.103:80 check backup # 备份服务器
       # server web4 192.168.1.104:80 check disabled # 禁用服务器
   
   listen stats
       bind *:8080 # 监听统计页面端口
       mode http
       stats enable
       stats uri /haproxy_stats # 统计页面URI
       stats realm Haproxy\ Statistics
       stats auth admin:password # 认证信息
       stats refresh 10s # 刷新间隔

   登录后复制

3. 启动HAProxy：

   systemctl start haproxy
   systemctl enable haproxy

   登录后复制

LVS与HAProxy的主要区别和适用场景是什么？

在选择LVS还是HAProxy时，我通常会先问自己一个问题：我需要的是高性能的纯粹转发，还是更智能的应用层路由？

LVS (Linux Virtual Server)

• 工作层面：主要工作在OSI模型的第四层（传输层），即IP层和TCP/UDP层。
• 特点：
  • 高性能：内核级实现，数据包转发效率极高，几乎没有额外的延迟。特别是在DR模式下，数据包只经过Director一次（入站），出站流量直接由Real Server返回给客户端，避免了Director成为瓶颈。
  • 低开销：对CPU和内存的消耗非常小。
  • 透明性：对后端服务器来说，客户端的源IP是可见的。
• 适用场景：
  • 高并发、大流量：例如大型网站的静态资源、CDN节点、数据库连接等场景。
  • 纯TCP/UDP负载均衡：对应用层协议不敏感，只做简单的端口转发。
  • 对性能要求极致：需要处理每秒数万甚至数十万的并发连接。
• 缺点：
  • 功能相对单一，不具备HTTP头部检查、URL路由、SSL卸载等应用层特性。
  • 配置相对复杂，特别是DR模式下的ARP问题需要额外处理。

HAProxy

豆绘AI

豆绘AI是国内领先的AI绘图与设计平台，支持照片、设计、绘画的一键生成。

485

查看详情

• 工作层面：可以工作在第四层（TCP模式）和第七层（HTTP模式）。
• 特点：
  • 功能丰富：支持HTTP头部修改、URL路由、内容切换、SSL卸载、会话保持（cookie、source IP等）、高级健康检查、ACL规则等。
  • 灵活性高：配置简单直观，易于管理和扩展。
  • 可观测性好：自带强大的统计页面，方便监控后端服务器状态和流量。
• 适用场景：
  • Web应用负载均衡：特别适合HTTP/HTTPS服务，如Web服务器、API网关、微服务入口。
  • 需要高级路由策略：根据URL、Cookie、Header等进行流量分发。
  • 会话保持：对需要保持用户会话的应用至关重要。
  • 中小型到大型规模：在大多数场景下，HAProxy的性能足以满足需求。
• 缺点：
  • 用户空间实现，相比LVS在极端高并发下会有一定的性能开销。
  • 作为代理，会改变客户端源IP（除非使用PROX Y协议或TPROXY模式）。

我的选择偏好：如果我只是想把流量均匀地分发到一组服务器，并且对性能要求极高，我会倾向于LVS。但如果我的应用是Web服务，需要更智能的流量管理，比如根据URL路径分发到不同的后端服务，或者需要SSL卸载来减轻后端服务器的压力，那HAProxy无疑是更好的选择。很多时候，LVS和HAProxy也会结合使用，LVS作为第一层负载均衡，将流量分发到HAProxy集群，再由HAProxy进行更细粒度的应用层分发。

如何解决LVS和HAProxy的单点故障问题？

负载均衡器本身如果挂了，那所有的后端服务器就都无法访问了，这显然是不能接受的。解决LVS和HAProxy的单点故障（SPOF）问题，最常见且有效的方法是引入Keepalived。

Keepalived的工作原理

Keepalived通过VRRP（Virtual Router Redundancy Protocol）协议实现高可用性。它会在一组服务器上配置一个虚拟IP（VIP），并通过心跳机制监控主服务器的状态。当主服务器发生故障时，Keepalived会自动将VIP漂移到备份服务器上，从而实现服务的无缝切换。

结合LVS实现高可用

在LVS集群中，通常会有两台或多台Director服务器。Keepalived会运行在这些Director上：

1. VIP管理：Keepalived会配置一个共享的VIP。正常情况下，主Director会持有这个VIP。
2. 健康检查：Keepalived会持续监控主Director的运行状态（例如，通过检查LVS进程、网络接口等）。
3. 故障切换：一旦主Director检测到故障，Keepalived会触发VRRP协议，让备份Director接管VIP，继续提供LVS负载均衡服务。
4. Real Server健康检查：Keepalived还可以配置对后端Real Server的健康检查。如果某个Real Server宕机，Keepalived可以通知LVS将其从服务列表中移除，避免流量发送到故障服务器。

Keepalived配置示例（LVS Director高可用）

# /etc/keepalived/keepalived.conf

global_defs {
    router_id lb01 # 路由器ID，唯一标识
}

vrrp_instance VI_1 {
    state MASTER # MASTER表示主服务器，BACKUP表示备份服务器
    interface eth0 # 绑定Keepalived的网卡
    virtual_router_id 51 # VRRP实例ID，同一组Keepalived必须相同
    priority 100 # 优先级，MASTER要高于BACKUP
    advert_int 1 # 广播间隔，秒

    authentication {
        auth_type PASS
        auth_pass 1111 # 认证密码
    }

    virtual_ipaddress {
        192.168.1.100/24 dev eth0 label eth0:0 # LVS的VIP
    }

    # 监控LVS进程，如果进程不存在，则切换
    track_script {
        chk_lvs
    }
}

# 定义一个脚本，用于检查LVS状态
vrrp_script chk_lvs {
    script "/usr/bin/killall -0 ipvsadm" # 检查ipvsadm进程是否存在
    interval 2 # 每2秒执行一次
    weight -20 # 如果脚本执行失败，优先级降低20
}

# LVS虚拟服务器定义（可选，Keepalived也可以直接管理LVS规则）
# 实际生产中，更推荐通过脚本或ipvsadm命令来管理LVS规则，Keepalived只负责VIP和Director切换
# virtual_server 192.168.1.100 80 {
#     delay_loop 6
#     lb_algo rr
#     lb_kind DR
#     persistence_timeout 0
#     protocol TCP

#     real_server 192.168.1.101 80 {
#         weight 100
#         TCP_CHECK {
#             connect_timeout 3
#             nb_get_retry 3
#             delay_before_retry 3
#         }
#     }
#     real_server 192.168.1.102 80 {
#         weight 100
#         TCP_CHECK {
#             connect_timeout 3
#             nb_get_retry 3
#             delay_before_retry 3
#         }
#     }
# }

结合HAProxy实现高可用

对于HAProxy，高可用的思路与LVS类似，也是通过Keepalived来管理HAProxy实例的VIP：

1. VIP管理：Keepalived在两台HAProxy服务器之间管理一个VIP。
2. 健康检查：Keepalived会监控HAProxy进程是否正常运行。
3. 故障切换：当主HAProxy服务器出现故障时，Keepalived会将VIP漂移到备份HAProxy服务器，确保服务不中断。

Keepalived配置示例（HAProxy高可用）

# /etc/keepalived/keepalived.conf

global_defs {
    router_id lb01
}

vrrp_instance VI_1 {
    state MASTER # MASTER或BACKUP
    interface eth0
    virtual_router_id 52
    priority 100 # MASTER优先级高于BACKUP
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 2222
    }

    virtual_ipaddress {
        192.168.1.200/24 dev eth0 label eth0:0 # HAProxy的VIP
    }

    track_script {
        chk_haproxy
    }
}

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy" # 检查haproxy进程是否存在
    interval 2
    weight -20
}

配置完Keepalived后，记得在两台服务器上都启动Keepalived服务。通过这种方式，即使一台负载均衡器宕机，服务也能快速恢复，大大提升了系统的可用性。

LVS的几种工作模式及其特点是什么？

LVS提供了三种主要的工作模式，每种模式都有其独特的优点和适用场景。在我看来，理解这些模式对于优化你的负载均衡方案至关重要。

1. NAT模式（Network Address Translation）

   • 原理：LVS Director作为所有请求的入口和出口。客户端请求到达Director，Director修改数据包的目标IP地址为Real Server的IP，然后转发给Real Server。Real Server处理完请求后，将响应发回给Director，Director再将响应的源IP地址修改为自己的IP，最后发回给客户端。
   • 特点：
     • 简单易用：配置相对简单，Real Server可以是任何操作系统，无需特殊配置。
     • Real Server可位于私有网络：Real Server可以与Director不在同一子网，甚至可以位于NAT后面的私有IP地址空间。
     • Director可能成为瓶颈：所有请求和响应流量都必须经过Director，当流量较大时，Director的带宽和处理能力可能成为瓶颈。
   • 适用场景：流量不是特别大，或者Real Server分布在不同网络环境中的情况。

2. DR模式（Direct Routing）

   • 原理：这是我最常用也是最推荐的LVS模式，尤其是在Web服务场景。客户端请求到达Director，Director只修改数据包的目标MAC地址为选定的Real Server的MAC地址，然后将数据包直接发送给Real Server。Real Server处理完请求后，直接将响应发回给客户端，不再经过Director。
   • 特点：
     • 高性能、高吞吐：Director只处理入站请求，响应流量不经过Director，极大地减轻了Director的负担，提高了整体吞吐量。
     • Real Server必须与Director在同一物理网络（或二层可达）：因为是基于MAC地址转发。
     • 需要解决ARP问题：Real Server需要配置VIP在回

以上就是Linux服务器负载均衡实现_Linux LVS与HAProxy配置教程的详细内容，更多请关注php中文网其它相关文章！