LVS三种工作模式原理个人理解

最新推荐文章于 2024-08-09 15:28:14 发布

copbint

最新推荐文章于 2024-08-09 15:28:14 发布

阅读量3.3k

点赞数

分类专栏：计算机网络

本文链接：https://blog.csdn.net/qq_31567335/article/details/79605878

版权

计算机网络专栏收录该内容

29 篇文章 0 订阅

订阅专栏

写在前面：

因为工作中的项目中用到了LVS，所以趁周末的时间好好学习一下。

找到了一些不错的讲解LVS工作原理的文章，弄懂了个大概。如：

架构设计：负载均衡层设计方案（4）——LVS原理

LVS-DR工作原理图文详解

但是有一些关键性的问题，又搜了很多文章，始终没太能弄明白，比如说LVS-DR模式改写mac地址之后，数据是如何转发到real Server的？以及realServer配置的VIP到底是否响应arp查询。

随便翻到一些讲解LVS发展背景的文章，了解到原来LVS是章文嵩博士发起的开源项目，这个项目现在在全世界范围内广泛应用，而且已经被做进了linux内核。真是厉害！！！

那么LVS肯定有官方文档吧，能不能解决我的困惑呢？一搜，就搜到了章文嵩博士写的文章。一看，果然解答了我心中的疑惑。相比于之前搜的那些介绍性的文章，章博士的文章本质，准确，而且文章介绍了更多的背景知识，有助于理解LVS的价值。

总结：

1.以后学习新东西的时候，了解一下其发展背景定会有所收获。

2.一般来说官方文档就是最好的学习材料，先看官方文档，确保大方向理解无偏差，再看介绍性文章丰富细节。

章博士文章链接：

Linux服务器集群系统（一）

写这篇文章是为了做一些输出，一是加深理解，二是方便自己将来查阅。（文章主要参考章博士的文章，图片也都来源于文章）

LVS的全称是linux virtual server，是一种由高性能网络或局域网互联的服务器集群来提供高可伸缩的、高可用网络服务的技术。这种服务器集群有这些优点：高性能，高性价比，可伸缩性，高可用性。

LVS是基于IP的负载均衡技术。有NAT，Tunnel，DR三种实现方式。

LVS—NAT

在Load Balancer上选择合适的realServer，然后做NAT映射，即改写数据报文的目的ip地址。realServer接收到报文后进行处理，响应报文发回到 Load Balancer(设置realServer的网关为Load Balancer)，Load Balancer再次做NAT，即对报文源IP地址进行修改，然后发回给客户端。

NAT的的特点是请求报文和响应报文都经过 Load Balancer，这会使Load Balancer成为服务器集群的瓶颈。而且internet的请求通常都具有这样的特点：请求报文远小于响应报文。为了解决NAT的这个问题，tunnel的模式出现了，在tunnel模式下，服务器的。响应报文不经过Load Balancer直接回发给客户端。这时大家也许会有疑问：在NAT模式下，将realserver的网关不配置成Load Balancer，而是配置成真正的网关，直接发回给客户端不就OK了吗？对于这个问题我的理解是这样的：因为realServer一般都是用的内网ip，所以不可能直接转发。如果想要将报文的源ip修改成Load Balancer的ip，再转发出去，就肯定要在tcp/ip协议栈的基础上做改造，这就影响了代码的通用性，而tunnel是一个不需要代码做改动的解决方案。当然这只是我个人思考得出的理解，很有可能不对，欢迎指出错误。

LVS-Tunnel

Tunnel的工作原理非常简单，就是将整个ip报文当做数据封装在新的ip报文中发送出去，Tunnel的另一端接收到后对报文进行解封，得到原来的报文，然后报文进行转发，vpn就是这个工作原理。

Load Balancer接收到请求后，选择一台realServer用tunnel对数据进行封装，然后转发。realServer接收到数据之后进行解封装，发现原报文的目的地址是VIP，这个时候realServer必须要能够识别这个报文是发给自己的，那么怎么做到的呢？文章原话是： 服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求 。这句话我不是很理解，不知道是不是跟后面的DR方案中的解决方法(后面详细介绍)一样，我猜测应该是一个意思。请求处理完毕之后将数据回发给客户端，源地址是VIP。

tunnel的工作原理决定了这种模式并不限制 Load Balancer和realServer必须在同一网络，而后面介绍的DR模式就有这一限制。

LVS—DR
tunnel由于需要对数据进行封装和解封装，会耗费一些性能和时延，DR是一个性能更高的解决方案。

