视频监控系统中负载均衡算法的设计
2014-08-25,
,
(浙江工业大学 信息工程学院，浙江 杭州 310023)
随着社会的进步和人们安防意识的增强，网络视频监控服务在各行各业中发挥着越来越重要的作用.由于视频监控系统规模的不断扩大，监控点数量的快速增长和视频质量的逐步提高，传统单一服务器的系统架构已经成为影响视频监控服务质量的性能瓶颈[1].在这种情况下，不断升级服务器配置并不是长久之计.只有改变传统架构，将集群技术和负载均衡技术应用到视频监控系统，才是解决瓶颈问题的有效措施.
集群和负载均衡技术可以有效避免单链路或单服务节点的工作瓶颈，合理使用硬件资源，使得整个系统的性能得到有效的提升[2].负载均衡算法作为负载均衡技术的核心，其性能的优劣直接关系到负载能否均衡分发以及能否充分利用各个服务节点的处理资源[3].在分析常用负载均衡算法的基础上，充分考虑视频监控系统自身的特点，将常用的动态反馈负载均衡算法进行改进，使其可以更加合理的分配负载，提高视频监控系统的服务质量.
1 负载均衡算法简介
1.1 常用的负载均衡算法
按照分配策略，负载均衡算法主要分为两大类：静态均衡算法和动态均衡算法[4].静态算法不考虑节点实时变化的情况，而以固定的分配原则为依据，因此可能造成集群负载不均甚至单台故障的情况.为了克服静态算法的问题，动态算法在系统运行过程中实时考虑各个节点的负载情况，能够将任务进行动态分配.目前常用的负载均衡算法有以下几种[5]：
1) 轮询算法：将请求任务按顺序依次分配给集群中的每台服务器.它的优点是简单易实现，缺点是没有考虑服务器节点之间处理能力的差异，无法充分利用节点资源.
2) 带权重的轮询算法：为每台服务器增加一个权值来表示其处理能力，在分配任务的时候可根据权值的不同按比例分配相应数目的任务，使得处理能力较强的服务器得以充分利用.但由于其没有考虑服务器实时的负载变化，也可能导致集群负载分配的不均衡.
3) 最小连接数算法：在集群中维护一张表用以记录当前所有节点的连接数，当新请求到来时将其分配给当前连接数最少的节点.它充分考虑当前每台服务器的连接情况，能把请求平滑分配到各个节点.
4) 最快响应速度算法：与最小连接数算法相似，但其记录的是每个节点请求连接的响应时间，并将新请求分配到响应时间最短的服务器上，使请求能最快获得处理.
5) 哈希表算法：利用特定的哈希函数将请求分配到某个服务节点.哈希是一种静态映射算法，哈希函数的选取关系到负载是否能够均衡的分布.该算法的缺点是不利于集群系统的伸缩.
1.2 周期性动态反馈负载均衡算法
基于周期性动态反馈的负载均衡算法是目前中小型应用系统中普遍常用的负载均衡策略[6].该算法的主要工作流程是，各节点服务器周期性向负载均衡器反馈其实时负载情况，负载均衡器依据实时负载将各节点进行队列划分，一般分为轻载、适载、重载三种队列，并在各队列中将节点按权值进行排序.当新请求到来时，将其优先分配到轻载队列中权值较大的节点上进行处理.同时，负载均衡器与节点之间周期性的交互可以检测节点是否处于正常服务状态，避免请求到单点失效的节点.
周期性动态反馈负载均衡算法汲取了常见算法的优势，但还是存在一些不足：
1) 在节点负载量收集的周期内，如果出现短时大量突发请求，可能出现某轻载节点实际上已转变为重载节点，而队列却未重新划分的情况.
2) 在轻载队列中使用加权轮询算法来分配任务，只考虑到节点服务器本身的性能，没有根据节点实时负载情况进行调整，可能出现负载分配不均的情况.
3) 将周期性动态反馈算法应用到视频监控系统时，还需要考虑视频监控系统本身的特点和工作流程，不能够直接套用.
2 系统模型
视频监控系统集群架构如图1所示.系统包含客户端、设备端、节点服务器集群和负载均衡器四个部分.系统工作时，负载均衡器接收客户端的视频请求，依据负载均衡算法将请求合理地分发到集群中的服务器节点，然后节点向设备请求视频，并接收设备端上传的实时视频数据流，最后转发给发起请求的客户端.为简化分析，系统模型中不考虑视频存储和转码问题.当有多个客户端并发请求同一台设备的实时视频时，节点服务器只与该设备建立单路连接来接收视频流，进行拷贝后再转发给请求该设备的所有用户[7].这样能够消除设备端处理性能受限和上传带宽不足的问题，提高系统整体的服务质量和资源利用率.
图1 视频监控系统集群架构
也就是说，如果客户端请求的设备已在上传视频流，那之后所有对该设备的请求需要分配给已接收该设备视频流的节点.因此，如果请求同一台设备的用户过多，将造成该服务节点负载过大，影响服务质量.
3 改进的动态反馈负载均衡算法
3.1 改进策略
针对上述提出的种种问题，将动态反馈负载均衡算法进行了改进，下面将从任务分类策略、加权最少任务均衡策略、节点协同工作策略和节点主动通知策略等四个方面对改进的算法进行详细说明：
1) 任务分类策略：根据请求的设备是否已上传视频流，负载均衡器将接收到的任务请求进行分类，并选取不同的均衡策略.如果设备未在上传，则选用加权最少任务策略，优先在轻载队列中分配该任务；否则，选用节点协同工作策略进行分配.
2) 加权最少任务均衡策略：负载均衡器在系统运行时维护一张数据表，表中记录当前每个节点的任务处理数.在分配任务时，应尽可能选择当前任务数最少的服务器节点.但考虑到每台服务器的硬件配置不一致，还需要使用相应的权值来表示其处理能力.假设集群节点数为n，当且仅当节点k满足
T(k)/W(k)=min{T(i)/W(i)} (i=0,1,…,n-1)
(1)
时，节点k被调用.式(1)中：T为节点当前任务数；W为节点权值.
3) 节点协同工作策略：如上所述，当有多个用户对同一设备视频进行请求时，所有任务需要分配到已经在接收该设备视频流的服务器节点以提高系统的资源利用率.不过随着任务数的不断增加，该节点也将可能面临负载过重的问题.我们使用协同工作的方法来解决这个问题.
当原节点已不是轻载节点，则从当前轻载队列中分配另一台服务器进行协同工作.节点之间以级联的方式进行协同，即原节点从设备获取视频流，拷贝并转发给协作节点，协作节点接收后再转发给客户端.在原节点退回轻载队列之前，请求都能由协作节点进行处理.若任务的数量继续增加，使得协同工作的轻载节点也面临过载，则继续从轻载队列中分配节点，以多层级联的方式进行协同工作.
4) 节点主动通知策略：在负载均衡器收集各节点实时负载量的周期内，如果出现大量突发请求，特别是对同一设备视频集中请求的情况，将可能使得原轻载节点迅速转换为适载节点，甚至重载节点.在这种情况下，为了避免过载，节点服务器主动通知负载均衡器，告知其负载量的变化，以便其重新划分队列.
3.2 算法参数
3.2.1 节点服务器实时负载量
负载量是服务器实际负载情况的体现.影响服务器实时性能的指标有很多，一般选用CPU、内存、带宽和磁盘I/O占用4个指标.通过CPU使用率和CPU个数的乘积ICPU、内存使用率IMEM、网络带宽使用率IBW、磁盘I/O占用率IDISK等参数来计算节点实时负载量为
L(i)=R1×ICPU+R2×IMEM+R3×IBW+R4×IDISK
(2)
式中Ri(i=1，2，3，4)为各参数的权值，∑Ri=1.参数对性能的影响越大，其权值也越大.考虑到视频流数据传输过程对服务器CPU性能和网络带宽的要求较高，可设置权值为{0.4，0.1，0.4，0.1}，实际操作中可以对Ri不断修正以达到最合适的比例.
3.2.2 节点服务器最大负载量
最大负载量用来描述服务器的处理能力，与节点本身的硬件配置相关.一般通过处理器主频和个数的乘积、内存大小、最大带宽和最大磁盘容量等4个指标来评价最大负载量.
由于不同指标具有不同的量纲和量纲单位，如果直接用原始数据进行分析，将无法得到准确的结果，因此需要先对原始数据进行标准化处理.最常用的标准化方法是Z-score方法，公式如下：
MAXI*=(MAXI-μ)/σ
(3)
式中：MAXI*为标准化后的参数数据；MAXI为原参数数据；μ为数据均值；σ为数据标准差.标准化处理之后，再计算最大负载量，公式如下：
(4)
式中：MAXL为节点最大负载量；MAXI*为参数的标准化数据；Ri(i=1，2，3，4)为各参数的权值，∑Ri=1.
3.2.3 节点服务器队列划分
根据实时负载量对节点进行划分，分为轻载、适载和重载三种队列.如果节点负载量L<0.6，说明该服务器负载较轻，还有足够的服务处理能力；当0.6
3.2.4 节点服务器权值
根据节点最大负载量计算权值，公式如下：
W(i)=(MAXL*(i))/(∑MAXL*(i))
(5)
式中：W为节点权值；MAXL*为节点最大负载量.
3.3 算法描述
改进的动态反馈负载均衡算法流程如图2所示，具体步骤描述如下：
1) 节点服务器检测自身的硬件数据，发送至负载均衡器，负载均衡器计算出各节点权值.
2) 节点服务器周期性计算自身的实时负载量，发送到负载均衡器.负载均衡器根据实时负载量，将节点划分到轻载、适载或重载三种队列.
3) 在负载收集周期内，节点服务器一旦发现自身负载过重，则主动发送实时负载量给负载均衡器，然后负载均衡器重新为其划分队列.
4) 是否有视频请求到来.是，转到5)；否，继续等待并周期性收集节点负载情况.
5) 判断请求的设备是否已上传视频流数据.否，则使用加权最少任务策略，优先在轻载队列中分配任务；是，则使用节点协同工作策略进行分配，转到6).
6) 判断已接收该设备数据流的节点是否是轻载节点.是，则调用该节点；否，则根据加权最少任务策略在轻载队列中分配新节点与原节点进行协同工作.
4 算法性能测试与分析
在局域网内搭建视频监控系统测试平台，包括3台性能不一的节点服务器和1台负载均衡器，服务器配置如表1所示.
图2 改进的动态反馈负载均衡算法流程图
表1 测试服务器配置
进行测试时，先在平台中模拟100台监控设备，再使用测试软件LoadRunner在10 min之内向设备随机发送1 000个视频监控请求.且规定请求的100台设备中有10台是热门设备，被请求的概率是其余设备的10倍.测试时，实时负载量参数权值设置为{0.4，0.1，0.4，0.1}.在测试过程中，观察3台节点服务器分别在原算法和改进算法的情况下CPU占用率和带宽使用率的变化.
图3(a，c)显示了使用原动态反馈算法时各节点CPU占用率和带宽的变化，图3(b，d)显示了使用改进的动态反馈算法时各节点CPU占用率和带宽的变化.由图3中曲线的变化情况可知：在模拟大量用户请求的过程中，使用改进前的算法，由于没有引入节点协作等策略，各节点对资源的利用率较不平衡，性能高的节点比起性能低的分配到更多的负载.而使用改进后的负载均衡算法，各节点资源利用率较为平衡，证明了改进策略能够有效改善负载的均衡分配.
图3 测试中各节点资源利用率变化
5 结 论
改进后的周期性动态反馈负载均衡算法，既能保留原始算法的优点，也能适应视频监控系统的自身特点和工作流程.引入的任务分类策略、加权最少任务均衡策略、节点协同工作策略和节点主动反馈策略等改进方案，可以更好的将请求任务分配到最合适的服务器节点.测试结果证明了该算法可以达到良好的负载均衡效果.
参考文献：
[1] 胡丽聪，徐雅静，徐惠民．基于动态反馈的一致性哈希负载均衡算法[J]．微电子学与计算机，2012，29(1)：177-180．
[2] 郭波，汪大洋．流媒体负载均衡技术在江苏电力视频会议中的应用[J]．电力信息与通信技术，2013，11(12)：111-115．
[3] 夏三波．SIP服务器集群系统的负载均衡技术研究[D]．武汉：华中科技大学，2012．
[4] 童瑞霞．基于动态反馈机制的集群负载均衡算法研究[D]．武汉：武汉理工大学，2011．
[5] 李坤，王百杰．服务器集群负载均衡技术研究及算法比较[J]．计算机与现代化，2009，8：7-15．
[6] 刘恩海，李伟，张素琪，等．集群文件服务系统中的负载均衡算法的研究[J]．计算机工程与设计，2013，34(8)：2754-2758．
[7] 王文革，郑三立，王文彬，等．流媒体技术在变电站遥视系统中的研究与实现[J]．中国电力，2010，43(7)：77-80．
[8] 杨建锋，孟利民．视频监控系统中实时流媒体传输控制方法的设计[J]．浙江工业大学学报，2012，40(4)：454-457．
[9] 李晓波，孟利民．H.264多媒体数据在嵌入式系统中的存储机制的设计[J]．浙江工业大学学报，2012，40(4)：437-440．
[10] 周晓，边裕挺，李杰．基于android智能终端的wsn监控系统[J]．浙江工业大学学报，2013，41(5)：558-561．
[11] DHAGE S N， MESHRAM B B． A survey on load balancing techniques in video on demand system[J]． Advances in Computational Research，2012，4(1)：61-65．
[12] DUSIT N， CHUTIMET S． Load balancing algorithms for internet video and audio server[C]//9th ieee international conference on networks． Bangkok： IEEE，2001：76-80．
[13] ZHANG Xing-ming， ZHAN Shao-xin． One load balancing solution for mobile video surveillance system[C]//International conference on computer science and service system． Nanjing： IEEE，2012：757-750．
[14] CHANDRA P K， SAHOO B． Performance analysis of load balancing algorithms for cluster of video on demand servers[C]//International Advance Conputing Conference． Patiala： IEEE， 2009：408-412．
[15] WU Chao， XIN Ming-jun． A cluster-based load-balancing mechanism for video surveillance system[C]//International Conference on Computer Application and System Modeling． Nanjing： IEEE，2010：40-43．
