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

举报
Sprother 发表于 2020/12/22 10:09:20 2020/12/22
【摘要】 GaussDB(DWS)的负载均衡通过LVS+keepAlived实现。对于这种方式,需要思考的问题是: CN的返回结果是否会经过LVS,然后再返回给前端应用?如果经过LVS,那么,LVS会不会成为单点瓶颈? 带着这两个问题,我们探究一下LVS+KeepAlived的实现原理。

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

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

现在的问题是:

  • CN的返回结果是否会经过LVS,然后再返回给前端应用?
  • 如果经过LVS,那么,LVS会不会成为单点瓶颈?

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

一、LVS是什么?

 LVSLinux Virtual Server的简称,也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目,它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分,在Linux2.4内核以前,使用LVS时必须要重新编译内核以支持LVS功能模块,但是从Linux2.4内核以后,已经完全内置了LVS的各个功能模块,无需给内核打任何补丁,可以直接使用LVS提供的各种功能。

二、LVS的目的是什么?

LVS主要用于服务器集群的负载均衡,拥有VIP,客户端将所有请求发送至此VIPLVS负责将请求分发到不同的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 hatGFS文件系统,oracle提供的OCFS2文件系统等。

    从整个LVS结构可以看出,Director Server是整个LVS的核心,目前,用于Director Server的操作系统只能是LinuxFreeBSDlinux2.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的负载均衡机制

1LVS是四层负载均衡,也就是说建立在OSI模型的第四层——传输层之上,传输层上有我们熟悉的TCP/UDPLVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡,因此它相对于其它高层负载均衡的解决办法,比如DNS域名轮流解析、应用层负载的调度、客户端的调度等,它的效率是非常高的。

2LVS的转发主要通过修改IP地址(NAT模式,分为源地址修改SNAT和目标地址修改DNAT)、修改目标MACDR模式)来实现。

GaussDB(DWS)目前主要采用的是DR(Direct Routing)模式,所以,我们主要聊一聊DR模式。

下图是DR模式的一个示意图:

DR模式下需要LVSRS集群绑定同一个VIPRS通过将VIP绑定在loopback实现),请求由LVS接受,由真实提供服务的服务器(RealServer, RS)直接返回给用户,返回的时候不经过LVS。详细来看,一个请求过来时,LVS只需要将网络帧的MAC地址修改为某一台RSMAC,该包就会被转发到相应的RS处理,注意此时的源IP和目标IP都没变,LVS只是做了一下移花接木。RS收到LVS转发来的包时,链路层发现MAC是自己的,到上面的网络层,发现IP也是自己的,于是这个包被合法地接受,RS感知不到前面有LVS的存在。而当RS返回响应时,只要直接向源IP(即用户的IP)返回即可,不再经过LVS

至此,回答了我们第一个问题:

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

答:GaussDB(DWS)采用的是LVSDR模式,返回时不再经过LVS

接下来,我们看看keepAlived

一、什么是keepAlived

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

二、keepAlived的原理

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

三、KeepAlivedLVS的关系

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

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

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

至此,我们可以回答第二个问题:

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

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

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200