LVS系列—LVS的三种工作方式(DR原理)(二)

来源:互联网 发布:环信 服务端开发 java 编辑:程序博客网 时间:2024/05/16 14:39

LVS的DR工作模式,是目前生产环境中最常用的一种工作模式,网上的资料也是最多的,有的文章对DR工作模式的讲解还是比较透彻的。这里我们通过图文的方式再向您介绍一下DR的工作模式(同样,如果看不清楚,请右键“查看原图”):

这里写图片描述

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

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

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

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

  • 使用DR模式时,需要Real Server设置LVS上的VIP为自己的一个回环IP,不然包会被丢弃。这又是为什么呢?很多网贴同样没有回答这个问题,好吧,我们马上回答一下。

先来说一说上图的工作原理:

  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就OK了。另外,需要说明的是,由于LVS-DR模式并没有更改原有的IP报文和TCP报文,所以LVS-DR模式本身是不支持端口映射的,实际上在日常使用实践中,我们一般使用Nginx做端口映射,因为: 灵.活.。

LVS-DR工作模式的优点在于:

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

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

LVS-DR当然也有缺点:

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

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


附:FAQ

1、LVS/DR如何处理请求报文的,会修改IP包内容吗?

vs/dr本身不会关心IP层以上的信息,即使是端口号也是tcp/ip协议栈去判断是否正确,vs/dr本身主要做这么几个事:

  1. 接收client的请求,根据你设定的负载均衡算法选取一台realserver的ip;
  2. 以选取的这个ip对应的mac地址作为目标mac,然后重新将IP包封装成帧转发给这台RS;
  3. 在hashtable中记录连接信息。

vs/dr做的事情很少,也很简单,所以它的效率很高,不比硬件负载均衡设备差多少。

2、RealServer为什么要在lo接口上配置VIP,在出口网卡上配置VIP可以吗?

既然要让RS能够处理目标地址为vip的IP包,首先必须要让RS能接收到这个包。在lo上配置vip能够完成接收包并将结果返回client。

不可以将VIP设置在出口网卡上,否则会响应客户端的arp request,造成client/gateway arp table紊乱,以至于整个loadbalance都不能正常工作。

3、RealServer为什么要抑制arp帧?

这个问题在上一问题中已经作了说明,这里结合实施命令进一步阐述。我们在具体实施部署的时候都会作如下调整:

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignoreecho "2">/proc/sys/net/ipv4/conf/lo/arp_announceecho "1">/proc/sys/net/ipv4/conf/all/arp_ignoreecho "2">/proc/sys/net/ipv4/conf/all/arp_announce

我相信很多人都不会弄懂它们的作用是什么,只知道一定得有。我这里也不打算拿出来详细讨论,只是作几点说明,就当是补充吧。

第一
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignoreecho "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

这两条是可以不用的,因为arp对逻辑接口没有意义。

第二

如果你的RS的外部网络接口是eth0,那么

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

其实真正要执行的是:

echo "1">/proc/sys/net/ipv4/conf/eth0/arp_ignoreecho "2">/proc/sys/net/ipv4/conf/eth0/arp_announce

所以我个人建议把上面两条也加到你的脚本里去,因为万一系统里上面两条默认的值不是0,那有可能是会出问题滴。

4、LVS/DR loadbalancer(director)与RS为什么要在同一网段中?

从第一个问题中大家应该明白vs/dr是如何将请求转发给RS的了吧?它是在数据链路层来实现的,所以director必须和RS在同一网段里面。

5、为什么director上eth0接口除了VIP另外还要配一个ip(即DIP)?

如果是用了keepalived等工具做HA或者LoadBalance,则在健康检查时需要用到DIP,
没有健康检查机制的HA或者Load Balance则没有存在的实际意义.

6、LVS/DR ip_forward需要开启吗?

不需要。因为director跟realserver是同一个网段,无需开启转发。

7、lvs/dr里,director的vip的netmask 没必要设置为255.255.255.255,也不需要再去 route add -host $VIP dev eth0:0,director的vip本来就是要像正常的ip地址一样对外通告的,不要搞得这么特殊。

阅读全文
0 0