lvs负载均衡简介

负载均衡集群（LB）

负载均衡集群工作原理

           当用户发送请求时，该请求不是立即发送给后端的真实服务器（realservers），而是先发送给调度器或者分发器（director）， 到达Director的数据包首先会经过PREROUTING，而后经过路由发现其目标地址为本地某接口的地址，因此，接着就会将数据包发往INPUT(LOCAL_IN HOOK)。此时，正在运行内核中的ipvs（始终监控着LOCAL_IN HOOK）进程会发现此数据包请求的是一个集群服务，因为其目标地址是VIP。于是，此数据包本来到达本机(Director)的目标行程被改变为经由POSTROUTING HOOK发往RealServer服务器处理，处理请求完成后，再响应给客户端。这种改变数据包正常行程的过程是根据IPVS表(由管理员通过ipvsadm定义)来实现的。

  

负载均衡设备

刚刚所说的调度器或者分发器是一种负载均衡设备，这种设备有硬件和软件之分：

常见的硬件负载均衡设备：

1、F5  BIG-IP

2、Citrix  NetScale

3、A10

 

常见的软件负载均衡软件

四层负载均衡软件：

LVS：全称Linux Virtual  Server，LVS是由电子科技大学的章文嵩博士创立的基于LINUX内核的负载均衡技术。。LVS可以兼容目前大多数的网络服务，具备高可用性和高伸缩性的特征，易于管理。LVS应用非常广泛。

haproxy也可以用于4层负载均衡。

 

七层负载均衡软件：

nginx、haproxy。一般用在反向代理功能。

 

LVS负载均衡类型

由于LVS在开源界使用比较广泛，因此本文主要使用的LVS这种负载均衡设备，来实现负载均衡功能。

实现LVS负载均衡集群方式有三种：

一、网络地址转换（NAT）

其工作模型如下：

这种方式的工作原理和DNAT的工作原理非常相似。首先，当客户端发送的报文请求到达调度器director时，调度器director根据连接调度算法从一组真实的服务器组中选择一个真实服务器进行响应，并将其报文的目标ip由VIP改为RIP，报文的目标端口，改为服务器的目标端口。当后端的真实服务器响应报文时，将其报文的源ip由RIP改为VIP，其报文的源端口也改为相应的端口。最后由调度器director将响应报文返回给客户端。整个过程对于用户来说，只知道调度器对外的VIP，其后端的真实服务器地址是不知道，因此，对于用户来说，整个集群系统是透明的。这种地址转换类似于iptables的DNAT。LVS的NAT模型主要用于隐藏real server的ip场景。

该方式下的数据报文流向为:

CIP→VIP→DIP→RIP→DIP→VIP→CIP

基于NAT实现集群功能具有如下特性：

1、real server必须和DIP在同一个IP网络中

2、由于数据包达到director是要修改数据包的目标地址和目标端口（做类似于iptables的DNAT），因此RIP通常是私有IP。

3、director位于client和real server之间，负责所处理进出的所有通信。

4、real server必须将网关指向DIP

5、支持端口映射

6、real server可以使用任意OS

7、高负载场景中，由于director处理所有的通信，承载压力较大，因此，director易成为系统瓶颈。

 

二、直接路由DR

在NAT模型中，由于director处理所有的通信，即接受请求还要处理响应。因此，承载压力比较大。在DR模型中，director只负责处理请求，而不负责响应。响应报文直接由后端的real server直接返回。

该方式是实现LVS负载均衡集群最广泛的方式，其工作模型如下：

 

其工作原理为：首先客户端发送的请求会达到调度器director时，director根据各服务器的负载能力，动态的选择后端一台真实服务器进行响应，调度器既不修改报文ip，也不封装ip，而是修改报文的目标MAC地址，并将刚刚选择的那台服务器的MAC地址作为目标MAC地址，然后在局域网中传输。因此，各个服务器节点与director必须在同一个物理网段中。当后端的真实服务器响应报文请求时，使用该服务器隐藏的VIP作为源ip，CIP作为目标ip，直接响应给客户端。因此，在后端的每一个服务器上面都有一个VIP，这个VIP不接受任何请求，仅仅只是在响应报文时，作为源IP响应客户端而已,因此，需要特定的机制将RS上的VIP其隐藏起来。

