云中心基于Nginx的动态权重负载均衡算法

谭 畅，谭 歆，胡 磊，熊 炜

(1.重庆邮电大学 通信与信息工程学院，重庆 400065;2.中电科技集团 重庆声光电有限公司，重庆 401332；3.重庆市住房公积金管理中心，重庆 401121)

0 引 言

20世纪以来，互联网技术开始高度发展普及，各行各业对计算机处理能力的要求也不断提高。为了达到此目的，云计算中心得到快速发展[1]。所谓云计算中心，是指通过互联网将共享的软硬件资源和信息按需提供给用户。云计算中心究其本质是庞大的服务器集群。在巨大访问量情况下，如何在服务器集群上解决负载失衡是必须解决的问题。

针对该问题，解决方案之一是采用性能和稳定性更好的硬件负载均衡，如F5硬负载均衡[2]。但是硬负载均衡成本过高，对于预算有限的公司而言，软负载均衡才是更好的选择[3]。在软负载均衡基础上，R. R. Patel等[4]考虑虚拟节点的资源分配问题，提出了一种动态的负载均衡算法，该算法缺陷在于每次分配资源时，需要扫描所有节点的负载信息，算法效率不高。M.J.S.Jane等[5]对分布式环境下的负载均衡策略进行研究，提出了一种基于模糊概念思想的动态负载均衡算法，针对分布式系统的不确定性特征，使用模糊控制方法和模糊集理论，清楚地反映了决策过程中不确定性的影响。L. Chen等[6]经过大量研究，发现负载均衡问题和热力学熵的概念有相通之处，使用了热力学熵的概念和最大熵方法(maximum entropy methods, MEM)的优势解决了集群中的负载均衡问题。郑祺等[7]设计了一种基于内容分类的集群负载均衡策略。该算法首先将用户对服务器的请求进行分类，然后再将分类后的请求均匀地分配至后端各个节点服务器，使得集群内的各个节点服务器得到的请求数量大致相同。此外，该算法还考虑了对负载权值进行等效变换，配合进入临界状态后的动态权值调整策略，防止节点负载倾斜。王红斌[8]提出了一种基于超文本传输协议(hypertext transfer protocol, HTTP)请求内容的分配决策，将HTTP请求分类为静态请求和动态请求2类。针对静态请求，主要对请求的cache命中率进行优化提高，而针对动态请求，则主要考虑了对负载进行均匀分配。同时，此算法还添加了一种动态反馈机制，以对Web服务器集群的负载做出周期性地调整。杜晋芳[9]提出了一种动态的基于Nginx的负载均衡算法。该算法在加权轮询算法的基础上，添加了动态反馈机制，提高了服务器负载均衡能力与负载均衡策略的适应性。

为了实现对服务器的合理任务分配，本文在Linux平台上搭建服务器集群以模拟云中心，在基于Nginx内置的加权轮询负载均衡技术，提出一种改进的动态加权轮询算法。首先，该算法考虑到后端节点硬件存在差异，各台服务器的处理能力有所不同，提出静态权重的概念，以反映硬件性能差异。静态权重计算过程中，由于服务器中的不同硬件对处理请求的性能影响不同，引入了硬件权重系数，权重越大表明此硬件对服务器性能影响越大。计算权重则使用了线性相关系数的方法，通过实验统计请求响应时间与对应硬件使用率，从而得到线性相关系数，进而计算出初始权重，即静态权重。然后，考虑到随着请求的处理，各个服务器节点的负载状况会不停地变化，提出动态权重的概念，引入剩余负载来表征动态权重。最后，结合初始权重与动态权重，得到节点服务器最终权值。周期性收集后端服务器动态性能情况，将旧权值更新，有效达到负载均衡的目的。

1 常用负载均衡技术分析

服务器端的负载均衡表示若干台服务器在后端同时与负载均衡器连接，当某请求来到时，负载均衡器通过所设置的负载均衡策略，根据策略计算选择后端服务器中最合适处理该请求的一台服务器。常用的负载均衡技术有以下几点。

1)硬件负载均衡(后简称硬负载均衡)。从硬件途径实现负载均衡的功能[10]，常用的有F5负载均衡器等。硬负载均衡独立性强，有多样化的均衡策略，能够智能化管理流量，性能出色。但是缺点比较明显，硬负载均衡价格昂贵，中小型企业难以承受。

2)软件负载均衡(后简称软负载均衡)。以软件方式实现负载均衡的功能，在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡。其优点是配置简单，使用灵活且成本低廉。然而其缺点也很明显，相对于硬负载均衡，软负载均衡适用范围更小，并且不支持通过统一资源定位符(uniform resource locator,URL)来检测服务器内部的故障，不支持Session的保持等[11]。

