当前位置: 移动技术网 > 网络运营>服务器>Linux > 深入理解Linux负载均衡LVS

深入理解Linux负载均衡LVS

2021年06月25日 Linux 我要评论
一、lvs负载均衡负载均衡集群是load balance 集群的缩写,翻译成中文就是负载均衡集群。常用的负载均衡开源软件有nginx、lvs、haproxy,商业的硬件负载均衡设备有f5、netsca

一、lvs负载均衡

负载均衡集群是load balance 集群的缩写,翻译成中文就是负载均衡集群。常用的负载均衡开源软件有nginx、lvs、haproxy,商业的硬件负载均衡设备有f5、netscale等。

二、负载均衡lvs基本介绍

lb集群的架构和原理很简单,就是当用户的请求过来时,会直接分发到director server上,然后它把用户的请求根据设置好的调度算法,智能均衡的分发后端真正服务器(real server)上。为了避免不同机器上用户请求的数据不一样,需要用到了共享存储,这样保证所有用户请求的数据是一样的。

这是由章文嵩博士发起的一个开源项目,官网:现在lvs已经是 linux 内核标准的一部分。使用 lvs 可以达到的技术目标是:通过 lvs 达到的负载均衡技术和 linux 操作系统实现一个高性能高可用的 linux 服务集群,它具有良好的可靠性、可扩展性和可操作性。从而以廉价的成本实现最优的性能。 

lvs集群采用ip负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服 务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。

三、lvs的体系架构

负载均衡的原理很简单,就是当客户端发起请求时,请求直接发给director server(调度器),这时会根据设定的调度算法,将请求按照算法的规定智能的分发到真正的后台服务器。以达到将压力均摊。但是我们知道,http的连接时无状态的,假设这样一个场景,我登录某宝买东西,当我看上某款商品时,我将它加入购物车,但是我刷新了一下页面,这时由于负载均衡的原因,调度器又选了新的一台服务器为我提供服务,我刚才的购物车内容全都不见了,这样就会有十分差的用户体验。所以就还需要一个存储共享,这样就保证了用户请求的数据是一样的。所以lvs负载均衡分为三层架构(也就是lvs负载均衡主要组成部分):

如图:

lvs的各个层次的详细介绍:

3.1、load balancer层

位于整个集群系统的最前端,有一台或者多台负载调度器(director server)组成,lvs模块就是安装在director server上,而director的主要作用类似于一个路由器,它含有完成lvs功能所设定的路由表,通过这些路由表把用户的请求分发给server array层的应用服务器(real server)上。同时,在director server上还要安装队real server服务的监控模块ldirectord,此模块用于检测各个real server服务的健康状况。在real server不可用时把它从 lvs 路由表中剔除,恢复时重新加入。

3.2、server arrary层

由一组实际运行应用服务的机器组成,real server可以是web 服务器、mall服务器、ftp服务器、dns服务器、等等,每个real server 之间通过高速的lan或分布在各地的wan相连接,在实际的应用中,director server也可以同时兼任real server的角色。

3.3、shared storage层

是为所有real server提供共享存储空间和内容一致性的存储区域,在物理上,一般有磁盘阵列设备组成,为了提供内容的一致性,一般可以通过nfs网络文件系统共享数据,但是nfs在繁忙的业务系统中,性能并不是很好,此时可以采用集群文件系统,列如red hat的gfs文件系统等等。一个公司得有一个后台账目吧,这才能协调。不然客户把钱付给了a,而换b接待客户,因为没有相同的账目。b说客户没付钱,那这样就不是客户体验度的问题了。

四、lvs的实现原理

(1)当用户负载均衡调度器(director server)发起请求,调度器将请求发往至内核空间

(2)prerouting 链首先会接受到用户请求,判断目标ip确实是本地ip,将数据包发往 input 链

(3)ipvs 是工作在 input 链上的,当用户请求到达input时,ipvs 会将用户请求和自己定义好的集群服务进行比对,如果用户请求的就是集群服务,那么此时 ipvs 会强行修改数据包里的目标ip地址和端口,并将新的数据包发往 postrouting 链

(4)postrouting 链将收到数据包后发现目标ip地址刚好是自己的后端服务器,那么此时通过选路,将数据包最终发送给后端的服务器

