一、写在前面
在前面组建好单个服务器后，现在开始规划集群网络流量负载平衡的方案，这也是集群当中很关键的一部分。
二、应用场景分析——HAProxy or LVS？
这里以HAProxy和LVS两个负载平衡工具，从流量流经之路来分析，讨论适合Gerrit服务器应用场景的方案。一组简易的流程如下，左图使用HAProxy，右图为LVS的DR/Tunnel模式：
从图中可以看出，LVS在响应用户请求时，不需要再经过Loading Balance Server，减少了不小开销。此外，LVS工作在网络4层（传输层）上，仅作分发之用，没有流量的产生，且对内存和CPU资源消耗较低。综上，这里选择用LVS作为解决方案。
三、进一步了解LVS
LVS是Linux Virtual Server的简写，即Linux虚拟服务器。是根据iptable的框架开发的，分为两个部分，一个部分是工作在内核空间的IPVS模块（该模块在Linux 2.6.X默认集成，而早前的版本则需要重新编译内核），LVS的主要功能都由这个模块实现；第二个部分工作在用户空间，相当于给用户一个管理接口，名为ipvsadm，在搭建Director Server前需安装这个工具。
LVS的工作模式有三种，分别是LVS-NAT（地址转换）、LVS-DR（直接路由）和LVS-Tunnel（隧道模式）。其中LVS-NAT工作行为与HAProxy类似，所有Real Server流量都需要经过Director Server才能到达用户，这里就不过多介绍了。
而LVS-DR大致工作流程是这样的：
a. 用户（Client IP）向服务器集群入口Virtual IP发起请求；
b. Director Server接收该请求后，根据预先设定好的负载平衡调度算法，将该数据包转发到特定的Real Server，在转发前会封装入Director Server到Real Server的MAC信息。
c. 当Real Server收到这个由Client IP到Virtual IP的数据包，由于Real Server也配置了Virtual IP，所以它会认定这个数据包是发送给自己的，于是接收，并将最终回应打上由Virtual IP到Client IP的包头，发送出去。
d. 根据此时包头IP，目的地址为Client IP的数据包会直接回复给用户。
这里有意思的是，步骤b，在最外层IP仍是Client IP到Virtual IP的情况下，这个数据包是如何由Director Server转发给Real Server的呢？这里大致工作流程是这样的：当Director接收帧首部为本机MAC的数据包，拆开对数据处理。此时发现目标地址为Virtual IP，知道这是一个集群服务。此时，在DR工作模式下，LVS不修改IP包任何信息，仅仅将拆掉的帧首部再包回去，只不过包的时候，将MAC信息变为由Director到Real Server。上文也提到，LVS工作在链路层，所以可以直接由MAC地址，将数据包转发出去。
而Real Server在接收数据包经过层层拆解，看到源IP为Client IP，会在应用层将回复的数据包传给Client IP。
这里还需要注意一个问题，由于每台Real Server在接收报文和响应报文的时候，都需要确认Virtual IP是否为自己的IP地址，因此，我们在配置时，需要给Real Server配置Virtual IP地址。那么同时有这么多台主机共用一个IP地址，会有什么影响呢？最大的影响是，当路由器向网内发送ARP广播，寻找Virtual IP对应的MAC地址时，会有多台主机响应，这会造成不必要的混乱。因此，在给Real Server配置Virtual IP时，要记得将它的ARP响应关闭。具体配置方法将在下一篇文章中贴出，本篇主要是对负载平衡工作模式的概览，就不细说了。
再看Tunnel模式，这个模式流程思想和DR模式一样，主要区别在于它针对的是Director和Real Server在不同网段的情况。这种情况之所以独立出来而且比较复杂，还是因为LVS是在数据链路层进行报文转发的。那么在Tunnel模式下的转发是如何进行的呢？此时LVS也不会修改IP包任何信息，只不过不再包入帧首部，而是再加上一个IP Tunnel首部，这个首部包含转发的源目的地址以及该封包协议头，因此，也要求使用Tunnel模式的主机都支持IP Tunnel协议。
四、LVS原理验证
结合上面对LVS的了解，这里以LVS-DR模式为例，关注Client请求TCP连接的第一个报文是如何经过转发修改到达Real Server的。图片中三个角色分别用黄、红、绿三色标识，是根据数据包传送过程，分别在这三个角色主机上获取的，在图片右下角也有标识。此外，直线箭头表示不同角色间转发，曲线箭头表示该角色内部的响应报文。
