基于keepalived实现负载均衡的高可用

标签：lb1 负载 keepalived 192.168 nginx 均衡均衡器 root

实验要求：

1、实现负载均衡器的高可用，提升负载均衡器在面对高并发时的稳定性实验的延伸。

2、增加一个VRRP实例配置，设置两个漂移VIP ，提升面对高并发时架构带宽。

3、vip 一般对应每一个VRRP实例的网络接口，本次实验中将使用以太网接口实现配置，可以尝试将多个以太网卡接口配置链路聚合功能，进一步提升带宽

IP地址规划：

后端服务器将统一使用虚拟主机进行配置

192.168.110.33 （80-82）
负载均衡器： 192.168.110.11 192.168.110.22
vrrp实例VIP： 192.168.110.100

实验过程：

后端服务器

安装Nginx

[root@backend-servers ~]# dnf -y install nginx

注释server块

[root@backend-servers ~]# vim /etc/nginx/nginx.conf

新建一个配置文件

[root@backend-servers ~]# cat /etc/nginx/conf.d/servers.conf
server{
        listen 80;
        server_name web1;
        root /usr/share/nginx/html1;
        index index.html index.htm;
}
server{
        listen 81;
        server_name web2;
        root /usr/share/nginx/html2;
        index index.html index.htm;
}
server{
        listen 82;
        server_name web3;
        root /usr/share/nginx/html3;
        index index.html index.htm;
}

关闭防火墙和SELINUX

[root@backend-servers ~]# setenforce 0
[root@backend-servers ~]#  systemctl stop firewalld.service

启动Nginx

[root@backend-servers ~]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@backend-servers ~]# systemctl start nginx

检查端口是否正常

[root@backend-servers ~]# ss -anput | grep nginx
tcp   LISTEN 0      511           0.0.0.0:81          0.0.0.0:*     users:(("nginx",pid=3853,fd=7),("nginx",pid=3852,fd=7),("nginx",pid=3851,fd=7),("nginx",pid=3850,fd=7),("nginx",pid=3849,fd=7))
tcp   LISTEN 0      511           0.0.0.0:80          0.0.0.0:*     users:(("nginx",pid=3853,fd=6),("nginx",pid=3852,fd=6),("nginx",pid=3851,fd=6),("nginx",pid=3850,fd=6),("nginx",pid=3849,fd=6))
tcp   LISTEN 0      511           0.0.0.0:82          0.0.0.0:*     users:(("nginx",pid=3853,fd=8),("nginx",pid=3852,fd=8),("nginx",pid=3851,fd=8),("nginx",pid=3850,fd=8),("nginx",pid=3849,fd=8))

创建主页文件，测试web能否正常访问

[root@backend-servers ~]# mkdir /usr/share/nginx/html{1..3}
[root@backend-servers ~]# echo server1 > /usr/share/nginx/html1/index.html
[root@backend-servers ~]# echo server2 > /usr/share/nginx/html2/index.html
[root@backend-servers ~]# echo server3 > /usr/share/nginx/html3/index.html

[root@backend-servers ~]# curl 192.168.110.33:80
server1
[root@backend-servers ~]# curl 192.168.110.33:81
server2
[root@backend-servers ~]# curl 192.168.110.33:82
server3

负载均衡器1

本次实验使用**haproxy**，可以提供基于端口、基于uri、基于服务访问的负载均衡，本质是一个7层负载均衡服务。

功能:

状态检查（为后端服务器提供状态检查）
数据统计，统计工作池中的后端服务器目前处理的连接数、活跃连接数、历史连接数
提供后端服务器的状态管理，可以在haproxy 中暂时禁用后端工作池中的某一个服务器，设置其为维护模式，不在于负载均衡的调度，维护结束后，移除维护标志，重新加入后端池，参数负载均衡调度。

haproxy 在配置负载均衡时，关注两个重点：

1、前端 frontend // 配置如何接受请求

2、后端 bakend // 后端真正处理请求的服务器池，在这个负载均衡池中，服务器的负载均衡调度算法的配置

安装配置haproxy

[root@lb1 ~]# dnf -y install haproxy
[root@lb1 ~]# vim /etc/haproxy/haproxy.cfg

从frontend 开始下面行删除重新编写

frontend main
    bind *:80
    default_backend servers

backend servers
    balance roundrobin
    server web1 192.168.110.33:80
    server web2 192.168.110.33:81
    server web3 192.168.110.33:82

检查配置文件是否有效

