lvs安装使用 lvs 配置详解

linux virtual server简称LVS，Internet的快速增长使多媒体网络服务器面对的访问数量快速增加，服务器需要具备提供大量并发访问服务的能力，因此对于大负载的服务器来讲， CPU、I/O处理能力很快会成为瓶颈。由于单台服务器的性能总是有限的，简单的提高硬件性能并不能真正解决这个问题。为此，必须采用多服务器和负载均衡技术才能满足大量并发访问的需要。Linux 虚拟服务器(Linux Virtual Servers,LVS) 使用负载均衡技术将多台服务器组成一个虚拟服务器。它为适应快速增长的网络访问需求提供了一个负载能力易于扩展，而价格低廉的解决方案。lvs的负载能力特别强，优化空间特别大，lvs的变种DPVS据说是lvs性能的几倍，由爱奇艺开发，并广泛用于爱奇艺IDC。其他负载均衡服务器还有nginx，haproxy，F5，Netscale。

一、LVS基本原理

1. 当用户向负载均衡调度器（Director Server）发起请求，调度器将请求发往至内核空间。
2. PREROUTING链首先会接收到用户请求，判断目标IP确定是本机IP，将数据包发往INPUT链。
3. IPVS是工作在INPUT链上的，当用户请求到达INPUT时，IPVS会将用户请求和自己已定义好的集群服务进行比对，如果用户请求的就是定义的集群服务，那么此时IPVS会强行修改数据包里的目标IP地址及端口，并将新的数据包发往POSTROUTING链。
4. POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器，那么此时通过选路，将数据包最终发送给后端的服务器。

二、LVS组成

LVS 由2部分程序组成，包括 ipvs 和 ipvsadm。

1. IPVS(ip virtual server)：一段代码工作在内核空间，叫IPVS，是真正生效实现调度的代码。IPVS的总体结构主要由IP包处理、负载均衡算法、系统配置与管理三个模块及虚拟服务器与真实服务器链表组成。
2. ipvsadm：另外一段是工作在用户空间，叫ipvsadm，即IPVS管理器，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)。

三、LVS技术术语

1. DS：Director Server。指的是前端负载均衡器节点。
2. RS：Real Server。后端真实的工作服务器。
3. VIP：Virtual IP，向外部直接面向用户请求，作为用户请求的目标的IP地址。
4. DIP：Director Server IP，主要用于和内部主机通讯的IP地址。
5. RIP：Real Server IP，后端服务器的IP地址。
6. CIP：Client IP，访问客户端的IP地址。

四、LVS工作模式和原理

4.1 NAT模式

4.1.1 NAT模式工作原理

1. 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP。
2. PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链。
3. IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP，然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP。
4. POSTROUTING链通过选路，将数据包发送给Real Server
5. Real Server比对发现目标为自己的IP，开始构建响应报文发回给Director Server。 此时报文的源IP为RIP，目标IP为CIP。
6. Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。 此时报文的源IP为VIP，目标IP为CIP。

4.1.2 NAT特性

• RIP最好是内网IP
• RS的网关必须指向DIP。
• DIP和RIP必须在同一个网段内。
• 请求和回应的报文都必须经过director，director容易成为瓶颈。
• nat支持端口转发。

4.2 DR模式

4.2.1 DR模式工作原理

1. 首先用户用CIP请求VIP。
2. 根据上图可以看到,不管是Director Server还是Real Server上都需要配置相同的VIP,那么当用户请求到达我们的集群网络的前端路由器的时候,请求数据包的源地址为CIP目标地址为VIP,此时路由器会发广播问谁是VIP,那么我们集群中所有的节点都配置有VIP,此时谁先响应路由器那么路由器就会将用户请求发给谁,这样一来我们的集群系统是不是没有意义了,那我们可以在网关路由器上配置静态路由指定VIP就是Director Server,或者使用一种机制不让Real Server 接收来自网络中的ARP地址解析请求,这样一来用户的请求数据包都会经过Director Servrer。
3. 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP。
4. PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链。
5. IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址
6. 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。
7. RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP
8. 响应报文最终送达至客户端。

4.2.2 配置DR有三种方式：

第一种方式：
在路由器上明显说明vip对应的地址一定是Director上的MAC，只要绑定，以后再跟vip通信也不用再请求了，这个绑定是静态的，所以它也不会失效，也不会再次发起请求，但是有个前提，我们的路由设备必须有操作权限能够绑定MAC地址，万一这个路由器是运行商操作的，我们没法操作怎么办？第一种方式固然很简便，但未必可行。

第二种方式：
在给别主机上（例如：红帽）它们引进的有一种程序arptables,它有点类似于iptables,它肯定是基于arp或基于MAC做访问控制的，很显然我们只需要在每一个real server上定义arptables规则，如果用户arp广播请求的目标地址是本机的vip则不予相应，或者说相应的报文不让出去，很显然网关（gateway）是接受不到的，也就是director相应的报文才能到达gateway，这个也行。第二种方式我们可以基于arptables。

第三种方式：
在相对较新的版本中新增了两个内核参数(kernelparameter)，第一个是arp_ignore定义接受到ARP请求时的相应级别;第二个是arp_announce定义将自己地址向外通告时的通告级别。【提示：很显然我们现在的系统一般在内核中都是支持这些参数的，我们用参数的方式进行调整更具有朴实性，它还不依赖于额外的条件，像arptables,也不依赖外在路由配置的设置，反而通常我们使用的是第三种配置】

arp_ignore:定义接受到ARP请求时的相应级别