Load Balancer在接收到客户端的请求报文之后，选择一台合适的realServer，将报文的目的MAC地址修改为选择的realServer的MAC地址，然后通过对应的接口将报文发送出去，此时报文的目的IP地址还是VIP。由于Load Balancer和realServer处于同一个网络，只通过二层转发便能够将这个报文正确的发送到realServer。这个地方值得多思考一下，如果要经过三层，也就是进行路由的话，那么这个报文又会被回发到Load Balancer，那么肯定也就无法正常工作了。所以这也就决定了Load Balancer必须要和realServer在同一个物理网段才能正常工作。realServer接收到这个报文后，链路层发现MAC地址是自己的，所以会继续将报文上传至IP层。由于报文的目的IP地址是VIP，并不是realServer的ip，会被IP层丢弃，如果被丢弃了那肯定也不能正常工作了。DR的解决方法是这样的：所有的服务器把VIP地址配置在各自的Non-ARP网络设备上。这样配置之后，ip层在解析报文的时候会认为这个报文就是发送给自己，所以会进行解析处理。而且因为是Non-ARP的，所以不会响应arp查询，也就不会与Load Balancer产生冲突。由于是从这个ip接收到的报文，响应报文也会通过这个ip发送出去，所以响应报文的源ip就是vip，从而客户端不会感知到这一系列的操作。改写目的MAC地址这个操作是在链路层进行的，所以性能非常高。

2018.05.16增加一些配置的理解

DR模式下，在realServer上配置浮动iP之后，还需进行以下配置：

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce

可以看出，以上配置不是针对某个IP(操作系统可能根本就没有提供这个能力)，也不是针对某个接口的，而是针对所有的接口，其中：
arp_ignore :

0 - (默认值): 回应任何网络接口上对任何本地IP地址的arp查询请求
1 - 只回答目标IP地址是来访网络接口本地地址的ARP查询请求
2 -只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内（可能相同的网络接口 ip被划分为不同子网）

所以：配置为1是为了使浮动ip不响应arp请求，不干扰LVS接收发往浮动ip的包。对于其中本地地址的概念不太理解。

arp_announce：
1 -尽量避免不在该网络接口子网段的本地地址做出arp回应. 当发起ARP请求的源IP地址是被设置应该经由路由达到此网络接口的时候很有用.此时会检查来访IP是否为所有接口上的子网段内ip之一.如果改来访IP不属于各个网络接口上的子网段内,那么将采用级别2的方式来进行处理.
2 -对查询目标使用最适当的本地地址.

在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送.

之所以配置为2，是因为节点在发送arp请求的时候，会携带自己的ip。收到此请求的节点可能会用报文中的源ip和源mac地址更新自己的arp缓存。realServer在回包的时候，源地址是浮动ip，所以正常情况下发送arp请求时，会将源地址设为浮动ip。而将arp_announce这个值设为2后。发送arp请求时就会选择一个与目的地址通信的本地地址。从而就不会选择浮动ip作为arp请求的源地址。就不会更新下一跳的arp缓存，从而避免问题。至于为什么最适当的本地地址就一定不是浮动IP，还需进一步学习。

关于 Non-ARP网络设备，在实际的操作过程中一般都是配置loop-back接口来实现的。关于什么是loop-back接口，可以自己搜索一下。然后推荐按这个教程配置一个loop-back接口，自己就会有一个非常直观的理解。

win10系统如何设置虚拟回环

当你配置了某个ip地址之后，你便能ping通这个ip了。

最后再次强烈推荐阅读章博士的原文。

http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/

补充：
博客中有这么一段：

由于是从这个ip接收到的报文，响应报文也会通过这个ip发送出去，所以响应报文的源ip就是vip，从而客户端不会感知到这一系列的操作。
当初写这段话的时候并没有细想其中的细节，为什么从某个IP收到报文后就会从某个ip返回回去呢？换名话说，TCP和UDP怎么保证接收到的响应报文的源IP就是接收报文的目的IP呢？一时半会儿没想清楚，最终我的理解如下：既然IP层和传输层属于不同的层次，传输层要让IP层发送报文，肯定得指定目的IP。
但是UDP属于无连接的协议，不像TCP那样靠客户端ip+端口，服务端ip+端口共4个标识来决定一个连接。所以答案是udp根本不需要保证响应报文源ip地址是请求报文的目标地址。

至于tcp，虽然我们操作的时候是直接使用socket函数的write函数进行回复，但是可以肯定，socket的内部实现一定记录了本端ip，然后将报文传给ip层的时候携带此ip。