载均衡技术有很多实现方案,有基于DNS域名轮流解析的方法、有基于客户端调度访问的方法、有基于应用层系统负载的调度方法,还有基于IP地址的调度方法。本文介绍基于传输层的负载均衡器LVS。

LVS是Linux Virtual Server的简称,也就是Linux虚拟服务器, 用现在的观点来看就是个4层(传输层tcp/udp)的负责均衡器。 它是一个由章文嵩博士发起的自由软件项目,它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分,在Linux2.4内核以前,使用LVS时必须要重新编译内核以支持LVS功能模块,但是从Linux2.4内核以后,已经完全内置了LVS的各个功能模块,无需给内核打任何补丁,可以直接使用LVS提供的各种功能。

LVS技术要达到的目标是:通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集,它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。

LVS自从1998年开始,发展到现在已经是一个比较成熟的技术项目了。可以利用LVS技术实现高可伸缩的、高可用的网络服务,例如WWW服务、Cache服务、DNS服务、FTP服务、MAIL服务、视频/音频点播服务等等,有许多比较著名网站和组织都在使用LVS架设的集群系统,例如:Linux的门户网站(www.linux.com)、向RealPlayer提供音频视频服务而闻名的Real公司(www.real.com)、全球最大的开源网站(sourceforge.net)等。

