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

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月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进行控制)




相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
相关文章
|
5月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
在数字化转型中,企业亟需从海量数据中快速提取价值并转化为业务增长动力。5月15日19:00-21:00,阿里云三位技术专家将讲解Kafka与Flink的强强联合方案,帮助企业零门槛构建分布式实时分析平台。此组合广泛应用于实时风控、用户行为追踪等场景,具备高吞吐、弹性扩缩容及亚秒级响应优势。直播适合初学者、开发者和数据工程师,参与还有机会领取定制好礼!扫描海报二维码或点击链接预约直播:[https://developer.aliyun.com/live/255088](https://developer.aliyun.com/live/255088)
351 35
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
|
5月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
175 11
|
6月前
|
弹性计算 负载均衡 网络协议
阿里云SLB深度解析:从流量分发到架构优化的技术实践
本文深入探讨了阿里云负载均衡服务(SLB)的核心技术与应用场景,从流量分配到架构创新全面解析其价值。SLB不仅是简单的流量分发工具,更是支撑高并发、保障系统稳定性的智能中枢。文章涵盖四层与七层负载均衡原理、弹性伸缩引擎、智能DNS解析等核心技术,并结合电商大促、微服务灰度发布等实战场景提供实施指南。同时,针对性能调优与安全防护,分享连接复用优化、DDoS防御及零信任架构集成的实践经验,助力企业构建面向未来的弹性架构。
494 76
|
5月前
|
负载均衡 前端开发 JavaScript
LVS-DR模式、keepalived、Nginx与Tomcat合作,打造动静分离,高效负载均衡与高可用性
为了采用这样的架构,你需要对LVS-DR、Keepalived、Nginx与Tomcat有一定的理解和掌握,同时也需要投入一些时间去研究和配置,但是一旦你把它运行起来,你将会发现,这一切都是值得的。
180 11
|
12月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
408 3
|
11月前
|
机器学习/深度学习 分布式计算 算法
【大数据分析&机器学习】分布式机器学习
本文主要介绍分布式机器学习基础知识,并介绍主流的分布式机器学习框架,结合实例介绍一些机器学习算法。
1269 6
|
12月前
|
程序员
后端|一个分布式锁「失效」的案例分析
小猿最近很苦恼:明明加了分布式锁,为什么并发还是会出问题呢?
120 2
|
12月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现
消息队列系统中的确认机制在分布式系统中如何实现
|
12月前
|
消息中间件 存储 监控
【10月更文挑战第2天】消息队列系统中的确认机制在分布式系统中如何实现
【10月更文挑战第2天】消息队列系统中的确认机制在分布式系统中如何实现
138 4

热门文章

最新文章