LVS之DR，NAT，TUN模式祥解

偏执的太偏执、 2022-05-31 09:38 404阅读 0赞

## 集群 ##

### 一、集群 ###

集群（cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术。集群是一组相互独立的、通过高速网络互联的计算机，他们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性。集群的主要优点：高可扩展性，高可用性，高性能，高性价比。

### 二、集群类型 ###

#### 1 scale on：向上扩展 ####

将服务器的内存容量调大和cpu数量增加些（升级服务器硬件）  
缺点：在一定的范围之内它的性能是上升的趋势，但是超出范围之后就是下降的趋势。因为随着它的cpu的个数增加我们需要给我们的cpu仲裁，而且随着cpu个数的增加，资源竞争性增大。

#### 2 scale out：向外扩展 ####

一台服务器应付不过来，我们就增加一台服务器。  
优点：增减服务器很方便，而且没有向上扩展随着增加性能下降。  
向上扩张的工作模式：当客户端向服务器端发送请求时，服务器根据一定的算法选择一台来响应客户的请求。

LB：Load Balance：负载均衡集群  
负载均衡集群中有一个分发器或者叫作调度器，我们将其称为Director，它处在多台服务器的上面，分发器根据内部锁定义的规则或者调度方式从下面的服务集群中选择一台来响应客户端发来的请求。负载均衡是对后端服务器的均衡。

HA：High Availability 高可用集群  
高可用集群时服务的可用性比较高，当我们某台服务器死机后不会造成服务不可用。其工作模式则是将一个具有故障的服务器的服务转交给一个正常工作的服务器，从而达到服务不会中断。一般来说我们集群中工作在前端（分发器）的服务器都会对我们的后端服务器做一个健康检查，如果发现我们服务器down机就不会对其再做转发。高可用是对服务器做备用机。  
衡量标准：可用性=在线时间/（在线时间+故障处理时间）  
99%， 99.9%， 99.99%，99.999%

HP：High Performance 高性能  
高性能的集群是当某一任务量非常大的时候，我们做一个集群来共同完成这个任务。这种处理方式我们成为并行处理集群，并行处理集群是将大任务划分为小任务，分别进行处理。一般这样的集群用来科学研究与大数据运算等方面的工作。现在比较火的Hadoop就是使用的并行处理集群。

说明：三种集群之间区别：  
负载均衡着重于提供服务并发处理能力的集群，是对后端服务器的均衡；高可用以提升服务在线的能力的集群，是对服务器做了备用机的机制；高性能着重于处理一个海量任务，是将一个任务分发给多个主机分别完成。

## LVS简介 ##

Internet的快速增长使多媒体网络服务器面对的访问量快速增长，服务器需要具备提供大量并发访问服务的能力，因此，对于大负载的服务起来讲，CPU，I/O处理能力很快成为瓶颈，由于单台服务器的性能总是有限的，简单的提高硬件性能并不能真正解决这个问题。为此必须采用多服务器和负载均衡技术才能满足大量并发访问的需求。linux虚拟服务器（LVS）使用负载均衡技术将多台服务器组成一台虚拟服务器。它为时应快速增长的网络访问需求提供了一个负载能力易于扩展，而价格低廉的解决方法。

## LVS的结构与工作原理 ##

### 一、LVS的结构 ###

lvs是由目前工作在阿里巴巴的著名工程师章文嵩开发的一款开源软件。现在LVS已经是linux内核标准的一部分。  
一般来说，LVS采用三层结构：负载调度器、服务器池、共享存储。工作在TCP/IP协议的四层，其转发是依赖于四层协议的特征进行转发的，由于其转发要依赖于协议的特征进行转发，因此需要在内核的TCP/IP协议栈进行过滤筛选。可想而知，这就需要在内核的模块来完成，而这样的过滤转发规则又是由管理员进行定义的。所以，LVS就是两段式的架构设计，在内核空间中工作的是“ipvs“，而在用户空间工作的，用来定义集群服务规则的是“ipvsadm“。  
**LVS集群采用三层结构，其主要组成部分为：**  
A、负载调度器（Load Balancer），它是前端机，负责转发客户的请求，而客户认为服务是来自同一个IP地址。  
B、服务器池（Server Pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。  
C、共享存储（Shared Storage），它为服务器池提供一个共享的存储区，使服务器池拥有相同内容，提供相同服务。  
![这里写图片描述][SouthEast]

### 二、LVS内核模型 ###

