LVS简介之DR模式

向右看齐 2022-05-12 06:48 409阅读 0赞

## **LVS** ##

*  LVS是一个开源的软件，可以实现LINUX平台下的简单负载均衡，LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器，目前有三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR）；八种调度算法（rr,wrr,lc,wlc,lblc,lblcr,dh,sh）：
 *  LVS工作在一台server上提供Directory(负载均衡器)的功 能，本身并不提供服务，只是把特定的请求转发给对应的realserver(真正提供服务的主机)，从而实现集群环境中的负载均衡。
 *  LVS的核心组件ipvs工作在kernel中，是真正的用于实现根据定义的集群转发规则把客户端的请求转发到特定的realserver。而另一个组 件ipvsadm是工作在用户空间的一个让用户定义ipvs规则的工具。故我们只要在server上装了ipvsadm软件包就可以定义ipvs规则，而 在linux kernel的2.6版本之后kernel是直接支持ipvs的。
 *   一般来说，LVS集群采用三层结构，其主要组成部分为：

A、负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。   
     B、服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。   
    C、共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同      的服务。

*  **Heartbeat**

Heartbeat 项目是 Linux-HA 工程的一个组成部分，其与lvs在本质上无关。   
Heartbeat提供了2个核心的功能正是lvs所需要的，心跳监测部分和资源接管，心跳监测可以通过网络链路和串口进行，而且支持冗余链路，安装了 Heartbeat 的两台机器会通过心跳检测互相检测对方的状态，当检测到对方失效的时候会调用资源接管来做接管服务器，保证高可靠性。   
在一个高可靠的lvs集群中，负载调度IPVS部分一般由2台服务器组成,一台负责调度，一台负责备用，当负责调度的服务器出现问题的时候迅速切换到备用 机器上，而heartbeat 就是负责检测，负载调度 IPVS 的可用性，并在出现问题的时候切换到备用 IPVS 上面。

*  **ldirectord**

ldirectord是专门为LVS监控而编写的，用来监控lvs架构中服务器池（server pool） 的服务器状态。   
ldirectord 运行在 IPVS 节点上， ldirectord作为一个守护进程启动后会对服务器池中的每个真是服务器发送请求进行监控,如果 服务器没有响应 ldirectord 的请求，那么ldirectord 认为该服务器不可用， ldirectord 会运行 ipvsadm 对 IPVS表中该服务器进行删除，如果等下次再次检测有相应则通过ipvsadm 进行添加。

*  **Keepalived**

Keepalived在这里主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP主机之间failover的实现 。IPVS通常与keepalived配合使用，后者也是LVS项目的子项目之一，用于检测服务器的状态。   
在lvs体系中，Keepalived主要有如下3个功能：   
1 管理LVS负载均衡软件   
2 实现对LVS集群节点的健康检查功能   
3 作为系统网络服务的高可用功能   
即 Keepalived 实现了 heartbeat + ldirectord 的功能。

## **一、IP虚拟服务器软件IPVS** ##

在调度器的实现技术中，IP负载均衡技术是效率最高的。

在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation），大多数商品化的IP负载均衡调度器产品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和 Alteon的ACEDirector。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。所以，IPVS软件实现了这三种IP负载均衡技术，它们的大致原理如下

1.  **Virtual Server via Network Address Translation（VS/NAT）**  
    通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
2.  **Virtual Server via IP Tunneling（VS/TUN）**  
    采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报 文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。
3.  **Virtual Server via Direct Routing（VS/DR）**  
    VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。

## **二、IPVS的八种负载调度算法** ##

针对不同的网络服务需求和服务器配置，IPVS调度器实现了如下八种负载调度算法：

1.  **轮询（Round Robin）**  
    调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
2.  **加权轮询（Weighted Round Robin）**  
    调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
3.  **最少链接（Least Connections）**  
    调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
4.  **加权最少链接（Weighted Least Connections）**  
    在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
5.  **基于局部性的最少链接（Locality-Based Least Connections）**  
    "基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。
6.  **带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）**  
    "带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。
7.  **目标地址散列（Destination Hashing）**  
    "目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

**  8.源地址散列（Source Hashing）**  
      "源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可   用的且未超载，将请求发送到该服务器，否则返回空。

## **三、LVS术语** ##

![70][]

## **四、直接路由模式（DR）** ##

**1.DR的概念**

直接路由模式比较特别,很难说和什么方面相似,前NAT和TUN种模式基本上都是工作在网络层上(三层),而直接路由模式则应该是工作在数据链路层上(二层)｡其原理 为,DR和REALSERVER都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有REALSERVER对本身这个IP的ARP请求保持静默｡也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的REALSERVER,把目的MAC地址改为 REALSERVER的MAC并发给这台REALSERVER｡这时REALSERVER收到这个数据包,则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡由于DR要对二层包头进行改换,所以DR和REALSERVER之间必须在一个广播域,也可以简单的理解为在同一台交换机上。

**2.特点**

*  LVS只接收客户端请求，后端自己返回给客户端
 *  通过更改数据包的目的MAC地址实现转发的
 *  所有节点和LVS要处于同一局域网
 *   RS需要注意VIP地址的绑定和抑制ARP的问题
 *  不支持端口的改变

## **五、DR模式操作实验** ##

实验环境：准备三台虚拟机，一台物理机

物理机：172.25.254.77    （客户端）

server1: 172.25.77.1          （调度器）

server2: 172.25.77.2          （真实主机1）

server3: 172.25.77.3         （真实主机2）

**1.lvs负载均衡的实现**

在server1中：

