基于动态反馈的负载均衡方法研究

杨杭，张昕，赵建平

（长春理工大学 计算机科学技术学院，长春 130022）

近年来，基于互联网的各类应用服务已逐步深入到人类生产生活的各个方面，在开展服务过程中，大量的服务请求在单位时间内到达服务端，并要求后者以尽可能短的延迟完成对服务请求的应对处理。因此，服务端的吞吐能力直接影响了应用服务质量，其直接体现为支撑服务能力的服务器（集群）所具备的并发处理能力，较高的并发处理能力意味着同时单位数量的服务请求能够在相对更短的时间内被应对处理［1］。作为一种提高并发处理能力的措施，负载均衡技术采用多点分发的方式实现对大量服务请求的均衡分组，使服务器集群中的多个工作服务器（按其在集群中发挥的作用可分别称为“总控节点”和“工作节点”）各自独立地对近似等量的服务请求实施接入，达成并行化的应对处理，从而降低服务请求的响应延迟，提高服务请求的接入效率。

本文提出基于动态反馈的负载均衡方法，通过动态反馈机制，实时收集各工作节点的运行情况，从而在服务请求接入过程中根据运行条件动态调整工作负载的分配方案，使各工作节点在可行的范围内承担相近的工作负载，避免负载分配不均衡。该方法能够有效适应并发处理过程中的动态运行条件，具有较好的实时性和灵活性。

1 相关工作

最早的均衡机制是通过循环DNS（Domain Name System）实现的［2］，该机制通过DNS配置使一台拥有域名的主机（称为工作主机）具备多个映射地址，到达的用户服务请求在与工作主机进行交互后，由后者采用轮询方式将请求分配至特定的映射地址，即另外实际开展处理响应的服务单元，从而实现由不同服务单元对多个服务请求进行应对处理，在一定程度上达到了负载均衡的效果，但此种方式下的负载分配效率相对较低，且受限于网络拓扑结构，因此其负载均衡效果并不太理想。

Nikolaou等人［3］通过研究认为，工作节点的资源实际利用率是达成更好负载均衡效果的核心因素，负载均衡方案的主要工作目标之一即是合理规划工作负载的分配，使各工作节点的资源均等充分地发挥效能。Cardellini和 Bryhni［4］等人对多种负载均衡方法进行了对比研究，主要分析了基于客户端、服务器、DNS以及中心分配器等负载均衡策略的优缺点，比较了各种实现算法的性能，为负载均衡方法体系提供了有力支持。关于负载均衡的产品，目前国内外已经有不少公司在从事基于软件和硬件的负载均衡产品研发。其中，基于软件负载均衡的产品有LVS、Lander Balance和Check Point等［5］。

2 基于动态反馈的负载均衡方法

在面对用户的大量并发服务请求时，实施负载均衡的核心任务是通过合理的任务调度安排策略，使得服务器集群在执行服务任务过程中满足来自总体完成时间、任务吞吐量、资源利用效率以及可扩展性等多方面的约束。本文提出的基于动态反馈的负载均衡方法，重点考虑工作节点自身负载状况和接入任务情况的动态性，形成并发请求工作条件下的任务分配及执行近优解决方案。

本文主要围绕以下四个方面构建负载均衡方法：

（1）节点参数：即各个工作节点即时的负载情况，包括运行队列中的任务数目、系统调用的速率、空闲存储器的大小等。

（2）评估决策：根据当前工作节点的负载情况评估是否需要将后续到达的任务分配转移至其他工作节点并处理。本文中采用阈值限定的方式对待任务转移进行判定。

（3）转移位置：对于适合转移到其他工作节点的任务，要明确任务转移的目标工作节点。

（4）维持手段：确定可进行转移的任务列表，进而通过任务传输实现负载调度，保持负载均衡。

图1 负载均衡方法执行流程

