LVS负载均衡

目录

一. LVS的定义

二. LVS的作用

三.lvs的3种工作模式的解析

1.基于NAT的LVS模式负载均衡

2.基于TUN的LVS负载均衡

3.基于DR的LVS负载均衡

四.DR模式实现负载均衡

ARP协议

五.LVS心跳检测——keepalived

六.LVS冗余——高可用

---

一. LVS的定义

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。

二. LVS的作用

【1】技术简介

LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。

【2】集群采用三层结构

一般来说，LVS集群采用三层结构，其主要组成部分为：

A、负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。

B、服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。

C、共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

【3】调度器

调度器是服务器集群系统的唯一入口点（Single Entry Point），它可以采用IP负载均衡技术、基于内容请求分发技术或者两者相结合。

在IP负载均衡技术中，需要服务器池拥有相同的内容提供相同的服务。当客户请求到达时，调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器，将该请求转发到选出的服务器，并记录这个调度；当这个请求的其他报文到达，也会被转发到前面选出的服务器。在基于内容请求分发技术中，服务器可以提供不同的服务，当客户请求到达时，调度器可根据请求的内容选择服务器执行请求。因为所有的操作都是在Linux操作系统核心空间中完成的，它的调度开销很小，所以它具有很高的吞吐率。服务器池的结点数目是可变的。当整个系统收到的负载超过所有结点的处理能力时，可以在服务器池中增加服务器来满足不断增长的请求负载。

对大多数网络服务来说，请求间不存在很强的相关性，请求可以在不同的节点上并行执行，所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。 共享存储通常是数据库、网络文件系统或者分布式文件系统。服务器结点需要动态更新的数据一般存储在数据库系统中，同时数据库会保证并发访问时数据的一致性。静态的数据可以存储在网络文件系统（如NFS/CIFS）中，但网络文件系统的伸缩能力有限，一般来说，NFS/CIFS服务器只能支持3~6个繁忙的服务器结点。对于规模较大的集群系统，可以考虑用分布式文件系统，如AFS、GFS、Coda和Intermezzo等。分布式文件系统可为各服务器提供共享的存储区，它们访问分布式文件系统就像访问本地文件系统一样，同时分布式文件系统可提供良好的伸缩性和可用性。

【4】分布式锁管理器

此外，当不同服务器上的应用程序同时读写访问分布式文件系统上同一资源时，应用程序的访问冲突需要消解才能使得资源处于一致状态。这需要一个分布式锁管理器（Distributed Lock Manager），它可能是分布式文件系统内部提供的，也可能是外部的。开发者在写应用程序时，可以使用分布式锁管理器来保证应用程序在不同结点上并发访问的一致性。

负载调度器、服务器池和共享存储系统通过高速网络相连接，如100Mbps交换网络、Myrinet和Gigabit网络等。使用高速的网络，主要为避免当系统规模扩大时互联网络成为整个系统的瓶颈。

【5】监视器

Graphic Monitor是为系统管理员提供整个集群系统的监视器，它可以监视系统的状态。Graphic Monitor是基于浏览器的，所以无论管理员在本地还是异地都可以监测系统的状况。为了安全的原因，浏览器要通过HTTPS（Secure HTTP）协议和身份认证后，才能进行系统监测，并进行系统的配置和管理。

三.lvs的3种工作模式的解析

1.基于NAT的LVS模式负载均衡

NAT（Network AddressTranslation）即网络地址转换，其作用是通过数据报头的修改，使得位于企业内部的私有IP地址可以访问外网，以及外部用用户可以访问位于公司内部的私有IP主机.
第一步，用户通过互联网DNS服务器解析到公司负载均衡设备上面的外网地址，相对于真实服务器而言，LVS外网IP又称VIP（Virtual IPAddress），用户通过访问VIP，即可连接后端的真实服务器（Real
Server），而这一切对用户而言都是透明的，用户以为自己访问的就是真实服务器，但他并不知道自己访问的VIP仅仅是一个调度器，也不清楚后端的真实服务器到底在哪里、有多少真实服务器。

