一种改进的ICE中间件负载均衡算法

一种改进的ICE中间件负载均衡算法
姜邵巍;朱建良;吴永胜
【摘要】针对异构网络环境,作为有效提供应用软件服务的优秀中间件平台,网络通信引擎(ICE,Internet Communications Engine)被广泛使用.由此,其中保证平台及应用服务稳定性的负载均衡模块即显得尤为重要.然而ICE中间件原有的负载均衡算法只以节点服务器的CPU核数作为节点负载的度量标准,缺少全面性和实时性.本文针对原有算法的不足,基于节点服务器的实时性能状态,提出了一种改进的负载均衡算法.该算法实时采集节点服务器的CPU使用率和内存占用率,综合计算出节点负载,选取最小负载节点作为应用分配节点.实验表明,改进的算法较原有算法增强了系统的稳定性和鲁棒性,具有更好的负载均衡效果.
【期刊名称】《中国电子科学研究院学报》
【年(卷),期】2016(011)003
【总页数】5页(P263-267)
【关键词】负载均衡;中间件;ICE
【作者】姜邵巍;朱建良;吴永胜
【作者单位】中国电子科学研究院,北京100041;中国电子科学研究院,北京100041;中国电子科学研究院,北京100041
【正文语种】中文
【中图分类】TP311.1
工程与应用
随着人们对计算机应用技术越来越丰富的需求增长，以及网络技术的飞速发展，用户所需的软件服务已不局限于单机器、单操作系统这种软硬件平台环境，而是要在多台不同厂商生产的服务器上、不同操作系统环境下运行。

为了对应用软件屏蔽操作系统等底层软硬件平台的不同[1]，同时解决异构网络环境下应用软件的通信、互操作和协同问题[2]，中间件技术应运而生。

最早的中间件产品诞生于20世纪80年代中期。

经过约30年的发展，中间件领域中已产生出了许多比较成熟的模型与产品。

主流的如微软的分布式组件对象模型(DCOM, Distributed Component Object Model)[3-4]、对象管理组织(OMG, Object Management Group)的通用对象请求代理体系结构(CORBA, Common Object Request Broker Architecture)模型[5-6]、Sun公司的企业级Java组件(EJB, Enterprise Java Bean)模型[7-8]和ZeroC公司的ICE中间件[9]。

其中前三种模型由于自身开发的复杂性和对部署环境的依赖性，导致其移植性和可扩展性不强，而ICE中间件支持多种编程语言、多种网络通信协议和多种请求/应答远程调用方式，具有高可扩展性和重用性，得到了广大企业和研究人员的青睐。

但无论哪种中间件，它们都要为用户提供资源管理、应用服务和网络通信等功能，因此负载均衡、服务调度和传输管理成为实现中间件功能较为重要的环节。

并且负载均衡的效果直接影响着后两者的性能，故该方面需要更加重视。

然而研究ICE 中间件的负载均衡部分发现，该平台只是将节点服务器的CPU核数作为资源负载因子，没有考虑服务器的CPU使用率、内存占用率等实时性能因素，对资源负载的衡量标准还不够细致，也做不到实时检测。

因此本文提出一种针对ICE中间件改进的负载均衡算法，考虑更丰富的资源负载数据，更加准确地实时评估节点服务器的负载情况，合理分配系统资源，更好地优化系统整体性能及其他模块的性能。

ICE中间件是Zeroc公司开发的一款开源的面向对象的分布式中间件平台，它借鉴了CORBA、DCOM、SOAP(Simple Object Access Protocol，简单对象访问协议)和Web services等中间件的优点，并针对这些中间件的应用局限给出了自己
的解决方法。

ICE提供了适用于异构环境下的面向对象中间件平台，为支撑广泛领域中的分布式应用开发提供了一整套特性。

ICE中间件为构建分布式系统的基础通信框架提供了高性能支撑，对分布式系统的通信做了面向对象级的封装；同时它还支持构建面向对象的客户/服务端应用。

ICE 应用适合于在异构平台环境中使用：客户端和服务端程序可采用不同编程语言编写，可以运行在不同的操作系统和硬件架构上，并且可以使用多种网络技术进行通信。

ICE中间件为应用服务提供请求/应答远程过程调用机制。

