和NAT模式不同，DR的负载均衡调度器工作在网络七层协议中的数据链路层，也就是第二层。它通过修改数据包的目标MAC地址，将数据包转发到实际应用服务器上，最重要的是，实际服务器的响应数据包将直接返回给用户端，而不需要经过负载调度器
1、LVS、DR简介
LVS 是Linux Virtual Server的简称，在实际环境中经常作为B/S结构的网络应用中的负载均衡器来使用，工作在7层网络模型中的，网络层，也就是通常说的IP层，由于数据的处理是在Linux内核态完成的，所以相对反向代理服务器来说，性能一般会高一些；
DR 是Direct Routing直接路由的简称，应答包通过单独的路由方法返回给客户端。不需要隧道结构，因此可以使用大多数linux操作系统做为物理服务器。
2、简单的LVS/DR架构图
这里我简单画一下LVS/DR模式在应用时的部署环境：
我们先假设百度用的是这种架构模型（实际上百度是什么架构我也没有实地调研过）
然后来模拟下用户访问百度的情况。
1.用户在浏览器输入http://www.baidu.com, 用户的电脑通过网络询问DNS，www.baidu.com域名的IP地址。
2.DNS服务器通过用户的地址，在服务器列表里选择一个可能是距离用户最近的LVS虚拟服务IP地址或者一个按照轮询策略的地址。
可以用ping www.baidu.com，能看到会返回一个IP地址，这个IP地址就是我们DNS返回给我们的地址。也可以用dig命令，能够看到www.baidu.com 实际对应了3个IP地址
3.用户浏览器通过DNS获得的IP地址，访问LVS服务器
4.进入LVS/DR模式，LVS将数据包提供给APACHE或者nginx构建的反向代理服务器；
5.反向代理服务器最终将请求送给应用服务器；
6.应用服务器完成用户请求之后，通过反向代理服务器直接返回给用户，而不需要通过LVS服务器。
3、IP别名
上面是从用户的数据的角度来看运行的情况，在这里面，会涉及到一个技术，那就是IP别名。它对于直接路由负载均衡的实现及其重要。一个网络接口可以有一个IP地址，但是一个网络接口也可以有多个IP地址，这些地址就叫做IP别名。
通过DR模式的负载均衡，调度器通过修改数据包的目标MAC地址，将数据转发给实际应用服务器。但是注意了，在这里并没有修改目标IP地址，当我们把数据转发出去之后，数据包发现自己来到了一个不应该来的地方，怎么办？
我开车去一个陌生的地方（南浦大桥），不认识路，于是我问路边的人（负载均衡设备），他告诉我一个地址（LVS地址），我开车往路人指导的方向开，我开呀开呀，路边的指示牌写的是卢浦大桥(实际应用服务器地址)。
如果我不认识路，那我肯定是傻眼了，怎么办，在指示牌的卢浦大桥的下面，加上南浦大桥的字样。
这样，我看到了南浦大桥的指示牌，我就能够按照指示牌继续前进。
IP别名就类似在一个指示牌上写上了“卢浦大桥”和“南浦大桥”。
我们要做的，就是给实际应用服务器添加和调度器IP地址相同的IP别名，这样才能让数据包正常运行。
除此以外，要防止实际应用服务器相应来自网络中针对IP别名的ARP广播：
Echo “1”>/proc/sys/net/ipv4/conf/lo/arp_ignore
Echo “2”>/proc/sys/net/ipv4/conf/lo/arp_announce
Echo “1”>/proc/sys/net/ipv4/conf/all/arp_ignore
Echo “2”>/proc/sys/net/ipv4/conf/all/arp_announce
4、配置LVS/DR
在调度器上进行设置，和NAT模式类似
Ipvsadm –a –t 122.12.12.12:80 –s rr
Ipvsadm –a –t 122.12.12.12:80 –r 10.0.0.100:8000 –g
Ipvsadm –a –t 122.12.12.12:80 –r 10.0.0.101:8000 –g
在添加实际应用服务器，要用-g选项，这代表告诉调度器使用直接路由的方式转发数据包
5、性能
相对LVS/NAT模式，DR模式不需要把返回的数据，通过负载均衡是被转发，想要他发挥优势，那么就要相应的数据包的数量和长度远远大于请求数据包，幸运的是，大部分WEB服务都具备这样的特点，响应和请求并不对称，因此常用的WEB服务，都可以使用这种模式。
这种方式，负载均衡器不再是系统的瓶颈。如果你的负载均衡器只拥有100M的全双工网卡和带宽的话，通过集群的横向扩展也可以让整个系统达到1G的流量。
来自LVS官方站点的测试结果也告诉我们，LVS-DR可以容纳100台以上的实际应用服务器，对一般的服务而已，这样的表现足够了。
6、缺点
DR模式下不能跨网段转发数据，如果必须要跨网段进行负载，那么就必须使用LVS/TUN模式。
原文地址：http://blog.csdn.net/ffm83/article/details/42589229