[root@lb1 ~]# haproxy -c -f /etc/haproxy/haproxy.cfg
Configuration file is valid

启动HAproxy服务

[root@lb1 ~]# systemctl start haproxy.service
[root@lb1 ~]# ss -anput | grep haproxy
tcp   LISTEN 0      3000          0.0.0.0:80          0.0.0.0:*     users:(("haproxy",pid=6616,fd=6))

测试

[root@lb1 ~]# setenforce 0
[root@lb1 ~]# curl 127.0.0.1
server1
[root@lb1 ~]# curl 127.0.0.1
server2
[root@lb1 ~]# curl 127.0.0.1
server3

负载均衡器2

配置负载均衡器2的过程，与负载均衡器1 的配置过程完全一致。

[root@lb2 ~]# dnf -y install haproxy
#将负载均衡器1的配置文件复制到负载均衡器2上。
[root@lb1 ~]# scp /etc/haproxy/haproxy.cfg [email protected]:/etc/haproxy/

[root@lb2 ~]# setenforce 0
[root@lb2 ~]# firewall-cmd --add-port=80/tcp
success
[root@lb2 ~]# firewall-cmd --add-port=80/udp
success
[root@lb2 ~]# haproxy -c -f /etc/haproxy/haproxy.cfg
Configuration file is valid
[root@lb2 ~]# systemctl start haproxy
[root@lb2 ~]# curl 127.0.0.1
server1
[root@lb2 ~]# curl 127.0.0.1
server2
[root@lb2 ~]# curl 127.0.0.1
server3

下面通过keepalived利用vrrp协议实现负载均衡器的高可用

分别在负载均衡器1 和负载均衡器2 上配置vrrp实例，需要保证VRRP实例的配置绑定的网卡能够互相通信，还需要保证负载均衡器1 和负载均衡器2 能够就优先级完成主备节点的选举，否则VIP无法分配，导致高可用实际不生效。

// 通过ens160 测试与另一台负载均衡器的通信

[root@lb1 ~]# ping -i ens160 192.168.110.22  -c 5
ping: option argument contains garbage: ens160
ping: this will become fatal error in the future
PING 192.168.110.22 (192.168.110.22) 56(84) bytes of data.
64 bytes from 192.168.110.22: icmp_seq=1 ttl=64 time=0.562 ms
64 bytes from 192.168.110.22: icmp_seq=2 ttl=64 time=0.311 ms
64 bytes from 192.168.110.22: icmp_seq=3 ttl=64 time=0.522 ms
64 bytes from 192.168.110.22: icmp_seq=4 ttl=64 time=0.285 ms
64 bytes from 192.168.110.22: icmp_seq=5 ttl=64 time=0.328 ms

--- 192.168.110.22 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 0.285/0.401/0.562/0.116 ms, ipg/ewma 0.737/0.477 ms

安装keepalived

在两个负载均衡节点上都安装keepalived

[root@lb1 ~]# dnf -y install epel-release
[root@lb1 ~]# crb enable
Enabling CRB repo
CRB repo is enabled and named: crb
[root@lb1 ~]# dnf repolist
repo id                   repo name
appstream                 CentOS Stream 9 - AppStream
baseos                    CentOS Stream 9 - BaseOS
crb                       CentOS Stream 9 - CRB
epel                      Extra Packages for Enterprise Linux 9 - x86_64
epel-cisco-openh264       Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64
epel-next                 Extra Packages for Enterprise Linux 9 - Next - x86_64
extras-common             CentOS Stream 9 - Extras packages
[root@lb1 ~]# dnf info keepalived
Available Packages
Name         : keepalived
Version      : 2.2.8
Release      : 3.el9
Architecture : x86_64
Size         : 560 k
…… 省略……
[root@lb1 ~]# dnf -y install keepalived

另一种安装仓库方式：参考网站

[root@lb1 yum.repos.d]# dnf config-manager --set-enabled crb                                        
[root@lb1 yum.repos.d]# dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

负载均衡器1 上修改配置文件

[root@lb1 ~]# cat /etc/keepalived/keepalived.conf

配置文件中修改成如下内容

! Configuration File for keepalived

global_defs {
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 100
   vrrp_gna_interval 100
}

vrrp_instance lb_ha {
    state MASTER
    interface ens160
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.110.100/24
    }
}

重启服务

[root@lb1 yum.repos.d]# systemctl restart keepalived.service

查看ip地址变化

配置防火墙

