Web集群服务器中基于服务时间的接纳控制机制

Web集群服务器中基于服务时间的接纳控制机制 Web集群服务器中基于服务时间的接纳控 制机制 第32卷 VoL32 第7期 脑7 计算机工程 ComputerEngineering 2006年4月 April2006 ? 网络与通信?文章一号:1伽0__3428(20o6)o7—0106__03文献标识码:A中圈分类号ITP393 Web集群服务器中基于服务时间的接纳控制机制 张永虐,赵银亮,来敏斌,李增智 (西安交通大学计算机科学与技术系,西安71o049) ?蔓:从周期性系统能力规划思想出发,提出基于"服务时间"尺度的接纳控制机制LBAC(延迟限定的接纳控制),与已有的度量方法 相比较,服务时间这一尺度能够更准确地表达系统负载.文章给出了LBAC的形式化表示及其调度算法.通过在一个Web集群服务器的 应用级Web交换机中实现表明,LBAC机制通过自动保持所接纳的请求量与系统服务能力之问的匹配,既能够满足系统吞吐量和限定的延 迟时间,同时有效地防止了系统超载. 关蝴:接纳控制;负载平衡;服务时间;服务质量 ServiceTimeBasedAdmissionControlMechanism inCluster.basedWlebServer ZHANGYongzhong,ZHAOYinliang,SONGJingbln,LIZengzhi (DepartmentofComputerScienceandTechnology,Xi'anJiaotongUniversity.Xi'an710049) [Abstract]Basedontheideaofsystemcapacityplanningperiodically,LBAC(1atency-boundedadmissioncontro1)mechanismwhichemploys servicetimeasitsbasicsystemloadmetricisputforward.Comparedtoothercurrentmetrics,servicetimecanrelativelyindicatethesystemload moreaccurately.TheformalrepresentationandschedulingalgorithmofLBACareillustrated.Theexperimentalresultoftheimplementationof LBACinWebswitchofcluster-basedWebserverispresentedaswel1.Theresultshowsthatthroughdynamicallymaintainingthematchbetweenthe amountofrequestsadmittedandtheprocessingabilityofthesystem.LBACmechanismcanadaptivelymeettheneedsofsystemthroughputand boundeddelaytimeandpreventthesystemfromoverloadeffectively. [KeywordslAdmissioncontrol;Loadbalance;Servicetime;Qualityofservices(QoS) 1概述 在高负载下,Web服务器的吞吐量会下降,响应时间会 增加,这会造成网站的客户丢失和收益降低.原因是超载的 Web服务器几乎一半的处理能力都消耗在中止,拒绝新的请 求上.防止服务器过载的一个主要方法是接纳控制,通过丢 弃一些请求,保证系统的正常运行. 已有的接纳控制的研究主要有以下两种:(1)文献【1】提出 了一个简单的接纳控制机制,预先设置最大的请求队列长度, 当请求队列的长度超过预定的阈值,拒绝接纳新的请求来防 止系统超载,当队列的长度低于阈值,继续接纳新的请求. (2)文献【2】也提出了一种接纳控制方法,检测系统的负载,如 CPU和内存的使用率,并根据状态来调整接收请求的速率, 通过改变请求速率来防止系统的超载.我们认为检测的系统 资源状态信息是过时数据(如检测的CPU的利用率是最近一 段时间内的CPU平均利用率),很难和下个时间间隔内能处 理的请求个数建立关系,不能作为准确预测下个时间间隔可 处理请求数的依据. 以上两种算法存在两个问题:(1)在当前Web流中,存 在各种请求类型,如文本,图像,音频,视频,不同的请求 类型消耗的系统资源差异很大,当到达的不同类型的请求的 数量突变时,请求速率或队列长度不能很好地指示系统的负 载.在这种情形下,因为上面几种算法都以请求速率或队列 长度作为算法的基础,所以不能很好地实现系统超载管理, 会造成系统超载或系统资源空闺.(2)上面几种接纳控制的 方法,都是通过检测低级的系统资源(如队列长度或CPU利 一 1ol:l广一 用率)为基础,这很难使系统完成服务级的管理,不可能实现 服务提供者和用户之间基于SLA(servicelevelagreement)的 交互.SLA通常描述价格和用户可觉察的QoS的关系,如用 户的每个请求的延迟时间限制在2s时,用户需I~111t务提供者 付5O元. 针对这些问题,本文提出新的概念,请求的服务时间, 与请求速率或队列长度相比较,可以很好地指示系统的负载. 并以请求的服务时间作为系统负载的基本度量单位,以设定 的时间间隔内服务器处理能力(JR务器的处理能力在任何时 候都是一个固定值,始终保持不变)为最大阈值,保证在设定 的时间间隔内,处理完成接纳的请求,从而把请求的延迟时 间限制在设定的时间间隔内,实现了系统服务级的管理.使 用这种方法提出一种新的接纳控制机制(延迟限定接纳控 制)LBAC,并在Web集群服务器中的Web交换机上实现, 限定了请求的延迟时间,同时防止Web集群服务器超载. 2系统模型 Web集群服务器由一个前端节点和多个后端节点组成, 前端节点用来分发请求,也称为Web交换机,后端节点处理 请求.集群中的所有节点使用交换机连接.我们的系统模型 是在普通接纳控制机制的基础上加以改进. 基金疆目:国家"863"计划基金资助项目(2004AA11111O);国家自 然科学基金资助项目(60173066) 作者倚介:张永忠(197O一),男,博士生,主研方向:WebQoS; 赵银亮,教授;宋敬斌,硕士;李增智,教授,博导 收稿日期:2005-04—05E-mail:zhyzh39@163.com wb交换机后端节点 1_I 响应… 图1熏筑横量 如图1,输入的请求先进入监听队列.请求分类模块按 照FCFS从监听队列取出请求.请求分类根据请求的URL中 文r日,把请求,j为不同服务类.接纳控制模块,用来 按纳或丢弃新的请求.调度模块根据调度算法选择后端节点, 然后,转发新的请求到该选定的后端节点中.后端节点的Web 应fH服务器采用FCFS机制. 值得指出的是:所有后端服务器配置完全相同,本文中 的请求服务时间是指在一个后端服务器上执行请求的服务时 间,所以,同一个请求,在任意一个后端节点的服务时间相 同;请求在整个集群的延迟时间,包括在Web交换机中的处 理时间和在后端节点队列中的等待时间和处理时间,由于任 何请求在Web交换机中的处理时间基本相同,因此,文本中 的延迟时间,只考虑在后端节点队列中的等待和处理时间. 3服务时问 本文算法的基础是请求的服务时间,什么是服务时间? 以前,Web服务中静态请求占有绝对的比例,DISK访问是 服务器中请求延迟的瓶颈,但随着动态和SSL请求的比例逐 渐增加,由于这些请求所消耗的CPU时间是静态请求的一个 或多个数县级,使得CPU逐渐变为服务器的瓶颈资源.当前 的Web服务器都采用多进程/多线程的模式,在同一时刻,不 同进程,线程处理不同的请求,这样正在处理的多个请求并行 共享CPU和DISK资源.在这种环境下,请求延迟时间可以 近似认为请求等待和使用瓶颈资源的时间,所以本文使用消 耗的瓶颈资源CPU时间作为请求服务时间的量度.本文中, 服务时间指的是后端节点建立请求链接和链接拆除之间所消 耗的CPU时间,它包括后端节点建立TCP链接所消耗的CPU 时问,接受请求的第一个字节到发送响应的最后一个字节之 问所消耗的CPU时间,和链接拆除所消耗的CPU时间. 不同服务类型消耗CPU时间差别很大,如动态请求所消 耗CPU时间是静态请求的一个数量级,这样通过请求类型白T 以大致确定请求的服务时间.在本文中,对服务时间的获得, 不使用实时检测的方法,而是采用不同的服务类放置在不同 的文件目录中,通过URL解析,就可以知道每个请求属于哪 一 种服务类,从而获得该请求的服务时间. 4接纳控制 目前Web集群服务器普遍研究的接纳控制方法是,当队 列请求的长度超过预定的闽值,新输入的请求会被丢弃.当 请求流中不同服务类的请求的数目突变时,造成同一长度队 列的请求所需的服务时间差别很大,因而队列的长度并不能 准确指示系统的负载,所以在这样的情况下,这种接纳控制 方法是有缺陷的.在我们的接纳控制方法中,把请求的服务 时间作为负载度量的基本单位,以时问间隔内的处理能力为 阈值,从而把请求廷迟时间限定在时间间隔内,为客户和服 务器提供者提供了基于SLA的交互的基础,来实现Web集 群服务器的接纳控制,同时成功地防止了系统超载. T为一个时间问隔,把时间划分为(0,T),(T,2T)…., (kT,(k+1)T),…. 引理在基于FCFS调度策略,任务守恒(work—conserving) 的环境下,在初始1存在未服务的请求时,如果在任何时间 间隔T,所接纳的请求能在T间隔内处理,那么,任何请求 的延迟时间不大于T.该引理在文献『41中已证明. 定理在有N个后端节点的Web集群服务器中,如果每 个后端节点的处理能力相同,那么根据引理,在相同的限定 延迟T下,集群服务器的接纳能力是一个后端节点的N倍. 证啊由于每个后端节点都独立运行,并且满足定理.这 样,对于任何后端节点Z: C ?it. IxsisTf11 I=l 其中,C为总的服务类,O<t<T,每个时间窗13开始,t初 始化为0,a,l是在(0,t】内接纳到后端服务器Z并且服务类为f 的总请求数.是服务类为的请求在一个后端节点中的服务 时间,N是后端节点的个数. 那么,后端节点数量为N的集群有 NC ??txsN~TI=1』=l 上式改写为 圭d?×T 其中nrit.I是在(0,tl时问段内接纳到Web集群服务器并且服务 类为的总请求数. 因为一个后端节点的接纳能力满足式(1),后端点为N 的集群服务器的接纳能力满足式(2),所以定理得证. 假设t'是接纳控制模块处理一个新请求的时刻,服务类 为C,t<tT,t为有请求接纳到后端服务器f并且最接近 t'的时刻,S是在t时刻处理的请求的服务时间,新的请求 被接纳必须满足式(3),否则将会丢弃. . 三 S:N×一>.axs(3) i=1 接纳控制的目的是实现请求的延迟时间限定,要求在任 何T时间间隔内,到达的请求的服务时间不超过T时间间隔 内后端节点的处理能力,这样可以防止后端节点超载.T的 大小设置要适中,T越小,接纳的请求越少,丢弃的请求就 越多,但是,T应限制在用户可以忍受的时问(如1s)内. 5调度算法 我们的调度算法,在请求的延迟时间满足限定时间的前 提下,满足各个后端节点的负载平衡.对于每个新的请求, 都按照下面的算法转发到一个后端节点. (1)选择后端节点集,在后端节点集中的每个后端节点,必须 满足引理.保证新到达的请求延迟时间限定在T内.即后端节点必 须满足式(4),如果不满足,该请求将被丢弃,跳到步骤(5).如果选 择的后端节点集的个数为1,跳到步骤(4). 上 S一'a , ×s. (4)'… 式(4)中的符号与式(1)和式(3)中的符号完全相同. (2)在选择的后端节点集中,选择负载最轻的节点集,也就是 保证式(5)最小.如果选择的后端节点集的个数为1,跳到步骤(4). 一 1O7一 ? 二2N ? . 一度 ,凋 , ? 辨 一纳制 接控. , .. r?一求獒一,一请分一列.队[一听监厂????r :拉,×C5) '… (3)由于不同的服务类的请求消耗的系统资源不同,为了保证 各个后端服务器消耗的资源大致相同.因此步骤(2)选择的后端节点 集中,按照同一服务类的请求均匀地分发到各个后端节点的原则, 选择一个后端节点.基本思想是: 假设,S(式(5))是CO,t)时间内接纳到后端服务器Z的所有请求 的服务时间,新请求的服务类型为C,在C0,t)时间内分发到后端服务 器Z并且服务类为C的请求总数为口,I.在步骤(2)选定的节点集中, 选择一个口f最小的后端节点. (4)把新的请求转发到选定的后端节点上. (5)结柬. 6试验 我们实现了一个如图2所示的系统原型,整个结构基于 文献【5】中所述的TCPhandoff,在应用层的Webswitch 中加入本文的LBAC机制.在后端节点中,使用Apache服 务器客户节点和集群中的节点用10Mbps交换机相连.Web 交换机配置两个网卡,一个与后端节点进行通信,一个与客 户端进行通信.所有节点运行操作系统Linux9.0,内核是 2.4.20—8. Web交换机与两个后端节点配置:CPUAMDXP2000+, 内存256MB,硬盘为ST80GB/7200. 客户端的配置:plll800MHz,内存128MB.使用httperl~ 向Web集群服务器发送动静态请求. I????P?%?E?.尊l?EcTEDlEthernetI???????i.I交换机 客端 圈2试奠环l嚏 时间间隔设置为lS;服务类分为2类: 为了实现简单, 一 类为静态页面,平均服务时间约3.5ms;另一类为动态网 页,平均服务时间约为20.5ms.为简单起见,使用静态文件 与动态文件的请求速率比例的变化,来模拟请求流中的不同 服务类的请求个数的变化.在试验中,测试了静态文件与动 态文件的请求速率比例(分别为4:】,】:4),对接纳控制机制的 影响.接纳控制策略分剐使用SAC和本文的LBAC作比较, SAC是文献【1】中的提到的方案. 吞吐量测试结果如图3所示,当静态和动态的请求速率 比例是4:1,请求速率增大时,SAC的吞吐量基本保持在200 左右,而LBAC的吞吐量基本保持在273左右.结合图4的 最大延迟时间,SAC的最大延迟时间基本保持在320ms左右, 而LBAC的最大延迟时间基本保持在900ms左右(限定在ls 一 1O8, 内),这充分说明SAC使得系统资源没能被充分利用,系统 还有处理更多请求的能力.当静态和动态的请求速率比例为 1:4,请求速率增大时,SAC的吞吐量有下降的趋势,而且低 于l00,而LBAC的吞吐量基本保持在117左右.结合最大 的延迟时间如图4所示,SAC的最大延迟时问基本保持在5 lOOms左右,而LBAC的最大延迟时间基本保持在830ms左 右(限定在1内),这可以充分说明SAC造成系统超载. 鼍 督 岫 崮 雌 量 鬟 噶 1o3l5O200250300350 请求速率(请求,s) 圈3吞吐量 请求速率(请求,s) 圈4量大?响应时阔 7结论 本文在一个Web交换机上实现了LBAC机制,以请求的 服务时间作为系统负载的基本度量单位,通过定期的系统能 力规划,限定r请求的延迟时间,防止了系统的超载.在多 类请求数量变化很大时,LBAC比当前接纳控制机制,能更 很好地保证系统的吞吐量和响应时间. j-}考文t IlyerR,TewariV,KantK,OverloadControlMechanismsforWeb ServerslC].WorkshoponPerformanceandQoSofNextGeneration Networks,Nagoya,Japan,2000-11. 2JamjoomH,ReumannJ,ShinKG.QGuard:ProtectingIntemet ServersfromOverload[R],TechnicalReportCSE-【-427一(J(J. DepartmentofComputerScienceandEngineering.Universityof Michigan,2000. 3MosbergerD,JinTai,Httperf一一AToolforMeasuringWebServer Pertbmlance[C],FirstWorkshoponlntemetServerPerformance, ACM,1998-06, 4BorowskyE.GoldingR.JacobsonPCapacityPlanningwithPhased Workloads[C].Proc.ofWOSP'98,SantaFe,NM,ACM,1998-10. 5PaiV,AronM,BangaG,eta1.Locality-awareRequestDistributionin Cluster-basedNetworkServers[C].Proceedingsofthe8Conf~rence onArchitecturalSupportforProgrammingLanguagesandOperating Systems,SanJose,CA,1998—10. 瑚猢瑚瑚枷帅