第二步，用户将请求发送至124.126.147.168，此时LVS将根据预设的算法选择后端的一台真实服务器（192.168.0.1~192.168.0.3），将数据请求包转发给真实服务器，并且在转发之前LVS会修改数据包中的目标地址以及目标端口，目标地址与目标端口将被修改为选出的真实服务器IP地址以及相应的端口。

第三步，真实的服务器将响应数据包返回给LVS调度器，调度器在得到响应的数据包后会将源地址和源端口修改为VIP及调度器相应的端口，修改完成后，由调度器将响应数据包发送回终端用户，另外，由于LVS调度器有一个连接Hash表，该表中会记录连接请求及转发信息，当同一个连接的下一个数据包发送给调度器时，从该Hash表中可以直接找到之前的连接记录，并根据记录信息选出相同的真实服务器及端口信息。
 

2.基于TUN的LVS负载均衡

在LVS（NAT）模式的集群环境中，由于所有的数据请求及响应的数据包都需要经过LVS调度器转发，如果后端服务器的数量大于10台，则调度器就会成为整个集群环境的瓶颈。我们知道，数据请求包往往远小于响应数据包的大小。因为响应数据包中包含有客户需要的具体数据，所以LVS（TUN）的思路就是将请求与响应数据分离，让调度器仅处理数据请求，而让真实服务器响应数据包直接返回给客户端。VS/TUN工作模式拓扑结构如图3所示。其中，IP隧道（IP tunning）是一种数据包封装技术，它可以将原始数据包封装并添加新的包头（内容包括新的源地址及端口、目标地址及端口），从而实现将一个目标为调度器的VIP地址的数据包封装，通过隧道转发给后端的真实服务器（RealServer），通过将客户端发往调度器的原始数据包封装，并在其基础上添加新的数据包头（修改目标地址为调度器选择出来的真实服务器的IP地址及对应端口），LVS（TUN）模式要求真实服务器可以直接与外部网络连接，真实服务器在收到请求数据包后直接给客户端主机响应数据。
 

3.基于DR的LVS负载均衡

在LVS（TUN）模式下，由于需要在LVS调度器与真实服务器之间创建隧道连接，这同样会增加服务器的负担。与LVS（TUN）类似，DR模式也叫直接路由模式，其体系结构如图4所示，该模式中LVS依然仅承担数据的入站请求以及根据算法选出合理的真实服务器，最终由后端真实服务器负责将响应数据包发送返回给客户端。与隧道模式不同的是，直接路由模式（DR模式）要求调度器与后端服务器必须在同一个局域网内，VIP地址需要在调度器与后端所有的服务器间共享，因为最终的真实服务器给客户端回应数据包时需要设置源IP为VIP地址，目标IP为客户端IP，这样客户端访问的是调度器的VIP地址，回应的源地址也依然是该VIP地址（真实服务器上的VIP），客户端是感觉不到后端服务器存在的。由于多台计算机都设置了同样一个VIP地址，所以在直接路由模式中要求调度器的VIP地址是对外可见的，客户端需要将请求数据包发送到调度器主机，而所有的真实服务器的VIP地址必须配置在Non-ARP的网络设备上，也就是该网络设备并不会向外广播自己的MAC及对应的IP地址，真实服务器的VIP对外界是不可见的，但真实服务器却可以接受目标地址VIP的网络请求，并在回应数据包时将源地址设置为该VIP地址。调度器根据算法在选出真实服务器后，在不修改数据报文的情况下，将数据帧的MAC地址修改为选出的真实服务器的MAC地址，通过交换机将该数据帧发给真实服务器。整个过程中，真实服务器的VIP不需要对外界可见。
 

四.DR模式实现负载均衡

这里我们使用server1为调度器，负载流量均衡，server2和server3为真实服务器

首先我们在server2和server3都下载httpd，然后在默认发布页面中添加自定义的内容并且开启httpd服务

​

​

在server1中安装ipvsadm，用于管理LVS的策略规则，从而调度用户访问
添加一个对外访问的虚拟IP：172.25.132.100即 VIP，提供虚拟服务的ip地址，但最好是独立出来的IP，不要和原IP混用

yum install ipvsadm -y
ip addr add 172.25.132.100/24 dev eth0    #添加VIP

