大白话图文结合剖析LVS原理

一、是什么

负载均衡调度器。那么和nginx区别是啥?

  • 首先nginx是七层的,lvs是四层的(网络七层,不是此篇重点,不多BB)
  • nginx每个请求都需要与客户端握手,且服务端返回响应后需要经过nginx转发到客户端,也就是请求和响应都需要经过nginx
  • lvs不需要和客户端握手,就是一个转发器,请求来了我就转发到后面真实服务器,LVS的DR模式,可以直接让后端真实服务器的响应打回到客户端,而不需要再次经过LVS一次。

二、那还要nginx干嘛?

首先我认为lvs和nginx是可以共存的。而不是单打独斗,当然单打独斗也没毛病,但是不存在替代互斥的关系。

lvs跟nginx一起用的场景,我是这么理解的:只有并发极其大的情况下才需要lvs, 并发太大,nginx可能压力会大(因为他每次都需要和client握手),这时候nginx前面挂一层lvs来帮nginx减轻负担,然后nginx做tomcat等容器的负载均衡。各自展现各自的优点,共同办事。

上面那段话看得懂的话就不用看下面这堆详细的解释,但个人建议看下,万一你不会呢?

nginx用来做http的反向代理,通过配置upsteam实现http请求的负载均衡异步转发。如果一个服务器请求失败,立即切换到其他服务器,直到请求成功或者最后一台服务器失败为止。简直就是集群的利器。

lvs采用的是同步请求转发的策略。

同步转发???异步转发???

同步转发是在lvs服务器接收到请求之后,立即redirect到一个后端服务器,由客户端直接和后端服务器建立连接。而不是客户端和lvs进行握手建立连接。

异步转发是nginx与客户端建立连接,保持客户端连接的同时,发起一个相同内容的新请求到后端,等后端返回结果给nginx后,再由nginx将后端返回的结果返回给客户端。

小结:nginx是所有的请求和响应流量都会经过nginx;而lvs是仅请求流量经过lvs的网络,响应流量由后端服务器的网络返回给客户端。

所以并发极大的情况下,nginx的网络带宽就成了一个巨大的瓶颈。

但是仅仅使用lvs作为负载均衡的话,一旦后端接受到请求的服务器出了问题,那么这次请求就失败了。但是如果在lvs的后端在添加一层nginx(多个),每个nginx后端再有几台应用服务器,那么结合两者的优势,既能避免单nginx的流量集中瓶颈,又能避免单lvs时一锤子买卖的问题(nginx转发失败后会找下一台服务器继续转发请求)。

三、LVS术语

  • DS:Director Server。前端负载均衡的服务器。比如LVS等。
  • RS:Real Server。后端真实的工作服务器,比如tomcat等。
  • VIP:Virtual IP。虚拟IP,是客户端请求的目标的IP地址,比如LVS集群,肯定多个IP,但是客户端只会请求其中一个固定IP,这个就是VIP。
  • DIP:Director Server IP,一般用于和后端真实的工作服务器通信的。
  • RIP:Real Server IP,后端真实的工作服务器的IP。
  • CIP:Client IP,客户端IP,通常直接和VIP交互。

CIP -> VIP -> DIP -> RIP

四、三种模型

不多BB,全在图上了。

0、补充:路由器

在这里插入图片描述

1、D-NAT

在这里插入图片描述

2、DR

解决D-NAT的请求响应都走DS,造成瓶颈问题。DR只有请求走DS,响应直接打到client,不在经过DS。
LVS DR原理等流程都在图上了。
在这里插入图片描述

3、TUN

在这里插入图片描述

4、三种模型对比

  • 是否需要VIP和realserver在同一网段

DR模式因为只修改包的MAC地址,需要通过ARP广播找到realserver,所以VIP和realserver必须在同一个网段,也就是说DR模式需要先确认这个IP是否只能挂在这个LVS下面;其他模式因为都会修改目的地址为realserver的IP地址,所以不需要在同一个网段内

  • 三种模式的性能比较

DR模式、IP TUN模式都是在包进入的时候经过LVS,在包返回的时候直接返回给client;所以二者的性能比NAT高
但TUN模式更加复杂,所以性能不如DR
性能比较:DR>TUN>NAT

五、LVS负载均衡算法

  • 轮叫调度 rr

均等地对待每一台服务器,不管服务器上的实际连接数和系统负载

  • 加权轮叫 wrr

调度器可以自动问询真实服务器的负载情况,并动态调整权值

  • 最少链接 lc

动态地将网络请求调度到已建立的连接数最少的服务器上,如果集群真实的服务器具有相近的系统性能,采用该算法可以较好的实现负载均衡

  • 加权最少链接 wlc

调度器可以自动问询真实服务器的负载情况,并动态调整权值,带权重的谁不干活就给谁分配,机器配置好的权重高

  • 基于局部性的最少连接调度算法 lblc

这个算法是请求数据包的目标 IP 地址的一种调度算法,该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器,如果这台服务器依然可用,并且有能力处理该请求,调度器会尽量选择相同的服务器,否则会继续选择其它可行的服务器

  • 复杂的基于局部性最少的连接算法 lblcr

记录的不是要给目标 IP 与一台服务器之间的连接记录,它会维护一个目标 IP 到一组服务器之间的映射关系,防止单点服务器负载过高。

  • 目标地址散列调度算法 dh

该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系,出现服务器不可用或负载过高的情况下,发往该目标 IP 的请求会固定发给该服务器。

  • 源地址散列调度算法 sh

与目标地址散列调度算法类似,但它是根据源地址散列算法进行静态分配固定的服务器资源。

  • 最少期望延迟 sed

不考虑非活动链接,谁的权重大,优先选择权重大的服务器来接收请求,但权重大的机器会比较忙

  • 永不排队 nq

无需队列,如果有realserver的连接数为0就直接分配过去

参考连接

六、个人公众号

微信公众号【Java码农社区】
在这里插入图片描述

发布了49 篇原创文章 · 获赞 44 · 访问量 2万+

猜你喜欢

转载自blog.csdn.net/ctwctw/article/details/105656616