介绍

Linux 集群相关概念

Linux 集群（cluster）就是一组 Linux 计算机，它们作为一个整体向用户提供一组网络资源，这些单个的计算机系统就是集群的节点（node）。一个理想的集群，用户是不会意识到集群系统底层的节点的，在他们看来，集群是一个系统，而非多个计算机系统，并且集群系统的管理员可以随意增加和删改集群系统的节点。

Linux 集群系统的优点主要有如下：

• 易于扩展，管理员可很方便的增加或删除集群系统中的节点。
• 高可用性，当集群中某一个节点失效时，其负责的任务可以传递给其他节点，有效避免单点故障。
• 高性能，负载均衡的集群系统能够承担极大的并发客户请求。
• 高性价比，可以使用相对廉价的硬件构造出高性能的系统。

常见的 Linux 集群类型包括：

• LB：Load Balancing，负载均衡集群
  负载均衡集群中有调度器（Director），它处在多台内部服务器的上层，根据定义的调度方式从下层的服务器组中选择一台来响应客户端发送的请求。
• HA：High Availability，高可用性集群
  顾名思义就是服务的可用性比较高，当某台服务器故障后不会造成所提供的服务中断，集群自动将客户的访问请求转交给一个正常工作的服务器。
• HP：Hight Performance，高性能
  高性能的集群是当某一项任务计算量非常大的时候，由一个计算机集群共同来完成这项任务，这种 处理方式我们称为并行处理机制。一般高性能集群用于科研工作方面。

常见的 Linux 集群扩展类型（组建方式）有：

• scale up（纵向扩展）：通过增加硬件资源，即增加更好的设备来满足性能消耗的需求，但是此方式性价比很低。
• scale out（横向扩展）：通过硬件或软件的方式，将由单一服务器负责的业务需求转为一组节点服务器来进行处理，此种方式易于扩展且性价比高。

LVS 概述

LVS，是 Linux Virtual Server 的 简称，也就是 Linux 虚拟服务器，是一个由章文嵩博士发起的自由软件项目。LVS 由 ipvsadm 和 IPVS 组成，其中：

• ipvsadm 是用户空间的命令行工具，用来为 IPVS 定义管理集群服务的规则；
• IPVS 工作于内核中 netfilter INPUT 钩子上，利用 ipvsadm 定义的规则工作；

LVS 也被称为四层交换/路由，它可以根据请求报文的目标 IP 和 PORT 将其转发至后端主机集群中的某一台主机（根据挑选算法/调度器），支持 TCP、UDI、AH、EST、AH_EST、SCTP 等诸多协议。

LVS 采用三层结构：调度器、服务器池、共享存储，结构如下图：

• Load balancer/Director：负载调度器，主要作用类似一个路由器，将用户请求分发给服务器池上的 Real Server；
• Real Server Pool：服务器池，一组真正执行客户请求的服务器，执行的服务一般有 WEB、MAIL、FTP 和 DNS 等；
• Shared Storage：共享存储，为服务器池提供一个共享的存储区，能使得服务器池拥有相同的内容，提供相同的服务；

现在 LVS 已经是 Linux 标准内核的一部分，在 Linux2.4 内核以前，使用 LVS 时必须要重新编译内核以支持 LVS 功能模块，但是从 Linux2.4 内核以后，已经完全内置了 LVS 的各个功能模块，无需给内核打任何补丁，可以直接使用 LVS 提供的各种功能。

上面有说到 LVS 已经是标准内核的一部分了，所以我们可以通过内核编译配置文件查看到它的配置信息，如下：

$ grep -i -A 10 'IPVS' /boot/config-3.10.0-862.el7.x86_64 
CONFIG_NETFILTER_XT_MATCH_IPVS=m
...
--
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
--
# IPVS SH scheduler
#
CONFIG_IP_VS_SH_TAB_BITS=8

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m

其中：

• IPVS transport protocol load balancing support 是支持的负载均衡协议；
• IPVS scheduler 是使用不同调度算法的调度器，-m 表示它们作为模块存在，调用时会被自动装载；

LVS 特点

通过 LVS 提供的负载均衡技术和 Linux 操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。LVS 的主要特点有以下几个方面：

• 高并发连接：LVS 基于内核网络层面工作，有超强的承载能力和并发处理能力。单台 LVS 负载均衡器，可支持上万并发连接。稳定性强：是工作在网络四层之上仅作分发之用，这个特点也决定了它在负载均衡软件里的性能最强，稳定性最好，对内存和 CPU 资源消耗极低；
• 成本低廉：硬件负载均衡器少则十几万，多则几十万上百万，LVS 只需一台服务器和就能免费部署使用，性价比极高；
• 配置简单：LVS 配置非常简单，仅需几行命令即可完成配置，也可写成脚本进行管理；
• 支持多种算法：支持多种论调算法，可根据业务场景灵活调配进行使用；
• 支持多种工作模型：可根据业务场景，使用不同的工作模式来解决生产环境请求处理问题；
• 应用范围广：因为 LVS 工作在4层，所以它几乎可以对所有应用做负载均衡，包括 HTTP、数据库、DNS、FTP 服务等等；
• 缺点：工作在四层，不支持七层规则过滤或修改，不适合小规模应用。