​

​

书写策略：

ipvsadm -A 添加规则；-t tcp协议；-s 调度；rr 轮循

-a向tcp虚拟服务添加
-r real server真实服务
-g 直连即DR模式

ipvsadm -ln：查看当前连接情况（-ln没有解析，-l有解析，但是速度慢）

Forward：转发方式，当前是路由转发；
Weight：权重；
ActiveConn：当前活跃的连接数；
InActConn：当前不活跃的连接数

ipvsadm -A -t 172.25.132.100:80 -s rr    #添加LVS负载均衡规则，VIP调度方式为轮循方式
ipvsadm -a -t 172.25.132.100:80 -r 172.25.132.2:80 -g   #添加真实服务，并采用DR模式
ipvsadm -a -t 172.25.132.100:80 -r 172.25.132.3:80 -g

​

​

此时在真机使用curl 172.25.132.2/3可以显示server的发布页面，但curl 172.25.132.100没有输出，这是因为LVS-DR集群类型要求，当用户向vip发起请求时，调度器和真实服务器上必须都要有vip，因此需要给server2和server3添加虚拟IP

注意：这里的server1添加的是/24，server2和server3添加的是/32

ip addr add 172.25.7.100/32 dev eth0

​

​ 此时真机使用curl 172.25.132.100，开始轮训访问server2/server3的http

​

ARP协议

ARP协议是将IP地址映射为MAC地址的协议，其在协议上使用ARP请求及ARP应答报文来实现

arp -d是删除ARP缓存列表的命令，可以删除所有的ARP缓存，也可以删除指定的ARP缓存

此时使用arp -an可以查看本地ARP缓存的172.25.132.100对应的MAC地址为调度器server1的地址
 

#真机中
arp -an |grep 100
#server1
ip addr   #查看MAC地址

server1调度器 ip addr查看MAC的地址与真机中arp -an | grep 100显示的MAC地址相同

当真机执行arp -d 删除指定虚拟IP的ARP缓存后，将不能得到172.25.132.100的MAC地址。
再次Ping之后又可以得到，但是已经不是调度器的地址（谁先响应就缓存谁的MAC地址）
这里相应的是server3的MAC地址（curl概率问题，谁先相应先缓存谁的）

​

​

​

此时curl 172.25.132.100，只有server3，已经不轮循访问，说明此时客户端向vip发起请求时，并没有经过调度器而是直接到达了真实服务器

​

要想避免这种情况的发生，我们需要防止客户端直接访问真实服务器，所以我们需要禁掉设备的APR响应

在server2和server3上安装ARP防火墙arptables——用于管理内核中的ARP包过滤规则表

​

​

APR配置规则 

arptable_filter 只有一个表 filter ，不指定 -t 表名时默认就是 filter 表
filter表有三个链，一个是INPUT，表示外面发进来的ARP包；另外一个是OUTPUT，表示本机发出的ARP包；第三个是FORWARD，转发ARP包
-A：向规则链中追加规则
-d：指定要匹配ARP包的目的IP地址
-j：指定满足添加的规则时执行的动作
-s：指定要匹配ARP包的源ip地址
-g：直连
-r：真实服务器地址

在server2/3上设定APR规则：
当数据包的目的地址是100时就丢弃该数据包，当从本机发送出的数据包IP是100时，mangle转换数据包源地址，伪装源地址IP为172.25.132.2

arptables -A INPUT -d 172.25.132.100 -j DROP    #在ARP协议中添加规则，指定虚拟IP访问时拒绝
arptables -A OUTPUT -s 172.25.132.100 -j mangle --mangle-ip-s 172.25.132.2    #从虚拟IP发送和出的数据源地址转换为伪装172.25.7.2
arptables-save > /etc/sysconfig/arptables     #保存策略到文件中
systemctl restart arptables.service           #重启服务
arptables -nL                                 #查看策略

​

然后将server2中保存的策略传输到server3中，然后修改传输过去的内容，2改成3

​

​

