【分布式技术专题】「LVS负载均衡」全面透析Web基础架构负载均衡LVS机制的原理分析指南

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介: 【分布式技术专题】「LVS负载均衡」全面透析Web基础架构负载均衡LVS机制的原理分析指南

LVS的介绍说明


  1. 官方站点:www.linuxvirtualserver.org;
  2. 用过LVS的童鞋,其实大家的目的性很明确,就是需要通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能,高可用的服务器群集;

  3. 并且这个集群具有良好的可靠性、可扩展性和可操作性,从而以低廉的成本实现最优的服务性能,这也是大多数中小型公司青睐的架构;




LVS的体系架构


请求传播路径

image.png



负载均衡层(Load Balancer)


  1. 处于集群最前端,一台或多台构成负载调度,俗称负载调度器(Director Server);


  1. 分发请求给服务器集群组层的应用服务器(Real Server);


  1. 监控应用服务器健康状况,动态从LVS路由表中剔除、添加;


  1. 也可以兼职Real Server的身份;



负载均衡的作用


  • 负载均衡设备的任务就是作为应用服务器流量的入口,挑选最合适的一台服务器,将客户端的请求转发给它处理,实现客户端到真实服务端的透明转发


  • 云计算以及分布式架构,本质上也是将后端服务器作为计算资源、存储资源,由某台管理服务器封装成一个服务对外提供,客户端不需要关心真正提供服务的是哪台机器,在它看来,就好像它面对的是一台拥有近乎无限能力的服务器,而本质上,真正提供服务的,是后端的集群支撑的计算能力。




典型的互联网应用的拓扑结构


image.png

负载均衡的类型


  • 负载均衡可以采用硬件设备,也可以采用软件负载。商用硬件负载设备成本通常较高(一台几十万上百万很正常)一般有F5和A10硬件负载均衡


  • 所以在条件允许的情冴下我们会采用软负载,软负载解决的两个核心问题是:选谁、转发,其中最著名的是 LVS(Linux Virtual Server)、Nginx、HAproxy等



软负载均衡(LVS)


LVS 是四层负载均衡,是我们国家著名技术专家:章文嵩博士研发的,也就是说建立在 OSI 模型的第四层——传输层之上,传输层上有我们熟悉的TCP/UDPLVS支持TCP/UDP的负载均衡。


LVS的转发主要通过修改IP地址(NAT模式,分为源地址修改SNAT和目标地址修改DNAT)、修改目标MAC(DR 模式)来实现。



LVS是在第四层做负载均衡


  • 首先,LVS不像HAProxy等七层软负载面向的是HTTP包,所以七层负载可以做的URL解析等工作,LVS无法完成。


  • 其次,用户访问是与服务端建立连接后交换数据包实现的,如果在第三层网络层做负载均衡,那么将失去「连接」的语义


  • 软负载面向的对象应该是一个已经建立连接的用户,而不是一个孤零零的 IP 包后面会看到,实际上 LVS 的机器代替真实的服务器的用户通过TCP三次握手建立了连接所以 LVS 是需要关心「连接」级别的状态的




服务器群组层(Server Arrary)


  1. 一台或多台实际运行的应用服务器构成;


  1. 每个Real Server关联时通过有效网络互连;



共享存储层(Shared Storage)


提供共享存储空间和内容一致性的存储区域;例如:数据库、OSS存储、FS文件服务器等。





LVS相关术语


  • DS:Director Server。指的是前端负载均衡器节点。


  • RS:Real Server。后端真实的工作服务器。


  • VIP:向外部直接面向用户请求,作为用户请求的目标的IP地址。


  • DIP:Director Server IP,主要用于和内部主机通讯的IP地址。


  • RIP:Real Server IP,后端服务器的IP地址。


  • CIP:Client IP,访问客户端的IP地址。



LVS 的工作模式主要有 4 种:


  • DR
  • NAT
  • TUNNEL
  • Full-NAT
  • TUN


返里挑选常用的 DR、NAT、Full-NAT、TUN 来简单介绍一下。



DR(Dynamic Route 动态路由)


通过为请求报文重新封装一个MAC首部进行转发,源MAC是DIP所在的接口的MAC,目标MAC是某挑选出的RS的RIP所在接口的MAC地址;源IP/PORT,以及目标IP/PORT均保持不变;

image.png

请求由LVS接受,由真实提供服务的服务器(RealServer, RS)直接返回给用户,返回的时 候不经过 LVS。



流程分析


DR 模式下需要LVS和绑定同一个 VIP(RS 通过将 VIP绑定在 loopback 实现),此时报文的源IP为CIP,目标IP为VIP;


源地址 目的地址
CIP VIP

