# LVS DR 原理
LVS-DR不同于普通的haproxy代理机制，它在网络中的作用层级更加底层。haproxy一般代理应用层的应用数据，所有的数据都会通过haproxy收发，导致了haproxy是一个性能瓶颈。而lvs-dr作用在IP和数据链路层，效率更高，并且只代理进入proxy的数据，应用的返回数据由应用服务器直接返回给client。
|
pros |
cons |
|
|
haproxy |
可以基于端口做代理 真实server与proxy不需要在一个二层网络 |
单点问题 进出流量都走proxy，负载高 |
|
lvs-dr |
只有request请求通过proxy，response数据直接返回给客户，性能高。 |
proxy和server必须在同一个二层网络 |
整个数据包的处理流程如下：
-
Client要访问192.168.1.2上的服务
-
request数据经过路由到达我们的proxy，上面运行着负载均衡器，负载均衡器通过策略算法，把目标MAC改成真实的Server MAC，并发送给目标MAC（这里决定了proxy和server只能在同一个二层网络中）
-
Server收到请求后，将响应数据直接通过路由发送给client，不再经过proxy
# 基于DPDK的DR架构
为什么要用DPDK呢？因为lvs是基于linux内核的，而linux内核处理包的速度太慢（10G网卡3～4Mpps），特别是对小包的处理，导致了性能瓶颈。而利用DPDK技术可以绕过linux内核从而直接处理网络数据报，写的好的话可以达到线速（10G网卡14Mpps）。
这个负载均衡器主要由两部分组成，转发器（Forwarder）和健康检查器（Monitor）。
Monitor通过ping或者arp的方式检查Server的状态，如果无法连接，则将此Server设置成unreachable的状态。
Forwarder通过hash算法把同一个来源的数据报发往同一个Server，以保证连接的一致性。
# 技术细节的考虑
来看看现在的设计距离google的设计还差多远？
还差着一个集群这么远。。。。。。。。。
目前只有单个proxy的设计，那作为一个集群要怎么玩呢？
首先是DNS层面，根据来源返回一个就近的VIP地址（如果在多个数据中心部署了的话）
然后是Router层面，使用了ECMP，把大量的请求分发到不同的负载均衡器上。
这就带来了一个问题，如何让同一个来源的请求总是能够到达同一个Server呢？有两个方法。
-
通过配置ECMP，把相同来源的请求都发往相同的负载均衡器。
-
使用一致性hash算法，让不同的负载均衡器在处理同一个请求时都能够转发到同一台Server。
＃ 现有技术
在构思这篇博文的时候还没注意到VPP刚出的LoadBalancing，之前一直想自己实现一个lb application或者基于ovs-dpdk进行修改。但是搜索了一下之后发现了VPP LoadBalancing plugin, 这个plugin就是仿照了Maglev进行设计和实现的。
不知道VPP是何技术的可以去google一下，这是cisco开源的sdn技术，类似于openvswitch，自称转发性能比openvswitch高不知道哪去了。VPP底层基于dpdk或者netmap的技术实现高速收发数据报。
VPP实现的LB跟上面说的有一部分不太一致，就是从proxy到server的过程，VPP是用gre tunnel技术实现的，这样就不需要server和proxy在同一个二层网络里了，相应的，tunnel技术会增加每个封包的长度，需要相应的修改MTU，启用Jumbo Frame。
最后的最后，至于VPP的LB性能如何，怎么用，我现在并没有试过：P
＃ Reference
-
http://oilbeater.com/%E5%8D%9A%E5%AE%A2/2016/11/21/google-loadbalancert.html
-
https://docs.fd.io/vpp/16.12/md_plugins_lb-plugin_README.html
本文转自Tenderrain 51CTO博客，原文链接：http://blog.51cto.com/tenderrain/1983570，如需转载请自行联系原作者