基于Nginx负载均衡的动态改进算法
2020-04-09张宇星马明栋王得玉
张宇星，马明栋，王得玉
(1.南京邮电大学 通信与信息工程学院，江苏 南京 210003；2.南京邮电大学 地理与生物信息学院，江苏 南京 210003)
0 引 言
随着互联网的快速发展，PC端、移动端的逐渐兴起，早期的单台服务器已经难以处理用户多样化的并发请求。通过服务器集群的负载均衡技术能有效地分散单台服务器的访问压力，还能有效避免当一台Web服务器发生故障或遭到攻击无法对外提供服务时，整个服务无法进行的状况[1]。当集群中的Web服务器宕机时，通过负载均衡技术可以将访问流量转移给集群中其他的服务器。负载均衡技术通过均衡后端服务器的压力，高效利用所有的后端服务器，提高整个服务器集群的性能。负载均衡的实现主要包括硬件和软件两个方面[2]。与基于硬件的负载均衡设备相比，基于软件的负载均衡不需要独立的机器设备，通过在服务器上安装和配置软件来实现负载均衡，配置灵活，可扩展性强，成本也较低[3]。LVS和Nginx是比较常见的基于软件的负载均衡，LVS工作在网络的第四层，作为请求的转发，没有流量，而Nginx工作在网络的第七层，可以高效地处理HTTP应用，可使用的场合也多于LVS，因此文中将主要研究Nginx的负载均衡。
Nginx是由俄罗斯人开发的一款开源Web服务器软件，占用资源低，处理请求快，模块化设计，可扩展性好，配置灵活，采用异步、非阻塞、事件驱动的方式处理请求，并发量高，具有反向代理和缓存服务功能[4-5]。在实际中应用非常广泛，目前国内的很多企业也都采用Nginx作为负载均衡和反向代理的Web服务器[6]。
负载均衡算法对Nginx负载均衡技术起着关键作用，文中通过研究Nginx自带的负载均衡算法，提出一种动态的改进算法，以有效提高服务器集群的性能。
1 Nginx体系架构
Nginx服务器启动后，产生一个Master进程，由Master进程产生多个Worker进程。Master进程负责管理多个Worker进程，而Worker进程则负责接收并处理客户端的请求[7]。Nginx的主要配置文件nginx.conf在编译安装好的nginx/conf目录下可以找到，打开文件可以观察到其大致结构，如图1所示。在文件中配置worker进程数、连接数等参数可以达到Nginx性能调优的效果。其中全局块主要是配置Nginx的用户组，工作进程数，进程pid的存放路径等。events块主要配置工作进程的最大连接数。http全局块主要配置sendfile和超时信息以及文件的引入等。server块和location块主要配置主机的服务信息等。
图1 nginx.conf配置文件结构
Nginx负载均衡的实现就是源于Nginx高效的反向代理服务[8]。反向代理服务的对象是服务器端，客户端并不知道实际处理请求的机器是哪一台。反向代理服务器收到来自客户端的请求，将请求转发给后端服务器处理。外部客户不能直接访问真实的服务器,即使遭到恶意攻击，也能保证后端服务器的安全[9]。Nginx的反向代理服务由proxy_pass URL来配置，反向代理配置如下：
upstream mynginx{
server 192.168.168.161;
server 192.168.168.163;
}
server {
listen 80;
server_name localhost 192.168.168.162;
resolver8.8.8.8;
location / {
proxy_pass http://mynginx;
include proxy_params;
}
}
当客户端的请求发送过来时，Nginx利用proxy_pass指令进行代理转发，然后在upstream模块中根据负载均衡算法将请求分配给后端服务器[10]。
Nginx服务器接收客户端的请求时，并不会立即转发给上游的Web服务器，而是如图2所示，在Nginx反向代理服务器上设置缓存，以键值对的形式存储在内存或者硬盘中，获得完整的HTTP请求包后再将完整的请求发给上游服务器[11]。并且对于一些静态资源，Nginx通过使用proxy_cache将用户的请求缓存到本地一个目录。当下一次有相同请求转到代理服务器时，会先查看本地缓存，如果找到了该请求则直接返回给客户端，如果本地缓存中没有找到，再将请求转发到后端Web服务器，减少了Nginx与后端Web服务器的连接次数，加快了响应速度，提高了Nginx处理性能[12]。
图2 Nginx反向代理模型
2 算法改进设计
常见的负载均衡算法主要有加权轮询、最小连接数、ip_hash、url_hash和fair算法[13]。加权轮询算法按照预先分配的权重轮流分发给各个服务器节点，没有考虑服务器的连接数和实时负载。ip_hash和url_hash针对Http应用本身来做分流策略，将客户端请求按ip或url的哈希结果分配[14]。可以避免用户每次访问的服务器不同，使得session落在不同的服务器上，造成用户端cookie验证失败等问题，但是容易导致某台服务器节点的压力变得非常大而其他节点却空闲的不均衡现象。最小连接数和fair算法考虑的指标也过于单一，因此算法的均衡效果也不是很明显[15]。
文中在Nginx的官网下载nginx-1.14.2版本的源码，在源码的src/http目录下可以找到默认的加权轮询算法ngx_http_upstream_round_robin.c文件。文件中的ngx_http_upstream_get_peer函数计算每一个后端服务器的权值，在函数中定义指针*peer和*best,通过for循环遍历后端服务器。再通过best指针选取权值最大的服务器，将 best指针作为ngx_http_upstream_get_peer函数的返回值。函数中权值的部分计算代码如下：
peer->current_weight+=peer->effective_weight;
total+=peer->effective_weight;
if(peer->effective_weight
peer->effective_weight++;
}
if(best==NULL||peer->current_weight>best->current_weight) {
best=peer;
p=i;
}
文中提出的动态改进算法是在加权轮询算法的基础上通过动态收集实时负载和硬件利用率，建立数学模型，得出动态反馈的负载均衡算法。
首先用Si表示服务器集群中的每个节点，Ci表示每个服务器节点的性能，服务器节点的默认权值为：
(1)
用Uc(i)，Um(i)，Ud(i)和Ub(i)分别表示周期T内单个节点的CPU、内存、磁盘IO和网络带宽的占用率，不同指标对服务器性能影响不同，Kc,Km,Kd,Kb分别表示CPU、内存、磁盘IO和网络带宽对服务器的影响因子[16]，并且Kc+Km+Kd+Kb=1。每个节点性能的实时负载比重WN(i)为：
WN(i)=
(2)
在最小连接数算法中，当有请求分发过来时，连接数加1，当请求处理完成时，连接数减1。文中提出的动态改进算法也将考虑每个节点的实时连接数Ni={N1,N2,…,Nn}，每个节点的连接数占比为：
(3)
当服务器节点负载较重时，请求的响应时间就比较长，所以响应时延也是衡量服务器节点实时负载的一个重要因素。然后考虑请求的响应时间，在Nginx的日志文件中提取每个节点服务器在周期T内的最近一次请求时间，Ti={T1,T2,…,Tn}，后端服务器集群最近一次的响应平均时间为：
(4)
服务器节点的响应时间比重为：
Wt(i)=Ti/Avg(T)
(5)
综合节点的实时性能，连接数和响应时间建立数学模型：
Wi=(1-WN(i))*Wd(i)+(1-Wc(i))*
Wd(i)+(1-Wt(i))*Wd(i)
(6)
将三个因素的权值动态相加得到实时的权值，即每个服务器节点的权值计算如下：
Wi=(3-WN(i)-Wc(i)-Wt(i))*Wd(i)
(7)
将计算所得结果与ngx_http_upstream_get_peer函数中的effective_weight结合，通过best指针返回权值最大的服务器节点。
3 实验环境搭建与测试
实验在虚拟机中搭建了五台服务器，一台作为客户端测试连接，一台作为反向代理服务器，其余三台作为后端服务器。在后端服务器中搭建Nginx+php环境来实现动态的网站运行环境。Nginx通过fastcgi接口来实现与php文件的交互。在server模块的location配置中引入一个index.php动态资源文件，放置在location中的root目录下，location的配置如下：
location ～ .php$ {
root html;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
实验环境搭建好后使用Httperf和Autobench来进行性能测试，Httperf可以根据每一次不同的测试要求产生不同的工作负载，而Autobench是一款基于Httperf开发的perf 脚本工具，可以根据参数设置自动进行并发测试，并将结果保存在.tsv文件中[17-18]。在客户端中键入如下命令进行测试：
autobench --single_host --host1 192.168.168.162 --port1 80 --uri1 /index.php --quiet --low_rate 20 --high_rate 200 --rate_step 20 --num_call 10 --num_conn 500 --timeout 5 --file results.tsv
实验中分别对默认轮询算法、最小连接数算法以及文中提出的动态反馈算法进行测试，将得到的三个results.tsv文件进行整理，得到的统计数据如表1和表2所示。
表1 三种算法的响应时间
表2 三种算法的实际并发连接数
从表中数据可以看出，当并发量较低时，三种算法的响应时间相差不大，但当并发量达到600以上时，三种算法的响应时间都迅速增大，并且最小连接数算法的响应时间要小于默认轮询算法，而文中提出的动态反馈算法响应时间则要优于其他两种。Autobench测试时设置了timeout为5秒，超时5秒的连接都会当作请求失败的连接。从表2中也可以看出，当并发数大于1 200时，实际处理的连接数都出现了不同程度的下降，但从整体来看，文中提出的动态算法成功处理的连接数要高于其他两种算法。
4 结束语
服务器集群技术和负载均衡技术能有效减轻Web并发请求所带来的后端服务器的压力。而负载均衡算法又对负载均衡技术有着重要的影响。文中所提出的负载均衡优化算法不用每次都去实时地更新权值，而是在周期T之后重新收集负载信息，计算权值，分配权值，减少了每次都去重新计算、分配权值带来的不必要的消耗。通过实验数据对比，验证了优化后的算法对负载均衡的性能有一定的提升。同时，在研究过程中，该算法也存在不足之处，对于时间周期T的取值，周期太长不能有效反映当前服务器节点的性能，周期太短频繁取值造成性能下降，对于这两方面的平衡还有待进一步的研究。
