负载均衡-LVS的工作原理

1、DR模型(Director Routing–直接路由)

LVS的DR工作模式,是目前生产环境中最常用的一种工作模式、下图反映了DR模式的整个工作过程,同样为了简单起见,这里的Real Server也只画了一个。如果是多个Real Server的话,LVS会通过调度算法来决定发往哪台Real Server。LVS-DR工作模式的几个关键点在于:

1、被Real Server处理后形成的响应报文,不再回发到LVS节点,而是直接路由给中心交换机然后发送出去。省去了LVS-NAT方式中的LVS回发过程。

2、LVS节点只会改写链路层的报文封装,对网络层和传输层报文是不进行改写的。

3、有网帖说DR工作模式,不能跨子网,也就是说LVS节点和各个Real Server节点必须处于同一个网段中。这是为什么呢?事实又真的是这样吗?很多网络帖子没有回答这个问题,这篇文章马上回答一下(实际上章文嵩先生已经回答过这个问题)。

4、使用DR模式时,需要Real Server设置LVS上的VIP为自己的一个回环IP,不然包会被丢弃。

img

工作原理:

1、中心交换机采取的IP映射的方式。但是与LVS-NAT方式不一样,Real Server在机房的中心交换机上也需要绑定一个外网映射。这样保证Real Server回发的响应报文能够被发送到外网。

2、LVS节点接收到请求报文后,会改写报文的数据链路层格式。将Target Mac改写成Real Server的Mac,但是网络层和传输层报文不会改写,然后重新回发给交换机。这里就涉及一个问题,现在target Mac和Destination IP的对应关系的错误的,这个数据报文到了交换机后,由于这种错位的关系,是不能进行三层交换的,只能进行二层交换(一旦进行IP交换,数据报文的验证就会出错,被丢弃)。所以LVS-DR方式要求Real Server和LVS节点必须在同一个局域网内,或者这样说更确切:LVS节点需要找到一个二层链路,将改写了Mac地址的报文发送给Real Server,而不能进行三层交换的校验。这样来看,实际上LVS节点和Real Server界面不一定要在同一个子网,您用一个独立网卡独立组网,传送报文也是可行的。

3、通过二层交换,数据被发送到Real Server节点。那么Real Server节点怎么来判断这个包的正确性呢?首先当然是传输层TCP/IP报文校验没有问题,LVS-NAT没有改写TCP/IP,当然校验就没有问题(除非报文本身就存在问题);然后是链路层的MAC地址能够被识别,这时就是回环IP的功劳了。对于Real Server节点来说,192.168.100.10这个VIP就是自己的回环IP,绑定的MAC也就是被LVS替换后的target mac。那么Real Server会认为这个包是在本机运行的某一个应用程序通过回环IP发给自己的,所以这个包不能被丢弃,必须处理。

4、被处理后的生成的响应报文,被直接发送给网管。只要保证Real server的默认路由设置成到核心交换机的192.168.100.1就可以了。另外,需要说明的是,由于LVS-DR模式并没有更改原有的IP报文和TCP报文,所以LVS-DR模式本身是不支持端口映射的,实际上在日常使用实践中,我们一般使用Nginx做端口映射。

DR的优点:

解决了LVS-NAT工作模式中的转发瓶颈问题,能够支撑规模更大的负载均衡场景。

比较耗费网外IP资源,机房的外网IP资源都是有限的,如果在正式生产环境中确实存在这个问题,可以采用LVS-NAT和LVS-DR混合使用的方式来缓解。

DR的缺点:

配置工作较LVS-NAT方式稍微麻烦一点,您至少需要了解LVS-DR模式的基本工作方式才能更好的指导自己进行LVS-DR模式的配置和运行过程中问题的解决。

由于LVS-DR模式的报文改写规则,导致LVS节点和Real Server节点必须在一个网段,因为二层交换是没法跨子网的。但是这个问题针对大多数系统架构方案来说,实际上并没有本质限制。

2、NAT模型(NetWork Address Translation – 网络地址转换)

NAT方式是一种由LVS Master服务节点收到数据报,然后转给下层的Real Server节点,当Real Server处理完成后回发给LVS Master节点然后又由LVS Master节点转发出去的工作方式。LVS的管理程序IPVSADMIN负责绑定转发规则,并完成IP数据报文和TCP数据报文中属性的重写。

img

工作原理:

1、在正式的机房环境中,一般有两种方式为一个机器分配外网地址:在核心交换机上直接绑定外网地址到主机网卡的,这样使用ifconfig命令看到的IP地址为外网地址;在核心交换机上使用映射规则,将一个外网地址映射到内网地址,这样使用ifconfig命令看到的IP地址为内网地址。上图中我们采用的是后一种映射规则。如果使用前一种外网IP的分配规则,也不会影响LVS NAT的工作方式,因为这个IP被限制在LVS NAT工作以外。只不过eth1的IP从192.168.100.10换成100.64.92.199而已。

2、我们用中文描述一下转换规则:凡是发送到“192.168.100.10:80”的数据报,目标地址全部改写为“192.168.220.121:8080”,所以来自于100.64.92.199:80的报文被改写了。被改写的属性包括:IP.header.destinationIP、IP.header.checksum、TCP.header.sourcePort、TCP.header.targetPort、TCP.header.checksum。注意IP报文的Source IP不会发生变化,还是“互联网某个IP”。

