跟我一起学Load Balance（3）

作者：[e-mail]
博客：blog.focus-linux.net   linuxfocus.blog.chinaunix.net 

微博：weibo.com/glinuxer

QQ技术群：4367710

 

本文的copyleft归[e-mail]所有，使用GPL发布，可以自由拷贝，转载。但转载请保持文档的完整性，注明原作者及原链接，严禁用于任何商业用途。

=======================================================

本系列文章均来源于书籍《Load Balancing Servers, Firewalls, and Caches》，均为书中的知识点，稍稍加上作者从事这行业的一些经验——应该是不涉及公司机密呵。。。

在前面的LB的应用网络拓扑中，LB作为服务器的前端设备，也是连接中的中间设备。client和server所有的流量都要经过LB设备。不仅这样，LB设备往往还需要修改数据包的报头，甚至包的内容。而世上没有免费的午餐，这些操作难免会带来一些性能损耗。

那么我们又想使用LB的功能，同时又不愿意有这样的性能下降，这时怎么办？性能的下降是由于所有的数据包都要经过LB设备。那么我们能不能让数据包不经过LB设备呢？这时，就需要让SLB另外一种应用拓扑Direct Server Reply，即DSR模式。顾名思义，DSR模式下，server的response包不会经过LB，直接发往client。而所有的client发送的request数据包，仍然经过LB设备。

在DSR模式下，LB设备只转换client发送包的目的MAC地址（转换为real server的mac地址），而目的IP地址不做任何转换，仍然为VIP（一般情况下，IP一旦转换，response就不得不经过LB）。由于是利用MAC地址来将request发给real server，所以real server需要和LB设备处于同一个L2 domain。

数据包的目的MAC为real server的MAC地址。这样，real server就可以收到该数据包，但是VIP怎么办？为了接收这个数据包，我们必须让real server也拥有这个VIP。但是在同一个L2 domain中，怎么能有两个不同的host拥有一个相同的IP呢？这里实际上是一个小trick。在real server上，我们需要将VIP配置在其loopback上。loopback是一个逻辑的IP接口，在其上面配置的IP不会响应任何的ARP请求。所以即使real server的loopback上配置VIP，除了它自己，其它任何设备都不知道，从而也就不会引发VIP冲突了。

当real server收到一个发给它的数据包（MAC匹配），数据包的IP也匹配其loopback上的VIP（对于real server，它认为VIP就是它的IP地址，即使是配置在loopback上）。因此，real server就会处理这个request，并可以直接将reply发送给client，而不经过LB设备。当client收到回复时，它看到的源目的IP地址仍然是VIP。这样对于client来说，real server仍然是透明的，其后续的request仍然发送到VIP，也就是LB设备。LB设备可以根据策略选择real server。也就是说SLB的功能，并不会由于DSR模式而受到影响。

使用DSR模式，看上去只有server的response不经过LB设备，只有单边的流量得到了优化。但是在一般的CS应用中，client的request往往比较简单，数据较小较少，而server的response的数据较多较大。一般server response的流量可以占到总流量的80%到90%时，使用DSR模式，可以有效的提高性能，又不损失SLB的灵活性。