LVS是Linux virtual server的缩写，为linux虚拟服务器，是一个虚拟的服务器集群系统。LVS简单工作原理为用户请求LVS VIP，LVS根据转发方式和算法，将请求转发给后端服务器，后端服务器接收到请求，返回给用户。对于用户来说，看不到Web后端具体的应用。
1. LVS负载均衡简介
可伸缩网络服务有很多结构，但都有一个共同点：它们都需要一个前端的负载调度器。而实现虚拟网络服务的主要技术指出IP负载均衡技术是在负载调度器的实现技术里面效率最高的一个。
在已有的IP负载均衡技术中，主要有通过网络地址转换将一组服务器构成一个高性能的、高可用的虚拟服务器，通常称为VS/NAT技术。在分析VS/NAT的缺点和网络服务的非对称的基础上，可以通过IP隧道实现虚拟服务器的方法VS/TUN和通过直接路由实现虚拟服务器的方法VS/DR，它们可以极大地提高系统的伸缩性。(摘自 LINUX企业运维实战一书中)
2. LVS结构
LVS集群分为三层结构：
- 负载调度器(Load Blancer):是整个LVS集群对外的前端机器，负责敬爱嗯client的请求发送到一组服务器【多台 LB IP】上执行，而client则认为返回来是同一个IP(通常把这个IP成为虚拟ip或VIP)
- 服务器池(server pool):一组真正执行clinet请求的服务器，一般是web服务器；除了web，还有FTP、MAIL、DNS等
- 共享存储(shared stord):它为server pool提供了一个共享的存储区，很容易让服务器池拥有相同的内容，提供相同的服务
3. LVS相关术语
- DS：Director Server。指的是前端负载均衡器节点
- RS：Real Server。后端真实的工作服务器
- VIP：向外部直接面向用户请求，作为用户请求的目标的IP地址
- DIP：Director Server IP，主要用于和内部主机通讯的IP地址
- RIP：Real Server IP，后端服务器的IP地址
- CIP：Client IP，访问客户端的IP地址
4. LVS负载均衡工作原理
4.1 LVS DR模式
LVS DR原理详解图
4.1.1 LVS DR原理
- 当客户端请求 www.sina.com.cn 主页，请求数据包穿过网络到达 Sina 的 LVS 服务器网卡：源 IP 是客户端 IP 地址 CIP ，目的 IP 是新浪对外的服务器 IP 地址，也就是 VIP ；此时源 MAC 地址是 CMAC ，其实是 LVS 连接的路由器的 MAC 地址（为了容易理解记为 CMAC），目标 MAC 地址是 VIP 对应的 MAC，记为 VMAC 。
- 数据包经过链路层到达 PREROUTING 位置（刚进入网络层），查找路由发现目的 IP 是 LVS 的 VIP ，就会递送到 INPUT 链上，此时数据包 MAC、IP、Port 都没有修改。
- 数据包到达 INPUT 链，INPUT 是 LVS 主要工作的位置。此时 LVS 会根据目的 IP 和 Port 来确认是否是 LVS 定义的服务，如果是定义过的 VIP 服务，就会根据配置信息，从真实服务器列表 中选择一个作为 RS1，然后以 RS1 作为目标查找 Out 方向的路由，确定一下跳信息以及数据包要通过哪个网卡发出。最后将数据包投递到 OUTPUT 链上。
- 数据包通过 POSTROUTING 链后，从网络层转到链路层，将目的 MAC 地址修改为 RealServer 服务器 MAC 地址，记为 RMAC ；而源 MAC 地址修改为 LVS 与 RS 同网段的 selfIP 对应的 MAC 地址，记为 DMAC 。此时，数据包通过交换机转发给了 RealServer 服务器（注： 为了简单图中没有画交换机 ）。
- 请求数据包到达后端真实服务器后，链路层检查目的 MAC 是自己网卡地址。到了网络层，查找路由，目的 IP 是 VIP（lo 上配置了 VIP），判定是本地主机的数据包，经过协议栈拷贝至应用程序（比如 nginx 服务器），nginx 响应请求后，产生响应数据包。
- 然后以 CIP 查找出方向的路由，确定下一跳信息和发送网卡设备信息。此时数据包源、目的 IP 分别是 VIP、CIP，而源 MAC 地址是 RS1 的 RMAC ，目的 MAC 是下一跳（路由器）的 MAC 地址，记为 CMAC（为了容易理解，记为 CMAC ）。然后数据包通过 RS 相连的路由器转发给真正客户端，完成了请求响应的全过程。
从整个过程可以看出，DR 模式 LVS 逻辑比较简单，数据包通过直接路由方式转发给后端服务器，而且响应数据包是由 RS 服务器直接发送给客户端，不经过 LVS。我们知道通常请求数据包会比较小，响应报文较大，经过 LVS 的数据包基本上都是小包，所以这也是 LVS 的 DR 模式性能强大的主要原因。
4.1.2 LVS DR特性
- 前端路由将目标地址为VIP报文统统发给Director Server
- RS跟Director Server必须有一个网卡在同一个物理网络中
- 所有的请求报文经由Director Server，但响应报文必须不能进过Director Server
- 所有的real server机器上都有VIP地址
4.1.3 优缺点和使用场景
DR 模式的优点
- 响应数据不经过 lvs，性能高
- 对数据包修改小，信息保存完整（携带客户端源 IP）
DR 模式的缺点
- lvs 与 rs 必须在同一个物理网络（不支持跨机房）
- 服务器上必须配置 lo 和其它内核参数
- 不支持端口映射
DR 模式的使用场景
如果对性能要求非常高，可以首选 DR 模式，而且可以透传客户端源 IP 地址。
4.2 LVS NAT模式
LVS NAT原理详解图
4.2.1 LVS NAT原理
- 用户请求数据包经过层层网络，到达 lvs 网卡，此时数据包源 IP 是 CIP，目的 IP 是 VIP。
- 经过网卡进入网络层 prerouting 位置，根据目的 IP 查找路由，确认是本机 IP，将数据包转发到 INPUT 上，此时源、目的 IP 都未发生变化。
- 到达 lvs 后，通过目的 IP 和目的 port 查找是否为 IPVS 服务。若是 IPVS 服务，则会选择一个 RS 作为后端服务器，将数据包目的 IP 修改为 RIP，并以 RIP 为目的 IP 查找路由信息，确定下一跳和出口信息，将数据包转发至 output 上。
- 修改后的数据包经过 postrouting 和链路层处理后，到达 RS 服务器，此时的数据包源 IP 是 CIP，目的 IP 是 RIP。
- 到达 RS 服务器的数据包经过链路层和网络层检查后，被送往用户空间 nginx 程序。nginx 程序处理完毕，发送响应数据包，由于 RS 上默认网关配置为 lvs 设备 IP，所以 nginx 服务器会将数据包转发至下一跳，也就是 lvs 服务器。此时数据包源 IP 是 RIP，目的 IP 是 CIP。
- lvs 服务器收到 RS 响应数据包后，根据路由查找，发现目的 IP 不是本机 IP，且 lvs 服务器开启了转发模式，所以将数据包转发给 forward 链，此时数据包未作修改。
- lvs 收到响应数据包后，根据目的 IP 和目的 port 查找服务和连接表，将源 IP 改为 VIP，通过路由查找，确定下一跳和出口信息，将数据包发送至网关，经过复杂的网络到达用户客户端，最终完成了一次请求和响应的交互。
NAT 模式双向流量都经过 LVS，因此 NAT 模式性能会存在一定的瓶颈。不过与其它模式区别的是，NAT 支持端口映射，且支持 windows 操作系统。
4.2.2 LVS NAT特性
- NAT模式修改的是目的ip，直接走的是switch不需要修改mac地址，所以VIP和RIP不需要在同一个网段内
- NAT的包的进出都需要经过LVS，所以LVS可能会成为一个系统的瓶颈问题
4.2.3 优点、缺点与使用场景
NAT 模式优点
- 能够支持 windows 操作系统
- 支持端口映射。如果 rs 端口与 vport 不一致，lvs 除了修改目的 IP，也会修改 dport 以支持端口映射。
NAT 模式缺点
- 后端 RS 需要配置网关
- 双向流量对 lvs 负载压力比较大
NAT 模式的使用场景
如果你是 windows 系统，使用 lvs 的话，则必须选择 NAT 模式了。
4.3 LVS FULLNAT模式
LVS FULLNAT报文变化
LVS FULLNAT特性：
- FULLNAT模式也不需要DIP和RIP在同一网段
- FULLNAT和NAT相比的话：会保证RS的回包一定可到达LVS
- FULLNAT需要更新源IP，所以性能正常比NAT模式下降10%
4.4 LVS TUN原理
Tunnel 模式在国内使用的比较少，不过据说腾讯使用了大量的 Tunnel 模式。它也是一种单臂的模式，只有请求数据会经过 lvs，响应数据直接从后端服务器发送给客户端，性能也很强大，同时支持跨机房。
LVS TUN原理详解图
4.4.1 LVS TUN原理
- 用户请求数据包经过多层网络，到达 lvs 网卡，此时数据包源 IP 是 cip，目的 ip 是 vip。
- 经过网卡进入网络层 prerouting 位置，根据目的 ip 查找路由，确认是本机 ip，将数据包转发到 input 链上，到达 lvs，此时源、目的 ip 都未发生变化。
- 到达 lvs 后，通过目的 ip 和目的 port 查找是否为 IPVS 服务。若是 IPVS 服务，则会选择一个 rs 作为后端服务器，以 rip 为目的 ip 查找路由信息，确定下一跳、dev 等信息，然后 IP 头部前边额外增加了一个 IP 头（以 dip 为源，rip 为目的 ip），将数据包转发至 output 上。
- 数据包根据路由信息经最终经过 lvs 网卡，发送至路由器网关，通过网络到达后端服务器。
- 后端服务器收到数据包后，ipip 模块将 Tunnel 头部卸载，正常看到的源 ip 是 cip，目的 ip 是 vip，由于在 tunl0 上配置 vip，路由查找后判定为本机 ip，送往应用程序。应用程序 nginx 正常响应数据后以 vip 为源 ip，cip 为目的 ip 数据包发送出网卡，最终到达客户端。
Tunnel 模式具备 DR 模式的高性能，又支持跨机房访问，听起来比较完美。不过国内运营商有一定特色性，比如 RS 的响应数据包的源 IP 为 VIP，VIP 与后端服务器有可能存在跨运营商的情况，很有可能被运营商的策略封掉，Tunnel 在生产环境确实没有使用过，在国内推行 Tunnel 可能会有一定的难度吧。
4.4.2 LVS TUN特性
- TUNNEL必须在所有的realserver上绑定VIP
- realserver直接把包发给client
- 隧道模式运维起来会比较难，所以一般不用
4.4.3 优点、缺点与使用场景
Tunnel 模式的优点
- 单臂模式，对 lvs 负载压力小
- 对数据包修改较小，信息保存完整
- 可跨机房（不过在国内实现有难度）
Tunnel 模式的缺点
- 需要在后端服务器安装配置 ipip 模块
- 需要在后端服务器 tunl0 配置 vip
- 隧道头部的加入可能导致分片，影响服务器性能
- 隧道头部 IP 地址固定，后端服务器网卡 hash 可能不均
- 不支持端口映射
Tunnel 模式的使用场景
理论上，如果对转发性能要求较高，且有跨机房需求，Tunnel 可能是较好的选择。
4.5 四种模式的比较
- 是否需要VIP和realserver在同一网段
DR模式因为只修改包的MAC地址，需要通过ARP广播找到realserver，所以VIP和realserver必须在同一个网段，也就是说DR模式需要先确认这个IP是否只能挂在这个LVS下面；其他模式因为都会修改目的地址为realserver的IP地址，所以不需要在同一个网段内 - 是否需要在realserver上绑定VIP
realserver在收到包之后会判断目的地址是否是自己的IP
DR模式的目的地址没有修改，还是VIP，所以需要在realserver上绑定VIP
IP TUN模式值是对包重新包装了一层，realserver解析后的包的IP仍然是VIP，所以也需要在realserver上绑定VIP - 四种模式的性能比较
DR模式、IP TUN模式都是在包进入的时候经过LVS，在包返回的时候直接返回给client；所以二者的性能比NAT高
但TUN模式更加复杂，所以性能不如DR
FULLNAT模式不仅更换目的IP还更换了源IP，所以性能比NAT下降10%
性能比较：DR>TUN>NAT>FULLNAT
5. LVS负载均衡十种算法
1. 轮叫调度 rr
均等地对待每一台服务器，不管服务器上的实际连接数和系统负载
2. 加权轮叫 wrr
调度器可以自动问询真实服务器的负载情况，并动态调整权值
3. 最少链接 lc
动态地将网络请求调度到已建立的连接数最少的服务器上
如果集群真实的服务器具有相近的系统性能，采用该算法可以较好的实现负载均衡
4. 加权最少链接 wlc
调度器可以自动问询真实服务器的负载情况，并动态调整权值
带权重的谁不干活就给谁分配，机器配置好的权重高
5. 基于局部性的最少连接调度算法 lblc
这个算法是请求数据包的目标 IP 地址的一种调度算法，该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器，如果这台服务器依然可用，并且有能力处理该请求，调度器会尽量选择相同的服务器，否则会继续选择其它可行的服务器
6. 复杂的基于局部性最少的连接算法 lblcr
记录的不是要给目标 IP 与一台服务器之间的连接记录，它会维护一个目标 IP 到一组服务器之间的映射关系，防止单点服务器负载过高。
7. 目标地址散列调度算法 dh
该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系，出现服务器不可用或负载过高的情况下，发往该目标 IP 的请求会固定发给该服务器。
8. 源地址散列调度算法 sh
与目标地址散列调度算法类似，但它是根据源地址散列算法进行静态分配固定的服务器资源。
9. 最少期望延迟 sed
不考虑非活动链接，谁的权重大，优先选择权重大的服务器来接收请求，但权重大的机器会比较忙
10. 永不排队 nq
无需队列，如果有realserver的连接数为0就直接分配过去