对于软负载均衡，现在常见的有LVS[12]、Nginx[13]、HAProxy[14]和Ribbon等。Nginx是一款优秀的软件负载均衡器，具有并发量高、代码开源等优点，因此，常常被用来作为服务器端的负载均衡器[15]，本文主要研究基于Nginx的负载均衡系统。Nginx的常用负载均衡策略按照各自的特性，可以分为静态负载均衡策略和动态负载均衡策略[16]。静态负载均衡是指负载均衡策略固定不变，不随输入或者服务器状态改变。动态负载均衡与静态相反，在服务器状态变化时，根据某一个或多个服务器性能指标调整负载均衡策略。表1分析了常见的Nginx负载均衡策略。

表1 常见Nginx负载均衡算法分析表

由表1可得，静态负载均衡算法通常配置简单，轻量，在系统请求量小时能够发挥很好的功效。但当请求量过大时，由于服务器性能差异或请求对资源消耗的不同，使用静态负载均衡将导致各个后端服务器节点的负载不平衡，使得整个系统性能降低。动态负载均衡算法都考虑到了后端服务器节点的实时负载情况，根据负载调整任务的分配。但是，在更新动态负载均衡算法时，需要频繁地采集后端服务器各节点的负载信息、计算服务器节点负载量，从而增大系统的通信开销和计算开销，导致响应时间变长，系统性能下降。针对上述问题，本文基于Nginx提出一种改进的加权轮询算法，该算法根据后端服务器节点的负载情况动态地改变权重，弥补了静态负载均衡算法未考虑后端服务器负载情况的缺陷，同时减少了后端服务器的通信开销，达到了降低响应时间、提高实际并发数的目的。

2 改进的加权轮询算法设计

本文提出实现负载均衡的系统模型由3个模块组成，分别为负载信息收集模块、负载信息处理模块和负载均衡算法实现模块，如图1。

负载信息收集模块部署在后端的每台服务器上，通过Linux系统下/proc文件夹周期性收集各台服务器的硬件负载信息，通过Redis数据库将数据传递负载信息处理模块。采集周期不能随意选取，周期过短会增加系统的通信开销，加大负载均衡器的负载和资源消耗，周期过长则会使负载均衡器收集到的负载信息不准确，从而影响负载均衡策略，导致系统性能下降。通过实验，本算法选取采集周期T=9 s。

图1 系统模型图Fig.1 System model diagram

负载信息处理模块和负载均衡算法实现模块均部署在Nginx宿主机上。负载均衡算法模块周期性地获取后端服务器负载信息，根据优化算法计算出节点周期内的最终权值，并写入Redis。负载均衡算法实现模块取出最终权值，并根据改写的Nginx的upstream模块[18]，使加权轮询算法的固定权重变为动态权重，从而动态地改变用户请求的目的服务器地址。

加权轮询算法是Nginx自带的负载均衡算法之一，与原始的轮询算法相比，考虑到各后端服务器性能差异，加权轮询算法对每一个后端服务器赋予了一个权重。在用户发出请求时，Nginx会根据权重分配请求到后端服务器，使性能较高的服务器处理更多的请求，避免了轮询算法均匀分配请求的缺点，从而达到成负载均衡的目的[19]。但是加权轮询算法对于后端服务器权重的配置往往只能根据经验设置，难以精确地衡量各个服务器的性能差异。并且由于服务器对每个请求的处理时间不同，当一个大权值的服务器处理一个需要较长时间的请求时，由于其权值大，后续进来的请求又会被大概率分配到该服务器，造成该服务器过载。本文提出的算法中，静态权值根据服务器各硬件性能计算得出，考虑到了服务器的性能差异，动态权值根据服务器的实时负载计算得出，考虑到了实时负载。静态权值反映了服务器的处理能力，动态权值反映了实时负载，因此，初始权值的选取与动态权值的设计都很重要。

2.1 初始权值的设计

初始权值表征了服务器节点相对的硬件性能情况。设N表示后端服务器节点的性能指标，Nc(Total)、Nm(Total)、Ni(Total)、Nn(Total)分别代表集群所有服务器节点的CPU、内存、磁盘I/O和网络性能情况总和，C(j)、M(j)、I(j)、N(j)分别代表集群内各个服务器节点的CPU、内存、磁盘I/O和网络性能，(1)—(4)式分别表示集群内所有节点性能情况总和。

(1)

(2)

(3)

(4)