为server1提供完整的yum源，方便后续实验的进行，如下图所示

![70 1][]

![70 2][]

![70 3][]

安装集群管理服务ipvsadm

![70 4][]

查看配置链内容

![70 5][]

添加vip

![70 6][]

添加LVS负载均衡Vserver，使用轮询算法（rr）

![70 7][]

#在创建的Vserver中添加real server节点，-g 是选用DR模式

![70 8][]

保存ipvsadm的操作

![70 9][]

在server2中

开启http服务

![70 10][]

在真实主机（real server）的回环接口或eth0上绑定vip

![70 11][]

*  `##安装arp防火墙`
 *  `arp防火墙用来屏蔽数据包，拦截ip冲突，因为vip与real server的地址一致，所以进入real server时需要把vip DROP掉，即拦截real server的vip`

![70 12][]

![70 13][]

在server3上做server2一样的操作

开启httpd

绑定vip

安装arp火墙，并设置

![70 14][]

![70 15][]

![70 16][]

在客户端物理机上进行测试：

轮询访问两台真实主机，达到了负载均衡的效果

![70 17][]

查看调度器vip的集群管理服务内容，显示两台真实主机各被调用了两次

![70 18][]

纯粹使用上面这种操作会有一个问题，当两台主机down掉任意一个的时候，调度器无法识别到，会传递错误的数据。

效果如下：停掉server2的httpd

![70 19][]

在客户的物理机上测试时，会出现错误的数据

![70 20][]

查看管理器，调度器传递了错误的数据

![70 21][]

**2.lvs 的健康检查（ldirectord）**

为改善上面的问题，需添加lvs的健康检查

在调度器server1 中

安装服务

![70 22][]

查找配置文件

![70 23][]

将ldirectord.cf 放到/etc/ha.d中

![70 24][]

编辑ldirectord.cf 文件

做以下修改

![70 25][]空清空ipvsadm 配置，并查看

![70 26][]

若是没有httpd安装，并编辑文件

![70 27][]

![70 28][]

开启httpd，重新加载ldirectord,并重启

![70 29][]

测试：down掉任意一台real server 进行测试

![70 30][]

测试结果为：客户端只能获取到正确的数据

![70 31][]

![70 32][]

down掉所有的real server

![70 33][]

当所有的real server down时，调度器自己充当

![70 34][]

[70]: /images/20220512/809788ca5c864c58b1864111ab2fe434.png
[70 1]: /images/20220512/33f05ee5387c430c8336fbba76ef11fa.png
[70 2]: /images/20220512/08b28f3fbbe04a0f80ea779ebfde470d.png
[70 3]: /images/20220512/1b5de440d41e4988998c8bef47d275ba.png
[70 4]: /images/20220512/77c9272bbbcc47a4b5d8603bc1dae4b7.png
[70 5]: /images/20220512/312cebf56f3c4d94a5d47f7103e79531.png
[70 6]: /images/20220512/30f7a0be8a4f4c71bf5b71bf99be692c.png
[70 7]: /images/20220512/81baa445f4294c5dbe532e2eb51bf091.png
[70 8]: /images/20220512/bbfdb35be7314ce0ba7a08b268bdcaba.png
[70 9]: /images/20220512/22660ae743074fb2a0bdfe82fb896bc6.png
[70 10]: /images/20220512/84a048e852e040a9b6ed2d806a9dd27d.png
[70 11]: /images/20220512/b379e7dd6499438a963a53c3670519c2.png
[70 12]: /images/20220512/9e437faa4132429ba29bf372814a4b03.png
[70 13]: /images/20220512/561af9bfdb094374bbb220a6494cb42c.png
[70 14]: /images/20220512/8f5d04c8b13a4a97b416626a8b82a525.png
[70 15]: /images/20220512/f71d3e5c980c492d8a73514a6f8ec794.png
[70 16]: /images/20220512/046a870cc7aa4756a065566765d7ca8d.png
[70 17]: /images/20220512/4c1bcaec78e74f269949aa3472ebd610.png
[70 18]: /images/20220512/2cfce568b0c9426692952d245dbcf91f.png
[70 19]: /images/20220512/c8687ef9a28b4523b90c1d21aee5099d.png
[70 20]: /images/20220512/7bd5d56916f44a82ba114619a2133769.png
[70 21]: /images/20220512/436fb2d2a8644ac0b188a5c8e20e06c2.png
[70 22]: /images/20220512/7cd7f0b1ae5546029cb798a78d0b0f35.png
[70 23]: /images/20220512/5c29c04e4f8c46cf9eac1d8226c46ccd.png
[70 24]: /images/20220512/e4b9ea5b4541418ba3e539c15fe892bf.png
[70 25]: /images/20220512/441a8e598c9444f5af0cac8f80f26303.png
[70 26]: /images/20220512/629298644c8842bcb05fa17306136323.png
[70 27]: /images/20220512/89b7e61e66794beda32bdec062e28969.png
[70 28]: /images/20220512/45cbc5431bd648c6b82fbdd6c8edd882.png
[70 29]: /images/20220512/734597724d5b4325854d3340f5da7c93.png
[70 30]: /images/20220512/cf3f7978612143db92596548a1236878.png
[70 31]: /images/20220512/50ec8abbd0144845a923faa8c6a8eb6e.png
[70 32]: /images/20220512/3cfc62c4596b4309b2de1fb4ab8fb1ae.png
[70 33]: /images/20220512/03ba9231d8934758abbd541610d5f429.png
[70 34]: /images/20220512/25595bf203644bcaa6efd7b3c1ded5e6.png