LVS虚拟服务器介绍及负载均衡系统配置

一、简介

        LVS(Linux Virtual Server) 是Unix-like系统中的一个虚拟服务器,LVS在Unix-like系统中是作为一个前端(Director)存在的,又称为调度器,它本身不提供任何的服务,只是将通过互联网进来的请求接受后再转发给后台运行的真正的服务器(RealServer)进行处理,然后响应给客户端。LVS有两个重要的组件:一个是IPVS,一个是IPVSADM。ipvs是LVS的核心组件,它本身只是一个框架,类似于iptables,工作于内核空间中。ipvsadm 是用来定义LVS的转发规则的,工作于用户空间中。

二、IPVS的四种转发模式

        根据负载均衡器转发客户端请求以及RS返回响应机制的不同,将IPVS的转发模式分为四种:NAT,DR,FULLNAT, TUNNEL

1、DR模式(Direct Routing)

        DR模式下,客户端的请求包到达负载均衡器的虚拟服务IP端口后,负载均衡器不会改写请求包的IP和端口,但是会改写请求包的MAC地址为后端RS的MAC地址,然后将数据包转发;真实服务器处理请求后,响应包直接回给客户端,不再经过负载均衡器。所以DR模式的转发效率是最高的,特别适合下行流量较大的业务场景,比如请求视频等大文件。

DR模式的特点:

        数据包在LB转发过程中,源/目的IP端口都不会变化

        LB只是将数据包的MAC地址改写为RS的MAC地址,然后转发给相应的RS。每台RS上都必须在环回网卡上绑定LB的虚拟服务IP因为LB转发时并不会改写数据包的目的IP,所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包,而不是丢弃,必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP,自己是能够处理这个数据包的。否则RS会直接丢弃该数据包!RS上的业务进程必须监听在环回网卡的虚拟服务IP上,且端口必须和LB上的虚拟服务端口一致,因为LB不会改写数据包的目的端口,所以RS服务的监听端口必须和虚拟服务端口一致,否则RS会直接拒绝该数据包。RS处理完请求后,响应直接回给客户端,不再经过LB。因为RS收到的请求数据包的源IP是客户端的IP,所以理所当然RS的响应会直接回给客户端,而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。

LB和RS须位于同一个子网,因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址,所以要能够查询到RS的MAC。而要获取到RS的MAC,则需要保证二者位于一个子网,否则LB只能获取到RS网关的MAC地址。

blob.png

2. NAT模式(Network Address Translation)

        NAT模式下,请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后,LB会对请求包做目的地址转(DNAT),将请求包的目的IP改写为RS的IP。当收到RS的响应后,LB会对响应包做源地址转换(SNAT),将响应包的源IP改写为LB的IP。

NAT模式的特点:

        LB会修改数据包的地址对于请求包,会进行DNAT;对于响应包,会进行SNAT。

        LB会透传客户端IP到RS(DR模式也会透传),虽然LB在转发过程中做了NAT转换,但是因为只是做了部分地址转发,所以RS收到的请求包里是能看到客户端IP的。需要将RS的默认网关地址配置为LB的浮动IP地址,因为RS收到的请求包源IP是客户端的IP,为了保证响应包在返回时能走到LB上面,所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然,如果客户端的IP是固定的,也可以在RS上添加明细路由指向LB的虚拟服务IP,不用改默认网关。LB和RS须位于同一个子网,并且客户端不能和LB/RS位于同一子网,因为需要将RS的默认网关配置为LB的虚拟服务IP地址,所以需要保证LB和RS位于同一子网。又因为需要保证RS的响应包能走回到LB上,则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC,响应包就直接回给客户端了,不会走网关,也就走不到LB上面了。这时候由于没有LB做SNAT,客户端收到的响应包源IP是RS的IP,而客户端的请求包目的IP是LB的虚拟服务IP,这时候客户端无法识别响应包,会直接丢弃。

效果演示,将调度器的两块网卡配置成不在同一个网段的IP地址,RS1和RS2的IP地址为同一网段

(1)设计规划图:

blob.png

(2)配置各个虚拟机的IP地址

blob.png

blob.png

blob.png

blob.png

(3)配置Director虚拟主机

blob.png

blob.png

(4)在RS1、RS2开启http服务

blob.png

blob.png

(5)指定RS1、RS2的网关

blob.png

blob.png

(6)效果监测

blob.png

3 、FULLNAT模式

        FULLNAT模式下,LB会对请求包和响应包都做SNAT+DNAT。

FULLNAT模式的特点:

        LB完全作为一个代理服务器,FULLNAT下,客户端感知不到RS,RS也感知不到客户端,它们都只能看到LB。此种模式和七层负载均衡有点相似,只不过不会去解析应用层协议,而是在TCP层将消息转发

LB和RS对于组网结构没有要求,不同于NAT和DR要求LB和RS位于一个子网,FULLNAT对于组网结构没有要求。只需要保证客户端和LB、LB和RS之间网络互通即可。

4、TUNNEL模式

TUNNEL模型的特点:

        RS服务器与前端的LB可以在不同的网络中,RIP一定不能是私有IP,前端的LB只处理客户端的请求,然后将请求转发RS,由后台的RS直接响应客户端,不再经过LB,此种模型也不支持端口映射,RS只能使用哪些支持IP隧道的操作系统。

三、IPVS支持的调度算法

        对于后端的RS集群,LB是如何决策应该把消息调度到哪个RS节点呢?这是由负载均衡调度算法决定的。IPVS常用的调度算法有:

1、轮询(Round Robin)

        LB认为集群内每台RS都是相同的,会轮流进行调度分发。从数据统计上看,RR模式是调度最均衡的。

2、加权轮询(Weighted Round Robin)

        LB会根据RS上配置的权重,将消息按权重比分发到不同的RS上。可以给性能更好的RS节点配置更高的权重,提升集群整体的性能。

3、最小连接数(Least Connections)

        LB会根据和集群内每台RS的连接数统计情况,将消息调度到连接数最少的RS节点上。在长连接业务场景下,LC算法对于系统整体负载均衡的情况较好;但是在短连接业务场景下,由于连接会迅速释放,可能会导致消息每次都调度到同一个RS节点,造成严重的负载不均衡。

4、加权最小连接数(Weighted Least Connections)

        默认调度方法

5、源地址哈希(Source  Hash)

        实现session sticky,源IP地址hash;将来自于同一个IP地址的请求始终发往第一次挑中的RS,从而实现会话绑定

6、从不排队调度方法(Never Queue)

        第一轮均匀分配,后续SED

7、基于本地的最少连接 (Locale-Based LC) 

        动态的DH算法,使用场景,根据负载状态实现正向代理

8、带复制的基于本地的最少连接 (LBLC with Replicated)

        带复制功能的LBLC,解决LBLC负载不均衡问题,从负载重的复制到负载轻的RS

9、目的地址哈希 (Destination Hash)

        第一次轮询,调度至RS,后续将发往同一个目标地址的请求始终转发至,第一次挑中的RS,典型使用场景是正向代理缓存场景中的负载均衡

猜你喜欢

转载自blog.51cto.com/13869554/2316213