该方式下的数据报文流向为:

CIP→VIP→DIP→RIP→CIP

这种方式实现的集群具有如下特性：

1、各个服务器节点和director必须在同一个物理网段中。可以和VIP不在同一个物理网段内。

2、RIP可以是私网地址，也可以是公网地址，从而便捷的远程管理和监控。

3、director仅仅负责处理入站请求报文，响应报文由real server直接返回给客户端。

4、real server不能将网关指向DIP。而是指向前端路由器地址，该路由器可以连接外网。

5、real server上需要配置VIP地址，并且禁止响应前端路由器发送的ARP广播。

6、不支持端口映射。

7、RS可以使用大多数的操作系统。

 

三、TUN，IP隧道方式

实现这种方式的集群，各个服务器必须处于不同的网段中，这是一种扩展的DR模型。

其工作模型如下：

工作原理是：首先，客户端发送的请求会到达调度器director，然后调度器会动态的选择一台后端服务器进行响应。然后调度器与该服务器动态的建立隧道（不是静态的建立），并且此时调度器会重新封装该报文请求（即有2个ip首部）。当服务器收到请求后，拆去外层封装，并对该报文进行响应，响应报文直接由real server返回给客户端。响应时源ip为VIP，目标ip为CIP。因此，此时各个服务器上面必须要有隐藏的VIP。

该方式下的数据报文流向为:

CIP→VIP→DIP→RIP→CIP

这种方式实现的集群具有如下特性：

1、集群节点可以跨越Internet

2、RIP必须是公网ip

3、director仅负责处理入站请求报文，响应报文由real server直接返回给客户端

4、real server不能将网关指向DIP

5、只有支持隧道功能的OS才可以当做real server

6、不支持端口映射

 

调度算法

上面每一种方式实现的集群功能，请求报文都要发送到调度器director，那么调度器又是根据什么条件来选择相应的后端真实服务器来响应请求报文的呢？这就要根据调度器director选择的调度算法来选择了。

调度算法一共有10种。其中有4种为静态调度算法，有6种为动态调度算法

4种静态调度算法：

1、循环调度：Round-Robin  Scheduling，简称RR

这种调度算法是将请求报文按照顺序发送给后端真实的服务器进行处理，它不考虑服务器的处理能力，均等的对待每一个服务器。这种调度模型和循环 DNS相似，但是它更粗糙些，因为它是基于网络连接的而不是基于主机的。这种算法简洁，调度器不需要记录所有的连接状态，是一种无状态调度。

2、加权循环调度：Weight Round-Robin  Scheduling ，简称WRR

这种调度算法也是将请求按照顺序发送给后端的真实服务器进行响应处理。但是每个服务器的响应能力由所占权重的比例来决定的，我们根据服务器的不同处理能力，给它分配一个不同的权重，使其接受相应权重所占比例的服务请求。适用于各个集群节点的处理能力大相径庭的场景。如有3太服务器，其权重为3,2,1。那么前3个请求由第一台服务器处理。接着后2个请求由第二台服务器处理。最后1个请求由第三台服务器进行处理。

3、源散列调度：Source  Hash  Scheduling，简称SH

这种调度算法主要实现session绑定，保留该用户之前访问的session信息。是根据请求报文的源ip，作为散列键（Hash Key），从静态分配的散列表中找出相应的服务器地址，若该服务器是可用的且未超出负载，则将该请求发送给该服务器进行处理，否则返回空。可以将同一个用户的请求始终定向到同一台服务器进行响应。这种调度算法违反了负载均衡原则。

4、目标散列调度：Destination  Hash  Scheduling，简称DH

这种调度算法和源散列调度算法大致相同。将请求报文的目标ip地址作为散列键，从静态分配的散列表中找出相应的服务器地址。若该服务器是可用的且未超出负载，则将该请求交给该服务器进行处理，否则返回空。

 

6种动态调度算法：

1、最少连接：Least-Connection，简称LC

