由两个问题引发的对GaussDB(DWS)负载均衡的思考

对于业务应用或者用户来说，他们发生请求给CN，CN解析并生成执行计划，交给DN去执行，执行后再由CN汇总将数据返回给业务用户或者业务应用。这个过程是容易理解的，本次我们重点关注的是站在CN前面的LVS+KeepAlived。
现在的问题是：
CN的返回结果是否会经过LVS，然后再返回给前端应用？
如果经过LVS，那么，LVS会不会成为单点瓶颈？
带着这两个问题我们探究一下LVS和KeepAlived的原理。
LVS是什么？
LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，现在LVS已经是 Linux标准内流量交易核的一部分，在Linux2.4内核以前，使用LVS时必须要重新编译内核以支持LVS功能模块，但是从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。
LVS的目的是什么？
LVS主要用于服务器集群的负载均衡，拥有VIP，客户端将所有请求发送至此VIP，LVS负责将请求分发到不同的RS，客户不感知RS。其目的是提高服务器的性能，将请求均衡的转移到不同的服务器上执行，从而将一组服务器构成高性能、高可靠的虚拟服务器。
LVS的体系结构
使用LVS架设的服务器集群系统有三个部分组成：
　　（1）最前端的负载均衡层，用Load Balancer表示；
　　（2）中间的服务器集群层，用Server Array表示；
　　（3）最底端的数据共享存储层，用Shared Storage表示；
在用户看来，所有的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。
Load Balancer层：位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。
Server Array层：由一组实际运行应用服务的机器组成，Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director Server也可以同时兼任Real Server的角色。
Shared Storage层：是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。
从整个LVS结构可以看出，Director Server是整个LVS的核心，目前，用于Director Server的操作系统只能是Linux和FreeBSD，linux2.6内核不用任何设置就可以支持LVS功能，而FreeBSD作为Director Server的应用还不是很多，性能也不是很好。对于Real Server，几乎可以是所有的系统平台，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。
LVS的程序组成部分
LVS 由2部分程序组成，包括 ipvs 和 ipvsadm。
ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。
ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)
LVS的负载均衡机制
1、 LVS是四层负载均衡，也就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡，因此它相对于其它高层负载均衡的解决办法，比如DNS域名轮流解析、应用层负载的调度、客户端的调度等，它的效率是非常高的。
2、 LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR模式）来实现。
GaussDB(DWS)目前主要采用的是DR(Direct Routing)模式，所以，我们主要聊一聊DR模式。
DR模式下需要LVS和RS集群绑定同一个VIP（RS通过将VIP绑定在loopback实现），请求由LVS接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过LVS。详细来看，一个请求过来时，LVS只需要将网络帧的MAC地址修改为某一台RS的MAC，该包就会被转发到相应的RS处理，注意此时的源IP和目标IP都没变，LVS只是做了一下移花接木。RS收到LVS转发来的包时，链路层发现MAC是自己的，到上面的网络层，发现IP也是自己的，于是这个包被合法地接受，RS感知不到前面有LVS的存在。而当RS返回响应时，只要直接向源IP（即用户的IP）返回即可，不再经过LVS。
至此，回答了我们第一个问题：
CN的返回结果是否会经过LVS，然后再返回给前端应用？
答：GaussDB(DWS)采用的是LVS的DR模式，返回时不再经过LVS。
接下来，我们看看keepAlived。