LVS目前有三种IP负载均衡技术(VS/NAT、VS/TUN和VS/DR 十种调度算法(rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq)
1.3 优点

功能特性

优点

1、抗负载能力强、是工作在网络4层之上仅作分发之用,没有流量的产生;
2、配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率;
3、工作稳定,自身有完整的双机热备方案;
4、无流量,保证了均衡器IO的性能不会收到大流量的影响;
5、应用范围比较广,可以对所有应用做负载均衡;

  • 高可用性
    LVS是一个基于内核级别的应用软件,因此具有很高的处理性能,用LVS构架的负载均衡集群系统具有优秀的处理能力,每个服务节点的故障不会影响整个系统的正常使用,同时又实现负载的合理均衡,使应用具有超高负荷的服务能力,可支持上百万个并发连接请求。如配置百兆网卡,采用VS/TUN或VS/DR调度技术,整个集群系统的吞吐量可高达1Gbits/s;如配置千兆网卡,则系统的最大吞吐量可接近10Gbits/s。
  • 高可靠性
    LVS负载均衡集群软件已经在企业、学校等行业得到了很好的普及应用,国内外很多大型的、关键性的web站点也都采用了LVS集群软件,所以它的可靠性在实践中得到了很好的证实。有很多以LVS做的负载均衡系统,运行很长时间,从未做过重新启动。这些都说明了LVS的高稳定性和高可靠性。
  • 适用环境
    LVS对前端Director Server目前仅支持Linux和FreeBSD系统,但是支持大多数的TCP和UDP协议,支持TCP协议的应用有:HTTP,HTTPS ,FTP,SMTP,,POP3,IMAP4,PROXY,LDAP,SSMTP等等。支持UDP协议的应用有:DNS,NTP,ICP,视频、音频流播放协议等。
    LVS对Real Server的操作系统没有任何限制,Real Server可运行在任何支持TCP/IP的操作系统上,包括Linux,各种Unix(如FreeBSD、Sun Solaris、HP Unix等),Mac/OS和Windows等。

与其他对比

现在网络中常见的负载均衡主要分为两种:

硬件

常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器,也有类似于LVS、Nginx、HAproxy的基于Linux的开源的负载均衡策略。
商用负载均衡里面NetScaler从效果上比F5的效率上更高。对于负载均衡器来说,不过商用负载均衡由于可以建立在四~七层 协议之上,因此适用 面更广所以有其不可替代性,他的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用。

软件

比较常见的有LVS、Nginx、HAproxy等,其中LVS是建立在四层协议上面的,而另外Nginx和HAproxy是建立在七层协议之上的。

  • Nginx的特点
    1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构;
    2、Nginx对网络的依赖比较小;
    3、Nginx安装和配置比较简单,测试起来比较方便;
    4、也可以承担高的负载压力且稳定,一般能支撑超过1万次的并发;
    5、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测;
    6、Nginx对请求的异步处理可以帮助节点服务器减轻负载;
    7、Nginx能支持http和Email,这样就在适用范围上面小很多;
    8、不支持Session的保持、对Big request header的支持不是很好,另外默认的只有Round-robin和IP-hash两种负载均衡算法。
  • HAProxy的特点
    1、HAProxy是工作在网络7层之上。
    2、能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
    3、支持url检测后端的服务器出问题的检测会有很好的帮助。
    4、更多的负载均衡策略比如:动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
    5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
    6、HAProxy可以对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡。

名词解释

vs:Virtual Server 虚拟服务,可称为Director、Dispatcher分发器、Balancer负载均衡器
rs:Real Server 真实服务器
CIP:Client IP 客户端IP
VIP:Director Virtual IP 等同于FIP(流动IP),负载均衡器虚拟IP
DIP:Director IP 调度IP(第二张网卡IP地址)
RIP:Real Server IP 真实服务器IP

转发机制流程

  • VS/NAT: 即(Virtual Server via Network Address Translation)
    也就是网络地址翻译技术实现虚拟服务器,当用户请求到达调度器时,调度器将请求报文的目标地址(即虚拟IP地址)改写成选定的Real Server地址,同时报文的目标端口也改成选定的Real Server的相应端口,最后将报文请求发送到选定的Real Server。在服务器端得到数据后,Real Server返回数据给用户时,需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口,然后把数据发送给用户,完成整个负载调度过程。
    可以看出,在NAT方式下,用户请求和响应报文都必须经过Director Server地址重写,当用户请求越来越多时,调度器的处理能力将称为瓶颈。

  1. 客户端发起请求到load balancer的虚拟ip
  2. load banlancer把客户请的目标地址改写为其中一个real server的,源地址改成不变。
  3. realserver接受请求,并返回给load banlancer响应
  4. load banlancer接受到响应,修改目标地址为不变,源地址改成自己的。
  5. 客户端接受loader banlancer的响应
  • VS/TUN :即(Virtual Server via IP Tunneling)l
    也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样,只是它的报文转发方法不同,VS/TUN方式中,调度器采用IP隧道技术将用户请求转发到某个Real Server,而这个Real Server将直接响应用户的请求,不再经过前端调度器,此外,对Real Server的地域位置没有要求,可以和Director Server位于同一个网段,也可以是独立的一个网络。因此,在TUN方式中,调度器将只处理用户的报文请求,集群系统的吞吐量大大提高。

  1. 客户端发起请求到load balancer的虚拟ip
  2. load banlancer把客户的请求包包裹,然后转发给其中的一个real server。
  3. realserver接受请求,解包。得到客户端发来的原始包。
  4. realserver处理,把结果通过vip直接返回给客户端。
  5. 客户端接受real server的响应。
    注意:
    a. load balancer和realserver 直接通过ip tunnel技术重新封装、解包
    b. load balancer和 realserver 使用相同的vip
    c. load balnacer和realserver可以不再同一个网络
  • VS/DR: 即(Virtual Server via Direct Routing)l
    也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样,但它的报文转发方法又有不同,VS/DR通过改写请求报文的MAC地址,将请求发送到Real Server,而Real Server将响应直接返回给客户,免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的,但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上。

  1. 客户端发起请求到load balancer的虚拟ip
  2. load banlancer把客户发送的包,修改源mac地址为vip的,目的mac地址为realserver的,然后发送给realserver
  3. realserver接受请求,并处理,然后把结果通过vip直接返回给客户端。
  4. 客户端接受real server的响应。
    注意
    a. load balancer和 realserver 使用相同的vip
    b. load balancer和realserver必须在同一个网络,因为load balancer需要知道realserver的mac地址。
    a. load balancer和 realserver 使用相同的vip
    b. load balancer和realserver必须在同一个网络,因为load balancer需要知道realserver的mac地址。

比较

调度算法

Director在接收到来自于Client的请求时,会基于”schedule”从RealServer中选择一个响应给Client。ipvs支持以下调度算法:(1、2为静态调度算法,3、4、5、6、7、8为动态调度算法)
1、 轮询(round robin, rr)

2. 加权轮询(Weighted round robin, wrr)——
新的连接请求被轮流分配至各RealServer;算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。轮叫调度算法假设所有服务器处理性能均相同,不管服务器的当前连接数和响应速度。该算法相对简单,不适用于服务器组中处理性能不一的情况,而且当请求服务时间变化比较大时,轮叫调度算法容易导致服务器间的负载不平衡。

3、目标地址散列调度(Destination Hashing,dh)
算 法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先 根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

4、源地址散列调度(Source Hashing,sh)
算 法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。除了将请求的目标IP地址换成请求的源IP地址外,它的算法流程与目标地址散列调度算法的基本相似。在实际应用中,源地址散列调度和目标地址散列 调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。

5、最少连接(least connected, lc), 加权最少连接(weighted least connection, wlc)——
新的连接请求将被分配至当前连接数最少的RealServer;最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1;当连接中止或超时,其连接数减一。
lc:256A+I=当前连接数 wlc:(256A+I)/W=当前连接数 【A:活动连接数 I:非活动连接数 W:权重值】

6、基于局部性的最少链接调度(Locality-Based Least Connections Scheduling,lblc)——
针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率,从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于其一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。

7、带复制的基于局部性最少链接调度(Locality-Based Least Connections with Replication Scheduling,lblcr)
——也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而 LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求,一台Cache 服务器可能会忙不过来处理这些请求。这时,LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器,映射该“热门”站点到这台Cache服务器,很快这台Cache服务器也会超载,就会重复上述过程选出新的Cache服务器。这样,可能会导致该“热门”站点的映像会出现在所有的Cache服务器上,降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合),当该“热门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache服务器数目。这样,该“热门”站点的映像不太可能出现在所有的Cache服务器上,从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按“最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。

