基于ESXi性能计数的Nginx负载均衡算法研究

2020-03-10潘谜，李旺

集美大学学报（自然科学版） 2020年1期

潘谜，李旺

(1.集美大学理学院，福建厦门 361021；2.集美大学计算机工程学院，福建厦门 361021)

0 引言

Nginx[1]是一款开源的轻量级Web服务，提供高性能的HTTP/HTTPS服务。Nginx因其具稳定性、低资源消耗、高性能等特点，近年来广受主流网络服务商的青睐。百度、京东、淘宝、新浪、腾讯等均使用Nginx或其扩展作为Web服务。目前，对Nginx的研究主要集中在两个方面：一个是模块扩展(如淘宝的Tengine)，另一个是反向代理的负载均衡及并发研究。关于Nginx负载均衡的研究，主要有两个方向：一类是基于非反馈的均衡调度算法；另一类是基于反馈的均衡调度算法。基于非反馈式的均衡调度算法主要有Nginx内置的轮询算法(round robin)、基于权重的调度算法(Weight)、IP散列调度算法(IP hash)、URL散列调度算法(URL hash)等，这些算法简单、资源消耗少，但在一定条件下会导致调度严重失衡。基于反馈式的均衡调度算法是根据集群中各节点实际负载情况，决定下一步的调度策略，目前主要集中在集群各节点权重及实际负载的计算算法的改进，如Nginx的加权最小连接调度算法(weighted least-connection scheduling)[1]、动态反馈负载均衡算法[2]、动态自适应负载均衡算法[3]、自适应和预测的轮询算法[4]、基于HAProxy的轮询算法[5]、云环境下自组织感知体均衡算法[6]。一般算法中使用的评价参数包括连接数、CPU使用率、内存使用率、I/O使用率、网络使用率、请求响应时间等[7-9]，根据这些参数动态计算权重，用于决定下一次请求的分配策略。在一定程度上，这些改进后的算法能够提高部分系统性能，但仍存在不足之处：1)评价参数需要由各节点计算并收集，这不可避免地增加了系统开销，且异构操作系统兼容性也会增加模块升级及维护难度;2)不均衡任务分配策略中仅仅考虑异构参数的同一化权重，在极端情况下，有可能导致瞬时节点瓶颈，甚至导致节点崩溃。

ESXi是VMware vSphere[10]的核心组件，提供虚拟化服务，是专门为运行虚拟机、最大限度降低配置要求、简化部署而设计的。它具有可靠、安全、简化部署和配置、减少管理开销等特性。ESXi提供的功能有镜像生成器(image builder)、面向服务的无状态防火墙、主机硬件全面监控、虚拟机迁移(vMotion)、安全系统日志(secure syslog)、VMware vSphere Auto Deploy、扩展增强型Esxcli框架，以及新一代的虚拟机硬件[11]。ESXi扩展了SNMP V3支持，实现主机硬件资源的全面监控，同时提供VMware API[12]，支持多种编程环境，为主机管理、自动化部署与管理提供接口。ESXi性能计数是VMware API提供的功能之一，包括主机和虚拟机CPU、内存、网络、磁盘等统计量。

针对上述问题，本文引入ESXi性能计数(ESXi performance counter,EPC)，提出基于ESXi性能计数的均衡算法(dynamic weight based on ESXi performance counter,DWEPC)，旨在使用近似实时的性能指标，预测并指导均衡分配策略，降低均衡模块的复杂度及各节点的通信开销，从而达到提升性能的目的。

1 负载均衡算法

Nginx反向代理主要由upstream模块实现。它处理用户请求的一般步骤如下：1)反向代理接受用户的请求；2)调用负载均衡算法，获取可调度的子节点索引值；3)将用户请求转发给步骤2)中返回的子节点，并等待响应；4)转发子节点响应给用户。其中，负载均衡调度算法为反向代理提供当前请求转接的子节点索引，它的优劣直接影响调度的性能。

1.1 权重更新算法

对于n个节点的Nginx集群，本研究选取CPU、内存、网络、磁盘I/O四个指标作为负载均衡算法调度指标。对于节点i(i=1,2,…,n)，其固有性能表示为ci=(ci1,ci2,ci3,ci4)，代表物理资源的最大限值。则n个节点固有性能使用矩阵表示为：C=(cij)n×4。

