应用负载均衡之LVS(一)：基本概念和三种模式

共计 6570 个字符，预计需要花费 17 分钟才能阅读完成。

本文目录：
1. LVS 简介
2. LVS-ipvs 三种模式的工作原理
2.1 VS/NAT 模式
2.2 VS/TUN 模式
2.3 VS/DR 模式
2.4 lvs-ipvs 的三种模式比较
3. VS/TUN 和 VS/DR 模式中的 ARP 问题
4. LVS 负载均衡的调度算法

网站架构中，负载均衡技术是实现网站架构 伸缩性 的主要手段之一。所谓 ” 伸缩性 ”，是指可以不断向集群中添加新的服务器来提升性能、缓解不断增加的并发用户访问压力。通俗地讲，就是一头牛拉不动时，就用两头、三头、更多头牛来拉。

负载均衡有好几种方式：http URL 重定向、DNS 的 A 记录负载均衡、反向代理负载均衡、IP 负载均衡和链路层负载。本文所述为 LVS，它的 VS/NAT 和 VS/TUN 模式是 IP 负载均衡的优秀代表，而它的 VS/DR 模式则是链路层负载均衡的优秀代表。

1.LVS 简介

LVS 中文官方手册：http://www.linuxvirtualserver.org/zh/index.html。这个手册对于了解 lvs 的背景知识很有帮助。

LVS 英文官方手册：http://www.linuxvirtualserver.org/Documents.html。这个手册比较全面，对于了解和学习 lvs 的原理、配置很有帮助。

LVS 是章文嵩开发的一个国产开源负载均衡软件。LVS 最初是他在大学期间的玩具，随着后来使用的用户越来越多，LVS 也越来越完善，最终集成到了 Linux 的内核中。有不少开源牛人都为 LVS 开发过辅助工具和辅助组件，最出名的就是 Alexandre 为 LVS 编写的 Keepalived，它最初专门用于监控 LVS，后来加入了通过 VRRP 实现高可用的功能。

LVS 的全称是 Linux virtual server，即 Linux 虚拟服务器。之所以是虚拟服务器，是因为 LVS 自身是个负载均衡器(director)，不直接处理请求，而是将请求转发至位于它后端真正的服务器 realserver 上。

LVS 是四层 (传输层 tcp/udp)、七层(应用层) 的负载均衡工具，只不过大众一般都使用它的四层负载均衡功能 ipvs，而七层的内容分发负载工具 ktcpvs(kernel tcp virtual server)不怎么完善，使用的人并不多。

ipvs 是集成在内核中的框架，可以通过用户空间的程序 ipvsadm 工具来管理，该工具可以定义一些规则来管理内核中的 ipvs。就像 iptables 和 netfilter 的关系一样。

2.LVS-ipvs 三种模式的工作原理

首先要解释的是 LVS 相关的几种 IP：

• VIP:virtual IP，LVS 服务器上接收外网数据包的网卡 IP 地址。
• DIP:director IP，LVS 服务器上转发数据包到 realserver 的网卡 IP 地址。
• RIP:realserver(常简称为 RS)上接收 Director 转发数据包的 IP，即提供服务的服务器 IP。
• CIP: 客户端的 IP。

LVS 的三种工作模式：通过网络地址转换 (NAT) 将一组服务器构成一个高性能的、高可用的虚拟服务器，是 VS/NAT 技术。在分析 VS/NAT 的缺点和网络服务的非对称性的基础上，提出了通过 IP 隧道实现虚拟服务器的方法 VS/TUN（Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法 VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。

2.1 VS/NAT 模式

客户端发送的请求到达 Director 后，Director 根据负载均衡算法改写目标地址为后端某个 RIP(web 服务器池中主机之一)并转发给该后端主机，就像 NAT 一样。当后端主机处理完请求后，后端主机将响应数据交给 Director，并由 director 改写源地址为 VIP 后传输给客户端。大多数商品化的 IP 负载均衡硬件都是使用此方法，如 Cisco 的 LocalDirector、F5 的 Big/IP。

