LVS--基础--01--理论

LVS–基础–01–理论

---

1、LVS 介绍

1. LVS 是 Linux Virtual Server 的简称，也就是 Linux虚拟服务器,也叫做ipvs。
2. 从Linux2.4 内核以后，已经完全内置了 LVS 的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。
3. LVS是一种叫基于TCP/IP的负载均衡技术
4. LVS转发效率极高，具有处理百万计并发连接请求的能力。
5. LVS的IP负载均衡技术是通过 IPVS模块 实现的,可以通过ipvsadm工具来管理ipvs。

1.1、LVS IPVS模块

1. IPVS模块 是LVS集群的核心软件模块
2. IPVS模块 安装在LVS集群作为负载均衡的主节点上，虚拟出一个IP地址和端口对外提供服务。用户通过访问这个虚拟服务(VS)，然后访问请求由负载均衡器(LB)调度到后端真实服务器(RS)中，由RS实际处理用户的请求给返回响应。

1.2、OSI模型

2、LVS 的体系结构

2.1、LVS 架设的服务器集群 由三个部分组成

1. 最前端的负载均衡层，用 Load Balancer 表示
2. 中间的服务器集群层，用 Server Array 表示
3. 最底端的数据共享存储层，用 Shared Storage 表示

2.2、LVS-ipvs相关的几种IP

VIP：virtual IP：LVS服务器上接收外网数据包的网卡IP地址
DIP：director IP：LVS服务器上转发数据包到realserver的网卡IP地址
RIP：realserver(简称RS)上接收Director转发数据包的IP，即提供服务的服务器的IP。
CIP：客户端的IP

3、LVS 负载均衡机制

1. 是四层负载均衡
   1. 建立在OSI模型的第四层(传输层)之上，传输层上有我们熟悉的TCP/UDP
   2. LVS 是支持TCP/UDP的负载均衡。
   3. 相对于其它高层负载均衡的解决办法，比如DNS域名轮流解析、应用层负载的调度、客户端的调度等，它的效率是非常高的。
2. 负载均衡方式
   1. NAT模式：修改 IP 地址
      1. 源地址修改 SNAT
      2. 目标地址修改 DNAT
   2. DR模式：修改目标 MAC地址
   3. TUN模式：

3.1、NAT模式：网络地址转换

1. NAT(Network Address Translation)是一种外网和内网地址映射的技术。
2. NAT模式下，网络数据包的进出都要经过LVS的处理。LVS是作为RS(真实服务器)的网关。
3. 通过网络地址转换(NAT)将一组服务器构成一个高性能的，高可用的虚拟服务器，是NAT技术

3.1.1、NAT模式的原理

1. 客户端发送请求到达Director后，Director根据负载均衡算法改写目标地址为后端某个RIP并转发给后端主机，就像NAT一样。

2. 当后端服务器处理完请求后，后端主机将响应数据交给Director，并由director改写源地址为VIP后传输给客户端。

3.1.2、网络数据包处理

3.1.2.1、客户端发送数据包，数据包到达LVS时

1. LVS 做目标地址转换(DNAT)，将 目标IP 改为 RS的IP。
   1. RS接收到包以后，仿佛是客户端直接发给它的一样。

3.1.2.2、RS处理完数据包，数据包到达LVS时

1. 这时 源IP是RS的IP，目标IP是客户端的IP。
2. RS的包通过LVS中转，LVS会做源地址转换(SNAT)，将包的源地址改为VIP
   1. 客户端接收到包以后，仿佛是LVS直接发给它的一样。

3.1.3、NAT模式的特点

3.1.3.1、LVS(LB)会修改数据包的地址

1. 对于请求包，会进行DNAT
2. 对于响应包，会进行SNAT

3.1.3.2、LVS(LB)会透传客户端IP到RS(DR模式也会透传)

虽然LVS(LB)在转发过程中做了NAT转换，但是因为只是做了部分地址转发，所以RS收到的请求包里是能看到客户端IP的。

3.1.3.3、需要将RS的默认网关地址配置为LVS(LB)的浮动IP地址

因为RS收到的请求包源IP是客户端的IP，为了保证响应包在返回时能走到LVS(LB)上面，所以需要将RS的默认网关地址配置为LVS(LB)的虚拟服务IP地址。
当然，如果客户端的IP是固定的，也可以在RS上添加明细路由指向LVS(LB)的虚拟服务IP，不用改默认网关。

3.1.3.4、LVS(LB)和RS须位于同一个子网，并且客户端不能和LVS(LB)/RS位于同一子网

因为需要将RS的默认网关配置为LVS(LB)的虚拟服务IP地址，所以需要保证LVS(LB)和RS位于同一子网。

又因为需要保证RS的响应包能走回到LVS(LB)上，则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC，响应包就直接回给客户端了，不会走网关，也就走不到LVS(LB)上面了。这时候由于没有LVS(LB)做SNAT，客户端收到的响应包源IP是RS的IP，而客户端的请求包目的IP是LVS(LB)的虚拟服务IP，这时候客户端无法识别响应包，会直接丢弃。

