LVS+keepalived配置高可用架构和负载均衡机制(2)

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介: LVS+keepalived配置高可用架构和负载均衡机制(2)

一、概述

接上文,实际生产场景中,往往存在硬件资源数量的限制,此时需要设置DS节点复用RS节点。
所以往往最常见的架构如下图所示:
1) 3台主机组建真实服务器集群,即3个RS
2) 2个RS兼做DS,构建负载均衡机制

                     Client
                        │
                        │VIP:17.7.7.18
       ┌────────────────┼────────────────┐
┌──────┴───────┐ ┌──────┴───────┐ ┌──────┴───────┐
│  RS1/DS1     │ │  RS2/DS2     │ │  RS3         │
│7.7.7.11      │ │7.7.7.12      │ │7.7.7.13      │
└──────────────┘ └──────────────┘ └──────────────┘

配置与非复用相同的情况下:在 docker 环境测试通过,但在生产环境中存在 LVS 转发混乱的情况!

二、DS/RS复用流量死循环:症状描述

如果 LVS 主备都是 localnode(即DS/RS复用),并且 backup 的 LVS rules 已经启用(比如 keepalived),那么就会出现下面的情况:
client 发 SYN 包给 master DS
50% 机会 master DS 把包转给 backup DS(因为 backup DS 也是 RS)
因为 backup 的 LVS rules 已经启用,所以50%机会 backup 把包转给 master
master 收到包后,又把包转给 backup,然后陷入死循环。

三、DS/RS复用流量死循环:解决思路

iptables的mangle表可以对目标数据包加上mark标记,用于实现策略路由控制数据包的流向。我们在规则中指定对端LVS节点的mac地址,如果不是对端mac地址的请求,说明是来自客户端的请求,需要打上mark标记;如果是来自对端mac地址的请求,则说明是主机转发的请求,就不打标记。而刚好LVS也支持通过fwmark配置虚拟服务,替代场景的VIP:PORT方式,只对打了fwmark标记的数据包进行转发。二者结合起来即可实现只针对客户端过来的请求进行转发,乒乓问题迎刃而解!
一次完整的客户端请求处理流程如下:
首先客户端的请求到达LVS主机,先由主机上的iptables对请求数据包打上一个mark值为1的标记(mark值可为任意正整数),然后LVS上配置了fwmark为1的虚拟服务,这样被打上mark的数据包就可以正常被主机的LVS捕获,进入虚拟服务转发;如果请求被转发给了备机,因为是来自主机mac地址的请求,所以备机不会打mark,也就不会进入备机的虚拟服务转发,而是直接由备机的RS服务处理。
其他描述参考:
经过 DS1 的包,如果 mac address 不是 DS2 的,用 iptables 给包打 mark=i
经过 DS2 的包,如果 mac address 不是 DS1 的,用 iptables 给包打 mark=j
在 keepalived 配置 LVS 时使用 fwmark-service 来表示 virtual_server,不用三元组(ip,port,protocol)的方式
这样,如果是 DS 转发过来的包,就不会进入 LVS 进行负载(防止两个 DS 互相扔皮球,进入死循环),而是被 RS 服务处理。而客户端进来的包,就会进入 LVS 进行负载。

四、DS/RS复用流量死循环:解决方法

#VIP=192.168.10.55
VIP=10.128.190.248
VPORT=80
#MAC_Director1=00:0c:29:0c:a9:ca
#MAC_Director2=00:0c:29:24:ce:e7
MAC_Director1=34:73:79:20:ca:73
MAC_Director2=34:73:79:20:cb:83

# DS1 配置 iptables ,除了 DS2 以外的包,都设置 mark 为 3
iptables -t mangle -I PREROUTING -d $VIP -p tcp -m tcp --dport $VPORT -m mac \
! --mac-source $MAC_Director2 -j MARK --set-mark 0x3

# DS2 配置 iptables ,除了 DS1 以外的包,都设置 mark 为 4
iptables -t mangle -I PREROUTING -d $VIP -p tcp -m tcp --dport $VPORT -m mac \
! --mac-source $MAC_Director1 -j MARK --set-mark 0x4

# 查看表 mangle:(默认 iptables 查看的是 filter 表)
iptables -t mangle -L -n
firewall-cmd --info-ipset=lvs_mark_list

# DS1 配置 keepalived
virtual_server fwmark 3 {
...
}

# DS2 配置 keepalived
virtual_server fwmark 4 {
...
}