[root@lb1 ~]# systemctl stop firewalld.service
[root@lb1 ~]# nft flush ruleset
[root@lb1 ~]# nft list  ruleset

在负载均衡器2 上同样方法安装keepalived并修改配置文件

[root@lb2 ~]# dnf install -y keepalived
[root@lb2 ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance lb_ha {
    state BACKUP		//
    interface ens160
    virtual_router_id 51
    priority 90		//
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.110.100/24
    }
}
[root@lb2 ~]# systemctl start keepalived.service

防火墙也一样

[root@lb2 ~]# systemctl restart keepalived.service
[root@lb2 ~]# systemctl stop firewalld.service
[root@lb2 ~]# nft flush ruleset
[root@lb2 ~]# nft list ruleset

查看ip地址区别

此时VIP根据优先级，出现在值更高的负载均衡器1上。

结合日志可以更直观看到VIP分配和VRRP选举过程

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:8b:3e:24 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 192.168.110.11/24 brd 192.168.110.255 scope global noprefixroute ens160
       valid_lft forever preferred_lft forever
    inet 192.168.110.100/24 scope global secondary ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe8b:3e24/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

[root@lb1 ~]# ping 192.168.110.100
PING 192.168.110.100 (192.168.110.100) 56(84) bytes of data.
64 bytes from 192.168.110.100: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 192.168.110.100: icmp_seq=2 ttl=64 time=0.037 ms
^C
--- 192.168.110.100 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.035/0.036/0.037/0.001 ms

通过VIP 访问负载均衡器，负载均衡器将请求转发给后端服务器，后端服务器按照轮询调度算法依次响应。

[root@lb1 ~]# curl 192.168.110.100
server1
[root@lb1 ~]# curl 192.168.110.100
server2
[root@lb1 ~]# curl 192.168.110.100
server3

此时只要VIP存在就可以访问VIP所在的负载均衡器，从而访问到后端节点。

宕机测试

下面模拟lb1宕机，通过停止keepalived服务来模拟，此时负载均衡器1 不在组播状态报文，则备份节点选举成为主节点。

注意因为切换过程中，防火墙会设定拒绝规则，每重启一次keepalived服务，就应该清理一次对应节点上的防火墙规则。

清理访问墙规则如下：

nft flush ruleset

模拟故障过程：

[root@lb1 ~]# systemctl stop keepalived.service

lb1上的VIP没了

发现在lb2上

清理一下防火墙规则

[root@lb2 ~]# nft flush ruleset

在测试一下

[root@lb1 yum.repos.d]# curl 192.168.110.100
server2
[root@lb1 yum.repos.d]# curl 192.168.110.100
server3
[root@lb1 yum.repos.d]# curl 192.168.110.100
server1

查看lb1日志

[root@lb1 ~]# tail -30 /var/log/messages

查看lb2日志

日志显示VIP漂移过程

附加

lb2的keepalived配置文件？

[root@lb2 ~]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance lb_ha {
    state BACKUP
    interface ens160
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.110.100/24
    }
}

这段配置是 keepalived 的配置文件，keepalived 是一个用于高可用性（HA）和负载均衡的工具，主要在 Linux 系统中使用。以下是该配置的详细解释：

1. global_defs 块
这个块包含一些全局配置选项，适用于所有的 VRRP（Virtual Router Redundancy Protocol）实例。

router_id LVS_DEVEL：
- 指定路由器的唯一标识符（ID）。在多实例配置中，确保每个路由器都有唯一的 ID，以避免冲突。
vrrp_skip_check_adv_addr：
- 跳过对 VRRP 广播地址的检查。这允许 VRRP 通信时忽略某些地址的验证，有助于避免某些配置错误。
vrrp_strict：
- 启用严格模式，以确保 VRRP 的状态转移和广告的正确性。这意味着如果某个条件不满足，实例不会转移状态。
vrrp_garp_interval 0：
- 设置 GARP（Gratuitous ARP）发送的时间间隔为 0，表示不发送 GARP。GARP 用于更新网络中的 ARP 缓存，在 IP 地址发生变化时通知其他设备。
vrrp_gna_interval 0：
- 设置 GNA（Gratuitous Neighbor Advertisement）发送的时间间隔为 0，表示不发送 GNA。GNA 在 IPv6 中用来通知相邻节点有关地址变化的信息。

2. vrrp_instance 块
这个块定义了一个 VRRP 实例，具体配置如下：