LVS 相关术语

LVS 中有一些常见的术语，如下表所示：

LVS 架构/工作模式

LVS 架构/工作模式有如下几种：

• lvs-nat（Network Address Translation）：仅修改请求报文的目标 IP，即多目标 DNAT 方式，也被称为 MASQUERADE 类型；
• lvs-dr（Direct Routing）：默认使用的类型，会修改请求报文二层 MAC 地址，也被称为 GATEWAY 类型；
• lvs-tun（IP Tunneling）：IP 隧道模式，会在请求报文的 IP 层之外会再包装一层 IP 地址，也被称为 IPIP 类型；
• lvs-fullnat（Full Network Address Translation）：全地址转换，修改请求报文的源 IP 和目标 IP；

生产场景中一般使用的都是 lvs-nat 模式和 lvs-dr 模式，当然，也并不是说其他模式并不会使用，还是要根据实际的生产场景来决定选择什么样的方案。

下面我们就要具体看一下每一种架构是如何工作的了，但是再这之前，我们还需要回顾一下之前在 iptables 章节说到的 netfilter 的工作模型，参考链接『iptables(1)之iptables(1)之防火墙与iptables相关概念』，因为 LVS 也是工作在 netfilter 的基础上的。

在学习 iptables 的过程中我们了解到 netfilter 默认的工作模型如下：

首先，用户发送请求经由 PREROUTING 链，接下来会来到一个分支：

• 如果目标主机为本机，请求将会到达 INPUT 链并送往用户空间进程，用户空间中的进程作出响应，响应报文经由 POSTROUTING 链发送至客户端；
• 如果目标主机不是本机，且本机开启了核心转发功能，请求则经由 FORWARD 链转发到 POSTROUTING 链，然后转发至其它主机；

而 LVS 在 Linux 内核中的工作模型是这样的：

可以看到，相对于 netfilter 的默认工作模型来说：

• 这里的 FORWARD 和 OUTPUT 链起不了任何作用；
• 客户端的请求目标是本机且不被 ipvsadm 配置项规则所匹配时，请求才会经由 INPUT 链送往用户空间对应进程；
• 客户端的请求目标是本机且被 ipvsadm 配置项规则所匹配时，请求将由 INPUT 链上的 IPVS 转发至 Real Server，而不是经由 FORWARD 链转发；

有了上述的概念支撑，下面我们就可以看一下 LVS 各工作类型的具体流程了。

下面为简洁易读后续内容的描述就都基于上面提到的 LVS 相关术语啦，约定如下：

• Client 的 IP 简称为 CIP；
• Director 的对外提供访问的 IP 为 VIP，与局域网内部通信的 IP 为 DIP；
• Real Server 简称 RS，其 IP 为 RIP；

lvs-nat

在 lvs-nat 模式下，Director 有能被外界访问到的合法 IP 地址，当外界请求报文送达 Director 时，它能判断出应该将该请求报文送到内部网络的的哪个 RS，随即修改请求报文的目标 IP 为该 RS 的 RIP 并转发到该 RS。
它的优点是节省 IP 地址，能对内部主机（RS）进行伪装，缺点是效率低，因为响应请求时的数据包还需经过 Director｡

它的完整数据包流向图如下：

下面对上图进行描述：

• 首先客户端发送请求报文经过路由到达 Director，此时报文的源 IP 为 CIP，目标 IP 为 Director 的 VIP；
• Director 会根据调度算法挑选出一个 RS，并将请求的目标地址修改为该 RS 的 RIP，通过 DIP 所在接口将其送出，此时报文的源 IP 为 CIP，目标 IP 为 RIP；
• RS 接收并处理完请求，发送响应报文，此时要将报文送回到 Director，所以要将 RS 的网关指向 Director 的 DIP，此时响应报文的源 IP 为 RIP，目标 IP 为 CIP；
• Director 接收到响应报文，将源 IP 修改为 VIP，转发至客户端，此时源 IP 为 VIP，目标 IP 为 CIP；

综上所述，lvs-nat 模式的特点如下：

1. RS 应该和 DIP 应该使用内网地址，且 RS 的网关需要指向 DIP；
2. 请求和响应报文都要经由 Director 转发，极高负载的场景中，Director 可能会成为系统瓶颈；
3. 支持端口映射；
4. RS 可以使用任意操作系统；
5. RS 的 RIP 和 Director 的 DIP 必须在同一网络；