通过对上述四个方面进行综合分析，首先对运行场景中的相关可用资源情况进行收集和识别，具体包括：可用的工作节点、节点的处理能力、可用的存储空间和内存；然后分析和判断当前接入任务的执行情况，如果所有任务均已完成，则转至等待新任务的接入；如果存有尚待完成的任务，则对任务需求进行分析，具体需求包括：任务的到达率、任务数量以及各项任务对内存的预计占用情况，并根据任务需求相应调整任务处理策略及参数；接下来采集各工作节点中任务运行队列参数，以实现对当前处理性能的判断，从而确定执行负载均衡措施的逻辑起始节点及可行时间点；在此之后配置和执行负载迁移方法，即选定需要迁出的任务条目及任务所在的工作节点，并将其迁入另外的工作节点；接下来识别是否有新的任务等待接入，如果有新任务，则转至之前对运行场景中可用资源情况的收集和识别，并执行后续的相应流程；如果没有新任务，则完成当前负载均衡方法的执行，如图1所示。

2.1 动态反馈策略

针对并发处理过程的实际情况，本文提出了面向全局均衡质量的工作情况动态反馈策略，综合考虑负载均衡场景的关键要素及其相互作用。在开展请求接入和服务响应的过程中，持续采集和分析各工作节点负载情况，重点围绕全局的负载均衡质量执行相应任务处理，结合动态反馈方式，保持均衡措施的合用和有效。

本文参考了控制论中的反馈原理动态地分析工作节点当前的运行状况，评估负载指标，进而调整和规划任务负载均衡的方案，保障工作性能的持续有效，如图2所示。

图2 基于动态反馈的评估机制

本文以各节点的工作状态作为出发点对其资源占用情况进行持续评估，并分析任务执行过程中的各种特征数据，持续评估实施负载均衡方案后的服务器集群系统性能，相应调整任务分配方案。其具体的评估任务包括两项：

（1）对工作节点的负载情况评估；

（2）根据负载情况评估，制定负载阈值设定策略，并根据评估结果对阈值进行动态调整。

节点负载情况评估主要包括对工作节点自身情况的评估和对各节点间交互情况的评估，其对应的工况指标参数分别是：

其中，idle表示在对应时间点CPU的空闲时间，cpu表示相应的CPU总运行时间。

其中，用MemTotal表示RAM总共的物理空间，用MemFree表示未使用的内存。

综上，在完成对工作节点内各部件工作情况评估的基础上，节点工况指标表达为：

其中，σ代表对应部件在评估中所占的衡量权重，称为部件性能权重，上述各部件工况指标均采用使用率表达，其取值范围为0%至100%，0%代表该部件未被使用，100%代表该部件已达到满负载工作状态。

相应的节点交互工况指标表达为：

其中，m为当前工作节点保持与其他节点连接的总数表示当前工作节点与标识编号为k的其他节点的连通交互情况，如果存在交互连通（即connected），其取值为1，否则（即disconnected）为0。

通过上述指标，对每个工作节点的负载指标评估表达为：

其中，θ表示对应指标在评估中所占的衡量权重，称为节点性能权重。

通过上述计算过程，可根据上述工作节点的负载指标评估结果构建调度策略。其中，设定两个阈值作为调度决策参数，分别为δ1和δ2，并且δ1＜δ2。

综合分析公式（3）、（4）、（5）可以得知，由变量标识S表征的指标参数直接反映了相关部件以及交互活动在负载均衡过程中的负载情况，部件性能权重σ和节点性能权重θ反映了各项负载情况在负载均衡方案中的关键程度。因此，上述公式中权重参数的设定能够将负载均衡任务场景引入到调度方案中，其取值主要来源于数据中心管理人员的经验设定，并通过长时间的运行积累逐步形成稳定配置。另外，通过实际工作中积累的经验和对服务器系统性能表现的分析，推荐的调度决策初始参数（即δ1和δ2）取值分别设定为0.5和0.8。

在负载均衡运行过程中，需要通过连续且持续的负载参数采集，形成周期性的负载指标评估，根据负载均衡方案运行的具体场景，可对采集周期进行调整，以减小由频繁评估参数采集造成的系统性能降低和能量损耗。根据实际工作经验表明，评估参数的采集周期可根据服务请求频度相应设定在10秒至90秒之间。