3、这个包最终被送到了192.168.220.121的8080端口进行处理,并由下层的Real Server生成了返回的数据报(至于这个Real Server是不是“真正的Real Server”,LVS不会关心)。你要问它是怎么被发送过去的,请参考ARP查询协议。

4、注意:因为LVS服务器和Real Server(可能有多个),组成了一个封闭的局域网。除了LVS节点以外,这个子网的任何节点都是无法访问外网的。所以要求192.168.220.121这个Real Server直接把数据报给“互联网某个IP”这个外网地址,显然是不行的,因为在局域网中根本就找不到这个IP。Real Server只能将数据报返给网关,再由网关去寻找这个外网地址。整个服务器中只有LVS节点能够找到这个外网地址,这就是为什么在LVS-NAT工作模式下,所有的Real Server节点必须设置自己的Gateway为LVS节点的原因。

5、收到来源于“192.168.220.121:8080”的数据报文后,IPVS又要进行数据报文的重写了。重写规则是:凡是来源于“192.168.220.121:8080”的数据报,源地址全部改写为“192.168.100.10:80”。于是数据报文的Source IP、Source Port被改写成“192.168.100.10:80”。在外层的核心交换机(或者是机房以外的请求方)看来,LVS接受了数据报,并进行了处理,返回了结果。它并不知道LVS节点的下层还有什么。

NAT的优点:

配置管理简单。LVS-NAT的工作方式是LVS三种工作模式中最容易理解、最容易配置、最容易管理的工作模式。

节省外网IP资源,一般机房分配给使用者的IP数量是有限的,特别是您购买的机架的数量不多时。LVS-NAT工作方式将您的系统架构封装在局域网中,只需要LVS有一个外网地址或外网地址映射就可以实现访问了。

系统架构相对封闭。在内网环境下我们对防火墙的设置要求不会很高,也相对容易进行物理服务器的运维。您可以设置来源于外网的请求需要进行防火墙过滤,而对内网请求开放访问。

另外改写后转给Real Server的数据报文,Real Server并不会关心它的真实性,只要TCP校验和IP校验都能通过,Real Server就可以进行处理。所以LVS-NAT工作模式下Real Server可以是任何操作系统,只要它支持TCP/IP协议即可。

当然作为Linux系统忠实拥护者,我并不建议使用Window服务器。但如果您的Real Server是.Net系统,又有业务场景需要用到LVS,那么LVS-NAT可能是一个不错的选择。

NAT的缺点:

转发点就是瓶颈点。您可以想象100台Real Server将处理结果全部转到一个LVS进行发送是一个怎么样的场景。事实上,LVS-NAT的极限负载是达不到100台Real Server的。

3、IP TUN模型(IP Tunneling – IP隧道)

DR模式和IP TUN模式的工作原理完全不一样,工作场景完全不一样。DR基于数据报文重写,TUN模式基于IP隧道,后者是对数据报文的重新封装。

IPIP隧道就是将一个完整的IP报文封装成另一个新的IP报文的数据部分,并通过路由器传送到指定的地点。在这个过程中路由器并不在意被封装的原始协议的内容。到达目的地点后,由目的地方依靠自己的计算能力和对IPIP隧道协议的支持,打开封装协议,取得原始协议。如下图:

img

可以说隧道协议就是为了解决跨子网传输准备的,在生产环境中由于业务需要、技术需要或者安全需要,可能使用交换机进行VLAN隔离(即形成若干个虚拟的独立的局域网),我们可能需要LVS节点在局域网A,而需要进行负载的多台Mysql读服务器可能在局域网B中。这个时候,我们就要配置LVS的隧道方式。

注意:目标节点要能够解开隧道协议,Linux支持IPIP隧道协议。

img

工作原理:

1、一旦LVS节点发现来目标为192.168.100.10VIP的请求,就会使用IPIP隧道协议对这个请求报文进行封装。而不是像LVS-DR模式重写数据报文的MAC信息。如果配置了多个Real Server,那么LVS会使用设置的调度算法确定一个Real Server。

2、重新封装后的IPIP隧道协议报文会重新被回发到路由器,路由器(或三层交换机)会根据设置的LVAN映射情况,找到目标服务器,并将这个IPIP隧道报文发送过去。

3、Real Server收到这个IPIP隧道报文后,会将这个报文进行解包。这里注意一下,一般情况下IPIP隧道报文会进行分片,就如同IP报文分片一样,只是为了讲解方便,我们假定这个报文不需要分片。解压后得到的数据报文就是原来发送给VIP的请求报文。

4、Real Server设置的回环IP,让Real Server认为原始的请求报文是从自己本地的某个应用程序发出的,完成原始报文的校验后,它会对这个报文进行处理。剩下的过程就和LVS-DR相同了,这里就不再进行复述了。

可以说LVS-TUN方式基本上具有LVS-DR的优点。在此基础上又支持跨子网间穿透。这样的敷在方案能够给我们架构师足够的系统设计场景。

4、补充:LVS调度方式

利用一致性Hash算法完成调度

目标地址Hash(DH):调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
原地址Hash(SH):根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

轮询调度

最简轮询(RR):调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。

最少连接轮询(LC):请注意“最少连接轮询”和“最少连接加权轮询”两种调度算法的区别。调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。注意请求肯定会被分配到这台目前连接数最少的Real Server上面,不会考虑几率问题

加权轮询调度:

性能加权轮询(WRR):调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

最少连接数的加权轮询(WLC):具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。注意,是按照一个比例,有较高的分配几率,而不是LC一样“肯定分配”。

推荐文章