前言
在现代企业级应用架构中,高可用性和负载均衡是确保系统稳定运行的关键技术。本文将详细介绍如何通过Keepalived实现双机热备,使用HAProxy构建内网服务负载均衡,以及解决网络性能问题中的网卡软中断优化。通过实际案例和详细配置说明,帮助读者理解这些技术的核心原理和实战应用。
Keepalived双机热备部署
VRRP原理
虚拟路由冗余协议(Virtual Router Redundancy Protocol, VRRP)是用于实现路由器高可用的协议。在VRRP架构中,多台路由器组成一个虚拟路由器,其中一台作为主路由器(MASTER)负责处理实际的网络流量,其他作为备份路由器(BACKUP)。当主路由器发生故障时,备份路由器会立即接管,确保网络服务的连续性。
VRRP的核心概念包括:
- 虚拟路由器ID(VRID):标识一个虚拟路由器组
- 虚拟IP地址:虚拟路由器对外提供的IP地址
- 优先级:决定路由器在组中的角色,数值越高优先级越高
- 通告间隔:路由器发送心跳消息的时间间隔
- 认证机制:确保只有授权的路由器可以加入虚拟路由器组
在我们的架构中,配置了多个VRRP实例以实现不同网络段的高可用:
flowchart TD
A[虚拟路由器组] --> B[外部网络VRRP实例]
A --> C[内部网络VRRP实例]
B --> D[服务器-1 主]
B --> E[服务器-2 备份]
C --> F[服务器-1 主]
C --> G[服务器-2 备份]
D --> H[浮动IP1: 192.168.1.66]
D --> I[浮动IP2: 192.168.1.67]
E --> H
E --> I
F --> J[浮动IP3: 192.168.2.12]
F --> K[浮动IP4: 192.168.2.16]
G --> J
G --> K
完整配置详解
服务器-1 配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
| ! Configuration File for keepalived
global_defs {
router_id server-1
}
static_ipaddress {
192.168.1.64/23 dev br0
192.168.2.13 dev br1
}
static_routes {
default via 192.168.1.1 dev br0
192.168.2.14/32 via 192.168.2.13 src 192.168.2.13
192.168.2.12/32 via 192.168.2.13 src 192.168.2.13
192.168.2.0/16 via 192.168.2.64 dev br1
}
vrrp_instance EX_1 {
state BACKUP
interface br1
mcast_src_ip 192.168.2.64
virtual_router_id 100
priority 100
advert_int 2
authentication {
auth_type PASS
auth_pass YOUR_PASSWORD
}
virtual_ipaddress {
192.168.1.66 dev br0
192.168.1.67 dev br0
192.168.1.68 dev br0
192.168.1.69 dev br0
}
}
vrrp_instance EX_2 {
state BACKUP
interface br1
mcast_src_ip 192.168.2.64
virtual_router_id 101
priority 50
advert_int 2
authentication {
auth_type PASS
auth_pass YOUR_PASSWORD
}
virtual_ipaddress {
192.168.1.76 dev br0
192.168.1.77 dev br0
192.168.1.78 dev br0
192.168.1.79 dev br0
}
}
vrrp_instance INT_1 {
state BACKUP
interface br1
mcast_src_ip 192.168.2.64
virtual_router_id 102
priority 100
advert_int 2
authentication {
auth_type PASS
auth_pass YOUR_PASSWORD
}
virtual_ipaddress {
192.168.2.12 dev br1
192.168.2.16 dev br1
192.168.2.17 dev br1
192.168.2.18 dev br1
192.168.2.19 dev br1
}
}
vrrp_instance INT_2 {
state BACKUP
interface br1
mcast_src_ip 192.168.2.64
virtual_router_id 103
priority 50
advert_int 2
authentication {
auth_type PASS
auth_pass YOUR_PASSWORD
}
virtual_ipaddress {
192.168.2.20 dev br1
192.168.2.21 dev br1
192.168.2.22 dev br1
192.168.2.23 dev br1
}
}
|
服务器-2 配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
| ! Configuration File for keepalived
global_defs {
router_id server-2
}
static_ipaddress {
192.168.1.65/23 dev br0
192.168.2.14 dev br1
}
static_routes {
default via 192.168.1.1 dev br0
192.168.2.13/32 via 192.168.2.14 src 192.168.2.14
192.168.2.12/32 via 192.168.2.14 src 192.168.2.14
192.168.2.0/16 via 192.168.2.65 dev br1
}
vrrp_instance EX_1 {
state BACKUP
interface br1
mcast_src_ip 192.168.2.65
virtual_router_id 100
priority 50
advert_int 2
authentication {
auth_type PASS
auth_pass YOUR_PASSWORD
}
virtual_ipaddress {
192.168.1.66 dev br0
192.168.1.67 dev br0
192.168.1.68 dev br0
192.168.1.69 dev br0
}
}
vrrp_instance EX_2 {
state BACKUP
interface br1
mcast_src_ip 192.168.2.65
virtual_router_id 101
priority 100
advert_int 2
authentication {
auth_type PASS
auth_pass YOUR_PASSWORD
}
virtual_ipaddress {
192.168.1.76 dev br0
192.168.1.77 dev br0
192.168.1.78 dev br0
192.168.1.79 dev br0
}
}
vrrp_instance INT_1 {
state BACKUP
interface br1
mcast_src_ip 192.168.2.65
virtual_router_id 102
priority 50
advert_int 2
authentication {
auth_type PASS
auth_pass YOUR_PASSWORD
}
virtual_ipaddress {
192.168.2.12 dev br1
192.168.2.16 dev br1
192.168.2.17 dev br1
192.168.2.18 dev br1
192.168.2.19 dev br1
}
}
vrrp_instance INT_2 {
state BACKUP
interface br1
mcast_src_ip 192.168.2.65
virtual_router_id 103
priority 100
advert_int 2
authentication {
auth_type PASS
auth_pass YOUR_PASSWORD
}
virtual_ipaddress {
192.168.2.20 dev br1
192.168.2.21 dev br1
192.168.2.22 dev br1
192.168.2.23 dev br1
}
}
|
配置要点解析
优先级设置:服务器-1在外部网络VRRP实例(EX_1)和内部网络VRRP实例(INT_1)中设置为100,为主节点;服务器-2在EX_2和INT_2中设置为100,为主节点。这种设计实现了负载均衡的同时确保高可用。
非抢占模式:配置中的#nopreempt注释表明采用非抢占模式,即主节点恢复后不会立即抢占资源,避免网络震荡。
双网络架构:分别处理外部网络(EX实例)和内部网络(INT实例)的流量,实现网络隔离和独立高可用。
认证机制:使用简单的密码认证确保VRRP通信的安全性。
flowchart TD
A[业务系统客户端] --> B[外部网络]
B --> C[浮动IP 192.168.1.66-69]
C --> D[Keepalived VIP]
E[内部业务系统] --> F[内部网络]
F --> G[浮动IP 192.168.2.12-23]
G --> H[Keepalived VIP]
D --> I[服务器-1/服务器-2]
H --> I
I --> J[业务系统服务]
HAProxy内网服务负载均衡
TCP模式负载均衡
部署架构
针对业务系统的两个核心服务(杀毒服务和投递服务),我们在服务器-1和服务器-2上部署了HAProxy实现负载均衡。这种架构的优势在于:
- 服务可用性:单台网关故障不会影响后端客户业务系统
- 负载分担:多台服务器共同承担服务压力
- 透明切换:后端配置无需感知具体的服务器变化
flowchart TD
A[客户端系统] --> B[HAProxy负载均衡器]
B --> C[服务器-1]
B --> D[服务器-2]
B --> E[服务器-3]
B --> F[服务器-4]
C --> G[杀毒服务6600]
D --> G
E --> G
F --> G
C --> H[投递服务8025]
D --> H
E --> H
F --> H
C --> I[反垃圾引擎8070]
D --> I
HAProxy配置详解
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| #---------------------------------------------------------------------
# 杀毒服务负载均衡配置
#---------------------------------------------------------------------
listen kill-virus-service
bind *:6600
mode tcp
balance roundrobin
server server-1-antivirus 192.168.1.64:6600 weight 1 maxconn 10000 check inter 10s
server server-2-antivirus 192.168.1.65:6600 weight 1 maxconn 10000 check inter 10s
server server-3-antivirus 192.168.1.66:6600 weight 1 maxconn 10000 check inter 10s
server server-4-antivirus 192.168.1.67:6600 weight 1 maxconn 10000 check inter 10s
server server-5-antivirus 192.168.1.69:6600 weight 1 maxconn 10000 check inter 10s
server server-6-antivirus 192.168.1.71:6600 weight 1 maxconn 10000 check inter 10s
server server-7-antivirus 192.168.1.73:6600 weight 1 maxconn 10000 check inter 10s
#---------------------------------------------------------------------
# 投递服务负载均衡配置
#---------------------------------------------------------------------
listen delivery-service
bind *:8025
mode tcp
balance roundrobin
server server-1-smtp 192.168.1.64:8025 weight 1 maxconn 10000 check inter 10s
server server-2-smtp 192.168.1.65:8025 weight 1 maxconn 10000 check inter 10s
server server-3-smtp 192.168.1.69:8025 weight 1 maxconn 10000 check inter 10s
server server-4-smtp 192.168.1.73:8025 weight 1 maxconn 10000 check inter 10s
#---------------------------------------------------------------------
# 反垃圾引擎服务负载均衡配置
#---------------------------------------------------------------------
listen cac-service
bind *:8070
mode tcp
balance roundrobin
server server-1-cac 192.168.1.68:8070 weight 1 maxconn 20000 check inter 10s
|
健康检查与统计
健康检查机制
HAProxy提供了完善的健康检查机制:
- 连接检查:通过
check参数启用 - 检查间隔:
inter 10s表示每10秒检查一次 - 最大连接数:
maxconn限制每个服务器的最大连接数 - 权重设置:
weight参数用于分配流量权重
统计功能
HAProxy内置Web统计界面,可以通过配置启用:
1
2
3
4
5
6
7
8
9
10
| listen stats
bind *:8404
mode http
stats enable
stats uri /stats
stats refresh 30s
stats auth admin:YOUR_PASSWORD
stats realm HAProxy\ Statistics
stats hide-version
stats auth admin:admin123
|
状态监控
通过以下命令监控HAProxy状态:
1
2
3
4
5
6
7
8
9
10
11
| # 查看HAProxy进程状态
systemctl status haproxy
# 查看HAProxy统计信息
curl http://192.168.1.100:8404/stats
# 查看连接状态
ss -tulnp | grep haproxy
# 查看日志
tail -f /var/log/haproxy.log
|
网络性能调优:网卡软中断优化
硬中断与软中断原理
什么是中断?
中断是由于接收来自外围硬件(相对于CPU和内存)的异步信号或者来自软件的同步信号,而进行的相应硬件、软件处理。发出这样的信号称为进行中断请求(interrupt request, IRQ)。
硬中断与软中断的区别
硬中断:
- 外围硬件发给CPU或内存的异步信号
- 需要有中断控制器参与
- 处理速度快,直接以硬件方式引发
- 可以通过设置CPU的屏蔽位进行屏蔽
软中断:
- 由软件系统本身发给操作系统内核的中断信号
- 通常是由硬中断处理程序或进程调度程序触发
- 以CPU指令的形式指示CPU进行处理
- 不能屏蔽,属于系统调用的一部分
中断处理流程
flowchart TD
A[硬件事件] --> B[硬中断触发]
B --> C[保存CPU上下文]
C --> D[执行硬中断处理程序]
D --> E[触发软中断]
E --> F[软中断处理]
F --> G[恢复CPU上下文]
G --> H[返回原程序]
问题定位过程
症状识别
业务网关高峰期出现网络丢包问题,CPU0软中断%sys高达90%,说明网络处理成为系统瓶颈。
监控工具使用
查看中断分布情况:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| # 查看各CPU的中断统计
cat /proc/interrupts | head -20
# 查看每个CPU的中断分布
cat /proc/interrupts | grep "CPU0"
# 使用itop工具实时查看
itop
# 查看系统负载
uptime
# 查看网络统计
netstat -s
|
详细分析步骤:
- 确定问题CPU:通过
/proc/interrupts查看哪个CPU处理中断最多 - 定位中断源:分析是哪个网卡或设备产生的高中断
- 分析网络流量:使用
iftop、nethogs等工具查看流量模式 - 检查驱动程序:确认网卡驱动版本是否支持优化
RPS/RFS优化方案
RPS(Receive Packet Steering)
RPS允许将接收到的网络包分发到多个CPU核心处理,避免单个CPU过载。
配置方法:
1
2
3
4
5
6
7
8
9
10
11
| # 查看当前网卡CPU亲和性
cat /proc/net/dev | grep -E "eth[0-9]+"
# 设置RPS,允许所有CPU处理网卡中断
echo ffffffff > /sys/class/net/eth0/queues/rx-0/rps_cpus
# 验证配置
cat /sys/class/net/eth0/queues/rx-0/rps_cpus
# 查看RPS统计
cat /proc/net/softnet_stat
|
RFS(Receive Flow Steering)
RFS进一步优化,将属于同一个网络流的包调度到相同的CPU处理,提高缓存命中率。
配置方法:
1
2
3
4
5
6
7
8
| # 启用RFS
echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
# 设置RFS过滤器
echo 2 > /proc/sys/net/core/rps_sock_flow_entries
# 验证RFS配置
cat /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
|
综合优化配置
优化脚本示例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| #!/bin/bash
# 获取网卡名称
interface="eth0"
# 启用RPS
echo ffffffff > /sys/class/net/$interface/queues/rx-0/rps_cpus
echo ffffffff > /sys/class/net/$interface/queues/rx-1/rps_cpus
echo ffffffff > /sys/class/net/$interface/queues/rx-2/rps_cpus
echo ffffffff > /sys/class/net/$interface/queues/rx-3/rps_cpus
# 启用RFS
echo 32768 > /sys/class/net/$interface/queues/rx-0/rps_flow_cnt
echo 32768 > /sys/class/net/$interface/queues/rx-1/rps_flow_cnt
echo 32768 > /sys/class/net/$interface/queues/rx-2/rps_flow_cnt
echo 32768 > /sys/class/net/$interface/queues/rx-3/rps_flow_cnt
# 启用中断合并
echo 1 > /sys/class/net/$interface/queues/rx-0/rps_flow_cnt
echo 1 > /sys/class/net/$interface/queues/rx-1/rps_flow_cnt
echo 1 > /sys/class/net/$interface/queues/rx-2/rps_flow_cnt
echo 1 > /sys/class/net/$interface/queues/rx-3/rps_flow_cnt
# 调整网卡队列长度
echo 1000 > /proc/sys/net/core/netdev_max_backlog
# 调整TCP缓冲区
echo 65536 > /proc/sys/net/core/rmem_max
echo 65536 > /proc/sys/net/core/wmem_max
# 启用TCP BBR拥塞控制
echo 'tcp_bbr' > /proc/sys/net/ipv4/tcp_congestion_control
# 验证配置
echo "RPS配置:"
cat /sys/class/net/$interface/queues/rx-0/rps_cpus
echo "RFS配置:"
cat /sys/class/net/$interface/queues/rx-0/rps_flow_cnt
|
优化效果验证
flowchart TD
A[优化前] --> B[软中断90%]
A --> C[网络丢包]
A --> D[单CPU过载]
E[优化后] --> F[软中断30%]
E --> G[零丢包]
E --> H[多CPU负载均衡]
B --> I[RPS/RFS优化]
C --> I
D --> I
I --> F
I --> G
I --> H
验证命令:
1
2
3
4
5
6
7
8
9
10
11
| # 监控中断使用情况
watch -n 1 "cat /proc/interrupts | grep eth0"
# 监控CPU使用情况
mpstat 1 5
# 监控网络性能
ping -c 100 192.168.1.1
# 检查丢包情况
netstat -s | grep packet
|
总结
本文详细介绍了Linux高可用与负载均衡的实战方案,主要包含以下关键点:
1. Keepalived双机热备架构
通过VRRP协议实现了高可用的网络架构,配置要点包括:
- 多实例设计分别处理外部和内部网络流量
- 优先级设置实现主备负载均衡
- 非抢占模式避免网络震荡
- 认证机制确保通信安全
2. HAProxy负载均衡实现
为业务系统的核心服务提供了高可用负载均衡:
- TCP模式负载均衡确保服务可用性
- 健康检查机制自动剔除故障节点
- 统计功能便于运维监控
- 多服务统一管理简化配置
3. 网络性能优化实践
针对软中断过高问题的解决方案:
- RPS技术实现接收包的多CPU分发
- RFS技术优化网络流处理
- 综合配置解决网络瓶颈
- 实时监控验证优化效果
4. 运维建议
- 定期监控:建立完善的监控体系,及时发现系统瓶颈
- 容量规划:根据业务增长预测,提前进行扩容规划
- 故障演练:定期进行故障切换演练,确保高可用机制有效
- 文档维护:保持配置文档的更新,便于故障排查和团队协作
通过这些技术方案的综合运用,可以构建一个稳定、高效、可扩展的Linux网络服务架构,为业务系统提供可靠的基础设施支撑。