开发基于ICE的应用，
包括定义服务接口，服务端(提供服务对象)和客户端(使用服务对象)。

服务接口定
义即定义服务对象对外提供的操作集合，使用平台自带的Slice语言定义。

服务端实现服务接口定义的操作，客户端获取服务接口的代理实例，即可获取远程对象的调用接口。

ICE的应用服务机制结构图如图1所示。

ICE核心为客户端和服务端间的远程通信提供运行时支持，主要包含线程管理、通信管理、调用分派、消息编解码、服务对象管理等一些基础服务模块；ICE代理为Slice接口定义文件生成的面向客户端应用的代理类，为客户端提供向下调用的接口，主要完成函数参数编解码(编码输入参数和解码返回值输出参数)、调用请求分发、超时控制、异常控制、请求结果处理等；ICE骨架为Slice接口定义文件生成
的面向服务端应用的代码部分，是ICE核心与服务端交互的桥梁，主要负责将ICE 核心的操作请求分派给服务端。

ICE骨架主要完成请求分派、编解码(编码返回值
输出参数和解码请求输入参数)、请求结果处理等；对象适配器主要负责服务对象
的管理与维护，包括将来自客户端的请求映射到服务对象中特定的方法，可以关联一个或多个传输终端，负责生成传给客户端的代理消息等功能。

负载均衡算法是负载均衡技术的核心，它将各应用程序均衡分布到集群中不同的节点服务器上，从而使各节点资源得到充分的利用。

常用的负载均衡算法分为静态负载均衡算法和动态负载均衡算法两种。

2.1 静态负载均衡算法
静态负载均衡算法是依照预先设定的策略进行节点负载分发的负载均衡技术。

常用的静态负载均衡算法主要有轮询算法、随机算法、散列算法[10]。

轮询算法就是将应用请求依次分配给集群中的节点进行处理。

轮询算法又分简单轮询算法和加权轮询算法。

简单轮询算法假定节点正常运行且性能相同，依次将请求分发到各节点。

这种算法虽然易于实现，但基于自身假设，该算法无法区分哪个节点负载更低；加权轮询算法是对节点按性能高低设定权值，按照权值大小进行应用请求的分发。

这种算法考虑了集群中不同节点性能的差异，克服了简单轮询算法的不足。

随机算法将请求随机分发到不同的节点上。

从统计学角度看调度结果，各个节点平均分担了应用请求。

但该算法适用于各节点性能相当的集群网络。

散列算法根据实际应用，分为基于源IP的散列算法、基于源IP端口的散列算法和基于目的IP的散列算法，分别保证来自同一IP(或IP 端口)及发送到同一目的IP 的请求任务分发给同一个节点。

静态负载均衡算法实现简单，调度快捷。

但这类算法不考虑系统运行时各节点的实际负载情况，必然会出现某些节点负载大，某些节点负载小的情况。

因此静态负载均衡算法不能很好地实现整个系统的负载均衡。

2.2 动态负载均衡算法
动态负载均衡算法分析收集集群中节点服务器的实时运行情况，把应用请求平均地分配到各节点上。

常用的动态负载均衡算法有最小连接数算法和快速响应优先算法两种。

最小连接数算法是将应用请求发给当前连接数最少的节点，并不考虑节点与节点之间性能的差异。

该算法可以通过加权进行优化，为每一台服务器设定一个代表其性能的权值，将应用请求发给服务器连接数与其权重比值最小的节点。

快速响应优先算法是将应用请求发给最快响应时间的节点，该算法在集群跨不同网络的环境下比较有用。

实验表明，通常情况下动态负载均衡算法较静态负载均衡算法可以提高30%～40%的性能[11]。

然而动态负载均衡算法仍存在不足。

因为以网络连接因素来调度，并不考虑分配任务在节点上的占用资源大小，由此被分配节点的资源消耗也不一定是最小的，反而有可能是最大的情况。

因此动态负载均衡算法依然不能很好地解决节点间的负载均衡问题。

由此，本文提出一种基于节点服务器实时性能状态的动态负载均衡算法，改进ICE 中间件原本的只考虑服务器CPU核数的负载均衡算法，使负载调度模块可以读取到集群中节点的实时性能情况，根据节点的实时负载进行应用任务调度。