![这里写图片描述][SouthEast 1]

1.  当客户端的请求到达负载均衡器的内层空间时，首先会到达PREROUTING链
2.  当内核发现数据包的请求目标地址时本机时，将数据包送往INPUT链
3.  lvs是由用户空间的ipvsadm和内核空间的IPVS组成，ipvs用来定义规则，IPVS利用ipvsadm定义的规则工作。IPVS工作在INPUT链上，当数据包到达INPUT链时，首先会被IPVS检查，如果数据包里面的ip地址和目标端口没有在ipvsadm定义的规则里，那这条数据包将会被放行至用户空间。
4.  如果数据包里面的ip地址和目标端口在规则里，那么这条数据报文将会送往内核空间的PUSTROUTING链，接收数据包后发现目标地址正好是自己的后端服务器，那么此时通过选路，将数据包最终送往后端的服务器。

### 三、LVS组成 ###

ipvsadm：用于管理集群服务的命令行工具，工作于linux系统中的用户空间。  
ipvs：为lvs提供服务的内核模块，工作于内核空间（相对于是框架，通过ipvsdm添加规则，来实现ipvs功能）。  
注：在linux内核2.4.23之前的内核模块中ipvs模块是不存在的，需要自己手动打补丁，然后把此模块编译进内核才可以使用此功能。rhel5 /rhel6 自带 LVS 软件包 安装 ipvsadm 软件包即可使用。

### 四、LVS中每个主机ip地址的定义 ###

vip：Director用来向客户端提供服务的IP地址，也是DNS解析的IP  
RIP：集群节点所使用的IP地址（real server）  
DIP：Director用来和RIP进行交互的IP地址  
CIP：公网IP，客户端使用的IP

### 五、LVS的包转发模型 ###

#### 1、NAT模型 ####

通过修改请求报文的目标IP地址（同时可能修改目标端口，支持端口映射），改为某Real Server的IP地址实现数据包的转发。  
![这里写图片描述][SouthEast 2]

1）客户端将请求报文发往前端的负载均衡器，请求报文源地址为CIP目标地址为VIP  
2）负载均衡器接受到报文，发现请求的是在ipvs规则里面存在的地址，那么它将客户端的请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。  
3）报文送到Real Server上，由于报文的目标地址是自己，所以会响应请求，并将响应报文返还给Director。  
4）然后Director将此报文的源地址修改为本机ip并发送给客户端。

**特点：**  
1）集群中各节点跟Directory必须在同一网段  
2）DIP，RIP通常为私有地址，仅用于集群，且Real Server的网关要指向DIP  
**3）支持端口映射和转发**  
4）Real Server可以使用任意的OS  
5）请求报文和响应报文都要经由Director，较大规模应用场景中Director可能成为系统瓶颈

#### 2、DR模型 ####

![这里写图片描述][SouthEast 3]

![这里写图片描述][SouthEast 4]

1）客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP  
2）负载均衡器接收到报文后，发现请求的是在ipvs规则中存在的地址和端口，那么它将客户端请求报文的源MAC地址改为自己的MAC地址，目标MAC改为了Real Server的MAC地址，并将此包发送给Real Server  
3）Real Server发现请求报文中的目标MAC地址是自己，就会把此报文接受下来，处理完请求报文后，将响应报文通过lo接口送给eth0网卡，直接发送给客户端。  
注意：各real server的lo接口上配置的VIP不能响应外部请求。

特点：  
1）集群节点跟Director必须在同一物理网络中  
2）RIP可以使用公网地址，使用便捷的远程控制服务器  
3）Direcotr只负责处理入站请求，响应报文由real server直接发往客户端  
4）real server不能将网关指向DIP  
**5）Director不支持端口映射**  
6）real server支持应用在大多数OS  
7）DR比NAT能处理更多的real server

**VIP地址为调度器和服务器组共享,调度器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处理目标地址为VIP 的网络请求。**

#### 3、TUN ####

![这里写图片描述][SouthEast 5]

1）客户端将请求报文法网前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP  
2）负载均衡器受到报文后，发现请求的是在IPVS规则中存在的地址和对应的端口，那么它将在客户端的请求报文的首部再封装一层IP报文，源地址为DIP，目标地址为RIP，并将此包发送给RS。  
3）RS收到请求报文后，会首先拆开第一层封装，然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会再次处理请求报文，并将响应报文通过lo接口送往eth0网卡直接发送给客户端。  
注意：需要设置lo接口上的VIP不能出现在公网上。