这种模式下：

1. RIP 和 DIP 一般处于同一私有网段中。但并非必须，只要它们能通信即可。
2. 各 RealServer 的网关指向 DIP，这样能保证将响应数据交给 Director。
3. VS/NAT 模式的最大缺点是 Director 负责所有进出数据：不仅处理客户端发起的请求，还负责将响应传输给客户端。而响应数据一般比请求数据大得多，调度器 Director 容易出现瓶颈。
4. 这种模式配置起来最简单。

2.2 VS/TUN 模式

采用 NAT 技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报文通过 IP 隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务响应报文比请求报文大许多，采用 VS/TUN 技术后，调度器得到极大的解放，集群系统的最大吞吐量可以提高 10 倍。

VS/TUN 模式的工作原理：

• (1)IP 隧道技术又称为 IP 封装技术，它可以将带有源和目标 IP 地址的数据报文使用新的源和目标 IP 进行第二次封装，这样这个报文就可以发送到一个指定的目标主机上；
• (2)VS/TUN 模式下，调度器和后端服务器组之间使用 IP 隧道技术。当客户端发送的请求 (CIP–>VIP) 被 director 接收后，director 修改该报文，加上 IP 隧道两端的 IP 地址作为新的源和目标地址，并将请求转发给后端被选中的一个目标；
• (3)当后端服务器接收到报文后，首先解封报文得到原有的 CIP–>VIP，该后端服务器发现自身的 tun 接口上配置了 VIP，因此接受该数据包。
• (4)当请求处理完成后，结果将不会重新交给 director，而是直接返回给客户端；在后端服务器返回给客户端数据包时，由于使用的是普通网卡接口，根据一般的路由条目，源 IP 地址将是该网卡接口上的地址，例如是 RIP。因此，要让响应数据包的源 IP 为 VIP，必须添加一条特殊的路由条目，明确指定该路由的源地址是 VIP。

采用 VS/TUN 模式时的基本属性和要求：

1. RealServer 的 RIP 和 director 的 DIP 不用处于同一物理网络中，且 RIP 必须可以和公网通信。也就是说集群节点可以跨互联网实现。
2. realserver 的 tun 接口上需要配置 VIP 地址，以便接收 director 转发过来的数据包，以及作为响应报文的源 IP。
3. director 给 realserver 时需要借助隧道，隧道外层的 IP 头部的源 IP 是 DIP，目标 IP 是 RIP。而 realsever 响应给客户端的 IP 头部是根据隧道内层的 IP 头分析得到的，源 IP 是 VIP，目标 IP 是 CIP。这样客户端就无法区分这个 VIP 到底是 director 的还是服务器组中的。
4. 需要添加一条特殊的路由条目，使得后端服务器返回响应给客户端时的源 IP 为 VIP。
5. director 只处理入站请求，响应请求由 realserver 完成。

一般来说，VS/TUN 模式会用来负载调度缓存服务器组，这些缓存服务器一般放置在不同网络环境，可以就近返回数据给客户端。在请求对象不能在 Cache 服务器本地命中的情况下，Cache 服务器要向源服务器发请求，将结果取回，最后将结果返回给客户。

2.3 VS/DR 模式

VS/TUN 模式下，调度器对数据包的处理是使用 IP 隧道技术进行二次封装。VS/DR 模式和 VS/TUN 模式很类似，只不过调度器对数据包的处理是改写数据帧的目标 MAC 地址，通过链路层来负载均衡。

VS/DR 通过改写请求报文的目标 MAC 地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同 VS/TUN 技术一样，VS/DR 技术可极大地提高集群系统的伸缩性。这种方法没有 IP 隧道的开销，对集群中的真实服务器也没有必须支持 IP 隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同一物理网段上，以便使用 MAC 地址通信转发数据包。