这种调度算法是根据服务器中的连接数来决定服务器的负载能力的。最少连接调度算法会将下一次新的请求转发给最少连接数的服务器进行处理。因此，director需要记录各个服务器已建立的连接数。当一个新的请求调度到某台服务器上时，则该服务器的连接数加1,当某个连接超时或断开，则该服务器的连接数减1,。如果某台服务器的权重为0,表示该服务器不可使用而不被调度。计算法则为active*256+inactive。其中active为活跃的连接数，inactive为非活跃的连接数。通常而言，活动连接占用系统资源比非活动连接占用系统资源要多得多。因此，这种调度算法也并非最合理。该调度算法适用于各个集群节点的处理能力大致相同。

2、加权最少连接法：Weight Least-Connections，简称WLC

这种调度算法是根据服务器的连接数和他们的权重比值来决定将请求发送给哪台服务器来进行响应的。计算法则为(active*256+inactive)/weight,哪个服务器的该值最小，则有那台服务器进行响应。

3、基于本地的最少连接调度：Locally-Base  Leaset-Connection Scheduling,简称LBLC

这种调度算法主要是根据报文的目标ip进行负载均衡的。主要用于cache集群。由于报文的目标ip地址是经常变化的，假设当后端的任意real server都能够进行处理时，那么每台real server都保留当时访问的cache。并且每台保留的cache还都不一样。这样将会导致客户在访问同一页面时，得到的结果可能不一样。这种调度算法的设计目标是将相同目标ip的报文交给同一个real server进行处理。这样当用户访问同一个资源时，得到的结果一定是一样的。这样大大提高了cache命中率和集群系统的处理能力。

      该算法根据请求报文的目标ip找出最近一次该目标ip使用的的realsever。如果该real server是可用的，则将该请求转发给该服务器进行处理；如果该服务器是不可用的或者工作负载超过了一半，则会根据“最少连接算法”，选择一个可用的服务器进行处理。

4、带有复制调度的基于本地的最少连接调度：Locally-Base  Leaset-Connection Scheduling with Replication Scheduling，简称LBLCR

该调度算法也是基于目标ip来说实现负载均衡的，它与 LBLC算法不同之处在于，它是将同一个ip映射到多台real server中，这样不管报文由哪台服务器进行处理，得到的结果都是一样的。因此，这样的real server彼此之间能够相互访问且彼此之间的cache能够相互复制，仅仅是复制自己没有的那一部分。

     该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

5、最短的期望的延迟：Shortest  Expected  Delay Scheduling,简称SED

这种算法是基于WLC算法的。调度器将新的请求转发给（active+1)*256/weight的值最小的服务器进行处理。该调度算法忽略了非活跃的连接数。

6、永不排队：Never Queue  Scheduling，简称NQ

这种调度算法是改进的SED算法。当新的请求到来时，如果某台real server处于空闲状态或者连接数=0，则director会将请求转发给该real server进行处理。因此不需要排队（队列）等待。

静态调度算法和动态调度算法的区别

就个人理解，静态调度算法不能够动态察觉到服务器的负载能力，而动态调度算法就可以根据服务器的负载能力，相应的选择real server进行响应。虽然静态调度算法中可以根据权重来分担不同的请求处理能力，但是使用这种调度算法的集群，其服务器性能却大相径庭。

 

 

ipvs规则管理工具ipvsadm

ipvsadm是运行于用户空间，用来与ipvs进行交互的命令行工具。而真正实现功能的是工作在内核中的ipvs这个框架。这有点类似于iptables/netfilter的架构思想。

ipvsadm主要作用表现在：

1、定义director是谁，以及在director上哪些real server用来提供此服务

2、可以为每一台提供某一种相同服务的服务器设置权重（即根据服务器的性能来确定其承担负载的能力）

注意：权重用整数来表示，有时候也可以将其设置为atomic_t；其有效表示值范围为24bit整数空间，即（2^24-1）；

 

根据不同的功能，ipvsadm的使用语法格式也不同，这些功能包括如下：

1、使用ipvsadm来管理集群服务（即定义、修改、删除director）

格式为：ipvsadm  {-A|-E|-D}   {-t|-u|-f}   service-address  [-s  scheduler]

