1998年，章文嵩博士成立了Linux Virtual Server的自由软件项目，进行Linux服务器集群的开发工作。
他的目标是：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
LVS到现在已经使用的非常广泛了，绝大部分国内的互联网企业用它来做四层的负载均衡组件。
我们分2-3篇博客来介绍LVS，包括从原理到实际的部署等方面。

LVS 做了什么工作？
当客户端向服务端发送请求，请求首先到LVS的服务器上。
- LVS选择一个服务器作为响应本次请求的真实服务器（Real Server）
- 将请求转发到 Real Server
- 将 Real Server 的回应转回客户端（某些模式下没有这一步）
归结起来，LVS做了两件很重要的事情：
- 挑选服务器
- 转发请求
下面就对这两个过程进行描述。在那之前，为了能更清楚的叙述，需要先认识一些名词：
Director运行LVS的服务器，也叫 Virtual Server
LVS并不能直接提供服务，需要后端服务器提供真正的服务
RIP实际提供服务的IPRS实际提供服务的服务器（Real Server）
一台Director至少提供两个IP，一个用来对外提供服务（一般为公网），一个用来向后端服务器转发请求：
VIPVirtual Server 对外提供服务的虚拟IP（Virtual IP）DIPVirtual Server 用于转发的IP（Director IP）
向服务器发出请求的称为Client
CIP客户端IP（Client IP）
转发请求
LVS在转发请求的方式一共有三种，各有优劣
1 Network Address Translation(VS/NAT)
全称 Virtual Network via Network Address Translation。
这种方法是通过NAT的方式来实现负载均衡。

如上图
- 当一个请求到达Director，其
源IP|目的IP为CIP|VIP； - Director将包的目的IP改为RIP，包地址为：
CIP|RIP； - RS处理请求后，将结果返回，包地址为：
RIP|CIP； - 返回的包经过Director时，将其包地址改为：
VIP|CIP
当包从RS返回时，其地址为RIP|CIP。如何保证包一定会经过Director呢？需要将所有的RS的Gateway设置为DIP。这需要DIP和RIP在同一个网段或Vlan中。
Full-NAT
这是VS/NAT方式的一个变种。原理是在转发到RS上时，将目标地址和原地址全部改写，回给客户端时再改回去。这样的话DIP和RIP可以不在一个网段上，可以实现跨机房，或者异地容灾。
缺点
这种方式的缺点是：request和response全部要经过Director，当RS的数量很多，或者请求量很大时，Director会变成性能瓶颈。2 Direct Routing（VS/DR）
全称：Virtual Server via Direct Routing。
这是目前较为常用的一种模式，可以避免VS/NAT出现的Director性能问题。

- 请求到达Director，将目标MAC改为RS的MAC；
- RS处理请求后，将包直接会给Client；
过程很简单，但中间的问题很多：
更改MAC地址来达到转发的时候，Director 和 RS们必须在同一物理交换机下啊？
是的，这也是这个模式的缺点，Director必须和RS在同一交换机下。
RS在收到包之后，发现目的IP不是自己的IP，不会去处理，怎么办？
为了解决这个问题，需要给RS上绑定VIP。
Linux主机的IP和MAC映射关系会通告给整个交换机网络下，这样的话就会出现混乱了，RS和Director都有同样的IP，该发给谁？
可以通过设置内核参数来决定将哪些网卡通报，哪些不通报。一般来说绑定在lo上是最省事的。
Linux包从某个网卡出去，此网卡必须有某个IP才能以此IP为源地址出去，VIP现在绑定到lo上，如何能回包？
为了解决这个问题，需要加主机路由，所有source为VIP的包全部从连通公网的网卡走。
3 IP Tunneling(VS/TUN)

Director收到Client的请求包后，在外层再加上一个IP头为DIP|RIP后封装成IP隧道协议报文，然后发送给real server.
RS一定要可以识别IP隧道协议才可以，拆包后看到还有一个头是CIP|VIP，所以RS就打上VIP|CIP的IP头直接回给Client.
选择服务器
选择服务器本质上就是如何调度请求。LVS提供了下面的几个算法：
1 轮询（Round Robin）
算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
2 加权轮询（Weighted Round Robin）
根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
3 最少链接（Least Connections）
算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
4 加权最少链接（Weighted Least Connections）
在集群系统中的服务器性能差异较大的情况下，调度器采用加权最少链接调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
5 基于局部性的最少链接（Locality-Based Least Connections）
针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。
6 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。
7 目标地址散列（Destination Hashing）
根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
8 源地址散列（Source Hashing）
根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
关于为什么要分篇来写
为什么要分开几篇写不是一篇写完呢？是因为我觉得，博客不是论文，不需要长篇大论一次把事情讲完。利用碎片时间就能读完才是好的。
不占用读者太长时间又能有收获才是我的追求。哈哈哈
作者和出处() 授权分享 By
关注微信公众号，获取新文章的推送！
