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

摘要：GaussDB(DWS)的负载均衡通过 LVS+keepAlived 实现。对于这种方式，需要思考的问题是，CN 的返回结果是否会经过 LVS，然后再返回给前端应用？如果经过 LVS，那么，LVS 会不会成为单点瓶颈？ 带着这两个问题，我们探究一下 LVS+KeepAlived 的实现原理。

我们知道 GaussDB(DWS)为了保证业务的连续性和高可靠性，各个组件都进行了高可用设计。

下图是应用访问 GaussDB(DWS)的业务流程架构图，对于业务应用或者用户来说，他们发生请求给 CN，CN 解析并生成执行计划，交给 DN 去执行，执行后再由 CN 汇总将数据返回给业务用户或者业务应用。这个过程是容易理解的，本次我们重点关注的是站在 CN 前面的 LVS+KeepAlived。

现在的问题是：

• CN 的返回结果是否会经过 LVS，然后再返回给前端应用？

• 如果经过 LVS，那么，LVS 会不会成为单点瓶颈？

带着这两个问题我们探究一下 LVS 和 KeepAlived 的原理。

LVS 是什么？

LVS 是 Linux Virtual Server 的简称，也就是 Linux 虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，它的官方站点是 www.linuxvirtualserver.org。现在 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。

1. ipvs(ip virtual server)：一段代码工作在内核空间，叫 ipvs，是真正生效实现调度的代码。

2. 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 模式的一个示意图：

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。

什么是 keepAlived？

Keepalived 顾名思义，保持存活，在网络里面就是保持在线了，也就是所谓的高可用或热备，用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。

keepAlived 的原理

Keepalived 的实现基于 VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议），而 VRRP 是为了解决静态路由的高可用。虚拟路由器由多个 VRRP 路由器组成，每个 VRRP 路由器都有各自的 IP 和共同的 VRID(0-255)，其中一个 VRRP 路由器通过竞选成为 MASTER，占有 VIP，对外提供路由服务，其他成为 BACKUP，MASTER 以 IP 组播（组播地址：224.0.0.18）形式发送 VRRP 协议包，与 BACKUP 保持心跳连接，若 MASTER 不可用（或 BACKUP 接收不到 VRRP 协议包），则 BACKUP 通过竞选产生新的 MASTER 并继续对外提供路由服务，从而实现高可用。

KeepAlived 与 LVS 的关系

1、keepalived 是 lvs 的扩展项目，是对 LVS 项目的扩展增强，因此它们之间具备良好的兼容性。

2、对 LVS 应用服务层的应用服务器集群进行状态监控：若应用服务器不可用，则 keepalived 将其从集群中摘除，若应用服务器恢复，则 keepalived 将其重新加入集群中。

3、检查 LVS 主备节点的健康状态，通过 IP 漂移，实现主备冗余的服务高可用，服务器集群共享一个虚拟 IP，同一时间只有一个服务器占有虚拟 IP 并对外提供服务，若该服务器不可用，则虚拟 IP 漂移至另一台服务器并对外提供服务，解决 LVS 本身单点故障问题。

至此，我们可以回答第二个问题：

• 如果经过 LVS，那么，LVS 会不会成为单点瓶颈或者出现单独故障？

答：返回结果不会经过 LVS，不会因为返回的数据量太大造成单独瓶颈的问题。对应请求， LVS 只需要将用户请求转发给 CN 即可，负载很低，也不会出现单独瓶颈的问题。另外，LVS 通过 keepAlived 实现了主备冗余，避免了单独故障。

本文分享自华为云社区《由两个问题引发的对 GaussDB(DWS)负载均衡的思考》，原文作者：Sprother 。

点击关注，第一时间了解华为云新鲜技术~