linux运维——LVS(DR模式)

本文深入探讨了LVS的DR模式工作原理,介绍了如何通过MAC地址实现同一局域网内的负载均衡,以及如何配置后端服务器集群以确保响应报文正确返回给客户端,同时还讨论了该模式的特点和解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

原理

====LVS:负载均衡软件,可达到硬件f5效果。写入linux内核。
DR模式:
当客户发送请求,代理服务器收到之后,进行服务器集群的询问,此时服务机谁先抢占到这个包就由谁响应,但是这样就达不到负载均衡的效果。所以在策略上当代理服务器接受到包,询问谁接受包,接受到包的服务机将这个包抛弃,不响应,由代理服务机策略起分配效果,以达到轮询(在这个过程中其实都是在四层服务以内,使用的不是IP地址,而使用的是MAC地址在同一局域网内进行寻址)。但是处理之后会将已经处理过的服务包发还给客户端,由于客户访问的是VIP,那么如果服务器端没有这个VIP,发还给客户的包肯定不被信任,那么就给这个服务器集群都加VIP,然后让后端服务器使用VIP将包发还给客户。
在这里插入图片描述当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP
(b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址,然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址
由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,那么此时数据包将会发至Real Server。
RS发现请求报文的MAC地址是自己的MAC地址,就接收此报文。处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP,目标IP为CIP
响应报文最终送达至客户端

LVS-DR模型的特性

特点1:保证前端路由将目标地址为VIP报文统统发给Director Server,而不是RS

RS可以使用私有地址;也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问
RS跟Director Server必须在同一个物理网络中
所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
不支持地址转换,也不支持端口映射
RS可以是大多数常见的操作系统
RS的网关绝不允许指向DIP(因为我们不允许他经过director)
RS上的lo接口配置VIP的IP地址
缺陷:RS和DS必须在同一机房中
特点1的解决方案:
在前端路由器做静态地址路由绑定,将对于VIP的地址仅路由到Director Server。
存在问题:用户未必有路由操作权限,因为有可能是运营商提供的,所以这个方法未必实用
arptables:在arp的层次上实现在ARP解析时做防火墙规则,过滤RS响应ARP请求。这是由iptables提供的
修改RS上内核参数(arp_ignore和arp_announce)将RS上的VIP配置在lo接口的别名上,并限制其不能响应对VIP地址解析请求。

以下实验在rhel7.3主机上进行,真实主机使用arptable策略解决将用户所有针对VIP的请求发送到DS 而不是RS

代理端:
[root@lucky2 ~]# yum install ipvsadm -y
在策略设置完毕之后。可以使用 ipvsadm -l 查看的
[root@lucky2 ~]# ipvsadm -A -t 172.25.35.100:80 -s rr
[root@lucky2 ~]# ipvsadm -a -t 172.25.35.100:80 -r 172.25.35.3:80 -g
[root@lucky2 ~]# ipvsadm -a -t 172.25.35.100:80 -r 172.25.35.4:80 -g
[root@lucky2 ~]# ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.25.35.100:http rr
  -> lucky3:http                  Route   1      0          0         
  -> lucky4:http                  Route   1      0          0 
[root@lucky2 ~]# ip addr add 172.25.35.100/24 dev eth0         这个的意思为加一个虚拟的vip 因为在客户访问的时候,企业是不会将自己real server的ip暴露的,所以使用vip 并且给所有的vip加上 客户端--->代理端---->后端服务器集群real server---->客户端 这样会比NAT模式更方便

加上虚拟的vip,而DR模式就是当 代理端接受的数据包通过vip ,而代理就会询问后台服务器,给其中一台服务器,而这台服务器就会传输给客户数据,但是出来的数据不是vip 的 ,显然这个的是不被信任的,所以就给服务器集群加上vip,通过 用户 ----> 代理-----> 服务器集群-----> 用户 这样的方式更加的快速。代理往后的都是在四层服务以内,使用的不是ip,而是MAC地址在统一局域网内寻址,

后端服务器:
  • 需要注意的是后端服务器集群所进行的操作都是相同的,所以在此不过多叙述,以一个为模版即可。
  • 两台服务下载httpd服务,并且分别书写index.html文件(在这里需要注意的是,我们为了实验效果明显,我们将index文件书写的不一样,但是在真正的后台服务器在负载均衡的情况下,index.htmnl文件里边的内容都是一样的)
[root@lucky3 ~]# yum install httpd -y
[root@lucky3 ~]# cd /var/www/html/
[root@lucky3 html]# vim index.html
[root@lucky3 html]# cat index.html 
lucky3
[root@lucky3 html]# systemctl start httpd
[root@lucky3 html]#  systemctl enable  httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
[root@lucky3 html]# ip addr add 172.25.35.100/24 dev eth0            这句话的就是给后端的服务器也加上vip  而其他的服务器也需要这样进行操作
用户端:

在刚开始测试的时候,会出现某一个后台服务器抢占,而就达不到轮询的目的,所以是需要进行清理的。

[kiosk@foundation35 images]$ curl 172.25.35.100
lucky4
[kiosk@foundation35 images]$ curl 172.25.35.100
lucky4
[kiosk@foundation35 images]$ curl 172.25.35.100
lucky4
[kiosk@foundation35 images]$ curl 172.25.35.100
lucky4
[kiosk@foundation35 images]$ arp -an | grep 172.25.35.100 
? (172.25.35.100) at 52:54:00:74:24:f1 [ether] on br0              这个时候可以查看这个的mac地址是台服务器在占用。

查看到有一台服务器在一直抢占响应,达不到负载均衡的目的,会导致系统崩溃。所以是要将其尽快处理

[root@foundation35 images]# arp -d 172.25.35.100 可以使用这种方式通过轮询达到负载均衡的目的,但是这种不稳定性,所以一般不推荐

使用第二种方式进行解决

  • 后端服务器集群同时操作
[root@lucky3 html]# yum install arptables -y
[root@lucky3 html]# arptables -A INPUT -d 172.25.35.100 -j DROP    后台服务器集群同时丢弃,让进来的客户端无法访问	
[root@lucky3 html]# arptables -A OUTPUT -s 172.25.35.100 -j mangle --mangle-ip-s 172.25.35.3 
# 在丢弃以后,还是需要这台服务器需要将数据传输出去的,但是后台服务器是不可能接触到用户的所以还是要代理端的vip 传输出去的。
在调试完毕可以在代理端查看策略 arptables -L 查看协议策略

检测:

[root@foundation35 images]# arp -d 172.25.35.100               可以先将之前的缓存清理,效果会更加明显
[root@foundation35 images]# curl 172.25.35.100
lucky4
[root@foundation35 images]# curl 172.25.35.100
lucky3
[root@foundation35 images]# curl 172.25.35.100
lucky4
[root@foundation35 images]# curl 172.25.35.100
lucky3
[root@foundation35 images]# curl 172.25.35.100
lucky4
<think>嗯,用户现在想了解LVS的基本概念和用途,特别是它的工作原理。之前用户问过OpenResty,现在转向了负载均衡技术,看来是在系统架构方面有学习需求。 用户提供的引用材料很专业,涵盖了LVS的架构组成、DR模式原理和实际配置案例。特别是引用[3]详细描述了DR模式下数据包的传输过程,这对理解LVS的工作机制非常关键。需要把这些技术细节用更通俗的方式解释清楚。 用户可能是个运维工程师或架构师,正在调研负载均衡方案。从提问方式看,ta更关注基础原理而非具体配置,所以回答要突出架构思想而非操作细节。不过最后生成的"相关问题"里可以包含些实践性内容,方便ta后续深入。 LVS的核心价值在于它作为操作系统内核级的负载均衡解决方案。和Nginx这类应用层代理不同,它直接在网络层转发流量,性能优势明显。这个特点需要重点强调,尤其是和用户之前问的OpenResty对比时——两者虽然都涉及流量管理,但属于不同层级的技术。 关于工作原理部分,DR模式最常用也最复杂。引用[3][4]提到的MAC地址改写过程是难点,需要用更形象的比喻说明:就像快递中转站修改包裹标签但不改变收件地址。还要解释为什么RealServer需要配置VIP在lo网卡——这是DR模式避免ARP冲突的关键设计。 架构方面,引用[2]的三层结构(LB/ServerArray/SharedStorage)是经典模型,可以结合淘宝双十一案例说明这种架构如何支撑亿级流量。调度算法虽然引用没提,但round-robin/least_connection这些基础算法应该简要带过。 最后生成的"相关问题"要覆盖不同层次:既有原理性的NAT/TUN模式对比,也有实践性的健康检查配置,还应该包含应用场景分析。用户如果来自电商或视频行业,特别补充CDN加速的案例会更有针对性。</think>### LVSLinux Virtual Server)基本概念与工作原理 LVS 是**基于 Linux 内核的高性能负载均衡器**,由章文嵩博士开发。它通过将客户端请求分发到多台真实服务器(Real Server),构建可扩展、高可用的服务器集群系统,对外表现为单一虚拟 IP(VIP)服务[^1][^2]。 --- #### **一、核心架构** LVS 集群由三层组成: 1. **负载均衡层(Loader Balancer)** - 核心组件:**LVS Director**(调度器),接收客户端请求,通过调度算法选择真实服务器。 - 关键配置:**虚拟 IP(VIP)** 对外提供服务,**真实 IP(DIP)** 与后端服务器通信[^2]。 2. **服务器群组层(Server Array)** - 多台真实服务器(Real Server, RS)处理实际业务,如 Web 服务器、数据库等。 3. **共享存储层(Shared Storage)** - 提供统一数据存储(如 NFS、分布式存储),确保所有 RS 数据一致性[^2]。 --- #### **二、工作原理(以 DR 模式为例)** **DR(Direct Routing)模式** 是 LVS 最高效的工作模式,**数据转发不经过 Director**,性能接近物理极限[^3][^5]。 ##### **请求处理流程**: 1. **客户端请求** - 客户端发送数据包: - 源 IP:`CIP`(客户端 IP) - 目的 IP:`VIP`(虚拟 IP) - 目的 MAC:`VMAC`(VIP 对应的 MAC 地址)[^3][^4]。 2. **Director 接收并转发** - LVS Director 收到请求后: - 根据调度算法(如轮询、加权最小连接)选择一台 RS。 - **改写目标 MAC 地址**:将 `VMAC` 替换为选定 RS 的 MAC 地址 `RMAC`。 - **源 MAC 地址** 改为 Director 的 DIP 对应 MAC(`DMAC`)[^3][^5]。 - **数据包不修改 IP 地址**,仅修改 MAC 层信息。 3. **真实服务器(RS)处理** - RS 收到数据包后: - 发现目的 IP 是 `VIP`(需在 RS 的 `lo` 网卡配置 VIP)。 - 处理请求并生成响应,**直接返回给客户端**(不经过 Director)。 - 响应包源 IP 为 `VIP`,目的 IP 为 `CIP`[^3][^5]。 ##### **关键点**: - **性能优势**:RS 直接响应客户端,避免 Director 成为带宽瓶颈。 - **ARP 抑制**:RS 需配置 `arp_ignore` 和 `arp_announce`,避免对外宣告 VIP 造成 ARP 冲突[^5]。 --- #### **三、LVS 的核心价值** 1. **高性能负载均衡** - 基于内核转发,吞吐量可达百万级 QPS,延迟极低。 2. **高可用性** - 结合 Keepalived 实现 Director 故障自动切换。 3. **灵活调度** - 支持 10+ 种调度算法(如 `rr` 轮询、`wlc` 加权最小连接)。 4. **透明扩展** - 动态增删 RS 节点不影响服务,客户端无感知[^1][^2]。 --- #### **四、典型应用场景** - **大型网站入口层**:如电商、社交平台的高并发访问分流。 - **金融交易系统**:保证服务高可用与低延迟。 - **视频直播/CDN**:高效分发海量流媒体请求[^1]。 --- ### 总结 LVS 通过**内核级负载均衡技术**,将多台服务器虚拟化为单一高性能服务,其 DR 模式因**直接路由**机制成为最优解。结合共享存储与健康检查,可构建企业级高可用集群[^2][^5]。 ```mermaid graph LR A[客户端] -->|请求 VIP| B(LVS Director) B -->|修改 MAC 转发| C[Real Server 1] B -->|修改 MAC 转发| D[Real Server 2] C -->|直接响应| A D -->|直接响应| A ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值