源MAC地址 目的MAC地址
CIP-MAC VIP-MAC



  1. 当用户请求到达DS后,LVS只需要将网络帧的MAC地址修改为某一台RS的 MAC,该包就会被转发到相应的RS处理,注意此时的源IP和目标IP都没变,LVS 只是做了一下移花接木

IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址, 此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址;



源地址 目的地址
CIP VIP

源MAC地址 目的MAC地址
DIP-MAC RIP-MAC


  1. 由于DS和RS在同一个网络中,所以是通过二层来传输。目标MAC地址为RIP的MAC地址,那么此时数据包将会发至RS。


  1. RS 收到 LVS 转发来的包,链路层发现 MAC 是自己的,到上面的网络层,发现 IP 也是自己的,于是返个包被合法地接受,RS 感知不到前面有 LVS 的存在。处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出,此时的源IP地址为VIP,目标IP为CIP;


源地址 目的地址
VIP CIP
  1. 响应报文最终送达至客户端,而当 RS 返回响应时,只要直接向源 IP(即用户的 IP)返回即可,不再经过 LVS。DR 模式是性能最好的一种模式


这种模式下,有几个要点:


主要是这种模式在于,通过LVS只是在请求阶段做转发,而且修改的也不是IP地址,而是MAC地址,针对于修改后的MAC地址会自动转发到对应网段内MAC主机的服务器上面,之后因为IP都没有改变,之后实际RS可以直接发送给目标client服务器,这种性能最好,但是对网络层面要求比较高,对网络扩展角度而言控制力度略低。


NAT(Network Address Translation 网络地址准换)


  • NAT是一种外网和内网地址映射的技术


  • NAT模式下,网络报的进出都要经过LVS的处理




原理


多目标IP的DNAT,通过将请求报文中的目标地址和目标端口修改为选出来的RS的RIP和PORT实现转发。

image.png

流程分析


  1. LVS需要作为RS的网关,当包到达LVS 时LVS 做目标地址转换(DNAT)。此时报文的源IP为CIP,目标IP为VIP;
源地址 目的地址
CIP VIP
  1. IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP, 此时报文的源IP为CIP,目标IP为RIP;RS接收到包以后,仿佛是客户端直接发给它的一样。
源地址 目的地址
CIP RIP
  1. RS比对发现目标为自己的IP,将请求处理完,返回响应时,此时报文的源IP为RIP,目标IP为CIP;
源地址 目的地址
RIP CIP
  1. 返回时RS的包通过网关(LVS)中转,LVS 会做源地址转换(SNAT),将包的源地址改为VIP,这样,这个包对客户端看起来就仿佛是LVS直接返回给它的。此时会将源IP地址修改为自己的VIP地址,然后响应给客户端,此时报文的源IP为VIP,目标IP为CIP;


客户端无法感知到后端RS 的存在


源地址 目的地址
VIP CIP
要点


客户端是不知道真是RS地址的,但是RS服务器却是可以知道ClientIP的(因为数据包中会包含了ClientIP),但是由于中介LVS的原因,使得发送的时候发给VIP(LVS),返回的时候,由LVS把源地址修改为VIP,所以对于客户端不能来讲是不知道目标地址的RS的存在。这就是反向代理的概念,客户端是不知道真正服务器的存在,知道的只有门面VIP的存在


特性


  1. 要求DS具备双网卡,VIP应对公网,而DIP必须和RIP在同一个网段内;


  1. RIP、DIP应该使用私网地址,同在一个网段中,且RS的网关要指向DIP;


  1. 请求和响应报文都要经由DS转发,极高负载中,DS可能会成为系统瓶颈;


  1. RS可以使用任意OS;

TUN


在原有的IP报文外再次封装多一层IP首部,内部IP首部(源地址为CIP,目标IIP为VIP),外层IP首部(源地址为DIP,目标IP为RIP)。


流程分析


  1. 当用户请求到达DS后,此时请求的数据报文会先到内核空间的PREROUTING链,此时报文的源IP为CIP,目标IP为VIP;
源地址 目的地址
CIP VIP
  1. PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链;


  1. IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP;


IP首部源地址 IP首部目的地址 源地址 目的地址
DIP RIP CIP VIP
  1. POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输),此时源IP为DIP,目标IP为RIP;


  1. RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的tun0接口VIP,那么此时RS开始处理此请求,处理完成之后,通过tun0接口送出去向外传递,此时的源IP地址为VIP,目标IP为CIP;
源地址 目的地址
VIP CIP
  1. 响应报文最终送达至客户端;




特性


1、DIP、VIP、RIP都应该是公网地址; 2、RS的网关不能,也不可能指向DIP; 3、RS必须支持IP隧道;


Full-NAT