特点：  
1）各集群节点可以跨越不同的网络  
2）RIP，DIP，VIP必须是公网地址  
3）DIrector只负责处理入站请求，响应报文由real server直接发往客户端  
4）real server网关不能指向Director  
5）real server仅能搭建在支持隧道功能的主机上  
**6）不支持端口映射**

**三种 IP 负载均衡技术的优缺点归纳在下表中:**  
![这里写图片描述][SouthEast 6]

### 六、LVS的调度算法 ###

#### 静态调度算法（4种） ####

rr：round robin，轮叫，轮询  
说明：轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N（内部服务器个数），然后重新开始循环。  
优点：简洁，无需记录当前所有连接的状态，是一种无状态调度  
缺点：不考虑每台服务器的处理能力

wrr：weight round robin，加权轮询（以权重之间的比例实现在各主机之间进行调度）  
由于每台服务器的配置、安装的业务应用等不同，其处理能力会不一样。所以，我们根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。

dh：destination hashing，目标地址hash  
将同样的请求发送给同一个server，一般用户于缓存服务器说。简单的说，LB集群后面又加了一层，在LB与real server之间加了一层缓存服务器。当一个客户端请求一个页面时，LB法给一个cache1，当第二个客户端请求同样的页面时，LB还是发给cache1。这就是我们所说的，将同一个请求法送给同一个server，来提高缓存的命中率。目标地址散列调度算法也是针对目标地址IP的负载均衡，它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找到相应的服务器，该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

sh：source hashing，源地址hash，实现会话绑定session  
将统一客户端的请求发送给同一个real server，源地址散列调度算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key），从静态分配的散列表找出相应的服务器，若该服务器是可用的并且没有超负荷，将请求发送给该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址。

#### 动态调度算法（6种） ####

lc：leash-connection 最少连接  
最少连接调度算法是把新的连接请求分配给当前连接数最小的服务器，最小连接调度是一种动态调度短算法，它通过服务器当前所活跃的连接数来估计服务器的负载均衡，调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1，当连接终止或超时，其连接数减一。在系统实现时，我们引入当服务器的权值为0时，表示该服务器不可用而不被调度。此算法忽略了服务器的性能问题，有的服务器性能好，有的服务器性能差，通过加权重来区分性能，所以就有了下面的wlc算法  
简单算法：active\*256+inactive

wlc：加权最少连接  
加权最小连接调度算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省值为1，系统管理员可以动态的设置服务器的权限，加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。由于服务器的性能不同，我们给性能相对好的服务器，加大权重，即会接受到更多的请求。  
简单算法：（active\*256+inactive）/weight（谁的小，挑谁）

sed：最少期望延迟  
不考虑非活动连接，谁的权重大，优先选择权重大的服务器来接受请求，但会出现问题，就是权值比较大的服务器刚开始会一直有请求接入，直到达到权重，才会去寻找下一台服务器。这样会导致权重大的服务器很繁忙，而权重小的服务器很闲，甚至接收不到请求，出于这个原因，就有了下面的算法。

nq：never queue，永不排队  
sed算法会由于某台服务器的权值较小，比较空闲，甚至接受不到请求，而权重大的服务器会很忙。此算法是sed算法的改进版，就是说不管你的权重多大都会被分配到请求。简单说，无需排队，如果有real server的连接数为0就直接分配过去，无需进行sed运算。

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

LBLCR：基于局部性的带复制功能的最少连接  
基于局部性的带复制功能的最少连接调度算法也是针对目标IP地址的负载均衡，该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接“原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送扫该服务器；若该服务器超载，则按“最小连接“原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

**注：LVS默认调度算法为wlc**

### 七、定义集群服务规则的ipvsadm命令 ###

#### 7.1 管理集群服务 ####

**添加：**

ipvsadm -A -t|u|f service-address [-s scheduler]
    -A :add virtual service with options -t：tcp协议的集群 service-address后面必须写成ip:port -u: ud协议的集群 service-address后面必须写成ip：port -f：fwm防火墙的标记 service-address后面必须写成mark number -s：指定调度算法，默认wlc

**修改**

ipvsadm -E -t|u|f server-address

**删除**

ipvsadm -D -t|u|f server-address

#### 7.2管理集群服务中的real server ####

**添加**