在基于动态反馈策略执行负载均衡措施过程中，经分析发现，引发集群中任务动态调整进而带动反馈动作的情况主要发生在新加入任务的实时载入、网络带宽情况的实时动态变动以及各工作节点即时的负载能力调整等三个场景中。

在新任务载入阶段，如果有新的工作节点被纳入到负载均衡系统方案中，此类工作节点的加入基本不会对整体任务规划和集群性能表现产生消极影响。新加入的工作节点会被优先配置执行完成时间相对较短的任务，并按照上述策略执行相应反馈措施。

2.2 负载均衡任务调度

在执行负载均衡解决方案的服务器集群中，其总控节点部署的负载均衡算法综合考虑所有工作节点的实时负载情况和处理性能，不断调整任务分布的比例，避免任务分配不平衡造成的各种问题。由于负载均衡处理的任务量随时间动态变化，通过对阈值的动态调整，使各工作节点工作情况大致等于负载阈值，实现任务均衡分配并充分发挥各工作节点的处理效能。

图3 负载均衡工作过程

负载均衡的具体工作过程为（参见图3）：

（1）在总控节点开展负载均衡管理，根据现有的节点工作情况和负载均衡阈值，分析系统负载情况；

（2）通过节点之间的连接，总控节点将工作任务分配至各个工作节点；

（3）各工作节点对接收到的任务进行处理；

（4）收集各个工作节点的实时负载状态信息；

（5）根据收集的负载状态信息，计算和评估各节点工作情况；

（6）对比节点的工作情况和负载均衡阈值，根据预设的均衡策略，在后续的负载均衡管理中相应调整负载均衡阈值。

在负载均衡工作过程的信息收集阶段，总控节点对其他工作节点的实时运行情况信息进行收集，收集的信息主要包括所在节点的负载情况、任务分配情况、响应速度等信息。收集过程根据策略以及实际情况，一般情况下都是周期性的机制。比较常用的机制是工作节点周期性地向总控节点发送信息，工作节点利用心跳机制周期性的向总控节点发送状态信息，保证总控节点掌握较新的工作节点状态，并使前者以此判断工作节点是否存在。

周期性的信息收集方式实现起来较为简单，但是所存在的问题也相对较为明显。首先，周期性的信息传输会加重总控节点的负载，并且所有工作节点均向总控节点发送消息，会造成较大的通信开销；其次，消息传送的周期长短不容易确定，太长会造成信息更新不及时，太短会造成通信负载的增加；最后，假如在一次任务分配周期内发送多次新任务，会导致后续任务不能得到高效的处理。反之，当两次更新之间没有新任务到达，就会造成系统资源的浪费。

鉴于上述情况，总控节点的周期性信息收集并不完全适合实际应用中出现的各种状况。因此，本文对周期性信息收集方式进行扩展，使总控节点在进行周期性信息收集的同时还根据当前任务数据量的需要采集工作节点状态信息。根据任务数据量进行信息收集的算法思想是：总控节点接收到新任务时，主动向工作节点发送状态询问请求，收集工作节点的负载情况；工作节点接收到总控节点的状态询问请求时，就会将当前的负载情况、资源占有情况、任务分配情况等信息发送给总控节点。

总控节点调度过程如下：

if新任务到达 ||开始新的时间周期

重置clock

总控节点发送询问请求，接受从节点负载信息

if当前节点i综合信息满足

给当前节点i分配或者加入队列

end if

end if

从当前节点i工作过程：

if当前节点i接收到总控节点的询问请求

将负载信息反馈给总控节点

end if