五、lvs的工作原理

lvs 的工作模式分为4中分别是 nat,dr,tun,full-nat。其中做个比较,由于工作原理的关系的,nat的配置最为简单,但是nat对调度器的压力太大了,导致其效率最低,dr和tun的工作原理差不多,但是dr中,所有主机必须处于同一个物理环境中,而在tun中,所有主机可以分布在不同的位置,服务器一个在纽约,一个在深圳。最多应用的是full-nat。

六、lvs相关术语

(1)ds:director server  指的是前端负载均衡器节点。

(2)rs:real server  后端真实的工作服务器。

(3)vip:向外部直接面向用户请求,作为用户请求的目标的ip地址。

(4)dip:director server ip  主要用于和内部服务器通讯的ip地址。

(5)rip:real server ip  后端服务器的ip地址。

(6)cip:client ip    访问客户端的ip地址。

七、nat 模式-网络地址转换

这个是通过网络地址转换的方法来实现调度的。首先调度器(lb)接收到客户的请求数据包时(请求的目的ip为vip),根据调度算法决定将请求发送给哪个后端的真实服务器(rs)。然后调度就把客户端发送的请求数据包的目标ip地址及端口改成后端真实服务器的ip地址(rip),这样真实服务器(rs)就能够接收到客户的请求数据包了。真实服务器响应完请求后,查看默认路由(nat模式下我们需要把rs的默认路由设置为lb服务器。)把响应后的数据包发送给lb,lb再接收到响应包后,把包的源地址改成虚拟地址(vip)然后发送回给客户端。

vs/nat是一种最简单的方式,所有的realserver只需要将自己的网关指向director即可。客户端可以是任意操作系统,但此方式下,一个director能够带动的realserver比较有限。在vs/nat的方式下,director也可以兼为一台realserver。vs/nat的体系结构如图所示。

八、nat 模式工作原理

(1)当用户请求到达director server,此时的请求数据报文会先到内核空间的prerouting链。此时报文的源ip为 cip,目标ip为 vip。

(2)prerouting检查发现数据包的目标ip 是本机,将数据包发送至input链。

(3)ipvs比对数据包请求的服务是否为集群服务,若是,修改数据包的目标ip地址为后端服务器ip,然后将数据包发送至postrouting链。此时报文的源ip为 cip,目标ip为rip。

(4)postrouting链通过选路,将数据包发送给real server。

(5)real server对比发现目标为自己的ip,开始构建响应报文发回给director server。此时报文的源ip为 rip,目标ip为 cip。

(6)director server在响应客户端前,此时会将源ip地址修改为自己的vip地址,然后响应给客户端。此时报文的源ip为 vip,目标ip为cip。

九、dr 模式-直接路由模式

dr模式也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与vs/nat和vs/tun中的一样,但它的报文转发方法又有不同,vs/dr通过改写请求报文的mac地址,将请求发送到real server,而real server将响应直接返回给客户,免去了vs/tun中的ip隧道开销。这种方式是三种负载调度机制中性能最高最好的,但是必须要求director server与real server都有一块网卡连在同一物理网段上。

director和realserver必需在物理上有一个网卡通过不间断的局域网相连。 realserver上绑定的vip配置在各自non-arp的网络设备上(如lo或tunl),director的vip地址对外可见,而realserver的vip对外是不可见的。realserver的地址即可以是内部地址,也可以是真实地址。

dr模式是通过改写请求报文的目标mac地址,将请求发给真实服务器的,而真实服务器响应后的处理结果直接返回给客户端用户。同tun模式一样,dr模式可以极大的提高集群系统的伸缩性。而且dr模式没有ip隧道的开销,对集群中的真实服务器也没有必要必须支持ip隧道协议的要求。但是要求调度器lb与真实服务器rs都有一块网卡连接到同一物理网段上,必须在同一个局域网环境。

9.1、dr 模式工作原理图

(1)首先用户用cip请求vip。

(2)根据上图可以看到,不管是director server 还是real server 上都需要配置相同的vip,那么当用户请求到达我们的集群网络的前端路由器的时候,请求数据包的源地址为cip,目标地址为vip;此时路由器还会发广播问谁是vip,那么我们集群中所有的节点都配置有vip,此时谁先响应路由器那么路由器就会将用户请求发给谁,这样一来我们的集群系统是不是没有意义了,那我们可以在网关路由器上配置静态路由指定vip就是director server,或者使用一种机制不让real server 接受来自网络中的arp 地址解析请求,这样一来用户的请求包都会经过director server。