ipvsadm -a -t|u|f server-address -r server-address [-g|i|m] [-w weight] -t: tcp协议，实现定义好的某集群服务 -r server-address：某rs的地址在net模型中可使用ip：port实现端口映射 [-g|i|m]: lvs类型， -g：DR -i：TUN -m：NAT [-w weight]：指定权重

**修改**

ipvsadm -e t|u|f server-address

**删除**

ipvsadm -d t|u|f server-address

#### 7.3 查看 ####

ipvsadm -L | ipvsadm -l
    -n:显示主机地址和端口为数字 --static:显示进出数据 --rate：显示速率 --timeout：显示每一个tcp tcpinfo udp的超时时间值 --deamon：显示进程信息 --sort：显示排序规则，默认是升序的 -c：显示多少个客户连接进来

#### 7.4 删除所有集群服务 ####

**清空ipvs规则**

ipvsadm -C

#### 7.5 保存已定义好的规则： ####

service ipvsadm save
    ipvsadm -S > /path/to/somefile

#### 7.6 载入之前的规则 ####

ipvsadm -R
    ipvsadm -R < /path/to/somefile

### 八、LVS-NAT模式演示 ###

**实验环境：rhel6.5**

![这里写图片描述][SouthEast 7]

**需要关闭Director和RealServer的iptables和selinux。特别注意VIP和DIP要分开，要不然可能会发生在调度器上可以访问集群，但是客户端访问不到，连接一直等待中！！！**

Director:
    echo "1" >/proc/sys/net/ipv4/ip_forward
    #指令中，参数值为1时启用ip转发，为0时禁止ip转发，在NAT模式下此操作是必须的。
    ipvsadm -A -t 172.25.254.100:80 -s rr
    ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.2:80 -m
    ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.3:80 -m
    ip addr add 172.25.56.100/24 dev eth0
    
    Real server1/2:
    route add default gw 172.25.254.1
    /etc/init.d/httpd start

### 九、LVS-DR模式演示 ###

**实验环境：rhel6.5**

![这里写图片描述][SouthEast 8]

Director:
    ipvsadm -C   #清空 ipvs 转发表
    ipvsadm -A -t 172.25.254.100:80 -s rr  
    ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.2:80 -g
    ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.3:80 -g
    
    保存 rule
    /etc/init.d/ipvsadm  save
    
    查看rule
    ipvsadm -ln
    
    Real server1/2:
    关闭arp响应
    echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce 
    echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce 
    echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore 
    echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore 
    说明：
    arp_ignore: 定义接收到ARP请求时的响应级别；
    0：只要本地配置的有相应地址，就给予响应
    1：仅在请求的目标地址配置请求到达的接口上的时候，才给予响应
    arp_ignore = 1
    arp_announce：定义将自己的地址向外通告的级别；
    0：将本地接口上的任何地址向外通告；
    1：仅向目标网络通告与其网络匹配的地址；
    2：仅向与本地接口上地址匹配的网络进行通告；
    arp_announce = 2
    绑定vip(2,3都要有vip)
    ifconfig lo:0 172.25.254.100 netmask 255.255.255.255 up
    
    arp -an | grep 100     #查找arp缓存
    arp -d 172.25.254.100  #删除关于172.25.254.100的arp缓存

![这里写图片描述][SouthEast 9]

**参考：另外一种修改arp的方式**  
**yum install arptables\_jf**  
![这里写图片描述][SouthEast 10]

[SouthEast]: /images/20220531/a68b1eb045b8490a97f55a1c7d09bc85.png
[SouthEast 1]: /images/20220531/06b2dbcbdc29463d86f2ac20b40ca08d.png
[SouthEast 2]: /images/20220531/7672d06dedaa40989c67f866191928ec.png
[SouthEast 3]: /images/20220531/230ecef9e6b841f9802b7692476820dd.png
[SouthEast 4]: /images/20220531/ad01f7bc1d024c6eb8b3e53b48dc9565.png
[SouthEast 5]: /images/20220531/1c3566792316487690aa5a92d0ea76a9.png
[SouthEast 6]: /images/20220531/bd9f07eb9f0f4e8d926321404daa91c1.png
[SouthEast 7]: /images/20220531/855a2fcfcb104819a76b25825f5e4510.png
[SouthEast 8]: /images/20220531/826bcd893fdb4b768d34ac1d2b4c75ff.png
[SouthEast 9]: /images/20220531/69189c68cf9f428aa2f7cb5346bfbc6e.png
[SouthEast 10]: /images/20220531/fd06e6f69a564fe7bd3c8ca32f7934f3.png