五、以上配置后,包处理流程就变成如下

client 请求,master DS 收到包后,打了 mark 为 3。
LVS 看到 mark=3 的请求,50% 自己的 RS 处理,50% 转发到 backup DS。
backup 收到包后,发现是 master 过来的,不设置 mark。所以这个包不会被 LVS 处理,而被 backup 上面的服务给处理了。
Redhat 7 之前用的是 Piranha 做 LVS 的 HA,7版本后用 Keepalived。Piranha 是不会启用 backup 的 rules的,所以不存在这个问题。

【注意事项】

防止系统重启导致 iptables 规则失效!

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
9天前
|
运维 负载均衡 网络协议
LVS+Keepalived 负载均衡
LVS+Keepalived 负载均衡
32 1
LVS+Keepalived 负载均衡
|
6天前
|
域名解析 运维 负载均衡
LVS+Keepalived 负载均衡(二)28-1
【8月更文挑战第28天】LVS+Keepalived 负载均衡 配置 LVS VIP
21 5
|
22天前
|
存储 搜索推荐 数据库
MarkLogic在微服务架构中的应用:提供服务间通信和数据共享的机制
随着微服务架构的发展,服务间通信和数据共享成为关键挑战。本文介绍MarkLogic数据库在微服务架构中的应用,阐述其多模型支持、索引搜索、事务处理及高可用性等优势,以及如何利用MarkLogic实现数据共享、服务间通信、事件驱动架构和数据分析,提升系统的可伸缩性和可靠性。
22 5
|
18天前
|
存储 安全 算法
探索操作系统的心脏:内核架构与机制的深度剖析
本文旨在深入探讨操作系统的核心——内核,揭示其架构设计与运行机制的内在奥秘。通过对进程管理、内存管理、文件系统、设备控制及网络通信等关键组件的细致分析,展现内核如何高效协调计算机硬件与软件资源,确保系统稳定运行与性能优化。文章融合技术深度与通俗易懂的表述方式,旨在为读者构建一幅清晰、立体的内核运作全景图。
39 0
|
2月前
|
消息中间件 负载均衡 Java
揭秘Kafka背后的秘密!Kafka 架构设计大曝光:深入剖析Kafka机制,带你一探究竟!
【8月更文挑战第24天】Apache Kafka是一款专为实时数据处理及流传输设计的高效率消息系统。其核心特性包括高吞吐量、低延迟及出色的可扩展性。Kafka采用分布式日志模型,支持数据分区与副本,确保数据可靠性和持久性。系统由Producer(消息生产者)、Consumer(消息消费者)及Broker(消息服务器)组成。Kafka支持消费者组,实现数据并行处理,提升整体性能。通过内置的故障恢复机制,即使部分节点失效,系统仍能保持稳定运行。提供的Java示例代码展示了如何使用Kafka进行消息的生产和消费,并演示了故障转移处理过程。
40 3
|
2月前
|
数据采集 存储 Java
Flume Agent 的内部原理分析:深入探讨 Flume 的架构与实现机制
【8月更文挑战第24天】Apache Flume是一款专为大规模日志数据的收集、聚合及传输而设计的分布式、可靠且高可用系统。本文深入解析Flume Agent的核心机制并提供实际配置与使用示例。Flume Agent由三大组件构成:Source(数据源)、Channel(数据缓存)与Sink(数据目的地)。工作流程包括数据采集、暂存及传输。通过示例配置文件和Java代码片段展示了如何设置这些组件以实现日志数据的有效管理。Flume的强大功能与灵活性使其成为大数据处理及实时数据分析领域的优选工具。
63 1
|
2月前
|
监控 Linux 应用服务中间件
在Linux中,如何配置负载均衡器?
在Linux中,如何配置负载均衡器?
|
2月前
|
负载均衡 应用服务中间件 Linux
在Linux中,如何配置负载均衡器?
在Linux中,如何配置负载均衡器?
|
2月前
|
存储 缓存 关系型数据库
Django后端架构开发:缓存机制,接口缓存、文件缓存、数据库缓存与Memcached缓存
Django后端架构开发:缓存机制,接口缓存、文件缓存、数据库缓存与Memcached缓存
36 0
|
2月前
|
缓存 负载均衡 算法
在Linux中, LVS负载均衡有哪些策略?
在Linux中, LVS负载均衡有哪些策略?
下一篇
无影云桌面