背景与功能

LVS全称为Linux Virtual Server，是国内常见的Load-Balance工具软件。除了能够在常见的UDP，TCP等OIS-4层协议上实现LB外，它也能为提供FTP、HTTP等典型应用层协议提供LB功能。

相比F5等硬件Load-Balance工具，它不需要专门的硬件工具；对比于Nginx等代理，LVS所有工作都在内核态运行，不涉及数据拷贝和内核态/用户态切换，性能是其最大的优势。

LVS的核心包括IPVS模块、KTCPVS模块以及一些其他集群管理模块：

  • IPVS:一款基于IP、端口的报文转发工具，已经被集成至Linux内核之中。
  • KTCPVS:提供应用层流量转发功能。

因为其性能的优异性，目前使用最多的便是基于IPVS构建的LVS系统。本文主要阐述IPVS系统的原理以及LVS系统基本搭建方式。

IPVS系统原理

netfilter/iptables简介

netfilter/iptables属于Linux内核的一部分，它提供了一整套API可供用户自定义对于IP报文的处理方式，用户可以通过这一模块自由组合IP报文的处理方式，实现Linux防火墙功能。

iptables-chain

数据包在netfilter/iptables中的流转如上图所示，一共有6个阶段用户可以通过注册回调函数的方式对数据包进行处理。每一个阶段都有对应的链表用于存储所有规则，IP报文将根据链表顺序依次经过每一个规则。因此，在不丢弃数据包的情况下，一个用于转发的ip报文将根据上图依次流经PreRouting、Forward、PostRouting，经过所有规则处理后再流转出去。

随着业务的增加，iptables对于报文处理的链条可能会变得很长，为了便于组织，iptables根据规则的用途对其进行了聚类。所有规则都根据自身通途被放到了4个table中，这也就是名称中table的由来。

表名 功能 涉及阶段
Filter(Default) 过滤IP报文 FORWARD、INPUT、OUTPUT
Nat 转发IP报文 PREROUTING、POSTROUTING、OUTPUT
Mangle 对IP报文进行修改和处理 PREROUTING、POSTROUTING、INPUT、OUTPUT、FORWARD
Raw(后续加入) 决定数据包是否被跟踪机制处理 OUTPUT、PREROUTING

IP报文在整个netfilter/iptables模块流转如下图

iptables-full-chain

iptables的不足

随着路由规则的逐渐增多，iptables会慢慢显现出它的先天不足：由于iptables采用链表来组织规则列表，每个IP报文将流经链表中每一项的处理，即使对其产生作用的只有一项或很少的几项。最典型的例子便是用作网关路由转发，如果集群内部存在成千上万的服务端口需要在网关server的iptables上配置路由转发规则，那么网关server的iptables chain将到达数千甚至数万的长度，任何IP通过iptables时都会在每个规则处判断一次，但是其中只有一条规则是用来处理该IP报文的。因此，iptables在大规模集群的情况下转发IP报文的效率不够高。

iptables引入了ipset来解决IP报文的匹配问题。简单来说，用户可以通过ipset创建一个包含ip或者端口的集合，然后以这个集合作为iptables规则链的判断条件，如果IP报文满足ipset条件，iptables则执行对应的操作。通过引入Set这一数据结构，iptables可以将match操作的时间复杂度从O(N)变为O(1)。但是ipset常用于Filter模块，无法用于Nat转发模块。

作为一个防火墙模块，iptables对于IP报文的处理相对简单，缺乏轮询，加权轮询，最短连接等负载均衡算法的支持。

IPVS

IPVS通过向INPUT阶段的规则链中注册回调函数，解决iptables/netfilter模块上述两个缺点，从而实现高效率、功能完备的LoadBalance功能。

IPVS

  • 当用户访问www.sina.com.cn时，DNS会将此域名解析为一个Virtual IP，指向LVS server
  • 数据包进入Server后，通过物理层、数据链路层等层层递进，达到iptables模块中
  • 进入PREROUTING后，Server发现报文中的VIP指向本机，于是将这个报文丢入INPUT chain中
  • 当IP报文进入IPVS处理逻辑时，IPVS首先会根据VIP+Port判断此数据包是否需要进行转发，经过确认后将根据预设算法选出对该数据包进行实际处理的RealServer，随后将数据包进行修改，不经过应用程序以及OUTPUT链，直接丢入POSTROUTING中
  • POSTROUTING收到数据包后将根据数据包的信息通过路由选路，最终将数据包发到选中的RealServer上。