3.1.3.4、NAT模式的最大缺点

LVS负责所有进出数据：不仅处理客户端发起的请求，还负责将响应传输给客户端。而响应数据一般比请求数据大的多，LVS容易出现瓶颈。

3.2、DR模式：直接路由模式

1. 一个请求过来时，LVS不会改写请求包的IP和端口,只将请求包的MAC地址 修改为某一台 RS的MAC地址，该包就会被转发到相应的RS处理。
2. RS处理请求后，响应包直接回给客户端，不再经过LVS。
3. DR模式的转发效率是最高的，特别适合下行流量较大的业务场景，比如请求视频等大文件。

3.2.1、工作原理

1. 客户端发送请求被director接收后，director根据负载均衡算法改写数据帧的目标MAC地址为后端某RS的MAC地址，并将该数据包转发给该RS(实际上是往整个局域网发送，但只有该MAC地址的RS才不会丢弃)
2. RS接收到数据包后，发现数据包的目标IP地址为VIP，而RS本身已经将VIP配置在了自身的某个接口上，因此RS会接收这个数据包并进行处理。
3. 处理完毕后，RS直接将响应报文响应给客户端。此时数据包源IP为VIP，目标IP为CIP。

3.2.2、优势

DR模式 数据分发过程中不修改 IP地址，只修改 mac地址，由于实际处理请求的真实物理 IP地址和数据请求目的 IP地址 一致，所以不需要通过LVS进行地址转换，可将响应数据包直接返回给用户浏览器，避免LVS网卡带宽成为瓶颈。因此，DR 模式具有较好的性能，也是目前大型网站使用最广泛的一种负载均衡手段。

3.2.3、DR模式的特点

3.2.3.1、数据包在LVS(LB)转发过程中，源/目的IP端口都不会变化

LVS(LB)只是将数据包的MAC地址改写为RS的MAC地址，然后转发给相应的RS。

3.2.3.2、每台RS上都必须在环回网卡上绑定LVS(LB)的虚拟服务IP

因为LVS(LB)转发时并不会改写数据包的目的IP，所以RS收到的数据包的目的IP仍是LVS(LB)的虚拟服务IP。为了保证RS能够正确处理该数据包，而不是丢弃，必须在RS的环回网卡上绑定LVS(LB)的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP，自己是能够处理这个数据包的。否则RS会直接丢弃该数据包！

3.2.3.3、RS上的业务进程必须监听在环回网卡的虚拟服务IP上，且端口必须和LVS(LB)上的虚拟服务端口一致

因为LVS(LB)不会改写数据包的目的端口，所以RS服务的监听端口必须和虚拟服务端口一致，否则RS会直接拒绝该数据包。

3.2.3.4、RS处理完请求后，响应直接回给客户端，不再经过LVS(LB)

因为RS收到的请求数据包的源IP是客户端的IP，所以理所当然RS的响应会直接回给客户端，而不会再经过LVS(LB)。这时候要求RS和客户端之间的网络是可达的。

3.2.3.5、LVS(LB)和RS须位于同一个子网

因为LVS(LB)在转发过程中需要改写数据包的MAC为RS的MAC地址，所以要能够查询到RS的MAC。而要获取到RS的MAC，则需要保证二者位于一个子网，否则LVS(LB)只能获取到RS网关的MAC地址。

3.3、TUNNEL模式:IP隧道

3.3.1、概念

1. 采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户的请求越来越多时，调度器就会处理不过来。
2. 调度器就是把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给用户，所以调度器只处理请求报文。
3. 由于一般网络服务响应报文比请求报文大许多，采用TUN技术后，调度器得到极大的解放，集群系统的最大吞吐量可以提高10倍。

3.3.2、隧道模式的工作原理

1. IP隧道技术又称为IP封装技术，它可以将带有源和目标IP地址的数据报文使用新的源和目标IP进行二次封装，这样这个报文就可以发送到一个指定的目标主机上。
2. 隧道模式下，调度器和后端服务器组之间使用IP隧道技术。当客户端发送的请求(CIP–>VIP)被director接收后，director修改该报文，加上IP隧道俩端的IP地址作为新的源和目标地址，并将请求转发给后端被选中的一个目标。
3. 当后端服务器接收到报文后，首先解封该报文原有的CIP—>VIP,该后端服务器发现自身的tun接口上配置了VIP，因此接受该数据包。
4. 当请求处理完成后，结果将不会重新交给director，而是直接返回给客户端。此时响应数据包的源IP为VIP，目标IP为CIP。

3.3.3、采用隧道模式的基本属性和要求

1. realserver的RIP和director的DIP不用处于同一物理网络中，且RIP必须可以和公网通信。也就是说集群节点可以跨互联网实现。
2. realserver的tun接口上需要配置VIP地址，以便接收director转发过来的数据包，以及作为响应的报文源IP。
3. director转发给realserver时需要借助隧道，隧道外层的IP头部的源IP是DIP，目标IP是RIP，而realserver响应给客户端的IP头部是根据隧道内层的IP头分析得到的，源IP是VIP，目标IP是CIP。
4. director只处理入站请求，响应请求由realserver自己完成。
5. 隧道都是静态建立的
6. 隧道一端有一个唯一的IP地址，另一端也有一个唯一的IP地址。

