术→技巧, 运维

负载均衡技术:LVS

钱魏Way · · 609 次浏览
!文章内容如有错误或排版问题,请提交反馈,非常感谢!

LVS是 Linux Virtual Server 的简写,意即 Linux 虚拟服务器,是一个虚拟的服务器集群系统。是由章文嵩博士发起的自由软件项目。LVS 主要用于多服务器的负载均衡。它工作在网络层,可以实现高性能,高可用的服务器集群技术。

  • 它廉价,可把许多低性能的服务器组合在一起形成一个超级服务器。
  • 它易用,配置非常简单,且有多种负载均衡的方法。
  • 它稳定可靠,即使在集群的服务器中某台服务器无法正常工作,也不影响整体效果。
  • 可扩展性也非常好。

LVS 是一个工作在四层的负载均衡器,它的实现和 iptables/netfilter 类似,工作在内核空间的 TCP/IP 协议栈上,LVS 工作在 INPUT Hook Funtion 上,并在 INPUT 设置附加规则,一旦客户端请求的是集群服务,LVS 会强行修改请求报文,将报文发往 POSTROUTING,转发至后端的主机。

和 iptables/netfilter 类似,LVS 也是两段式的:

  • ipvsadm:工作在用户空间,负责定义和管理集群服务的规则
  • ipvs:工作在内核中,在 4.23 之前,必须向内核打补丁,并重新编译内核。在 2.4.23 和 2.6 之后的版本,ipvs 直接内置在内核中。

LVS 集群的设备地址命名

  • VIP:Virtual IP,LVS 面向用户请求的 IP 地址
  • RIP:Real server IP,后端服务器用于和 LVS 通信的 IP 地址
  • DIP:Director IP,LVS 用户和后端服务器通信的 IP 地址
  • CIP:Client IP,客户端 IP 地址

LVS 的特性:

  • 高可用性:LVS 是一个基于内核级别的应用软件,因此具有很高的处理性能,用 LVS 构架的负载均衡集群系统具有优秀的处理能力,每个服务节点的故障不会影响整个系统的正常使用,同时又实现负载的合理均衡,使应用具有超高负荷的服务能力,可支持上百万个并发连接请求。如配置百兆网卡,采用 VS/TUN 或 VS/DR 调度技术,整个集群系统的吞吐量可高达 1Gbits/s;如配置千兆网卡,则系统的最大吞吐量可接近 10Gbits/s。
  • 高可靠性:LVS 负载均衡集群软件已经在企业、学校等行业得到了很好的普及应用,国内外很多大型的、关键性的 web 站点也都采用了 LVS 集群软件,所以它的可靠性在实践中得到了很好的证实。有很多以 LVS 做的负载均衡系统,运行很长时间,从未做过重新启动。这些都说明了 LVS 的高稳定性和高可靠性。
  • 适用环境:LVS 对前端 Director Server 目前仅支持 Linux 和 FreeBSD 系统,但是支持大多数的 TCP 和 UDP 协议,支持 TCP 协议的应用有:HTTP,HTTPS,FTP,SMTP,POP3,IMAP4,PROXY,LDAP,SSMTP 等等。支持 UDP 协议的应用有:DNS,NTP,ICP,视频、音频流播放协议等。LVS 对 RealServer 的操作系统没有任何限制,RealServer 可运行在任何支持 TCP/IP 的操作系统上,包括 Linux,各种 Unix(如 FreeBSD、Sun Solaris、HP Unix 等),Mac/OS 和 Windows 等。
  • 开源软件:LVS 集群软件是按 GPL(GNU Public License)许可证发行的自由软件,因此,使用者可以得到软件的源代码,并且可以根据自己的需要进行各种修改,但是修改必须是以 GPL 方式发行。

