青蛙学Linux—高性能负载均衡集群软件LVS

时间:2021-10-29 23:13:02

LVS,即Linux Virtual Server的简写,是目前非常流行的一款实现负载均衡集群的软件。该项目在1998年5月由章文嵩博士成立,是中国国内最早出现的*软件项目之一。LVS官网http://www.linuxvirtualserver.org/

1、LVS体系架构

LVS负载均衡集群由三部分组成:最前端的负载均衡层,即Load Balancer;中间的服务器群组层,即Server Array;最后端的数据共享存储层,即Shared Storage。在用户看来,所有的内部应用都是透明的,用户只是在使用一个虚拟服务器提供的高性能服务。

  • Load Balancer:位于整个集群的最前端,由一台或多台负载调度器(Director Server)组成,LVS模块就安装在Director Server上,Director Server的作用类似于一个路由器,它含有完成LVS功能所需要的路由表,通过这些路由表把用户的请求分发给Server Array的应用服务器(Real Server)。同时,在Director Server上还要安装监控模块Ldirectord,用于监控后端Real Server的健康状况,在Real Server不可用时将其从LVS的路由表中剔除,恢复时重新加入;Director Server是整个LVS的核心,操作系统只支持Linux或FreeBSD,Linux从2.6内核起不用重新编译就可以支持LVS功能
  • Server Array:由一组实际运行的应用服务器(Real Server)组成,每个Real Server之间通过高速的LAN或分布在各地的WAN相连,在实际应用中Director Server也可以同时兼任Real Server的角色;对于Real Server,可以是任意平台的操作系统,如Linux、Windows、AIX等
  • Shared Storage:为所有的Real Server提供共享存储空间和内容一致性的存储区域。在物理上,一般由磁盘阵列设备组成;为了提供内容的一致性,一般可以通过NFS进行数据共享,但NFS在繁忙的业务系统中性能并不是很好,此时可以采用集群文件系统,如RedHat的GFS、Oracle的OCFS2等

整个架构具体如下图所示:

青蛙学Linux—高性能负载均衡集群软件LVS

2、LVS IP负载均衡机制的实现

负载均衡技术有多种实现方案,如基于DNS域名轮流解析的方法、基于客户端调度访问的方法、基于应用层系统负载的调度方法、基于IP地址的调度方法。在这些调度方法中,基于IP地址的方法是执行效率最高的。

LVS的IP负载均衡技术是通过IPVS模块来实现的,IPVS是LVS的核心模块。

在LVS中,访问请求首先经过VIP到达负载均衡调度器,然后由负载均衡调度器从Real Server列表中选取一个Real Server响应用户的请求。Real Server如何将请求的数据返回给用户,是IPVS实现的重点,IPVS实现负载均衡的机制有以下几种:

2.1、DR模式

DR即Virtual Server via Direct Routing,使用直接路由技术实现虚拟服务器。VS/DR通过改写请求报文的MAC地址,将请求发送到Real Server,而Real Server将响应直接返回给客户端。这种调度方式的性能是最好的。DR模式架构如下图所示:

青蛙学Linux—高性能负载均衡集群软件LVS

  • DR模式是通过在负载均衡调度器LB上修改数据包的目的MAC地址实现转发。因此数据包来源地址保持不变,目的地址仍然是VIP
  • 请求的报文经过LB,而后端RS响应处理后的报文无需经过LB,因此并发访问量大时效率很高(与NAT模式相比)
  • 因为DR模式通过MAC地址改写机制实现转发,因此所有RS和LB只能在一个局域网中
  • RS上需要绑定VIP地址到lo接口上,并且需要配置ARP抑制
  • RS的默认网关不需要配置成LB,而是直接配置为上层路由网关,只要能让RS直接与客户端通讯即可
  • 由于DR模式的LB仅作MAC地址改写,所以LB就不能改写目标端口,那么RS就能使用和VIP相同的端口提供服务

2.2、NAT/FULL NAT模式

NAT,即Virtual Server via Network Address Translation,使用网络地址翻译技术实现虚拟服务器。当用户的请求到达LB时,LB将请求报文的目的地址改成选定的RS地址,同时将报文的目标端口也改成选定的RS的相应端口;RS将返回的数据提交给LB,LB再将报文源地址和源端口修改成VIP和相应的端口后将数据返回给用户,完成整个负载调度过程。NAT/FULL NAT模式架构如下图所示:

青蛙学Linux—高性能负载均衡集群软件LVS

  • NAT模式不需要LB和RS在同一个网段
  • NAT模式将请求的报文和响应的报文都经过LB进行转发和地址改写,因此访问量大时,LB有较大的瓶颈,一般一台LB最多只能带10-20台RS
  • 只需要在LB上配置一个公网IP即可
  • 每台RS的网关地址必须是LB的IP
  • 支持IP地址和端口的转换,即前端LB和后端RS提供服务的端口可以不一致
  • LB节点上必须开启数据转发功能,否则返回的数据无法到达客户端。在Linux下使用以下方法打开数据转发功能
    # 在/etc/sysctl.conf中添加以下内容
    net.ipv4.ip_forward = 1    # 值为0表示不开启转发功能,1表示开启转发功能
    # 修改完成后执行以下命令使配置生效
    sysctl -p
FULL NAT与NAT的区别

FULL NAT与NAT的区别主要在对报文的处理方面:

  • FULL NAT在客户端请求VIP时,不仅替换了报文中的目的IP,还替换了源IP;VIP返回给客户端时也替换了源IP
  • FULL NAT因为要替换源IP所以性能比NAT下降10%

2.3、TUN模式

TUN,即Virtual Server via IP Tunneling,通过IP隧道技术实现虚拟服务器。LB采用IP隧道技术将用户的请求转发到某个RS,RS直接将数据返回给用户,不需要再经过LB。在TUN模式中,LB与RS不需要在同一个网段;同时LB只处理用户请求报文,使得集群吞吐量大大提高。TUN模式架构如下图所示:

青蛙学Linux—高性能负载均衡集群软件LVS

  • TUN模式中LB和RS之间的传输不需要修改报文,而是通过单独建立的IP隧道传输
  • TUN模式必须在所有的RS上绑定VIP
  • TUN模式使用IP隧道,在增加了运维方面的难度

3、LVS的负载调度算法

LVS的负载调度算法可以分为静态和动态两种。静态算法是仅根据算法进行调度,而不考虑后端RS的实际连接和负载情况;动态算法可以根据后端RS的实际连接和负载来进行请求调度。

静态算法有四种,分别是RR、WRR、DH和SH。

  • RR轮询算法:LB将请求按照顺序轮流分配到后端RS,它均等对待后端每一台RS,适用于后端RS节点处理性能差不多的场景
  • WRR加权轮询算法:LB根据RS的权重分配任务
  • DH目的地址哈希调度算法:以目的IP地址为关键字查找一个静态哈希表来获取需要的RS
  • SH源地址哈希调度算法:以源IP地址为关键字查找一个静态哈希表来获取需要的RS

动态算法有六种,分别是LC、WLC、SED、NQ、LBLC和LBLCR

  • LC最少连接算法:LB将请求动态的调度到已建立连接最少的后端RS上。在后端RS性能相近的情况下适用该算法可以较好的平衡负载
  • WLC加权最少连接算法:在LC的基础上根据权重来将请求动态的调度到后端的RS上,用于在后端RS性能相差较大的环境中
  • SED最短延迟调度算法:基于WLC算法。如果ABC三台RS的权重分别为1、2、3,则使用SED时会进行以下计算,A - (1+1)/1;B - (2+1)/2;C - (3+1)/3,LB会将请求交给运算结果最小的RS
  • NQ永不排队/最少队列算法:无需排队,如果有RS的连接数为0则直接将请求调度给该RS而不进行SED计算
  • LBLC基于地址的最小连接数调度算法:将来自同一个目的IP地址的请求分配给同一台RS,如果该RS的负载已满,则将请求分配给连接数最小的RS,并将该RS做为下一次分配的首选RS
  • LBLCR带复制的基于地址的最小连接数调度算法:与LBLC不同的是,该算法维护的是从同一个目的IP地址到一组RS的映射,请求的RS会从该组RS中选择得出
常用服务 调度算法
Web、mali、MySQL RR、WLC、WRR
web cache、DB cache LBLC、LBLCR
防火墙集群 SH、DH