LVS

LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统。


Screenshot from 2018-02-09 15-12-19.png


宗旨

使用集群技术和Linux操作系统实现一个高性能、高可用的服务器.

很好的可伸缩性(Scalability)

很好的可靠性(Reliability)

很好的可管理性(Manageability)。

特点

可伸缩网络服务的几种结构,它们都需要一个前端的负载调度器(或者多个进行主从备份)。我们先分析实现虚拟网络服务的主要技术,指出IP负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的IP负载均衡技术中,主要有通过网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用的虚拟服务器, 我们称之为VS/NAT技术(Virtual Server via Network Address Translation)。在分析VS/NAT的缺点和网络服务的非对称性的基础上,我们提出了通过IP隧道实现虚拟服务器的方法VS/TUN (Virtual Server via IP Tunneling),和通过直接路由实现虚拟服务器的方法VS/DR(Virtual Server via Direct Routing),它们可以极大地提高系统的伸缩性。VS/NAT、VS/TUN和VS/DR技术是LVS集群中实现的三种IP负载均衡技术

技术

【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等。分布式文件系统可为各服务器提供共享的存储区,它们访问分布式文件系统就像访问本地文件系统一样,同时分布式文件系统可提供良好 的伸缩性和可用性。

Screenshot from 2018-02-09 17-28-07.png



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隧道协议的要求,但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。


八种负载调度算法:


  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)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。


优点

编辑

1、开源,免费

2、在网上能找到一些相关技术资源

3、具有软件负载均衡的一些优点

缺点

编辑

1、最核心的就是没有可靠的支持服务,没有人对其结果负责;

2、功能比较简单,支持复杂应用的负载均衡能力较差,如算法较少等;

3、开启隧道方式需重编译内核;

4、配置复杂;

5、主要应用于LINUX,目前没有专门用于WINDOWS的版本,不过可以通过配置,使windows成为LVS集群中的real server


实验


实验环境

server1     192.168.122.11     Load Balance

server2     192.168.122.12    Realserver1

server3     192.169.122.13    Realserver2


server1配置

做实验前,先配置好yum源


Screenshot from 2018-02-09 16-07-22.png


[root@server1 yum.repos.d]# yum install -y ipvsadm

Screenshot from 2018-02-09 16-11-11.png

[root@server1 ~]# ipvsadm -A -t 192.168.122.100:80 -s rr    加入策略

Screenshot from 2018-02-09 16-15-19.png

[root@server1 ~]# ipvsadm -a -t 192.168.122.100:80 -r 192.168.122.12:80 -g     加入轮询

[root@server1 ~]# ipvsadm -a -t 192.168.122.100:80 -r 192.168.122.13:80 -g

Screenshot from 2018-02-09 16-18-39.png


[root@server1 ~]# /etc/init.d/ipvsadm status   列出状态

Screenshot from 2018-02-09 16-20-25.png



[root@server1 ~]# ipvsadm -l                   #查看
[root@server1 ~]# ipvsadm -ln                 #查看

ipvsadm -­C               #清除以前的 rules

[root@server1 ~]#/etc/init.d/ipvsadm save   #保存策略

Screenshot from 2018-02-09 16-24-17.png


[root@server1 ~]# ip addr add 192.168.122.100/24 dev eth0    加VIP 192.168.122.100/24

[root@server1 ~]# ip addr del 192.168.122.100/24 dev eth0     删除命令

Screenshot from 2018-02-09 16-32-30.png



server2配置

装有http服务,加入VIP

Screenshot from 2018-02-09 16-38-55.png


server3配置

装有http服务,加入VIP



客户端测试

[root@foundation12 Desktop]# curl 192.168.122.100
<h1>server3.........</h1>
[root@foundation12 Desktop]# curl 192.168.122.100
<h1>server2.........</h1>

通过arp命令,可以通过对比mac地址,判断vip来自哪里,也可清除缓存 (arp -d)

Screenshot from 2018-02-09 17-04-03.png


[root@server2 ~]# yum install -y arptables_jf   安装服务

Screenshot from 2018-02-09 17-25-56.png


[root@server2 ~]# arptables -A IN -d 192.168.122.100 -j DROP     192.168.122.100 进不来
[root@server2 ~]# arptables -A OUT -s 192.168.122.100 -j mangle --mangle-ip-s 192.168.122.12 出去不广播自己192.168.122.100

[root@server2 ~]# /etc/init.d/arptables_jf save   保存

[root@server2 ~]# arptables -nL      #查看策略   /arptables  -L

Screenshot from 2018-02-09 17-34-28.png


[root@server3 html]# yum install -y arptables_jf   安装服务

Screenshot from 2018-02-09 17-37-15.png


客户端测试

Screenshot from 2018-02-09 17-42-33.png

查看mac地址可得,VIP都来自 (server1) ->Load Balance

Screenshot from 2018-02-09 17-44-39.png

Screenshot from 2018-02-09 17-45-22.png


可是,当某一个realserver出现问题时,就会出现问题

模拟realserver出现问题

Screenshot from 2018-02-09 17-51-27.png

后端的realserver出现故障,可客户是不知道的,客户端在连接时,就会出现如下问题

Screenshot from 2018-02-09 17-51-37.png


安全检测

[root@server1 ~]# yum install -y ldirectord-3.9.5-3.1.x86_64.rpm   安装服务

将配置文件拷贝到 /etc/ha.d 目录下

Screenshot from 2018-02-09 18-14-52.png 

[root@server1 ha.d]# vim ldirectord.cf  修改配置文件

Screenshot from 2018-02-09 18-18-20.png

关掉之前的ipvsadm,防止影响,再开启ldirectord

Screenshot from 2018-02-09 18-20-55.png

可看到之前的策略

Screenshot from 2018-02-09 18-21-10.png


当关掉server2上的http服务时,查看得

Screenshot from 2018-02-09 18-25-14.png


此刻在客户端访问时,只要有一台realserver正常工作,客户端的访问就不会受到影响

Screenshot from 2018-02-09 18-27-42.png