3.3.4、使用场景

TUN模式可以负载调度缓存服务器组，这些缓存服务器一般放置在不同的网络环境，可以就近折返给客户端。在请求对象不在Cache服务器中的情况下，Cache服务器要向源服务器发送请求，将结果取回，最后将结果返回给用户。

3.3.5、网络数据包处理

3.3.5.1、客户端发送数据包，数据包到达LVS时

1. 利用IP隧道技术将请求报文封装转发给后端服务器
2. 因为后端服务器有一组而非一个，所以我们不可能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。各个服务器将VIP地址配置在自己的IP隧道设备上。

3.3.5.2、RS处理完数据包时

响应报文能从后端服务器直接返回给客户

4 IPVS调度算法

4.1、轮叫调度(Round-Robin Scheduling)

1. 以轮叫的方式依次将请求调度不同的服务器
2. 公式：每次调度执行i = (i + 1) mod n，选出第i台服务器。
3. 算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。

4.2、加权轮叫调度(Weighted Round-Robin Scheduling)

1. LB会根据RS上配置的权重，将消息按权重比分发到不同的RS上。
2. 可以给性能更好的RS节点配置更高的权重，提升集群整体的性能。

4.3、最小连接调度(Least-Connection Scheduling)

1. 把新的连接请求分配到当前连接数最小的服务器。
2. 最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。
3. 调度器需要记录各个服务器已建立连接的数目
   1. 当一个请求被调度到某台服务器，其连接数加1
   2. 当连接中止或超时，其连接数减1。

4.4、加权最小连接调度(Weighted Least-Connection Scheduling)

1. 是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。
2. 服务器的缺省权值为1,系统管理员可以动态地设置服务器的权值
3. 加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。

4.5、基于局部性的最少链接(Locality-Based Least Connections Scheduling)

1. 简称：LBLC
2. 是针对请求报文的 目标IP地址 的负载均衡调度
3. 主要用于Cache集群系统
   1. 因为在Cache集群中,客户请求报文的 目标IP地址 是变化的。
   2. 这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。

4.6、带复制的基于局部性最少链接(Locality-Based Least Connections with Replication Scheduling)

1. 简称：LBLCR
2. 是针对 目标IP地址 的负载均衡
3. 主要用于Cache集群系统。

4.6.1、与LBLC的区别

4.6.1.1、维护映射

1. LBLCR要维护从一个 目标IP地址 到一组服务器的映射
2. LBLC 要维护从一个 目标IP地址 到一台服务器的映射。

4.6.1.2、对于一个 "热门站点A"的服务请求，一台Cache服务器可能会忙不过来处理这些请求时

1. LBLC调度算法会从所有的Cache服务器中按"最小连接"原则选出一台Cache服务器C1
   1. “热门站点” 映射到C1，很快C1也会超载，就会重复上述过程选出新的Cache服务器。
   2. 可能会导致该 “热门站点” 的影响会出现在所有的Cache服务器上，降低了Cache服务器的使用效率。
2. LBLCR调度算法将 “热门站点” 映射到一组Cache服务器(服务器集合)
   1. 当该 “热门站点” 的请求负载增加时，会增加集合里的Cache服务器数量，来处理不断增长的负载
   2. 当该 “热门站点” 的请求负载降低时，会减少集合里的Cache服务器数目。
   3. 该 “热门站点” 的影响不太可能出现在所有的Cache服务器上，从而提高Cache集群系统的使用效率。

4.7、目标地址散列调度(Destination Hashing Scheduling)

1. 是针对 目标IP地址 的负载均衡
2. 是一种静态映射算法
3. 通过一个散列(Hash)函数将一个 目标IP地址 映射到一台服务器。
   1. 先根据请求的 目标IP地址，作为散列键(Hash Key)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

4.8、源地址散列调度(Source Hashing Scheduling)

1. 是针对 源IP地址 的负载均衡
2. 是一种静态映射算法
3. 通过一个散列(Hash)函数将一个 源IP地址 映射到一台服务器。
   1. 先根据请求的 源IP地址，作为散列键(Hash Key)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

5、优缺点

5.1、优点

1. 抗负载能力强，是工作在传输层上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和 cpu 资源消耗比较低。
2. 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。
3. 工作稳定，自身有完整的双机热备方案如 LVS+Keepalived；
4. 无流量，LVS 只分发请求，而流量并不从它本身出去，这点保证了均衡器 IO 的性能不会受到大流量的影响。
5. 应用范围比较广，因为 LVS 工作在传输层，所以它几乎可以对所有应用做负载均衡，包括 http、数据库、在线聊天室等等。

5.2、缺点

1. 无法检查后端节点的健康情况；
2. 软件本身不支持正则表达式处理，不能做动静分离
3. 如果是网站应用比较庞大的话，LVS/DR + Keepalived 实施起来就比较复杂了，相对而言，Nginx / HAProxy + Keepalived 就简单多了。；
4. 网络环境依赖性较大；