想要计算各个节点在集群中所占的静态权重，需要将此节点的各硬件空载性能作为参考指标。其中硬件性能包括CPU性能、内存性能、磁盘I/O性能以及网络带宽性能。另外，由于各个硬件对于服务器性能影响大小不同，故需要对各硬件性能指标进行加权处理。单节点在某一个硬件方面的性能除以集群内所有节点在这一方面硬件性能的总和，乘以各方面对服务器性能影响比重权重，即可求得节点占集群的静态权值，即初始权值为

(5)

(5)式中：Nc(j)、Nm(j)、Ni(j)、Nn(j)分别表示节点的静态CPU性能、静态内存性能、静态磁盘I/O性能以及静态网络带宽性能；Wc、Wm、Wi、Wn分别表示此节点的CPU、内存、磁盘I/O、网络带宽的权重系数；SW(j)代表节点j占集群内所有节点的初始权重；A是调整常量，作用是使得SW(j)为一个整数，使得舍弃的小数部分更小，造成的误差更小。

对于权重Wc、Wm、Wi、Wn的计算，传统方法是根据经验取值，难以精确衡量各个硬件对服务器性能的影响。本文通过计算各方面硬件的使用率与节点响应时间的相关系数对各权重进行赋值。相关系数是研究变量之间线性相关程度的量，因此，该数值能一定程度上从侧面反映出该硬件对于节点性能的影响。硬件初始权重为

(6)

(7)

(8)

(9)

(6)—(9)式中：Wcpu、Wmem、Wio、Wnet代表各方面硬件对节点性能影响的初权重；cov(A,B)为求A、B两项的协方差：Xcpu、Xmem、Xio、Xnet分别表示若干个负载采集周期得到的CPU、内存、磁盘I/O、网络带宽利用率组成的向量；Y表示响应时间向量。由于权重Wc、Wm、Wi、Wn需要满足

Wc+Wm+Wi+Wn=1

(10)

故对Wcpu，Wmem，Wio，Wnet进行归一化处理

(11)

(12)

(13)

(14)

2.2 动态权值与最终权值的设计

确定服务器初始权重后，需要动态调节集群内各个节点的权重。权重的动态调节需要根据节点当前的负载状态来量化，对于负载过高的节点，需要降低其集群内权重；对于负载相对较低的节点，则需要相应提高权重。本文引入节点剩余负载的概念，表征此节点还能承受多少负载。剩余负载主要根据硬件使用率，本机硬件性能和节点平均硬件性能作为输入指标，衡量了当前节点还能够承受多少负载，得到的结果是一个小数。计算公式为

(15)

(15)式中：Lc(j)、Lm(j)、Li(j)、Ln(j)分别表示了节点j的CPU、内存、磁盘I/O速率、网络带宽4种指标的剩余负载，其计算方法为

Lc(j)=Cj·[1-Cu(j)]

(16)

Lm(j)=Mj·[1-Mu(j)]

(17)

Lio(j)=IOj·[1-IOu(j)]

(18)

Ln(j)=Nj·[1-Nu(j)]

(19)

(16)—(19)式中：Cj代表节点j的CPU信息，为CPU主频和核心数量的乘积；Mj表示节点j的内存容量；IOj表示节点j的磁盘速率；Nj代表节点j网络带宽;Cu(j)、Mu(j)、IOu(j)、Nu(j)分别表示节点j上的CPU、内存、磁盘和宽带的使用率；Pc、Pm、Pi、Pn为节点j上的CPU、内存、磁盘和宽带的均值，表示各部分的性能基准。

(20)

(21)

(22)

(23)

经过上述各式的计算，得到节点j的剩余负载量L(j)，可以侧面反映该节点可以继续承受负载的能力。再结合(5)式的节点初始权重，即可计算出节点的最终权重大小，即

DW(j)=B×SW(j)×L(j)

(24)

(24)式中：DW(j)表示节点j在集群中一个周期内的最终权重大小；SW(j)由(5)式可得；L(j)则由(15)式计算可知；B是放大常数，使结果放大若干倍，丢弃的小数部分减小，从而减少误差。在计算完成集群内各个服务器节点的动态权值DW(j)后，将各个最终权重更新到Nginx执行的加权轮询算法中，完成一轮算法流程。

以下给出动态权重负载均衡算法。

步骤1获取各后端服务器节点的无负载状态下的硬件性能情况；

步骤2根据各硬件对性能的影响大小计算出硬件影响权重，可使用参考值:[0.38,0.38,0.12,0.12]，依次代表CPU、内存、磁盘I/O、网络带宽权重；

步骤3根据获取的硬件性能情况和计算出的硬件影响比重计算各后端服务器节点在无负载状态下的权重，并将此权重作为动态权重负载均衡算法的初始权重；