lvs-dr

默认使用的模型，它通过修改请求报文的目标 MAC 地址进行转发，仅请求报文经过 Director，响应报文不经过。

Director 绑定了 VIP、DIP，RS 绑定了 RIP 和 VIP（VIP 绑定在 lo 接口）。

其报文流向图具体如下：

下面对上图进行描述：

• 首先客户端发送请求报文经过路由到达 Director，此时报文的源 IP 与源 MAC 为 CIP、CMAC，目标 IP 与 目标 MAC 为 Director 的 VIP、VMAC；
• Director 会修改请求报文的目标 MAC 为某 RS 接口的 RMAC，报文经由 Director 发出，报文的源 MAC 会修改为 DMAC，而源 IP 与目标 IP 不变，此时请求报文的源 IP 与 MAC 为 CIP、DMAC，目标 IP 与 MAC 为 VIP、RMAC；
• 报文经由交换机到达 RS，检查目标 IP 为 lo 接口上的 VIP，接受请求将其送往用户空间对应进程处理，然后发出响应报文，此时响应报文的源 IP 为 lo 接口绑定的 VIP，目标 IP 为 CIP；
• 响应报文直接经由交换机、路由到达客户端，不和 Director 打交道；

在该示例中，由于 Director 和 RS 都绑定了 VIP，所以要保证前端路由器将目标 IP 为 VIP 的请求报文准确的发送给 Director，而不是 RS，此时有如下几种解决方案：

• 静态绑定 VIP 的 MAC 地址为 Director 的 MAC 地址；
• 在 RS 中使用 arptables 拒绝对 VIP 的请求；
• 修改 RS 主机内核的参数（Linux）拒绝对 VIP ARP 的响应；

修改 Linux 内核参数是最常用的方式，可参考：『Linux内核参数之arp_ignore和arp_announce』。

综上所述，lvs-dr 模式有如下特点：

• RS 的 RIP 可以使用私有地址，也可以使用公网地址；
• RS 跟 Director 必须在同一物理网络中（通过 MAC 地址通信）；
• 请求报文经由 Director 调度，但响应报文一定不能经由 Director；
• 不支持端口映射；
• RS 可以是大多数的操作系统；
• RS 的网关不能指向 DIP；

lvs-tun

lvs-tun 模式也被称为 IP 隧道模式，有隧道之名的原因是该模式不修改请求报文的 IP 首部，而是通过在原有的 IP 首部（源：CIP，目标：VIP）之外再封装一个 IP 首部（源：DIP，目标：RIP）。

在该模式下，RS 除了在物理接口上绑定 RIP，也需要将 VIP 绑定在 lo 接口上，

其报文流向图如下：

下面对上图进行描述：

• 首先客户端发送请求报文经过路由到达 Director，此时报文的源 IP 为 CIP，目标 IP 为 Director 的 VIP；
• Director 接收到请求报文，会在请求报文的 IP 首部外层再次封装一个 IP 首部，外层首部的源 IP 为 Director 的 DIP，目标 IP 为某 RS 的 RIP；
• 请求报文经过路由到达对应的 RS，RS 进行解包，发现内层还有一层 IP 首部，此首部的源 IP 为 CIP，目标 IP 为 VIP，RS 发现本机 lo 接口绑定了该 VIP，所以接收该报文将其送往用户空间进行处理，处理完毕后进行相应，此时响应报文的源 IP 为 VIP，目标 IP 为 CIP；
• 响应报文经由互联网路由到达客户端，而无需经由 Director；

综上所述，lvs-tun 有如下特点：

• RIP、DIP、VIP 全得是公网地址；
• RS 的网关不能指向 DIP；
• 请求报文必须经由 Director 调度，但响应报文必须不能经由 Director；
• 不支持端口映射；
• RS 的操作系统必须支持 IP 隧道功能，不然无法对 IP 首部进行二次解包；

lvs-fullnat

在 lvs-fullnat 模式下，Director 通过同时修改请求报文的源地址和目标地址进行转发。

这个相对来说就容易理解啦，这里我就不画内核流向图啦~~在报文大致通信流程如下：

• VIP 是公网地址，RIP 和 DIP 可以是私网地址，二者无须在同一网络中；
• RIP 的网关未必需要指向 DIP，因为 RS 的响应报文的目标 IP 就是 DIP，只要指向网关能够到达 DIP 所在网络即可；
• 支持端口映射；
• RS 的操作系统可以使用任意类型；
• 请求报文经由 Director，响应报文也经由 Director；

参考：

1. https://blog.csdn.net/gui951753/article/details/80316565
2. https://www.cnblogs.com/walk1314/p/9336848.html