vrrp_instance lb_ha：
- 实例的名称为 lb_ha，用于标识该 VRRP 实例。
state BACKUP：
- 指定当前实例的状态为 BACKUP。在 VRRP 中，实例可以是 MASTER（主节点）或 BACKUP（备份节点）。这里表明该实例当前不是主节点。
interface ens160：
- 指定该实例监听的网络接口为 ens160。这意味着 VRRP 广播和管理流量将通过这个网络接口进行。
virtual_router_id 51：
- 定义虚拟路由器的 ID，所有参与同一 VRRP 组的实例必须具有相同的虚拟路由器 ID，以便彼此识别。
priority 90：
- 指定该实例的优先级为 90。优先级用于确定在发生故障时哪个实例将成为主节点，值越高，优先级越高。MASTER 节点优先级通常会高于 BACKUP 节点。
advert_int 1：
- 指定广告的时间间隔为 1 秒。主节点将每秒发送一次 VRRP 广告，以通知其他节点其状态。
authentication** 块**：
- 定义 VRRP 实例的认证信息：
- auth_type PASS：指定认证类型为简单的密码认证。
- auth_pass 1111：指定用于认证的密码（在实际部署中，请确保使用强密码并保护此信息）。
virtual_ipaddress** 块**：
- 指定该 VRRP 实例的虚拟 IP 地址：
- 192.168.110.100/24：配置的虚拟 IP 地址，用于故障转移和负载均衡。当主节点故障时，备份节点将接管此 IP 地址，确保服务的连续性。

总结
这段配置定义了一个 VRRP 实例 lb_ha，其中当前实例处于 BACKUP 状态，通过接口 ens160 监听。配置的虚拟 IP 地址为 192.168.110.100，并且使用简单的密码认证。此配置的目的是实现高可用性，确保在主节点出现故障时，备份节点能够及时接管，保证服务的连续性。

什么是keepalived？

Keepalived 是一个用于实现高可用性（HA）和负载均衡的 Linux 工具。它主要利用 VRRP（Virtual Router Redundancy Protocol）协议来确保在主服务器发生故障时，能够快速而自动地切换到备份服务器，从而保证网络服务的连续性。以下是 Keepalived 的一些关键特点和功能：

1. 高可用性

故障转移：Keepalived 允许在服务器故障时实现快速故障转移。通过 VRRP，当主节点不可用时，备份节点会接管虚拟 IP 地址，从而确保服务不中断。
健康检查：Keepalived 可以定期检查服务或节点的健康状态，并根据检查结果决定是否将某个节点标记为主节点或备份节点。

2. 负载均衡

负载分配：Keepalived 支持负载均衡，可以在多个后端服务器之间分配流量。这样，用户的请求可以根据不同的策略（如轮询、最少连接数等）分配给后端服务器，优化资源利用率和响应时间。

3. 配置简单

易于配置：Keepalived 的配置文件相对简单，使用起来较为直观，便于用户根据需求进行定制。配置文件中可以定义全局参数、VRRP 实例、虚拟 IP 地址等。

4. 兼容性

与其他工具兼容：Keepalived 可以与多种负载均衡器配合使用，比如 Nginx、HAProxy 等，提供更为灵活的架构解决方案。

5. 运行机制

VRRP 协议：Keepalived 通过 VRRP 协议实现主备节点之间的通信，确保在主节点故障时备份节点能够快速接管。
健康检查机制：Keepalived 可以执行多种健康检查（如 TCP、HTTP、脚本检查等），以监测后端服务的可用性。

应用场景
Keepalived 通常用于需要高可用性的服务场景，如：

Web 服务（如 Nginx、Apache）
数据库服务（如 MySQL、PostgreSQL）
应用服务器
企业级服务和云环境

总结
Keepalived 是一个强大的高可用性和负载均衡解决方案，适用于各种网络服务和应用程序。它能够有效地提高系统的可靠性和可用性，确保用户服务的连续性。

HAproxy和Nginx的区别？

HAProxy 和 Nginx 是两个非常流行的负载均衡器和反向代理服务器，它们各自有其独特的功能和使用场景。以下是它们之间的主要区别：

1. 功能和用途

HAProxy:
- 主要用于负载均衡，支持 TCP 和 HTTP 协议。
- 提供高可用性和故障转移能力，能够在多个后端服务器之间分配流量。
- 适用于需要高性能和高并发的应用场景，特别是在金融和电商等行业。
Nginx:
- 既可以作为负载均衡器，也可以作为 web 服务器。
- 除了反向代理和负载均衡，Nginx 还支持静态内容服务、SSL/TLS 终止、HTTP/2、WebSocket 等。
- 常用于内容分发网络 (CDN) 和高性能 web 应用。