-A:表示添加一个集群

-E:表示修改某个集群

-D:表示删除某个集群

-t:表示tcp集群

-u:表示udp集群

-f:用来做防火墙标记

service-address:director的VIP地址和端口号，即格式为：VIP:PORT               

-s   scheduler：表示该集群服务使用哪种调度算法

-p: timeout persistent connection 持久连接

 

2、使用ipvsadm来管理集群中的real  server

格式为：ipvsadm  {-a|-e|-d}  {-t|-u|-f}  service-address  -r  real-server-address  [-g|-i|-m]  [-w weight]

-a:表示添加一个real server

-e:表示修改某个real  server

-d:表示删除某个real  server

server-address：为事先定义好的director上的VIP和PORT

real-server-address:即提供某种服务的real server的ip（或ip:port）

-g:表示使用DR这种方式来实现LVS负载均衡

-i:表示使用TUN这种方式来实现LVS负载均衡

-m:表示使用NAT这种方式来实现LVS负载均衡

 

3、使用ipvsadm来查看集群服务

格式为：ipvsadm  {-L|-l}  {option}

-L、-l：显示内核中的虚拟服务器规则列表。它后面还可以接许多子选项，包括：    

        -n：以数字的方式来显示主机地址和端口

        --stats:显示统计信息

        --rate：显示速率信息

        --timeout:显示tcp、tcpfin和udp的会话超时时长

        -c: 显示当前的ipvs连接状况

        --deamon:显示同步守护进程的状态

        --sort：对VIP和real server的ip进行排序输出

        --exact：精确显示，不做单位换算

 

4、删除所有集群服务

格式：ipvsadm  -C   清空所有ipvs规则

 

5、保存所有规则

格式：ipvsadm  -S  >   /path/to/somefile

或者ipvsadm-save > /path/to/somefile

 

6、载入之前保存的规则

格式：ipvsadm   -R  <  /path/to/somefile

或者ipvsadm-restore < /path/to/somefile

 

7、显示ipvs和ipvsadm的版本号

格式：

ipvsadm:不接任何选项，用来显示ipvs的版本号

ipvsadm  --version:表示显示ipvsadm的版本号

8、计数器清零

ipvsadm -Z 

 

 

session持久机制

在某些应用场景中，通常需要保持session的持久性。如在电商架构中，某个用户买到的商品加入到购物车中后，此时一刷新，刚刚买到的商品在购物车中就没有了，那么该用户的体验就非常不好了，感觉这个网站很诡异似的。我们知道当页面刷新后，该请求被定向到其他服务器去了，而这台服务器根本就没有这个用户的session信息，于是一刷新后，购物车上的商品就没有了。但是对于用户来说，他们根本就不知道发生了什么问题，只是感觉网站有问题而已，对于这样的场景，不管用户如何刷新页面，都需要保持此前的的信息要存在，也就说此前的session信息必须存在，不能因为页面一刷新session信息就丢失了。保持session信息持久性有3种方式：

1、session绑定，即将同一个请求者的连接始终定向到同一台服务器上（第一次请求时仍然由调度器决定）。不过这种方式没有容错能力，即当这台服务器挂了之后，其session信息也会丢失。有损负载均衡效果。

2、session复制或session集群。即在所有的real sever之间同步session，是的所有的real sever都有相同的session信息。不过此种方式并不适应于大服务器集群环境。

3、session服务器，即将一台共享服务器作为session服务器，所有的集群节点当需要加载session信息，直接到后端的session服务器加载即可。

ipvsadm使用中注意的问题

默认情况下，ipvsadm在输出主机信息时使用其主机名而非IP地址，因此，Director需要使用名称解析服务。如果没有设置名称解析服务、服务不可用或设置错误，ipvsadm将会一直等到名称解析超时后才返回。当然，ipvsadm需要解析的名称仅限于RealServer，考虑到DNS提供名称解析服务效率不高的情况，建议将所有RealServer的名称解析通过/etc/hosts文件来实现；

 

 

                

注意：在做集群服务时，各节点之间的时间偏差不应该超出1秒钟；可以使用NTP服务来进行时间同步

NTP：Network Time Protocol