LVS介绍及工作原理

1. LVS 介绍

   LVS,Linux Virtual Server 的简写，意即 Linux 虚拟服务器，是一个虚拟的服务器集群系统，可以在 UNIX/Linux 平台下实现负载均衡集群功能。

   文章：LVS项目介绍

       LVS集群体系结构

       LVS集群的IP负载均衡技术

       LVS集群中的负载调度

   早在 Linux 内核 2.2 时，IPVS 就已经以内核补丁的形式出现。从 2.4.23 版本开始时，IPVS 软件就是合并到 Linux 内核的常用版本的内核补丁的集合。从 2.4.24 以后已经成为 Linux 官方标准内核的一部分。

   从上图可以看出，LVS 负载均衡调度技术是在 Linux 内核中实现的，因此被称为 Linux 虚拟服务器。我们使用该软件配置 LVS 时候，不能直接配置内核中的 IPVS，而需要使用 IPVS 的管理工具 IPVSADM 进行管理，当然也可以用 Keepalived 软件管理。

2. LVS 体系结构与工作原理

   LVS 集群负载均衡器接收服务的所有入栈客户端计算机请求，并根据调度算法决定哪个集群节点应该处理回复请求。负载均衡器（简称 LB）。

   LVS 虚拟服务器的体系结构如下所示，一组服务器通过高速的局域网或者地理分布的广域网相互连接，在它们的前段有一个负载调度器（Load Banlancer）。负载均衡调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能，高可用的服务器一样。客户程序不受服务器集群的影响不需做任何修改。系统的伸缩性通过在服务集群中透明地加入和删除一个节点来达到，通过检测节点或服务进程故障和正确地重置系统达到高可用性。由于负载调度技术是在 Linux 内核中实现的，称为 Linux 虚拟服务器。

LVS工作模式与原理

1. LVS 相关术语命名约定

   LVS 集群内部的节点称为真实服务器（Real Server）,也叫集群节点。请求集群服务的计算机称为客户端计算机。

2. LVS 三种工作模式与原理

IP虚拟服务器软件 IPVS

   在调度器的实现技术中，IP 负载均衡技术是效率最高的。在已有的 IP 负载均衡技术中有通过网络地址转换将一组服务器构成一个高性能、高可用的虚拟服务器，我们称为 VS/NAT 技术（Virtual Server via Network Address Translation）。大多数商业化的 IP 负载均衡调度器产品都使用 NAT 方法。

   在分析 VS/NAT 的缺点和网络服务的非对称性的基础上，我们提出通过 IP 隧道实现虚拟服务器的方法 VS/TUN 和通过直接路由实现虚拟服务器的方法 VS/DR，他们可以极大地提高系统的伸缩性。所以 IPVS 实现了这三种 IP 负载均衡技术，大致原理如下：

• NAT模式—网络地址转换

   Virtual Server via Network Address Translation（VS/NAT）

   通过网络地址转换，调度器 LB 重写请求报文的目标地址，根据预设的调度算法，将请求分配给后端的真实服务器；真实服务器的响应报文处理之后，返回时必须要通过调度器时，经过调度器时报文的原地址被重写，再返回给客户，完成整个调度过程。

   过程：客户端主机请求是携带着报文（CIP:VIP 80）,请求到达 LB 之后，LB 将其转换为（CIP:RIP1 9000）,然后该请求会到达 RIP1 进行处理，处理完毕之后返回报文（RIP:CIP）,由于 RIP1 找不到 CIP 便会通过网关出去（RIP 应该设置网关为 DIP）,这样报文到达网关（DIP）之后，调度器再进行改写为（VIP:CIP 80）,然后将数据包发给 CIP，这样 CIP 接收到的报文就是（VIP:CIP）。

   总结：

    1.NAT 技术奖请求的报文和响应的报文通过调度器地址重写然后再转发给内部的服务器，报文返回时再改写原来的地址。

     2.主需要在调度器 LB 上配置 WAN 公网 IP 即可，调度器也要有私网 LAN IP 和节点内部通信。内部节点配置 LAN IP。

     3.每台内部 RS 节点的网关，要配成 LB 的 LAN 内物理网卡地址，这样才能确保数据返回仍然经过 LB。

     4.由于请求与回传数据都经过负载均衡器，因此访问量大时有瓶颈。

     5.支持对 IP 及端口进行转换，即 10.0.0.1:80 可以转换到 10.0.0.2:8080