LVS 结构体系

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

  • Load Balancer 层:这是 LVS 的核心部分,它好比网站 MVC 模型的 Controller。它负责将客户的请求按照一定的算法分发到下一层不同的服务器进行处理,自己本身不做具体业务的处理。该层由一台或者几台 Director Server 组成。LVS 模块就安装在 Director Server 上,Director 的主要作用类似于一个路由器,它含有完成 LVS 功能所设定的路由表,通过这些路由表把用户的请求分发给 Server Array 层的应用服务器(RealServer)上。同时,在 Director Server 上还要安装对 RealServer 服务的监控模块 Ldirectord,此模块用于监测各个 RealServer 服务的健康状况。在 RealServer 不可用时把它从 LVS 路由表中剔除,恢复时重新加入。
  • Server Array 层:该层负责具体业务。由一组实际运行应用服务的机器组成,RealServer 可以是 WEB 服务器、MAIL 服务器、FTP 服务器、DNS 服务器、视频服务器中的一个或者多个,每个 RealServer 之间通过高速的 LAN 或分布在各地的 WAN 相连接。在实际的应用中,Director Server 也可以同时兼任 RealServer 的角色。
  • Shared Storage 层:是为所有 RealServer 提供共享存储空间和内容一致性的存储区域,在物理上,一般有磁盘阵列设备组成,为了提供内容的一致性,一般可以通过 NFS 网络文件系统共享数据,但是 NFS 在繁忙的业务系统中,性能并不是很好,此时可以采用集群文件系统,例如 Redhat 的 GFS 文件系统,oracle 提供的 OCFS2 文件系统等。

LVS 的工作模式

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

LVS 的 IP 负载均衡技术是通过 IPVS 模块来实现的,IPVS 是 LVS 集群系统的核心软件,它的主要作用是:安装在 Director Server 上,同时在 Director Server 上虚拟出一个 IP 地址,用户必须通过这个虚拟的 IP 地址访问服务。这个虚拟 IP 一般称为 LVS 的 VIP,即 Virtual IP。访问的请求首先经过 VIP 到达负载调度器,然后由负载调度器从 RealServer 列表中选取一个服务节点响应用户的请求。当用户的请求到达负载调度器后,调度器如何将请求发送到提供服务的 RealServer 节点,而 RealServer 节点如何返回数据给用户,是 IPVS 实现的重点技术,IPVS 实现负载均衡机制有三种,分别是 NAT、TUN 和 DR,详述如下:

VS/NAT:即(Virtual Server via Network Address Translation)

LVS-NAT 模型类似于 DNAT,工作机制与 DNAT 一样,当客户端请求的是集群服务时,LVS 修改请求报文的目标地址为 RIP,转发至后端的 RealServer,并修改后端响应报文的源地址为 VIP,响应至客户端。

在 LVS-NAT 模型下,Director 进出请求报文都经过 Director,因此 Director 的压力是比较大的。

LVS-NAT 的特性:

  • 集群节点跟 Director 必须在同一个 IP 网络中
  • RIP 通常是私有地址,仅用于各集群节点间的通信
  • Director 位于 client 和 Realserver 之间,负责处理进出的所有报文
  • Realserver 必须将网关指向 DIP
  • 支持端口映射
  • 较大规模应用场景中,Director 易成为系统瓶颈(bottleneck)

即使是是负载均衡器成为整个系统的瓶颈,如果是这样也有两种方法来解决它。一种是混合处理,另一种是采用 Virtual Server via IP tunneling 或 Virtual Server via direct routing。如果采用混合处理的方法,将需要许多同属单一的 RRDNS 域。你采用 Virtual Server via IP tunneling 或 Virtual Server via direct routing 以获得更好的可扩展性。也可以嵌套使用负载均衡器,在最前端的是 VS-Tunneling 或 VS-Drouting 的负载均衡器,然后后面采用 VS-NAT 的负载均衡器。

VS/TUN:即(Virtual Server via IP Tunneling)

和 DR 模型类似,Realserver 都配有不可见的 VIP,Realserver 的 RIP 是公网地址,且可能和 DIP 不再同一网络中。当请求到达 Director 后,Director 不修改请求报文的源 IP 和目标 IP 地址,而是使用 IP 隧道技术,使用 DIP 作为源 IP,RIP 作为目标 IP 再次封装此请求报文,转发至 RIP 的 Realserver 上,Realserver 解析报文后仍然使用 VIP 作为源地址响应客户端。

LVS-TUN 的特性:

  • 集群节点和可以跨越 Internet
  • RIP,DIP,VIP 都是公网地址
  • Director 仅负责处理入站请求,响应报文由 Realserver 直接发往客户端
  • Realserver 使用自己的网关而不是 Director
  • Realserver 只能使用支持隧道功能的操作系统
  • 不支持端口映射

VS/DR:即(Virtual Server via Direct Routing)

DR 值 Direct Routing,直接路由,DR 模型中,Director 和 Realserver 处在同一网络中,对于 Director,VIP 用于接受客户端请求,DIP 用于和 Realserver 通信。对于 Realserver,每个 Realserver 都配有和 Director 相同的 VIP(此 VIP 隐藏,关闭对 ARP 请求的响应),仅用户响应客户端的请求,RIP 用于和 Director 通信。