当真机再次执行arp -d 删除指定的虚拟IP，ping 虚拟IP之后，得到172.25.132.100的MAC地址是server1的MAC地址，此时使用curl 172.25.132.100，可以论循访问 。并且可以在server1中 ipvsadm -ln查看策略是否到达，如果轮询成功了但是策略没有生成，那么就是真实主机server2和server3的问题，如果轮询成功且策略生成，那么实验成功。

arp -d 172.25.132.100
arp -an |grep 100
ping 172.25.132.100
arp -an |grep 100           #此时查看发现是serve1的MAC地址
for i in {1..10}; do curl 172.25.132.100; done;   #论循访问

​

​

​

五.LVS心跳检测——keepalived

这样使用LVS会出现一个问题，当真实服务器宕机的时候，客户访问时当LVS匹配到宕机主机时客户端会报错，ipvsadm策略依然可以看到服务器存在，所以引入LVS高可用来解决这个问题

ipvsadm没有健康检测功能，后端服务是否正常需要通过keepalived来检测

在server1中

yum install keepalived       #下载健康检测功能
yum install postfix mailx

vim /etc/keepalived/keepalived.conf     #修改keepalived的主配置文件
\\\
global_defs {
   notification_email {
        root@localhost
   }
   notification_email_from keepalived@localhost   #设置通知邮件，出了问题给谁发送邮件notification_email_from
   smtp_server 127.0.0.1
   smtp_connect_timeout 30    #超时时间   
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   #vrrp_strict               #注释vrrp_strict，这一参数功能是在出问题时抓取数据包
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}
##主虚拟路由MASTER：向所有备用虚拟路由BACKUP发送“心跳包”，备用虚拟路由只负责接收，当备用虚拟路由接收不到时，priority优先级最高的备用虚拟路由代替MASTER提供虚拟服务，数字越高，优先级越高，所以MASTER优先级一定要大于虚拟路由id
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51     #路由id
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.25.132.100     
    }
}
#虚拟服务语句块：
virtual_server 172.25.132.100 80 {
    delay_loop 3          #每s/次健康检测
    lb_algo rr            #调度算法 
    lb_kind DR            
    #persistence_timeout 50    #持久连接，即在多长时间内DR会将所有连接请求持续调度给一个后端
    protocol TCP
#LVS集群策略设定，设定之后不需要手动设置VIP及ipvsadm设置的规则
    real_server 172.25.132.2 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            
    real_server 172.25.132.3 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}
\\\

​

​

​此时删掉server1上手动设置的虚拟ip172.25.132.100，ipvsadm -C清除设置的规则

ip addr del 172.25.132.100/24 dev eth0    #删除VIP
ip addr      #查看IP
ipvsadm -C   #清楚ipvsadm设定的规则
ipvsadm -ln  #查看规则 

​

​

启动keepalived软件 

systemctl start keepalived.service
ip addr       #能看到虚拟ip172.25.132.100由keepalived自动生成
ipvsadm -ln   #ipvsadm策略自动生成

​

心跳检测keepalived配置完毕后，停止server2的http服务，在server1上查看，此时将检测不到server2

​

​

客户端自然也访问不到已经停止运行的服务器

​

注意： 如果server1也安装了httpd服务，curl 172.25.132.100不会访问server1的80

六.LVS冗余——高可用

当server1的lvs down怎么办?
配置备用LVS调度器server4

在server4上下载keepalived
将server1的keepalived.conf文件scp传输到server4
在server4上修改BACKUP、优先级

server1：

scp  /etc/keepalived/keepalived.conf server4:/etc/keepalived/  

​

server4：

#server4
yum install keepalived -y
yum install ipvsadm -y
vim /etc/keepalived/keepalived.conf
systemctl restart keepalived.service

​

并且ipvsadm -ln：查看当前连接情况，并且查看日至发现server4的keepalived状态为backup，有策略，但是没有vip

然后当server1停止keepalived服务后，再次查看server4的日志，可以看到此时的server4是MASTER

​

​

在真机中访问VIP,通过arp -an | grep 100查看MAC地址，对比发现是server4的MAC地址

​

​

​

再次开启server1的 keepalived服务后，过滤得到172.25.132.100的MAC地址是server1的MAC地址，并且将vip抢了过来，此时server4为BACKUP 

​

​

​