在整个节点的通信过程中，可采用TCP协议进行消息传输来确保可靠性，根据传输特点，工作节点接收总控节点分配任务并回复总控节点，为了确保总控节点监测到的信息更准确，工作节点收到任务之后向总控节点回复消息，该消息中包含工作节点自身信息和在负载均衡调整过程中所用到的伙伴节点信息，并且每一个工作节点都在回复消息中添加其携带的时间戳，以保证总控节点收到的信息是最新的。总控节点依据携带信息对所存的相应工作节点信息进行更新，既能准确获得工作节点的负载信息又能减少节点之间的通信量，又可保持调度算法的简单可行。按需收集状态信息的方式会出现空载运行的情况，为此，当系统空闲时，工作节点等待总控节点收集信息并做出决策；当系统运行时，工作节点并行处理实际任务和回复总控节点的询问请求，并不持续等待分配任务，能够充分利用系统资源。

总控节点只在提交任务的时候收集信息，当系统负载均衡处理压力比较大且特定时间段内执行任务数量过大时，总控节点在任务分配方面消耗的运算资源较多，时间消耗大。上述算法在进行设计的时候考虑到工作节点在接收到任务之后捎带发送自己最新的负载信息给总控节点，在此过程中总控节点只会更新接收到任务的节点负载信息，而那些没有接收任务的节点不会发送负载信息给总控节点。通过此种方式，能够有效降低空闲节点接收到新任务的可能性。结合采用周期性的节点负载信息收集方式，使总控节点在保持按需收集方式的同时，周期性地收集所有节点的信息，可提高近期未被分配任务的节点接受新任务的可能性。综上所述，周期性收集和按需收集相结合的工作模式，能够保证负载信息的实时性和降低节点间交互的通信量，在提高系统整体性能的同时，较好地均衡各节点的负载。

3 实验验证

本文采用CloudSim云计算仿真平台验证负载均衡方案（版本为4.0），CloudSim是基于离散事件模型使用Java语言设计开发的仿真模拟应用系统［6］，具备Java语言的跨平台部署特性，可在Windows、Linux或MacOS操作系统中运行，用于在集群环境下对系统架构和部署方案进行建模和仿真。

本文选择了CloudSim的部分核心类用于构建仿真模拟环境，具体包括：

（1）DataCenter class：该类用于模拟集群基础设施中的数据中心解决方案，封装了在其中配置相应工作节点的相关方法；

（2）DataCenterBroker class：该类封装了管理内部工作节点的相关方法，支持对工作节点的加入、回收等操作；

（3）Host class：该类用于模拟集群环境下物理主机对虚拟机的映射关系，封装了物理主机对部署虚拟机的管理策略，如对内存容量、数据存储容量、处理器性能等性能参数的管理；同时，该类还提供对虚拟机协作交互的仿真模拟。

（4）VirtualMachine class：该类用于模拟集群中部署的虚拟机，其在Host class中作为成员模拟多个虚拟机之间的资源共享和内部调度等策略；

（5）VMScheduler class：该类用于模拟对多个虚拟机之间的调度和管理策略，允许实现虚拟机任务的挂载；

（6）VMProvsioner class：该类用于对DataCenter对象中Host对象与VirtualMachine对象的映射关系进行配置；

（7）Cloudlet class：该类用于对集群中的任务进行模拟，并支持对任务的资源配置。

本文使用3台物理主机（分别标识为PH_LB_1601、PH_LB_1602和PH_LB_1603）配置部署负载均衡仿真实验环境，各台物理主机在安装和配置JDK8.0基础上，配置CloudSim4.0，并相应设置了环境变量。

负载均衡仿真实验将上述3台物理主机配置到1个DataCenter对象中（标识为CS_DC_LB）。物理主机PH_LB_1601在该DataCenter对象中配置2个VirtualMachine对象（分别标识为VM_CL_1601_01、VM_LB_CTL_1601_02）作为负载均衡控制器，用于执行负载均衡的调度和管理；物理主机PH_LB_1602和物理主机PH_LB_1603各自分别构建了3个VirtualMachine对象（标识依次为VM_LB_1602_01、 VM_LB_1602_02、 VM_LB_1602_03、VM_LB_1603_01、VM_LB_1603_02和 VM_LB_1603_03）。上述物理主机内部的VirtualMachine对象形成了由7个节点组成的负载均衡方案。上述节点的网络拓扑结构如图4所示。