2. 性能

HAProxy:
- 以高性能和低延迟著称，适合处理大量的 TCP 连接。
- 更加专注于负载均衡，处理能力强，尤其是在 Layer 4 负载均衡方面。
Nginx:
- 也非常高效，特别是在处理静态文件和高并发连接时表现出色。
- 因其事件驱动架构，能够处理大量的并发连接，但在某些情况下可能不如 HAProxy 在 TCP 层的性能。

3. 配置与使用

HAProxy:
- 配置文件相对简单，主要集中在负载均衡和后端服务的设置上。
- 适合那些主要关注负载均衡而不需要其他 web 服务器功能的用户。
Nginx:
- 配置灵活，可以进行复杂的路由和条件处理。
- 需要更多的配置项，适合需要多种功能（如缓存、压缩、访问控制等）的用户。

4. 负载均衡算法

HAProxy:
- 提供多种负载均衡算法（如轮询、最少连接、源 IP 哈希等），适合于多种场景。
Nginx:
- 也提供基本的负载均衡算法（如轮询、最少连接），但在高级算法和自定义选项上不如 HAProxy 灵活。

5. 监控和统计

HAProxy:
- 提供内置的统计界面，允许实时监控后端服务器的性能和流量。
- 统计信息详细，便于进行性能分析。
Nginx:
- 也提供日志和监控工具，但需要额外的模块（如 nginx-stats）来获取详细的性能统计。

6. 生态系统与社区支持

HAProxy:
- 拥有活跃的社区支持和丰富的文档，主要关注于负载均衡。
Nginx:
- 同样有强大的社区支持和丰富的文档，广泛用于各种类型的 web 应用。

总结

HAProxy 更加专注于负载均衡，适合需要高性能和高并发处理的场景。
Nginx 作为一个多功能的 web 服务器和反向代理，适合需要丰富功能的应用场景。

选择哪个工具取决于你的具体需求和使用场景。如果主要需要负载均衡，HAProxy 是不错的选择；如果需要一个高性能的 web 服务器，Nginx 会更合适。

Nginx可以完全取代Apache吗

Nginx和Apache都是非常流行的Web服务器，具有各自的优点和适用场景。关于Nginx是否可以完全取代Apache的问题，实际上并没有明确的答案，因为这取决于具体的使用场景和需求。以下是对两者的比较和考虑因素：

Nginx的优点

高性能：
- Nginx以事件驱动架构为基础，能够处理大量并发连接，适合高流量的网站。
- 在静态内容处理上，Nginx通常比Apache更快。
低资源消耗：
- Nginx在内存和CPU使用方面更高效，适合资源有限的服务器。
反向代理功能：
- Nginx非常适合用作反向代理服务器和负载均衡器，能够很好地与后端服务（如应用服务器）配合使用。
易于配置和维护：
- Nginx的配置文件相对简单，易于理解和修改。
处理高并发：
- Nginx能够有效管理高并发连接，特别是在静态内容服务和反向代理方面表现优异。

Apache的优点

模块化：
- Apache的模块化设计允许用户根据需求加载不同的模块，这使得其功能非常灵活。
- 有许多现成的模块可以扩展Apache的功能。
动态内容处理：
- Apache在处理动态内容（如PHP、Python等）方面相对成熟，支持多种运行模式（如mod_php）。
丰富的文档和社区支持：
- Apache的历史悠久，有大量的文档和社区支持，容易找到解决方案和案例。
可定制性：
- Apache提供了更高的可定制性，用户可以根据具体需求进行深度配置。

结合使用的可能性
在许多情况下，Nginx和Apache可以结合使用，以发挥各自的优势。例如，Nginx可以作为反向代理服务器，处理所有的HTTP请求，然后将动态请求转发到Apache进行处理。这样，Nginx可以利用其高性能来处理静态文件和大量并发连接，而Apache则处理动态内容。

结论
Nginx可以在许多场景下完全替代Apache，尤其是在高流量和高并发的环境中。然而，某些情况下（如需要大量动态内容处理或使用特定Apache模块），Apache仍然具有优势。因此，选择Nginx还是Apache应根据具体的项目需求、服务器资源和开发团队的熟悉程度来决定。

标签：lb1,负载,keepalived,192.168,nginx,均衡,均衡器,root
From： https://blog.csdn.net/qq_42853133/article/details/142848396