由于任何反馈式的性能计数都是离散的(这是综合考虑性能及信息采集的特点而定的)，ESXi性能计数也是离散的。考虑最近m个采集的计数(当采集数量超过m时，舍弃开头的数据，仍然只保留m个窗口大小)，每次采集的计数表示为n行4列矩阵，

(1)

(2)

∂Ψ/∂wi=0,i=1,2,3,4。

(3)

解公式(3)所示的方程组得到向量W，即为当前权重向量。

由于性能计数是每隔一段时间采集一次，因此权重向量也是每隔一段时间更新一次，与性能计数同步。

1.2 主调度算法

2)计算L=QW-Vm，L表示各节点剩余可分配次数向量；

3)在向量L中寻找最大元素对应的行标k(若多行同时最大，则随机选取一行)；

4)更新Vm的第k行元素的值：vkm=vkm+1。

输出：k。

DWEPC算法的返回值表示待分配的子节点索引，反向代理根据该索引值选择请求转接的子节点。

1.3 均衡指标

2 试验结果

2.1 测试环境

测试环境搭建于VMware ESXi 6.5 Update 1平台上，双路Intel Xeon L5630，CPU主频2.13 GHz(4核8线程)，内存40 GB。搭载Nginx的虚拟机节点配置有双核CPU、2GB内存、40GB硬盘(精简置备)、VMXNET3网卡(虚拟万兆网络适配器)。

提供Nginx Web服务的主虚拟机节点安装Nginx-1.17.1，其余每个虚拟机子节点安装Nginx-1.17.1、Tomcat 9.0.21。

测试时，取n为5，即包含5个子节点，每个子节点中运行3个Tomcat实例，共15个Tomcat实例。其中，主节点worker进程数设置为8，子节点设置为4。

由于实际应用时，CPU、网络资源尤其关键，它的性能直接影响到其他几个指标，因此本文设计的测试用例也主要针对CPU、网络的调度。测试图例T1的内容为5个静态页面，大小分别为1 KB、16 KB、64 KB、512 KB、1 MB；测试用例T2的内容为5个动态页面，页面中分别包含50k次加法运算，k=1,2,…,5。

为模拟现实操作，每个页面请求之间间隔2 s。测试用例T1主要针对CPU和网络负载，而T2则主要测试CPU负载均衡。

2.2 试验结果及分析

选取Nginx最具代表性的Weight均衡策略，与本文提出的DWEPC算法(取m=20，采集时间间隔为3 s)对比，在5个子节点的环境下，分别运行T1和T2测试用例。性能测试终端使用Apache JMeter，虚拟用户数(virtual user,简写VU)分别取100、500、1000、1500、2000，运行10 min，最终每个节点采集N次(N由运行时长和采集时间间隔确定)。

由于测试用例对于内存需求趋于常量，且Nginx本身拥有页面缓存模块，使得磁盘访问也基本可以忽略不计。本文仅列出CPU、网络的测试结果，在不同虚拟用户数(VU)下分别运行3次取平均值，所得的均和方差如表1所示(为了方便数值比较，这里取Nδ2(k)为均和方差)。

表1 不同VU下的均和方差

从表1可以看出，两种算法在T1测试的CPU均衡、T2测试的网络均衡调度上性能相当，但在T1的网络均衡、T2的CPU均衡调度上，DWEPC总体上拥有更好的性能(见图1、图2)。

进一步，考察两种算法在T2测试下，虚拟用户数(VU)为1000时，某次运行时各节点CPU实际负载走势，分别如图3、图4所示。图3中，节点5的CPU负载几乎都在100%附近，而其他几个节点却都在0～20%之间，即，节点5几乎承担了所有的CPU运算工作。图4中，所有节点的CPU负载几乎都在变化，没有出现某一节点过载的情况，因此更能合理利用各节点资源，从而提升整体吞吐率。尽管图4看起来杂乱无章，但那是因T2测试用例中的页面极端不平衡导致的，如，第5个页面是第1个页面计算量的6.25×106倍。

由此可见，DWEPC算法能够根据ESXi性能计数，更均衡地实现各节点负载调度。