基于上述网络拓扑结构，调用Host对象和VMScheduler对象将本文提出的基于动态反馈的负载均衡策略和调度算法部署至物理主机PH_LB_1601、物理主机PH_LB_1602和物理主机PH_LB_1603的虚拟节点中。

图4 实验方案的网络拓扑结构

在测试负载均衡方案时，本文在VirtualMachine对象VM_CL_1601_01中配置由Httperf生成负载任务，用于测试服务请求接入能力。测试方案中重点关注两项性能指标：（1）服务请求的平均响应时间与并发连接数的关联关系，以反映方案的服务请求接入性能；（2）给定服务请求场景中的可用并发连接数，以反映方案能够处理的最大并发接入能力。实验环境中由多台服务器构成的集群对多种并发连接数的平均响应时间表现比较稳定，测试数据如表-1所示。从上述实验结果可以看出，采用集群方式的负载均衡方案在处理并发请求方面具备较好的性能表现，在并发连接数持续上升的情况下，响应时间基本保持在7ms以内。可见采用集群方式构建的负载均衡方案能够有效控制服务器处理请求接入的时间。

表1 负载均衡方案的响应时间

对负载均衡策略进行评价时，主要考察实际并发连接数来分析基于动态反馈的负载均衡算法的性能表现，并以Nginx自带的IP Hash算法作为对比。其中，IP Hash算法的核心思想是根据服务请求来源的IP地址进行哈希映射，并将哈希运算结果作为选择实际应答服务请求的服务器节点的依据，进而将服务请求分配至相应的服务器节点,如表2所示。

表2 实际并发连接数对比

由图5分析能够发现，当并发连接数较低时（800以内），实际并发连接数基本与并发请求连接数持平，偶有少量丢失情况（IP Hash算法的丢失率为0.2%，基于动态反馈的负载均衡算法的丢失率为0.6%），能够保持基本正常的请求接入性能。当并发连接数持续增加并达到1000时，IP Hash算法出现了明显的并发请求连接丢失情况，其丢失率达到31.8%，而此时基于动态反馈的负载均衡算法的丢失率仅为2%。相比之下可见，后者拥有更好的服务请求接入性能。

图5 实际并发连接数测试对比结果

4 结语

本文通过对动态负载均衡方法的介绍，优化了动态负载均衡过程中的动态反馈策略，并在实际过程中实现负载均衡的任务调度，对负载均衡工作过程中的任务队列调度进行了详细的分析。论文首先实现对节点负载情况的一个评估，之后通过对负载均衡的阈值设定，进而实现了在负载均衡优化策略方面的优化。并通过搭建实验环境对实验结果进行了仿真验证，证明进行优化了的基于动态反馈的负载均衡算法在解决数据高并发方面比IP Hash算法更加良好。随着网络数据量不断增大这一现实问题，在数据高并发处理过程中，对于网络负载均衡优化的研究需要采用更加优化的算法，在以后的工作中将会在该方面进行更加深入的研究。

［1］文军，张思峰，李涛柱.移动互联网技术发展现状及趋势综述［J］.通信技术，2014（9）：977-984.

［2］Cybenko G.Dynamic load balancing for distributed memory multiprocessors［J］.JournalofParallel&Distributed Computing，1989，7（2）：279-301.

［3］Bond A.ODSI：Enterprise service coordination［C］.International Symposium on Distributed Objects and Applications，2001.

［4］Xinhua E，Han J，Wang Y，et al.Big data-as-a-service：definition and architecture［C］.IEEE International Conference on Communication Technology，IEEE，2013：738-742.

［5］Raghavendra S，Chitra S Reddy，Geeta C M，et al.Survey on data storage and retrievaltechniques over encrypted cloud data［J］.International Journal of Computer Science and Information Security（IJCSIS），2016，14（9）：718-745.