0： 只要本地配置的有相应地址，就给予响应。（默认）

1： 仅回应目标IP地址是本地的入网地址的arp请求。

2： 仅回应目标IP地址是本地的入网地址，而且源IP和目标IP在同一个子网的arp请 求。

3： 不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应

4-7：保留未使用

8： 不回应所有的arp请求。

arp_announce：定义将自己地址向外通告是的通告级别

0: 将本地任何接口上的任何地址向外通告

1： 试图仅向目标网络通告与其网络匹配的地址

2： 仅向与本地接口上地址匹配的网络进行通告

4.2.3 DR特性

• 特点1：保证前端路由将目标地址为VIP报文统统发给Director Server，而不是RS。
• Director和RS的VIP为同一个VIP。
• RS可以使用私有地址；也可以是公网地址，如果使用公网地址，此时可以通过互联网对RIP进行直接访问。
• RS跟Director Server必须在同一个物理网络中。 所有的请求报文经由Director Server，但响应报文必须不能进过Director Server。
• 不支持地址转换，也不支持端口映射
• RS可以是大多数常见的操作系统
• RS的网关绝不允许指向DIP(因为我们不允许他经过director)
• RS上的lo接口配置VIP的IP地址
• DR模式是市面上用得最广的。
• 缺陷：RS和DS必须在同一机房中

补充：特点1的解决方法

• 在前端路由器做静态地址路由绑定，将对于VIP的地址仅路由到Director Server。存在问题：用户未必有路由操作权限，因为有可能是运营商提供的，所以这个方法未必实用。
• arptables：在arp的层次上实现在ARP解析时做防火墙规则，过滤RS响应ARP请求。这是由iptables提供的。
• 修改RS上内核参数（arp_ignore和arp_announce）将RS上的VIP配置在lo接口的别名上，并限制其不能响应对VIP地址解析请求。

4.3 Tunnel模式

4.3.1 Tunnel模式工作原理

• 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP 。
• PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链。
• IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为为DIP，目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP，目标IP为RIP。
• POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输）。 此时源IP为DIP，目标IP为RIP。
• RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的lo接口VIP，那么此时RS开始处理此请求，处理完成之后，通过lo接口送给eth0网卡，然后向外传递。 此时的源IP地址为VIP，目标IP为CIP
• 响应报文最终送达至客户端

4.3.2 Tunnel模式特性

• RIP、VIP、DIP全是公网地址。
• RS的网关不会也不可能指向DIP
• 所有的请求报文经由Director Server，但响应报文必须不能进过Director Server
• 不支持端口映射
• RS的系统必须支持隧道

五、LVS的调度算法

固定调度算法：rr，wrr，dh，sh

动态调度算法：wlc，lc，lblc，lblcr

固定调度算法：即调度器不会去判断后端服务器的繁忙与否，一如既往得将请求派发下去。

动态调度算法：调度器会去判断后端服务器的繁忙程度，然后依据调度算法动态得派发请求。

5.1 rr：轮询（round robin）

这种算法是最简单的，就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是简单。轮询算法假设所有的服务器处理请求的能力都是一样的，调度器会将所有的请求平均分配给每个真实服务器，不管后端 RS 配置和处理能力，非常均衡地分发下去。这个调度的缺点是，不管后端服务器的繁忙程度是怎样的，调度器都会讲请求依次发下去。如果A服务器上的请求很快请求完了，而B服务器的请求一直持续着，将会导致B服务器一直很忙，而A很闲，这样便没起到均衡的左右。

5.2 wrr：加权轮询（weight round robin）

这种算法比 rr 的算法多了一个权重的概念，可以给 RS 设置权重，权重越高，那么分发的请求数越多，权重的取值范围 0 – 100。主要是对rr算法的一种优化和补充， LVS 会考虑每台服务器的性能，并给每台服务器添加要给权值，如果服务器A的权值为1，服务器B的权值为2，则调度到服务器B的请求会是服务器A的2倍。权值越高的服务器，处理的请求越多。

5.3 dh：目标地址散列调度算法 （destination hash）

简单的说，即将同一类型的请求分配给同一个后端服务器，例如将以 .jgp、.png等结尾的请求转发到同一个节点。这种算法其实不是为了真正意义的负载均衡，而是为了资源的分类管理。这种调度算法主要应用在使用了缓存节点的系统中，提高缓存的命中率。

5.4 sh：源地址散列调度算法（source hash）

即将来自同一个ip的请求发给后端的同一个服务器，如果后端服务器工作正常没有超负荷的话。这可以解决session共享的问题，但是这里有个问题，很多企业、社区、学校都是共用的一个IP，这将导致请求分配的不均衡。

5.5 lc：最少连接数（least-connection）

这个算法会根据后端 RS 的连接数来决定把请求分发给谁，比如 RS1 连接数比 RS2 连接数少，那么请求就优先发给 RS1。这里问题是无法做到会话保持，即session共享。

5.6 wlc：加权最少连接数（weight least-connection）

这个比最少连接数多了一个加权的概念，即在最少连接数的基础上加一个权重值，当连接数相近，权重值越大，越优先被分派请求。

5.7 lblc：基于局部性的最少连接调度算法（locality-based least-connection）

将来自同一目的地址的请求分配给同一台RS如果这台服务器尚未满负荷，否则分配给连接数最小的RS，并以它为下一次分配的首先考虑。

5.8 lblcr：基于地址的带重复最小连接数调度 (Locality-Based Least-Connection with Replication)

这个用得少，可以略过。