• TUN模式-隧道模式

   采用 NAT 技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器处理能力将成为瓶颈。为了解决此事，调度器把请求报文通过 IP 隧道转发至真实服务器，而真实服务器将服务器响应处理后直接返回给客户，这样调度器只处理请求入站报文，由于一般网络服务应答数据比请求报文大很多，采用 VS/TUN 技术后，集群系统最大吞吐量可以提高 10 倍。

   VS/TUN 工作流程如下图：它的连接调度和管理与 VS/NAT 中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器，调度器将原请求报文封装在另一个 IP 报文中，再将封装后的 IP 报文转发给选定的真实服务器；真实服务器收到报文后，先将收到的报文解封获得原来目标地址为 VIP 的报文，服务器发现 VIP 地址被配置在本地的 IP 隧道设备上，所以就处理这个请求，然后根据路由表将相应报文直接返回给客户。（这种模式数据包封装了一个 IP 报文到达真实服务器上之后解包发现 VIP 地址不是本身的，会不接受此报文，所以这种模式的每个真实服务器必须在 lo 网卡上配置VIP地址，这样才能让解开后的报文发现 VIP 地址在本地有，才能接受并处理）。

   问题：

   1.当用户通过互联网请求负载均衡器的时候，目标地址是 VIP，通过路由器到达负载均衡集群网络中，当到达网络中之后，由于要和局域网主机进行通信，但又没有调度器的 MAC 地址，那么就会发 ARP 广播，广播到达局域网各个主机之后就有可能真实服务器和调度器都应答。

   答：让所有真实服务器的网卡抑制 arp，让所有真实服务器不要响应目标地址是 vip 的请求，只让 vip 去响应。 

   2.为什么要在 lo 网卡上绑定 vip 而不再其它网卡上绑定呢?

   答：防止局域网 IP 地址冲突，lo 是一个属于本地的网卡，在 lo 上绑定在局域网中不会冲突。

   总结：

    1.负载均衡器通过把请求的报文通过 IP 隧道的方式把请求的报文不经过源目的地址的改写，而是直接封装成另外的 IP 报文

     2.由于真实服务器处理请求后直接响应给客户端，因此真实服务器最好有一个外网 IP 地址，效率更高。如果是内网也能出去，但是势必会经过一个 NAT 映射，NAT 服务器又可能成为瓶颈，因为所有服务器都走 NAT 服务器。

     3.由于调度器只处理入站请求的报文，因此集群系统的吞吐量可以提高 10 倍，但隧道模式会封装报文再传输也会带来一定的系统开销。TUN 模式适合 LAN/WAN。

     4.TUN 模式的 LAN 环境不如 DR 模式效率高，有的系统还要考虑 IP 隧道的支持问题。

     5.所有的真实服务器还要绑定 VIP，抑制 ARP 等，配置复杂

     6.LAN 环境一般多采用 DR 模式，WAN 环境可以用 TUN 模式，但是当前在 WAN 环境下，更多的被 DNS+haproxy/nginx等取代

• DR模式—直接路由模式

   Virtual Server via Direct Routing

   VS/DR 模式通过改写请求报文的目标 MAC 地址，将请求发送到真实服务器，而真实服务器将相应后的处理结果直接返回给可以。同 VS/TUN 技术一样，VS/DR 技术可以极大地提高集群系统的伸缩性。而且，这种方法没有 IP 隧道开销，对集群中的真实服务器也没有必须支持 IP 隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同一物理网段上，即必须在同一个局域网环境。

   VS/DR 的工作流程如图，它的连接调度和管理与 VS/NAT 和 VS/TUN 中的一样，它的报文转发方式又有不同，将报文直接路由给目标服务器。在 VS/DR 中，调度器根据各个服务器的负载情况，连接数多少等，动态地选择一台服务器，不修改目的IP地址和目的端口，也不封装 IP 报文，而是将请求的数据帧的 MAC 地址改为选出服务器的 MAC 地址，再将修改后的数据帧在于服务器组的局域网中发送。因为数据帧的 MAC 地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该 IP 报文。当真实服务器发现报文的目标地址不在本地网络设备时，就会拒绝处理，所以需要在本地绑定 VIP 地址，真实服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。

   总结：

    1.通过在 LB 上修改数据包的目的 MAC 地址实现转发。注意，源地址仍然是 VIP 地址。

     2.由于只有请求的报文经过调度器，而处理后响应的报文无需经过调度器，因此访问量大时使用效果特别好。（和 NAT 比）

     3.因 DR 模式是通过 MAC 地址改写的机制实现的转发，因此所有节点和 LB 只能在一个局域网 LAN 中。（小缺点）

     4.需要注意 RS 节点的 VIP 的绑定（lo:vip1,lo:vip2...）和 ARP 抑制问题。

     5.强调下：RS 节点的默认网卡不需要是 LB 的 DIP，直接是 IDC 公网机房分配的上级路由器的 IP.（RS 带有外网地址情况）

     6.由于 DR 模式仅进行了 MAC 地址的改写，因此调度器 LB 无法改变请求的报文的目的端口（和 NAT 要区别）

     7.调度器 LB 支持几乎所有 Unix，Linux 系统，目前无 Windows 版，但是 RS 节点可以是 Windows (LVS NAT)

     8.效率高但是配置比较麻烦。访问量不是特别大的公司可用 haproxy/nginx 取代之。日：2000W PV 下都可用 haproxy+nginx

     9.直接对外的访问业务，例如 web 服务做 RS 节点，最好用公网 IP 地址。不直接对外的业务，如 Mysql，存储用内网IP地址

3. LVS 调度算法

  LVS 的调度算法决定了如何在集群节点之间分布工作符合。当 Director 调度器收到来自客户端计算机访问它的 VIP 上的集群服务的入站请求时，Director 必须决定哪个集群节点应该处理请求。Director 可用于做出该决定的调度方法分成两个基本类别：

  固定调度方法：rr、wrr、dh、sh

  动态调度算法：wlc、lc、lblc、lblcr、sed、nq

生成环境 LVS 调度算法选型

  1.一般的网络服务，如 http、mail、mysql 等，常用调度算法：rr、wlc、wrr

  2.web cache 和 db cache：基于局部性的最少链接 lblc、带复制的基于局部性最少链接 lblcr

  3.防火墙集群：源地址散列调度 sh 和 目标地址散列调度 dh，可以保证整个系统的唯一出入口。

  4.处理时间相对较长的网络服务：最短预期延时调度 sed 和不排队调度 nq

  实际使用中，这些算法的使用范围不限于这些。最好参考内核中的调度算法的实现原理，根据具体的业务需求合理的选型。

常见 LVS 负载均衡高可用解决方案：

  1.通过自己开发脚本解决：比较笨重，不推荐

  2.heartbeat + lvs + ldirectord 配置：比较复杂，不易控制，很少使用

  3.Piranha，Redhat 的一款基于 Web 的配置软件：可以省去手工配置繁琐工作，但是出问题不知道原理，不推荐

 4.Keepalived+LVS：极力推荐的最优方案，简单、易用、高效