根据路由转发规则的不同，开源LVS有三种工作模式，分别适用于不同场景：

  • DirectRouting 模式
  • NAT 模式
  • Tunnel 模式

DR模式

lvs-dr

如上图所示，lvs-DR模式工作原理如下

  1. 数据包从客户端处经过层层转发至LVS-Server处，此时数据包的源IP为客户端IP地址，目的IP为LVS-Server服务器IP地址，源MAC地址为路由器MAC地址，目的MAC地址为LVS-Server的MAC地址。
  2. LVS-Server对发向虚IP的数据包做一定处理：根据负载均衡算法得到一个真正负载请求的RealServer，并 将数据包的目标MAC地址变为RealServer的MAC地址，并将数据包发给RealServer。此时数据包的源IP地址与目的IP地址都未修改，源MAC地址变为LVS-Server与RealServer相通网卡的MAC地址，目的MAC地址变为RealServer的MAC地址。
  3. RealServer接收并处理请求，回应将被直接发送给Client。具体IP与MAC情况请见上图。

DR模式的核心原理便是通过修改IP报文MAC地址，使请求报文根据负载均衡算法将请求分摊至多个RealServer上。 DR模式最大的优点便是性能高:所有的响应数据由RealServer直接返回给Client，整个系统最大的瓶颈LVS-Server只需要处理请求数据，而且通常来说请求的数据是远小于响应数据的，使用DR模式的LVS系统整体性能最优。 由于数据转发是通过修改MAC地址实现，因此LVS-DR模式最大的缺点在于限制了LVS-Server必须与RealServer处于同一交换机环境中。

NAT模式

LVS的NAT模式可以简单认为就是iptables路有规则的增强版，其完全运行于ip层之上，通过修改源IP与目的IP的方式实现负载均衡转发。最关键的改进在于查找路由规则时将iptables原本O(n)的链式判断变为了Map O(1)级别，加快了转发的效率。

NAT 模式双向流量都经过 LVS，因此 NAT 模式性能会存在一定的瓶颈。不过与其它模式区别的是，NAT 支持端口映射，且支持 windows 操作系统。

Tunnel模式

Tunnel模式结合了NAT模式与DR模式的优点，通过在IP报文外面再包裹一层的方式使得转发突破了DR模式下只能同一物理网络部署的限制，同时可以实现NAT模式的端口转发功能；由于响应报文不会再次经过LVS服务器，因此Tunnel模式理论上可以达到接近DR的性能水平。

Tunnel 模式具备 DR 模式的高性能，又支持跨机房访问，听起来比较完美了。不过国内运营商有一定特色性，比如 RS 的响应数据包的源 IP 为 VIP，VIP 与后端服务器有可能存在跨运营商的情况，有可能被运营商的策略封掉。Tunnel 在生产环境确实没有使用过，在国内推行 Tunnel 可能会有一定的难度。

keepalived

作为与LVS搭配使用的组件，keepalived保证了LVS系统下的高可用性：

1.LVS 服务器本身的高可用性 2.后端多台RS的故障嗅探，实时从集群中移除无法正常工作的RS，待其正常后再次加入负载均衡集群

VRRP

keepalived服务器本身的高可用性是通过VRRP协议实现的：一组高可用服务器将被划分至同一个虚拟广播网段中，该网段可通过vrid进行区分，且通过认证协议进行身份校验。一组高可用服务器中只会存在一个MASTER节点，其他都是冗余BACKUP节点，每个节点有两个关键值，分别是priority以及state，当多台服务器都处于正常工作状态时，总是priority以MASTER身份工作，如果两台及以上服务器的priority相同，则根据state预设值进行区分。集群中的Master节点会不断向所有节点发送广播表明自己存活，当BACKUP节点一段时间没有收到MASTER节点的广播时，则认为MASTER已经失效了，于是按照预设规则进行选举，另起一个新的Master。

当MASTER恢复后，又会通过广播接管整个集群，如下图所示 ![keepavlived-master-recovery]lvs-dr

故障嗅探

keepalived的RS故障嗅探功能与其他网关基本一致，通过轮询的方式验证下游服务是否存活，并动态移除非活跃服务/增加活跃服务。它提供的嗅探方式包括：TCP,HTTP,SSL,MISC。