无论是 DR 还是 NAT 模式,不可避免的都有一个问题:LVS 和 RS 必须在同一个 VLAN 下, 否则 LVS 无法作为 RS 的网关


这引发的两个问题是:


  1. 同一个VLAN的限制导致运维不方便,跨VLAN的RS无法接入


  1. LVS的水平扩展受到制约。当RS水平扩容时,总有一天其上的单点LVS会成为瓶颈


Full-NAT 由此而生,解决的是 LVS 和 RS 跨 VLAN 的问题,而跨 VLAN 问题解决后,LVS 和 RS 不再存在 VLAN 上的从属关系,可以做到多个 LVS 对应多个 RS,解决水平扩容的问 题。


Full-NAT 相比 NAT 的主要改迕是,在 SNAT/DNAT 的基础上,加上另一种转换,转换过 程如下:

image.png

  • 在包从 LVS 转到 RS 的过程中,源地址从客户端 IP 被替换成了 LVS 的内网 IP。


  • 内网IP之间可以通过多个交换机跨VLAN通信


  • 当RS处理完接受到的包,返回时,会将返个包返回给LVS的内网IP,返一步也不受限于VLAN。
  • LVS 收到包后,在 NAT 模式修改源地址的基础上,再把RS发来的包中的目标地址从LVS内网 IP 改为客户端的 IP。


Full-NAT主要的思想是把网关和其下机器的通信,改为了普通的网络通信,从而解决了跨 VLAN 的问题。采用返种方式,LVS 和 RS 的部署在 VLAN 上将不再有任何限制,大大提高了运维部署的便利性


上面其实是把内网ip和内网ip之间通过交换机进行转换捆绑,从而可以跨vlan进行服务请求代理。



Session


客户端与服务端的通信,一次请求可能包含多个TCP 包,LVS 必须保证同一连接的TCP包,必须被转发到同一台RS,否则就乱套了。为了确保返一点,LVS 内部维护着一个 Session的 Hash 表,通过客户端的某些信息可以找到应该转发到哪一台 RS 上




LVS 集群化


采用 Full-NAT 模式后,可以搭建 LVS 的集群,拓扑结构如下图:

image.png



容灾


容灾分为 RS 的容灾和 LVS 的容灾。


RS 的容灾可以通过 LVS 定期健康检测实现,如果某台 RS 失去心跳,则认为其已经下线, 不会在转发到该 RS 上。


LVS 的容灾可以通过主备+心跳的方式实现。主 LVS 失去心跳后,备 LVS 可以作为热备立 即替换。

容灾主要是靠 KeepAlived 来做的。(心跳以及下线剔除或者替换工作主要通过keepalived进行控制)




相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
28天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
21天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
141 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
27天前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
负载均衡 应用服务中间件 Linux
企业实战(13)LVS负载均衡NAT(网络地址转换)模式实战详解(一)
企业实战(13)LVS负载均衡NAT(网络地址转换)模式实战详解(一)
188 0
|
存储 负载均衡 网络协议
企业实战(13)LVS负载均衡DR(直接路由)模式实战详解(二)
企业实战(13)LVS负载均衡DR(直接路由)模式实战详解(二)
228 0
|
负载均衡 应用服务中间件 Linux
Nginx系列教程(14) - LVS+KeepAlived+Nginx实现高性能负载均衡集群
Nginx系列教程(14) - LVS+KeepAlived+Nginx实现高性能负载均衡集群
1413 0
|
11天前
|
负载均衡 算法 Linux
LVS+Keepalived:实现高效软负载均衡的利器
本文介绍了如何使用LVS(Linux Virtual Server)和Keepalived搭建高可用负载均衡集群。LVS通过不同调度算法将请求转发给后端服务器,而Keepalived基于VRRP协议实现服务高可用,避免IP单点故障。具体步骤包括环境准备、安装配置ipvsadm和Keepalived、启动服务及测试。文中还详细解释了配置文件中的关键参数,并提供了故障转移测试方法。最后,文章简要对比了软件、硬件和云负载均衡方案的特点,帮助读者选择合适的负载均衡策略。
112 4
|
4月前
|
运维 负载均衡 网络协议
LVS+Keepalived 负载均衡
LVS+Keepalived 负载均衡
105 8
LVS+Keepalived 负载均衡
|
4月前
|
域名解析 运维 负载均衡
LVS+Keepalived 负载均衡(二)28-1
【8月更文挑战第28天】LVS+Keepalived 负载均衡 配置 LVS VIP
79 5
|
8月前
|
负载均衡 网络协议 算法
LVS 负载均衡部署的三种模式 与搭建dr模式具体步骤
LVS 负载均衡部署的三种模式 与搭建dr模式具体步骤

热门文章

最新文章