VS/DR 模式的工作原理：

• (1)客户端发送的请求被 director 接收后，director 根据负载均衡算法，改写数据帧的目标 MAC 地址为后端某 RS 的 MAC 地址，并将该数据包转发给该 RS(实际上是往整个局域网发送，但只有该 MAC 地址的 RS 才不会丢弃)。
• (2)RS 接收到数据包后，发现数据包的目标 IP 地址为 VIP，而 RS 本身已经将 VIP 配置在了某个接口上，因此 RS 会接收下这个数据包并进行处理。
• (3)处理完毕后，RS 直接将响应报文响应给客户端。在返回给客户端的时候，由于实用的是普通网卡接口，根据一般的路由条目，源 IP 地址将是该网卡接口上的地址，例如 RIP。因此，要让响应数据包的源 IP 为 VIP，需要添加一条特殊的路由条目，明确指定该路由的源地址为 VIP。

也就是说，客户端请求发送到 LB 上，源和目标 IP 为 CIP:VIP，LB 上有 VIP 和 DIP，重新改写 MAC 地址后通过 DIP 发送给某个 realserver，如 RS1，此时源和目标 IP 还是 CIP:VIP，但是目标 MAC 地址改写为 RIP1 所在网卡的 MAC 地址 ”RS1_MAC”，RS1 发现自身有 VIP 地址，所以收下此数据报文(所以在 RS 上必须配置 VIP)。返回时，RS1 根据路由表直接返回给客户端，此时，源和目标 IP 是 VIP:CIP。

采用 VS/DR 模式时的基本属性和要求：

1. RealServer 的 RIP 和 director 的 DIP 必须处于同一网段中，以便使用 MAC 地址进行通信。
2. realserver 上必须配置 VIP 地址，以便接收 director 转发过来的数据包，以及作为响应报文的源 IP。
3. realsever 响应给客户端的数据包的源和目标 IP 为 VIP–>CIP。
4. 需要添加一条特殊的路由条目，使得后端服务器返回响应给客户端时的源 IP 为 VIP。
5. director 只处理入站请求，响应请求由 realserver���成。

2.4 lvs-ipvs 的三种模式比较

三种模式的比较如图所示：

在性能上，VS/DR 和 VS/TUN 远高于 VS/NAT，因为调度器只处于从客户到服务器的半连接中，按照半连接的 TCP 有限状态机进行状态迁移，极大程度上减轻了调度器的压力。VS/DR 性能又稍高于 VS/TUN，因为少了隧道的开销。但是，VS/DR 和 VS/TUN 的主要区别是 VS/TUN 可以跨网络实现后端服务器负载均衡(也可以局域网内)，而 VS/DR 只能和 director 在局域网内进行负载均衡。

3.VS/TUN 和 VS/DR 模式中的 ARP 问题

在【【VS/TUN 和 VS/DR 的 arp 问题】】中非常详细地分析了 ARP、arp_ignore 和 arp_announce 相关原理和设置方法。此处简单说明为何需要设置 arp 抑制以及设置 arp 抑制的方法。

当一个目标 IP 地址为 VIP 的数据包进入 Director 前端的路由器时，路由器会向局域网内发送 ARP 广播，以找出 VIP 地址的 MAC 地址在哪台主机上。

Director 和各 RS 都配置了 VIP。当路由器发送 ARP 广播后，Director 和 RS 都会收到这个广播包，且都认为这个广播包找的就是自己，于是都回应给路由器，这样路由器上的 ARP 缓存表中的条目 VIP<-->vip_MAC 就不断被覆盖直到最后一个回应。这样一来，路由器将把客户端的数据包发送给最后一个回应的主机，这台主机的 VIP 可能是 Director 上的，也可能是某个 RS 上的。在一定时间内，路由器收到目标 IP 为 VIP 的数据包都会发送给该主机。但路由器会定时发送 ARP 广播包，这样一来 ARP 缓存表中的 VIP 对应的 MAC 地址可能会换成另一台主机。