该算法通过实时地采集全网节点服务器的性能状态，计算出节点服务器各自的资源负载量化值，负载均衡调度模块将应用任务分配到负载值最小的节点服务器上，均衡全网的负载，保证全网集群系统的稳定性和鲁棒性。

由于CPU和内存的性能典型地体现集群节点的计算处理能力，因此本文使用CPU 占用率(包含所有处理核数)和内存使用率这两个指标作为计算节点的实时性能衡量因子，用于计算得到每个节点的负载量化值。

本文计算节点有效性能因子的几何平均数作为节点的负载量化值。

假设一个节点上有m个性能因子，每一个性能因子为ri (1 ≤ i ≤ m)，ri的正常取值范围在0到1之间，数值等于0或者为异常的性能因子个数为n，那么节点的负载量化值L的计算公式如公式(1)所示:
经过对每个节点服务器计算出各自的负载值后，即可将应用任务分配给最小负载节
点，完成负载均衡的调度过程。

具体的算法过程如下：
(1) 计算每个节点服务器的CPU占用率和内存使用率，即性能因子r1和r2；
(2) 计算每个节点服务器的负载量化值L；
(3) 选择负载值最小的节点服务器作为待分配应用任务的目标节点。

在每次要分配应用任务时都重新运行该算法，保证系统实时动态分配应用任务的功能。

本文在搭建ICE中间件的多节点计算机环境下，进行了改进算法与ICE的原负载均衡算法和最小连接数动态负载均衡算法的性能比较实验。

具体设置了3台同为Linux操作系统的计算机，其中1台为2核CPU，另外两台均为单核CPU。

新旧算法的调度任务都是为相同的5个应用程序分配待运行节点。

性能比较的指标为所有应用程序运行后全节点负载值的均方差，哪种算法调度后产生的全网负载均方差小，哪种算法的性能更优。

指标计算如公式(2)所示:
其中Li为某一节点的负载值，为所有节点负载值的平均值，N为节点计算机的个数。

命名改进的负载均衡算法为新算法，ICE中间件的原负载均衡算法为原算法。

三种算法的全节点负载均方差对比结果如图2所示。

本文还将三种算法在全节点应用连接数均方差这个指标上进行了评测。

哪种算法调度后产生的全网连接数均方差小，哪种算法的系统网络稳定性更优，指标计算如公式(3)所示。

其中Ci为某一节点的连接数，为所有节点连接数的平均值，Nc为存在应用连接数的节点计算机个数，N为节点计算机的个数。

三种算法的全节点连接数均方差对比结果如图3所示。

从实验结果可以分析出，新算法产生的全节点负载均方差和连接数均方差比原算法的小，说明新算法使全网负载得到了更好的均衡，提高了整个系统的稳定性。

产生
这种结果的原因是因为原算法根据节点计算机的CPU核数将所有的应用任务都分配给了3台机器中的CPU核数最多的节点计算机，认为核数多，处理能力强，负载小。

然而实际情况是随着应用任务的分配，双核计算机的CPU和内存负载已经很高，但仍然分配给该节点，闲置其他两台单核节点，造成全节点负载均方差较大；而新算法实时计算节点的负载，均匀地将应用任务分配给3台节点计算机上，故
全节点负载均方差较小。

另外，新算法的指标也优于最小连接数算法，说明该算法较最小连接数算法对各节点的负载分配更加合理。

由此说明，改进的负载均衡算法能够更好地合理调度应用任务，降低单节点负载，较好地达到整个系统的负载均衡效果。

本文分析了ICE中间件原有负载均衡算法的不足，基于节点服务器的实时性能状态，提出了一种改进的的负载均衡算法。

实验结果表明，新算法可以有效地提高全网集群的整体性能，增强系统的稳定性和鲁棒性。

目前本文重在描述算法思路，只是典型地采集了CPU和内存占用率这两个性能因子，但算法本身可以支持涵盖更多的性能因素。

未来可以增加网络占用率、设备温度等性能因子，进一步提升整个系统的负载均衡性能。

姜邵巍(1986—)，男，黑龙江人，博士，主要研究方向为软件中间件技术；
E-mail:******************
朱建良(1964—)，男，江苏人，研究员级高级工程师，主要研究方向为信息系统；吴永胜(1982—)，男，河北人，工程师，主要研究方向为通信与信息系统。