8、 最短的期望的延迟(Shortest Expected Delay Scheduling ,sed)
sed: (A+1)/w=当前连接数

9、最少队列调度(Never Queue Scheduling ,nq)
无需队列。如果有台realserver的连接数=0就直接分配过去,不需要在进行sed运算

相关命令

1
2
3
-c 清除所有配置
-L|l 查看配置
-L -n 查看当前配置

实战

LVS/NAT

nat.PNG
Director准备

1
2
3
4
echo "1" >/proc/sys/net/ipv4/ip_forward
ipvsadm -A -t 192.168.122.2:80 -s rr
ipvsadm -a -t 192.168.122.2:80 -r 192.168.0.151:80 -m
ipvsadm -a -t 192.168.122.2:80 -r 192.168.0.149:80 -m

两个Real server
目的将默认网关设置为Director的ip
route add default gw 192.168.0.148
然后就可以开始测试了

LVS-DR

dr.PNG
Director

1
2
3
4
ifconfig enp0s3:1 192.168.0.155 broadcast 192.168.1.255 netmask 255.255.255.0
ipvsadm -A -t 192.168.0.155:80 -s rr
ipvsadm -a -t 192.168.0.155:80 -r 192.168.0.151:80 -g
ipvsadm -a -t 192.168.0.155:80 -r 192.168.0.149:80 -g

两个Real server
首先为环回接口配置VIP 然后添加路由 最后禁止发送和响应本机虚拟ip的arp,

1
2
3
4
ifconfig lo:1 192.168.0.155 netmask 255.255.255.255
route add -host 192.168.0.155 dev lo:1
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce

Keppalived

安装epel之后可以直接用yum安装
主要的配置文件在/etc/keepalived/keepalived.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
! Configuration File for keepalived
global_defs {
notification_email {
acassen@firewall.loc #设置报警邮件地址,可以设置多个,每行1个,
failover@firewall.loc #需开启邮件报警及本机的Sendmail服务。
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 192.168.200.1 #设置SMTP Server地址;
smtp_connect_timeout 30
router_id LVS_DEVEL # 设置lvs的id,在一个网络内应该是唯一的
}
########VRRP Instance########
vrrp_instance VI_1 {
state MASTER #指定Keepalived的角色,MASTER为主机服务器,BACKUP为备用服务器
interface eth0 #使用eth0作为网卡
virtual_router_id 51 #虚拟路由编号,主备要一致
priority 100 #定义优先级,数字越大,优先级越高,主DR必须大于备用DR。
advert_int 1 #检查间隔,默认为1s
authentication {
auth_type PASS #设置验证类型,主要有PASS和AH两种
auth_pass 1111 #设置验证密码
}
virtual_ipaddress {
192.168.1.200 #设置主DR的虚拟IP地址(virtual IP),可多设,但必须每行1
}
}
########Virtual Server########
virtual_server 192.168.1.200 80 { #注意IP地址与端口号之间用空格隔开
delay_loop 6 #设置健康检查时间,单位是秒
lb_algo rr #设置负载调度算法,默认为rr,即轮询算法,最优秀是wlc算法
lb_kind DR #设置LVS实现LB机制,有NAT、TUNN和DR三个模式可选
nat_mask 255.255.255.0
persistence_timeout 50 #会话保持时间,单位为秒
protocol TCP #指定转发协议类型,有TCP和UDP两种
real_server 192.168.1.132 80 {
weight 1 #配置节点权值,数字越大权值越高
TCP_CHECK {
connect_timeout 3 #表示3秒无响应,则超时
nb_get_retry 3 #表示重试次数
delay_before_retry 3 #表示重试间隔
}
}
real_server 192.168.1.133 80 { #配置服务器节点,即Real Server2的public IP
weight 3 #配置节点权值,数字越大权值越高
TCP_CHECK {
connect_timeout 3 #表示3秒无响应,则超时
nb_get_retry 3 #表示重试次数
delay_before_retry 3 #表示重试间隔
}
}
}

http://superproxy.github.io/docs/lvs/index.html