因此，必须要保证路由器只保存 Director 上 VIP 对应的 MAC 地址，即只允许 Director 才对路由器的 ARP 广播进行回应。也就是说，所有 RS 上的 VIP 必须隐藏起来。

一般通过将 Real Server 上的 VIP 设置在 lo 接口的别名接口上 (如 lo:0)，并设置arp_ignore=1 和arp_announce=2的方式来隐藏 RS 上的 VIP。至于 VIP 为何要设置在 lo 接口上以及为何要这样设置这两个 arp 参数，请参看【【VS/TUN 和 VS/DR 的 arp 问题】】，内容非常详细。

echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/all/arp_announce
或者

sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2
或者将 arp 参数设置到内核参数配置文件中以让其永久生效。

echo “net.ipv4.conf.all.arp_ignore=1” >>/etc/sysctl.conf
echo “net.ipv4.conf.all.arp_announce=2” >>/etc/sysctl.conf
sysctl -p
在网上几乎所有文章还设置了 lo 接口上的 arp 参数：

echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/lo/arp_announce
但这没有任何意义，因为从 lo 接口不受 arp 参数的影响。

应该在配置 VIP 之前就设置 arp 参数，以防止配置 VIP 后、设置 arp 抑制之前被外界主机发现。

4.LVS 负载均衡的调度算法

LVS 的调度算法，详细内容见官方手册：http://www.linuxvirtualserver.org/zh/lvs4.html。

IPVS 在内核中的负载均衡调度是 以连接为粒度 的。在 HTTP 协议（非持久）中，每次从 WEB 服务器上获取资源都需要建立一个 TCP 连接，同一用户的不同请求会被调度到不同的服务器上，所以这种细粒度的调度在一定程度上可以避免单个用户访问的突发性引起服务器间的负载不平衡。

LVS 分为两种调度方式：静态调度和动态反馈调度。

静态调度方式是指不管 RS 的繁忙程度，根据调度算法计算后轮到谁就调度谁。例如两台 realserver，一开始双方都在处理 500 个连接，下一个请求到来前，server1 只断开了 10 个，而 server2 断开了 490 个，但是此时轮到了 server1，就会调度 server1 而不管繁忙的程度。

动态调度方式是指根据 RS 的繁忙程度反馈，计算出下一个连接应该调度谁(动态反馈负载均衡算法考虑服务器的实时负载和响应情况，不断调整服务器间处理请求的比例，来避免有些服务器超载时依然收到大量请求，从而提高整个系统的吞吐率)。

在内核中的连接调度算法上，IPVS 已实现了以下八种调度算法：默认的算法为 wlc。

• 静态调度：
  • 轮叫调度（Round-Robin Scheduling,rr）
  • 加权轮叫调度（Weighted Round-Robin Scheduling,wrr），按照权重比例作为轮询标准
  • 目标地址散列调度（Destination Hashing Scheduling,dh），目标地址哈希，对于同一目标 IP 的请求总是发往同一服务器
  • 源地址散列调度（Source Hashing Scheduling,sh），源地址哈希，在一定时间内，只要是来自同一个客户端的请求，就发送至同一个 realserver
• 动态反馈调度：
  • 最小连接调度（Least-Connection Scheduling,lc），调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某服务器，其连接数加 1；当连接中止或超时，其连接数减 1。当各个服务器的处理能力不同时，该算法不理想。
  • 加权最小连接调度（Weighted Least-Connection Scheduling,wlc）
  • 基于本地的最少连接（Locality-Based Least Connections Scheduling,lblc），目前该算法主要用于 cache 集群系统。
  • 带复制的基于局部性最少连接（Locality-Based Least Connections with Replication Scheduling,lblcr），目前主要用于 Cache 集群系统。

本文永久更新链接地址：https://www.linuxidc.com/Linux/2018-02/150977.htm