关于数据:由两个问题引发的对GaussDBDWS负载均衡的思考

摘要 ：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。

点击关注，第一工夫理解华为云陈腐技术~