步骤4定时获取各后端服务器的负载信息，包括CPU、内存、磁盘I/O、网络带宽负载；

步骤5根据获取的负载信息计算出各硬件使用比率；

步骤6根据后端服务器节点的硬件性能计算出硬件平均性能基准P；

步骤7根据各硬件使用比率和硬件平均性能基准计算得出各节点剩余负载L(j)；

步骤8根据初始权重和剩余负载计算出最终权重DW(j)，并更新；

步骤9根据所述最终权值为服务器分配相应的负载，在新的收集周期T来到时，跳转步骤4开始新一轮算法流程。

3 实验结果与分析

3.1 实验环境及参数设置

实验采取集群系统结构，如图2。本文搭建本地服务器集群以模拟云中心的服务器集群。系统由一台客户端，一台反向代理服务器(即负载均衡器)，3台后端服务器组成。客户端通过性能测试软件发送负载指令，反向代理服务器上部署Nginx及其相关组件。

图2 实验集群系统结构Fig.2 Experimental cluster system structure

为保证后端服务器有不同的请求处理能力，使3台后端服务器硬件设施有所不同。系统所有设施软硬件信息如表2。

表2 实验集群配置

3.2 结果分析

本文使用了Httperf和Autobench对系统性能进行测试，2个工具都运行在Linux系统上，用于测试服务器性能情况。测试分为3个方面：①单一服务器与服务器集群在不同请求并发数下的响应时间对比；②在不同的请求并发数下，分别对Nginx的加权轮询算法(简称WRR算法)、最小连接数算法(简称least-con)和本文提出的改进算法(简称动态权重算法) 的响应时间进行对比测试；③在不同的请求并发数下对上述3种算法的实际并发连接数进行测试。实验进行10次，并对记录的实验数据取均值。得到的单一服务器与集群服务器响应时间对比、集群内各算法响应时间与并发数关系、实际并发数与请求并发数关系如图3—图5。

图3 单一服务器与服务器集群响应时间Fig.3 Single server and server cluster response time

图4 算法响应时间与并发数关系图Fig.4 Relationship between algorithm response time and the concurrent number

图5 算法请求并发数与实际并发数关系图Fig.5 Relationship between the number of algorithm requests and the actual number

从图3可知，单服务器对并发连接的处理能力为150～200左右，并且响应时间随着请求并发数的增加而迅速上升；同时服务器集群对递增的请求并发数的响应时间则一直保持平稳，在400并发数下保持在4.1 ms左右。

从图4可以看出，平均响应时间总体而言是随着并发数量的增加而增长的。在并发数为700之前，3种算法的响应时间没有明显增长趋势，均有足够的能力处理。在并发数为700后，WRR算法的响应时间开始大幅上升，高于least-con算法和本文提出的动态权重算法。在并发数为1 000后，动态权重算法响应时间开始大幅上升，但仍然低于WRR算法和least-con算法。并发数1 100时，动态权重算法与WRR算法相比，响应时间降低了28.75%，与least-con相比降低了20.97%。在并发数较高的1 400时，动态权重算法比WRR算法降低11.77%，比least-con降低13.4%。总体来看，动态权重的平均响应时间为3种算法中最短，表明本文提出的动态权重算法能够有效地在高并发数情况下合理分配请求，从而减少服务器响应时间，提升系统性能。

从图5可以看出，在并发数达到700之前，3种算法的实际并发数与请求的并发数基本相同，说明3种算法在此并发数下都可以很好地达成负载均衡效果。在并发数为700后，WRR算法开始出现实际并发数丢失的情况。并发数为900后，least-con算法的实际并发数也开始丢失。在并发数达到1 000时，动态权重算法的实际并发连接数才有丢失的情况。动态权重算法的实际并发数基本都要持平于请求并发数，当请求并发数达到1 000时，动态权重算法的实际并发连接数才有丢失的情况。并发数1 100时，动态权重算法比WRR算法实际响应数高11.25%，比least-con高4.2%；并发数1 400时，动态权重算法比WRR算法实际响应数高22.85%，比least-con高10.65%。从整体来看，动态权重算法的实际并发数基本都要持平或高于其余2种算法，表明本文提出的动态权重算法优于WRR算法和least-con算法。

4 结束语

本文针对云中心服务器负载失衡问题，提出了一种基于加权轮询算法的动态权重算法。算法通过对节点的各个硬件指标权重、集群中节点的初始权重和动态权重进行建模，根据采集的服务器节点的实时负载情况，动态修改各个节点的权值，以达到实现请求的负载均衡目的。实验结果表明，在并发数较高情况下，本算法能够合理地分配请求到后端服务器节点，有效地提高处理请求的效率，提升负载均衡系统性能。