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

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




相关实践学习
小试牛刀,一键部署电商商城
SAE 仅需一键,极速部署一个微服务电商商城,体验 Serverless 带给您的全托管体验,一起来部署吧!
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
1月前
|
存储 消息中间件 缓存
支持百万人超大群聊的Web端IM架构设计与实践
本文将回顾实现一个支持百万人超大群聊的Web端IM架构时遇到的技术挑战和解决思路,内容包括:通信方案选型、消息存储、消息有序性、消息可靠性、未读数统计。希望能带给你启发。
49 0
支持百万人超大群聊的Web端IM架构设计与实践
|
5月前
|
前端开发 JavaScript
探索现代Web应用的微前端架构
【10月更文挑战第40天】在数字时代的浪潮中,Web应用的发展日益复杂多变。微前端架构作为一种新兴的设计理念,正逐步改变着传统的单一前端开发模式。本文将深入探讨微前端的核心概念、实现原理及其在实际项目中的应用,同时通过一个简单的代码示例,揭示如何将一个庞大的前端工程拆分成小而美的模块,进而提升项目的可维护性、可扩展性和开发效率。
|
4月前
|
弹性计算 Java 关系型数据库
Web应用上云经典架构实践教学
Web应用上云经典架构实践教学
Web应用上云经典架构实践教学
|
4月前
|
弹性计算 Java 数据库
Web应用上云经典架构实战
本课程详细介绍了Web应用上云的经典架构实战,涵盖前期准备、配置ALB、创建服务器组和监听、验证ECS公网能力、环境配置(JDK、Maven、Node、Git)、下载并运行若依框架、操作第二台ECS以及验证高可用性。通过具体步骤和命令,帮助学员快速掌握云上部署的全流程。
103 1
|
5月前
|
存储 Dubbo Java
分布式 RPC 底层原理详解,看这篇就够了!
本文详解分布式RPC的底层原理与系统设计,大厂面试高频,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
分布式 RPC 底层原理详解,看这篇就够了!
|
4月前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
229 4
|
4月前
|
弹性计算 负载均衡 安全
云端问道-Web应用上云经典架构方案教学
本文介绍了企业业务上云的经典架构设计,涵盖用户业务现状及挑战、阿里云业务托管架构设计、方案选型配置及业务初期低门槛使用等内容。通过详细分析现有架构的问题,提出了高可用、安全、可扩展的解决方案,并提供了按量付费的低成本选项,帮助企业在业务初期顺利上云。
|
5月前
|
消息中间件 前端开发 JavaScript
探索微前端架构:构建现代Web应用的新策略
本文探讨了微前端架构的概念、优势及实施策略,旨在解决传统单体应用难以快速迭代和团队协作的问题。微前端允许不同团队独立开发、部署应用的各部分,提升灵活性与可维护性。文中还讨论了技术栈灵活性、独立部署、团队自治等优势,并提出了定义清晰接口、使用Web组件、状态管理和样式隔离等实施策略。
|
5月前
|
监控 前端开发 JavaScript
探索微前端架构:构建可扩展的现代Web应用
【10月更文挑战第29天】本文探讨了微前端架构的核心概念、优势及实施策略,通过将大型前端应用拆分为多个独立的微应用,提高开发效率、增强可维护性,并支持灵活的技术选型。实际案例包括Spotify和Zalando的成功应用。
|
5月前
|
前端开发 JavaScript API
探索JAMstack架构:现代Web开发的新范式
【10月更文挑战第28天】JAMstack架构是一种现代Web开发方法,以其高性能、高安全性和易于维护的特点受到开发者青睐。本文深入探讨了JAMstack的核心概念、优势、工具链及其如何改变Web开发方式,包括静态网站生成、API驱动和预渲染等关键技术。

热门文章

最新文章