LB:实用的负载均衡群集原理及实现

距离小编将HA群集已经有一个多月啦,还记得小编在HA群集最后提出的一个小问题么,没有企业会拿HA来做一些普通业务的,HA一般都是来做一些关键性业务的,那么在这篇博客中小编就来讲讲LB群集(负载均衡群集)的原理以及实现啦 

一、负载均衡群集总体架构

使用负载均衡群集能实现综合业务的海量并发,在负载均衡架构中,Director(dispatcher)负责接收客户端请求,并将请求按照某种算法分发到后台真正提供服务的服务器上。按照层次来划分,有四层交换和七层交换。为了实现这种技术可以基于硬件来实现,常用的有F5(四层交换),也可以基于软件来实现ipvs(四层交换)、squid(七层交换)、nginx(七层交换) 

二、使用LVS(Linux Virtual Server)来实现负载均衡

在linux的2.4之后的内核中有一种实现数据包请求处理的模块叫ipvs,并且提供了的相关客户端软件ipvsadm来实现规则的定义以完成对请求数据包的处理,小编的内核是2.6.18,看看它的内核配置文件可以发现IPVS的

clip_image002

LVS的整体架构如图2-1所示:

clip_image004

图2-1

VIP(Virtual IP):Director对外呈现的IP地址,用户可以通过VIP来获取相关服务;

DIP(Director's IP):Director用来和Real Server通信的IP;

RIP(Real IP):Real Server的IP;

三、LVS的模型分类

根据Director和后端服务器的通信方式,LVS大致可分为三类:Network Address Translation(LVS-NAT)、Director routing (LVS-DR )、IP tunneling (LVS-TUN ),小编就每一种分类做一下简要说明

1、Virtual Server via Network Address Translation(LVS-NAT)

通过网络地址转换,Director重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的Real Server;Real Server的响应报文通过Director时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。可以想象一下,所有的数据请求都经过Director,那实现Director的服务器压力三大啦;

2、Virtual Server via Direct Routing(LVS-DR)

为了解决LVS-NAT的的问题,便产生了LVS-DR,外界用户发送每次发送数据请求的时候是要经过Director的,Director通过一定得调度算法选择Real Server并将收到的客户端请求报文的目标MAC改写成为被选Real Server的MAC地址,而Real Server将响应客户端的时候并不经过Director了。

3、Virtual Server via IP Tunneling(LVS-TUN)

Director把请求报文通过IP隧道转发至Real Server,而Real Server将响应直接返回给客户,所以Director只处理请求报文。由于一般网络服务应答比请求报文大许多,采用 LVS-TUN技术后,集群系统的最大吞吐量可以提高10倍。

四、Director采用的调度算法

Director支持的调度算法可以直接从内核配置文件中看到的,如图4-1所示:

clip_image006

图4-1

当然这九种调度算法又可以分为两大类,分别是静态调度和动态调度啦,小编这里做一下解释:

1、固定调度算法

按照某种既定的算法,不考虑实时的连接数予以分配:

A、Round-robin(RR)轮循:将外部请求按顺序轮流分配到集群中的Real Server, 它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载;

B、Weighted round-robin(WRR)加权轮询:给每台Real Server分配一个权值,权值越大,分到的请求数越多;

C、Destination hashing (DH)目标散列:根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。来自于同一个IP地址的请求都被重定向到同一台Real Server上,保证目标地址不变;

D、Source hashing(SH)源地址散列:根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。Director必须确保响应的数据包必须通过请求数据包所经过的路由器或者防火墙,保证源地址不变。

2、动态调度算法

通过检查服务器上当前连接的活动状态来重新决定下一步调度方式该如何实现:

A、Lease Connection (LC) 最少连接:哪一个Real Server上的连接数少就将下一个连接请求定向到那台Real Server上去。算法实现:连接数=活动连接数*256+非活动连接数;

B、Weight Least-Connection(WLC) 加权最少连接:在最少连接的基础上给每台Real Server分配一个权重。算法实现:连接数=(活动连接数*256+非活动连接数)÷权重,是一种比较理想的算法;

C、Shortest Expected Delay (SED) 最短期望延迟:不再考虑非活动连接数,算法实现:连接数=(活动连接数+1) *256 ÷权重;

D、Never Queue (NQ) 永不排队算法:对SED的改进,当新请求过来的时候不仅要取决于SED算法所得到的值,还要取决于Real Server上是否有活动连接;

E、Locality-Based Least-Connection (LBLC) 基于本地状态的最少连接:在DH算法的基础上还要考虑服务器上的活动连接数;

F、Locality-Based Least-Connection with Replication Scheduling (LBLCR) 带复制的基于本地的最少连接:是LBLC算法的改进。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.heiqu.com/e03a22d8faadec57b8134b44918d408a.html