LVS 官方中文站点参考资料：
http://www.linuxvirtualserver.org/zh/index.html
LVS 二层负载均衡机制
- 只有
LVS实现了二层负载均衡 - 通过
LVS的DR模式来实现的
数据包走向原理说明：
-
客户端请求数据包报文源地址和目标地址：CIP、VIP
-
负载均衡将客户端请求数据包报文的源 MAC 地址改为自己 DIP 的 MAC 地址，目前 MAC 地址改为 RIP 的 MAC 地址，并将这个数据包发送给后端服务器
后端服务器和负载均衡服务器只能在一个局域网内，不能跨 VLAN
-
后端服务器直接获取的是客户端的源IP地址
-
后端服务器发现请求的数据包报文中的目标地址的 MAC 是自己，就接收了这个数据包，由于数据包的 MAC 地址被修改，因此后端服务器需要在 lo 网口绑定 VIP，处理完报文后，将响应报文通过 lo 接口送给
eth0网卡直接发给客户端，因为数据包由后端直接返回给客户端，所以后端服务器必须绑定公网 IP 地址
LVS 三层负载均衡机制
- 只有
LVS实现了三层负载均衡 - 是通过
LVS的【IP-TUN】模式完成的
数据包走向原理说明：
- 客户端请求数据包报文源地址和目标地址：CIP、VIP
- 负载均衡将客户都请求的数据包报文首部再封装一层 IP 报文，将源地址改为 DIP，目标地址改为 RIP，并将这个数据包发送给后端服务器，这个模式是可以跨 VLAN 的，三层负载会导致在后端服务器中不能直接获取到客户端的源 IP 地址
- 后端服务器接收到报文请求后，首先拆开第一层封装，然后发现里面还有一层 IP 首部的目标地址，是自己 lo 接口上的 VIP 地址，所以会处理请求报文，并将响应报文通过 lo 接口发送给 eth0 网卡直接发送给客户端
LVS 四层负载均衡机制
-
LVS通过【NAT】模式实现的
数据包走向原理说明：
- 客户端请求数据包报文源地址和目标地址：CIP、VIP
- 负载均衡将客户端请求数据包中的报文的目标地址改成 RIP 地址，并将数据包发给后端服务器，同样要求所有的后端服务器和负载均衡服务器只能在一个 VLAN 中
- 报文送到后端服务器后，目标服务器就会响应请求，并将响应数据包返回给负载均衡服务器
- 负载均衡将响应数据包的源地址 IP 改成 VIP 地址后发送给客户端
- 负载均衡服务器会存在性能瓶颈
LVS 调度算法
IPVS 在内核中的负载均衡调度是以连接为粒度的。在 HTTP 协议（非持久）中，每个对象从 WEB 服务器上获取都需要建立一个 TCP 连接，同一用户的不同请求会被调度到不同的服务器上，所以这种细粒度的调度在一定程度上可以避免单个用户访问的突发性引起服务器间的负载不平衡。
在内核中的连接调度算法上，IPVS 已实现了以下八种调度算法
轮叫调度（RR）
轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。
-
适合后端服务器组处理性能一致（配置相同）
-
请求间隙较大时，容易导致分配不均衡
加权轮叫调度（WRR）
加权轮叫调度（Weighted Round-Robin Scheduling）算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，服务器的缺省权值为1。假设服务器A的权值为1，B的 权值为2，则表示服务器B的处理性能是A的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接，权值高的服 务器比权值低的服务器处理更多的连接，相同权值的服务器处理相同数目的连接数。
- 有三个服务器A、B和C分别有权值4、3和2，则在一个调度周期内(mod sum(W(Si)))调度序列为AABABCABC。加权轮叫调度算法还是比较简单和高效
- 请求间隙较大时，容易导致分配不均衡
最小连接调度（LC）
最小连接调度（Least-Connection Scheduling）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。
- 在系统实现时，我们也引入当服务器的权值为零时，表示该服务器不可用而不被调度
- 当各个服务器有相同的处理性能时，最小连接调度算法能把负载变化大的请求分布平滑到各个服务器上，所有处理时间比较长的请求不可能被发送到同一台服务器上。但是，当各个服务器的处理能力不同时，该算法并不理想，因为TCP连接处理请求后会进入TIME_WAIT状态，TCP的TIME_WAIT一般为2分钟，此时连接还占用服务器的资源，所以会出现这样情形，性能高的服务器已处理所收到的连接，连接处于TIME_WAIT状态，而性能低的服务器已经忙于处理所收到的连接，还不断地收到新的连接请求
加权最小连接调度（WLC）
加权最小连接调度（Weighted Least-Connection Scheduling）算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权 值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。
基于局部性的最少链接调度（LBLC）
基于局部性的最少链接调度（Locality-Based Least Connections Scheduling，以下简称为LBLC）算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。
- LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不 存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器
带复制的基于局部性最少链接调度（LBLCR）
带复制的基于局部性最少链接调度（Locality-Based Least Connections with Replication Scheduling，以下简称为LBLCR）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要 维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器，映射该“热门”站 点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会导致该“热门”站点的映像会出现 在所有的Cache服务器上，降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热 门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载；当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器 数目。这样，该“热门”站点的映像不太可能出现在所有的Cache服务器上，从而提供Cache集群系统的使用效率。
- LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组；按“最小连接”原则从该服务器组中选出一台服务器，若服务器没有超载， 将请求发送到该服务器；若服务器超载；则按“最小连接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该 服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度
目标地址散列调度（DH）
目标地址散列调度（Destination Hashing Scheduling）算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。
目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。文章来源：https://www.toymoban.com/news/detail-718754.html
源地址散列调度（SH）
源地址散列调度（Source Hashing Scheduling）算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。文章来源地址https://www.toymoban.com/news/detail-718754.html
- 源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口
到了这里，关于负载均衡：LVS 负载调度原理的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