(3)当用户请求到达director server,此时请求的数据报文会先到内核空间的prerouting链,此时报文的源ip为cip,目标ip为vip。

(4)prerouting检查发现数据包的目标ip为本机,将数据包发送至input链。

(5)ipvs对比数据包请求的服务是否为集群服务,若是,将请求报文中的源mac地址修改dip的mac地址,将目标mac地址修改为rip的mac地址,然后将数据包发至postrouting链,此时的源ip和目标ip均未修改,仅修改了源mac地址为dip的mac地址,目标mac地址为rip的mac地址。

(6)由于ds和rs在同一个网络中,所以是通过二层来传输,postrouting链检查目标mac地址为rip的mac地址,那么此时数据包将会发至real server。

(7)rs发现请求报文的mac地址是自己的mac地址,就接收报文。处理完成之后,将相应报文通过lo接口传送给eth0网卡然后向外发出。此时的源ip地址为vip,目标ip为cip。

(8)响应报文最终送达至客户端。

配置dr的三种方式:

  • 第一种:在路由器上明显说明vip对应的地址一定是director上的mac,只要绑定,以后再跟vip通信也不用再请求了,这个绑定是静态的,所以它也不会失效,也不会再次发起请求,但是有个前提,我们的路由设备必须有操作权限才能够绑定mac地址,万一这个路由器是运营商操作的,我们没法操作怎么办?第一种方式固然很简单,但未必可行。
  • 第二种:在个别主机上(列如:红帽)它们引进的有一种程序arptables,它有点类似iptables,它肯定是基于arp或者mac做访问控制的,很显然我们只需要在每一个real server上定义arptables规则,如果用户arp广播请求的目标地址是本机的vip则不予响应,或者说响应的报文不让出去,很显然(gateway)是接收不到的,也就是director响应的报文才能到达gateway,这个也行。第二种方式我们可以基于arptables。
  • 第三种:在相对较新的版本中新增了两个内核参数(kernelparameter),第一个是arp_ignore定义接受到arp请求时的响应级别;第二个是arp_announce定义将自己地址向外通告时的通告级别。[提示:很显然我们现在的系统一般在内核中都是支持这些参数的,我们用参数的方式进行调整更具有朴实性,它还不依赖额外的条件,像arptables,也不依赖外在路由配置的设置,反而通常我们使用的是第三种配置方式

arp_ignore:定义接收到arp请求时的响应级别

0:只要本地设置的有相应的地址,就给予响应。(默认)

1:仅回应目标ip地址是本地的入网地址的arp请求。

2:仅回应目标ip地址是本地的入网地址,而且源ip和目标ip在同一个子网的arp请求。

3:不回应网络界面的arp请求,而只对设置的唯一和连接地址做出回应。

4-7:保留未使用。

8:不回应所有的arp请求。

arp_announce:定义将自己地址向外通告的通告级别:

0:将本地任何接口上的任何地址向外通告。

1:视图仅向目标网络通告与其网络匹配的地址。

2:仅向与本地接口上地址匹配的网络进行通告。

9.2、dr模式的特性

  • 保证前端路由将目标地址为vip报文统统发给director server,而不是rs。
  • director和rs的vip为同一个vip。
  • rs可以使用私有地址,也可以是公网地址,如果使用公网地址,此时可以通过互联网对rip进行直接访问。
  • rs跟director server必须在同一个物理网络中。
  • 所有的请求报文经由director server,但响应报文必须不能经过director server。
  • 不支持地址转换,也不支持端口转换。
  • rs 可以是大多数常见的操作系统。
  • rs 的网关绝不允许指向dip(因为我们不允许它经过director)
  • rs上的lo接口配置vip的ip地址
  • dr模式是市面上用得最广的。
  • 缺陷:rs和ds必须在同一机房。

十、tunnel 模式

10.1、tunnel 模式工作原理

(1)当用户请求到达director server,此时请求的数据报文会先拿到内核空间的prerouting链,此时报文的源ip为cip,目标ip为vip。

(2)prerouting检查发现数据包的目标ip是本机,将数据包发送至input链。

(3)ipvs对比数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层ip报文,封装源ip为dip,目标ip为rip。然后发至postrouting链,此时源ip为dip,目标ip为rip。

(4)postrouting链根据最新封装的ip报文,将数据包发送至rs(因为在外层多封装了一层ip首部,所以可以理解为 此时通过隧道传输)。此时源ip为dip,目标ip为rip。

(5)rs接收到报文后发现是自己的ip地址,就将报文接收下来,拆除掉最外层的ip后,会发现里面还有一层ip首部,而且目标是自己的lo接口vip,那么此时rs开始处理请求,处理完成之后,通过lo接口发送给eth0网卡,然后向外传递。此时源ip为vip,目标ip为cip。

(6)响应报文最终送达至客户端。

10.2、tunnel模式的特性

  • rip、vip、dip全是公网地址。
  • rs的网关不会也不可能指向dip。
  • 所有的请求报文经由director server,但响应报文必须不能经过director server。
  • 不支持端口映射。
  • rs的系统必须支持隧道。

十一、lvs 的调度算法

固定调度算法:rr,wrr,dh,sh

动态调度算法:wlc,lc,lblc,lblcr

固定调度算法:即调度器不会去判断后端服务器的繁忙与否,一如既往得将请求派发下去。

动态调度算法:调度器会去判断后端服务器的繁忙程度,然后依据调度算法动态得派发请求。

11.1、rr:轮询(round robin)

这种算法是最简单的,就是按依次循环的方式将请求调度到不同的服务器上,该算法最大的特点就是简单。轮询算法假设所有的服务器处理请求的能力都是一样的,调度器会将所有的请求平均分配给每个真实服务器,不管后端 rs 配置和处理能力,非常均衡地分发下去。这个调度的缺点是,不管后端服务器的繁忙程度是怎样的,调度器都会讲请求依次发下去。如果a服务器上的请求很快请求完了,而b服务器的请求一直持续着,将会导致b服务器一直很忙,而a很闲,这样便没起到均衡的左右。

11.2、wrr:加权轮询(weight round robin)

这种算法比 rr 的算法多了一个权重的概念,可以给 rs 设置权重,权重越高,那么分发的请求数越多,权重的取值范围 0 – 100。主要是对rr算法的一种优化和补充, lvs 会考虑每台服务器的性能,并给每台服务器添加要给权值,如果服务器a的权值为1,服务器b的权值为2,则调度到服务器b的请求会是服务器a的2倍。权值越高的服务器,处理的请求越多。

11.3、dh:目标地址散列调度算法 (destination hash)

简单的说,即将同一类型的请求分配给同一个后端服务器,例如将以 .jgp、.jpg等结尾的请求转发到同一个节点。这种算法其实不是为了真正意义的负载均衡,而是为了资源的分类管理。这种调度算法主要应用在使用了缓存节点的系统中,提高缓存的命中率。

11.4、sh:源地址散列调度算法(source hash)

即将来自同一个ip的请求发给后端的同一个服务器,如果后端服务器工作正常没有超负荷的话。这可以解决session共享的问题,但是这里有个问题,很多企业、社区、学校都是共用的一个ip,这将导致请求分配的不均衡。

11.5、lc:最少连接数(least-connection)

这个算法会根据后端 rs 的连接数来决定把请求分发给谁,比如 rs1 连接数比 rs2 连接数少,那么请求就优先发给 rs1。这里问题是无法做到会话保持,即session共享。

11.6、wlc:加权最少连接数(weight least-connection)

这个比最少连接数多了一个加权的概念,即在最少连接数的基础上加一个权重值,当连接数相近,权重值越大,越优先被分派请求。

11.7、lblc:基于局部性的最少连接调度算法(locality-based least-connection)

将来自同一目的地址的请求分配给同一台rs如果这台服务器尚未满负荷,否则分配给连接数最小的rs,并以它为下一次分配的首先考虑。

以上就是深入理解linux负载均衡lvs的详细内容,更多关于linux 负载均衡 lvs的资料请关注移动技术网其它相关文章!

(0)
打赏 微信扫一扫 微信扫一扫

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。

发表评论

验证码:
移动技术网