当客户端请求集群服务时,请求报文发送至 Director 的 VIP(Realserver 的 VIP 不会响应 ARP 请求),Director 将客户端报文的源和目标 MAC 地址进行重新封装,将报文转发至 Realserver,Realserver 接收转发的报文。此时报文的源 IP 和目标 IP 都没有被修改,因此 Realserver 接受到的请求报文的目标 IP 地址为本机配置的 VIP,它将使用自己的 VIP 直接响应客户端。

LVS-DR 模型中,客户端的响应报文不会经过 Director,因此 Director 的并发能力有很大提升。

LVS-DR 模型的特性:

  • 保证前端路由器将目标地址为 VIP 的报文通过 ARP 解析后送往 Director。
    • 静态绑定:在前端路由将 VIP 对应的目标 MAC 地址静态配置为 Director VIP 接口的 MAC 地址。
    • arptables:在各 Realserver 上,通过 arptables 规则拒绝其响应对 VIP 的 ARP 广播请求
    • 修改内核参数:在 Realserver 上修改内核参数,并结合地址的配置方式实现拒绝响应对 VIP 的 ARP 广播请求
  • 各 RIP 必须与 DIP 在同一个物理网络中
  • RS 的 RIP 可以使用私有地址,也可以使用公网地址,以方便配置
  • Director 仅负责处理入站请求,响应报文由 Realserver 直接发往客户端
  • Realserver 不能将网关指向 DIP,而直接使用前端网关
  • 不支持端口映射

LVS-FULLNAT

FULLNAT 由淘宝研发,目前还没有加入至 CentOS 可用的内核中,使用时需要向内核打补丁。

类似于 DNAT,它修改请求报文的源地址为 DIP,目标地址为 RIP 来实现转发。对于响应报文,源地址修改为 VIP,目标地址修改为 CIP 来实现转发。

特点:

  • RIP,DIP 可以使用私有地址
  • RIP 和 DIP 可以不再同一网络中,且 RIP 的网关不需要指向 DIP
  • 支持端口映射
  • 请求和响应报文都经由 Director

具体比较:

LVS 的调度算法

针对不同的网络服务需求和服务器配置,IPVS 调度器实现了如下八种负载调度算法:

  • 轮询(Round Robin):“轮询”调度也叫 1:1 调度,调度器通过“轮询”调度算法将外部用户请求按顺序 1:1 的分配到集群中的每个 RealServer 上,这种算法平等地对待每一台 RealServer,而不管服务器上实际的负载状况和连接状态。
  • 加权轮询(Weighted Round Robin):“加权轮询”调度算法是根据 RealServer 的不同处理能力来调度访问请求。可以对每台 RealServer 设置不同的调度权值,对于性能相对较好的 RealServer 可以设置较高的权值,而对于处理能力较弱的 RealServer,可以设置较低的权值,这样保证了处理能力强的服务器处理更多的访问流量。充分合理的利用了服务器资源。同时,调度器还可以自动查询 RealServer 的负载情况,并动态地调整其权值。
  • 最少链接(Least Connections):“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用“最小连接”调度算法可以较好地均衡负载。
  • 加权最少链接(Weighted Least Connections):“加权最少链接调度”是“最少连接调度”的超集,每个服务节点可以用相应的权值表示其处理能力,而系统管理员可以动态的设置相应的权值,缺省权值为 1,加权最小连接调度在分配新连接请求时尽可能使服务节点的已建立连接数和其权值成正比。
  • 基于局部性的最少链接(Locality-Based Least Connections):”基于局部性的最少链接”调度算法是针对目标 IP 地址的负载均衡,目前主要用于 Cache 集群系统。该算法根据请求的目标 IP 地址找出该目标 IP 地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用”最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。
  • 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication):”带复制的基于局部性最少链接”调度算法也是针对目标 IP 地址的负载均衡,目前主要用于 Cache 集群系统。它与 LBLC 算法的不同之处是它要维护从一个目标 IP 地址到一组服务器的映射,而 LBLC 算法维护从一个目标 IP 地址到一台服务器的映射。该算法根据请求的目标 IP 地址找出该目标 IP 地址对应的服务器组,按”最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按”最小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。
  • 目标地址散列(Destination Hashing):”目标地址散列”调度算法根据请求的目标 IP 地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
  • 源地址散列(Source Hashing):”源地址散列”调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

参考链接:

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注