请求调度模式（精选三篇）
请求调度模式 篇1
Web集群服务器 (简称Web集群) , 以其可扩展、高性能、高可用、高性价比、以及对客户透明等特性, 已成为当前应用最为广泛的一种提高Web服务器性能的解决方法, 并且也是未来Web服务器的主流发展方向。请求调度和体系结构是Web集群技术中的核心问题, 它们共同决定着集群系统的性能和可扩展性。请求调度和体系结构相辅相成, 一方面, 调度算法必须与体系结构相适应;另一方面, 体系结构必须给调度算法以相应的支持。
虽然研究人员为Web集群的请求调度提出了不少算法, 但网络和Web应用的发展对Web集群的请求调度提出了一些新的更高的要求。在分析了这些新要求的基础上, 本文提出了一种新的请求调度模式——基于文档组织分布的请求调度模式。随着基于内容请求分发的广泛采用, 调度的瓶颈问题急需解决, 虽然研究人员提出了多分配器集群[1,2]和分布式集群[3,4]的解决方案, 但它们仍然存在着一些不足。针对这些不足, 以及基于文档组织分布请求调度模式的特点, 本文提出了一种可扩展的Web集群体系结构——分布调度、分布路由的集群体系结构。
1集群体系结构的相关研究
Web集群一般主要由调度器、转发器和Web服务器三部分组成。在传统的单分配器集群中, 分配器的角色包括调度器和转发器, 而后台服务器的角色就是单一的Web服务器。在基于内容调度的Web集群中, 分配器的负担很重, 容易成为系统的瓶颈。针对分配器的瓶颈问题, 研究者们提出了两种解决方案:多分配器集群和分布式集群。
在多分配器集群系统中, 有多个分配器同时担当请求分发的任务, 从而避免单个分配器产生的瓶颈。文献[1]提出了一种多分配器的结构, 但从请求分发过程和系统结构上看, 它实际是一种两层的树型结构, 有一主分配器担任根节点的角色, 根节点将成为整个集群系统的瓶颈。文献[2]提出了一种多分配器结构, 但其存在如下问题:1) 分配器每次分发请求时都要与调度器通信以询问目标服务器, 增加了响应延时;2) 当调度算法较复杂时, 单一的调度器仍可能制约系统的扩展性, 且还存在发生单点故障的可能。
在分布式集群中, 每台服务器既转发请求又提供Web服务, 其典型代表包括CARD[3]和WARD[4]。这些分布式设计使得每台服务器的任务都很重, 因为它们每台都要进行包重写、连接维护、负载均衡和提供Web服务等工作。如此繁重的任务使得每台服务器的服务性能都大大下降。并且, 服务器的任务太多, 需要消耗大量的内存 (特别是维护链表) , 这将影响到Web服务器缓存对内存的需求。另外, 服务器的任务太多也不利于对服务器进行优化配置。
2对请求调度提出的新要求
虽然研究人员为Web集群请求调度提出了不少算法, 但网络和Web应用的发展对Web集群请求调度的设计提出了一些新的要求, 这些新要求包括:
(1) 存储扩展性
在传统的调度算法 (即使是基于内容分发的算法) 下, 客户请求可以被分发到集群中的任何一个节点, 因此, 集群中的每个节点都必须有能力为访问网站中任何内容的请求提供服务。通常的解决方案是使用网络文件系统, 或者内容全拷贝。然而对于集群来说, 以上两种方案由于没有考虑服务器和数据内容的异构性而存在着明显的不足, 且存在着浪费磁盘空间或单点失效的问题。因此, 在设计调度算法时, 应让每个节点只需服务访问一部分文档的请求, 从而使每个节点只用存储一部分的文档数据, 并且这样还有利于提高缓存命中率。
(2) 调度算法的分布性
为解决集群扩展性的问题, 研究人员提出了很多分布式结构和多分配器结构的集群, 目前这些集群要么采用多播或广播的方式在各调度节点间频繁地交换服务节点的各种状态信息, 要么采用集中式的调度算法。前者消耗了调度节点的大量资源。后者则只能在一个集中的调度节点上运行, 这样不但为系统增加了单一失效节点, 而且在很大程度上限制了系统的扩展;另外, 由于每次分发请求时都需要通过网络与调度节点交互, 不仅增加了响应延时, 而且占用了大量的内部带宽。因此, 需要设计出分布式的调度算法来解决上述问题。分布式调度算法的重要特点就是, 请求的调度不依赖于全局的状态 (包括服务器的缓存状态和负载状态) 信息。
(3) 针对HTTP/1.1进行优化 HTTP/1.1已被广泛使用。
HTTP/1.1支持持续连接特性, 即一个TCP连接可请求多个文档。该特性虽然减少了服务器与客户端的连接开销, 但对于基于内容请求分发的集群来说却要产生额外的开销。实现基于内容的请求调度可采用的请求路由机制有:HTTP重定向、TCP Splicing和TCP Handoff[5]。如果客户在一个连接中访问的多个文档不在同一台服务器上, 那么, 在HTTP重定向方式下, 系统需要重定向客户的请求;在TCP-Splicing方式下, 系统需要重新拼接与客户的TCP连接;在TCP-Handoff方式下, 系统需要将与客户建立的TCP连接从一台服务器迁移到另一台服务器上。这里, 我们将上述HTTP重定向, TCP重新拼接和TCP连接迁移统称为“额外开销”, 它不仅增加了响应延时还增加了系统开销, 如果“额外开销”的次数太多将大大影响集群系统的性能。而目前绝大多数调度算法都没有考虑如何减少这种“额外开销”。
3基于文档组织分布的请求调度模式
现存绝大部分的请求调度策略都是这样一种工作模式:每当到来一个请求, 根据请求的信息和服务器的状态, 依据一定的规则来选择目标服务器。而我们提出的请求调度模式是根据请求负载特征的历史记录和变化趋势, 制定出下一阶段的请求负载分布策略, 从而使集群系统工作在最佳性能 (例如, 响应时间最小) 状态。它首先根据历史访问记录求解集群中负载分布 (如访问某个文档的请求由哪台服务器负责响应) 的最优方案, 然后根据该方案生成请求路由表, 并根据该请求路由表来对下一阶段的请求进行调度 (满足调度算法分布性的要求) 。这种调度模式类似于文档分布方案, 因为, 调度算法中的将访问某个文档的请求分发给某台服务器处理, 就相当于文档分布方案中的将该文档放置到该服务器上, 因此, 我们称此调度模式为基于文档组织分布的请求调度模式。
如何合理地组织分布文档是该请求调度模式的重要环节, 因为系统不仅需要根据文档分布的结果产生请求路由表, 而且需要通过分布文档来均衡负载, 使系统性能最优化。文档组织分布的主要步骤包括:
(1) 网页组簇
在基于内容请求分发的集群中, 要想提高系统的性能, 必须采取一定的措施来减少HTTP/1.1持续连接所带来的“额外开销”。如果将用户经常一起访问的网页组织成簇, 并以网页簇为单位来分布文档, 那么, “额外开销”将大大降低。
网页组簇也就是网页聚类的过程。我们先通过Web挖掘计算出网页之间的相关距离[6], 然后利用基于密度的聚类算法RDBC[7]将网页聚类。
(2) 网页簇分布
我们结合网页的访问频率和大小定义网页的负载, 并计算得到网页簇的负载, 然后根据比例确定各网页簇的拷贝份数, 以平衡网页簇负载之间的差别。网页簇分布的结果为一矩阵A, 若网页簇i的拷贝在服务器j上则A (i, j) 为1, 否则为0。矩阵A必须满足拷贝份数的约束条件, 即第i行中1的个数等于网页簇i的拷贝份数。
随着网页簇的分布不同, 各服务器的请求到达速率和服务请求的平均服务时间也会不同, 因此它们都是分布矩阵A的函数。所以集群系统的平均响应时间也是分布矩阵A的函数。因此, 网页簇分布的目标就是在拷贝份数的约束条件下, 求解矩阵A使整个集群系统的平均响应时间达到最小。这个问题是一个0-1整数规划问题。我们采用混沌搜索算法[8]来求解该问题。
显然, 基于文档组织分布的请求调度模式能很好的满足上述网络和Web应用的发展对Web集群请求调度提出地新要求。
4分布调度、分布路由的Web集群体系结构
为解决多分配器结构和分布式结构的不足, 以及针对基于文档组织分布的请求调度模式的特点, 我们设计了分布调度、分布路由的Web集群体系结构, 如图1所示。为满足更大规模网站系统的需要, 可将若干个分布在不同地域的该结构的集群子系统通过WAN互联起来, 改进的DNS服务器在解析DNS请求时, 根据请求的源IP地址选择离它最近的集群子系统为其提供服务。
该结构结合了多分配器集群和分布式集群的优点, 每个分配器都是一个传统的、功能完整的分配器, 都具有调度器和转发器的功能;后台服务器就是纯粹的Web服务器。其工作流程如下:
1) 请求首先到达第四层交换机, 第四层交换机采用Direct Routing机制和简单的调度算法 (例如随机或源端口Hash算法) 将请求分发给各个调度器;
2) 调度器解析请求的内容, 然后根据请求路由表选择后台服务器 (若有多台可供选择, 则随机选择一台) ;
3) 转发器采用TCP Handoff机制将请求转发给选中的后台服务器;
4) 后台服务器服务请求, 并且响应的数据包不经过分配器和第四层交换机直接路由到客户端;
5) 如果HTTP/1.1持续连接的后续请求达到后台服务器, 它也从请求的内容中解析出URL, 然后看该URL所请求的对象本地有没有;如果有就本地服务;若本地没有, 根据请求路由表选择新的后台服务器, 并将与客户的TCP连接迁移到该目标服务器上。
该结构的主要优点如下:
1) 各分配器没有主次之分, 并行工作;
2) 转发器和调度器没有分离, 因此不存在它们之间的通信问题, 也不会引起额外的响应的延时;
3) 调度器不单一, 因此不存在调度器制约系统扩展性的问题, 也不存在调度器单点失效的问题;
4) 服务器的任务单一, 有利于对其进行优化配置, 服务性能能得到保障;
5) 各节点仅根据请求路由表来调度请求, 它们之间不需要交换服务器的任何信息, 故采用的是一种分布式的调度算法;
6) 随着分配器数量的增加, 第四层交换机可能会成为系统的瓶颈, 但可采用网络处理器来开发第四层交换机以消除该瓶颈, 并且网络处理器为硬件, 可靠性较高。
5测试
被测试的集群系统由第四层交换机、分配器和后台服务器构成, 用多台测试客户机来发送测试请求。各机器的主要硬件配置如表1所示。网络环境为100M, Web服务器使用的是Apache 2.0.40。采用的测试软件是WebBench 5.0[9]。
5.1请求调度模式的性能测试
将我们的系统与以下系统进行测试比较:1) 全拷贝系统。每台服务器上都放有所有文档的拷贝, 并采用基于连接的轮转算法分发请求;2) 基于类型分布系统。将文档分为两类:图片和非图片, 每类放在一半数量的服务器上, 并在同类请求中采用轮转算法分发请求;3) 组簇单拷贝系统。将网页组簇后, 让每个网页簇只有一份拷贝, 且使用混沌搜索算法分布网页簇。
测试使用的原始日志为美国环保署Web服务器一天的日志[10]。预处理后得到3, 054个不同的文档, 7, 184个用户会话, 网页被组织成24个网页簇。在重建网站内容时, 我们只是根据请求URL和传输字节数重建了相应的文档。对于动态文档, 脚本只是简单地print相应大小的内容。
为缩短测试时间, 我们选择8点～19点间的请求进行测试。另外, 原日志的负载强度较小, 并且为了在不同负载强度的情况下进行测试, 我们需要强度大一些且能变化的负载。因此我们定义, 用原始日志驱动时的负载强度为1。可以用如下的方法得到负载强度为2的日志:在原始日志的每个请求后面复制一个请求, 复制的请求仅仅只有客户与原请求不同外。
使用6台后台服务器, 测试环境为HTTP/1.1, 在不同的负载强度下, 四个系统的平均响应时间如图2所示。图2表明, 基于类型分布系统的平均响应时间最长, 而我们系统的平均响应时间最短。
影响系统平均响应时间的因素主要是集群系统内的TCP连接迁移开销和负载的均衡程度。显然, TCP连接迁移次数越少, 负载越均衡, 系统平均响应时间就越小。表2给出了对测试结果的分析。值得注意的是, 这里我们对动态请求进行了简化处理, 如果在真实的环境下, 我们系统的性能优势将更加明显。
5.2体系结构的可扩展性测试
采用HTTP/1.0协议, 文档的大小都为5KB, 第四层交换机采用源端口Hash调度算法, 分配器采用匹配文档类型的调度算法, 测试使用单台分配器和使用双台分配器时系统的最大每秒连接数。测试结果如图3所示。图3表明, 单分配器最多支持3台后台服务器, 而双分配器最多支持6台后台服务器, 即双分配器支持的后台服务器数量是单分配器的2倍。
如果采用更多的分配器, 系统支持的后台服务器的数量将进一步增加, 但由于我们测试客户机的数量和性能有限, 无法测试出系统的极限能力。
随着分配器数量的增加, 可采用网络处理器开发第四层交换机以消除第四层交换机的瓶颈。因为第四层交换机采用Direct Routing机制转发数据包, 并且其转发的数据包的类型仅包括SYN数据包、ACK数据包、FIN数据包和带HTTP请求的数据包, 其中前三种数据包都不带数据, 长度为64Byte, 而HTTP请求一般也很短, 从而, 其转发的都是很小的数据包, 平均大小一般不超过128Byte。仿真实验表明, Intel IXP2400转发128Byte数据包的流量至少可达800Mbps, 即819, 200个/秒。HTML文件的平均大小约为10KB。实验表明, 每服务一个10KB的请求, 且使用HTTP/1.0协议 (使用HTTP/1.1协议时, 转发的包更少) , 分配器约需要转发13个数据包, 那么第四层交换机最少每秒可转发819, 200/13=63, 015个请求。而我们的测试表明, 单台后台服务器 (P4-1.7G, 256M) 的极限服务能力一般不超过每秒500个10KB的请求, 也就是说, 即使服务器扩展到63, 015/500=126台时, 第四层交换机仍然不会成为系统的瓶颈。这对于局域网范围内的集群来说足够了。
6总结
本文分析了网络及Web应用的发展对Web集群请求调度提出的新要求, 即存储扩展性、调度算法的分布性和针对HTTP/1.1进行优化, 并提出了一种满足这些要求的新的请求调度模式——基于文档组织分布请求调度模式。实验表明, 该请求调度模式能有效减少HTTP/1.1带来的TCP连接迁移开销, 且能较好地均衡负载, 因而能取得较好的性能。并针对该请求调度模式的特点, 提出了一种分布调度、分布路由的Web集群体系结构, 该结构结合了多分配器集群和分布式集群的优点, 能有效减少集群内的通信开销和消除单点故障。实验结果表明, 该结构具有良好的可扩展性。
参考文献
[1]Hong J, Kim D.Hierarchical cluster for scalable web servers.Proceed-ings of IEEE International Conference on Cluster Computing[C].New-port Beach, USA, Washington:IEEE Computer Society Press, 2001:156-159.
[2]雷迎春, 李国杰, 张松.基于请求内容的高性能L5-Dispatcher[J].计算机研究与发展, 2002, 39 (2) :183-191.
[3]Aron M, Sanders D, Druschel P, et al.Scalable content-aware request distribution in cluster-based network servers[C].Proceedings of the2000Annual USENIX Technical Conference, San Diego, USA, Berke-ley:USENIX Press, 2000:323-336.
[4]Cherkasova L, Karlsson M.Scalable web server cluster design with workload-aware request distribution strategy WARD[C].Proceedings of the3rd IEEE International Workshop on Advanced Issues in E-com-merce and Web-Based Information Systems, San Jose, USA, Washing-ton:IEEE Computer Society Press, 2001:212-221.
[5]Sit Y F, Wang C L, Lau F.Socket cloning for cluster-based web server[C].Proceedings of the4th IEEE International Conference on Cluster Computing, Chicago, USA, Washington:IEEE Computer Society Press, 2002:333-340.
[6]Xiong Z, Wu G.MCBDist:a novel Markov-chain-based measure of dis-tance among webpages[C].Proceedings of IEEE International Confer-ence on Networking, Sensing and Control, Sanya, China, New York:IEEE Systems, Man and Cybernetics Society Press, 2008, 2:1577-1582.
[7]Su Z, Yang Q, Zhang H, et al.Correlation-based document clustering u-sing web logs[C].Proceedings of the34th Annual Hawaii Internation-al Conference on System Sciences, Maui, USA, Washington:IEEE Computer Society Press, 2001, 5:5022-5028.
[8]熊智, 郭成城.求解Web集群文档分布的混沌搜索算法[J].计算机工程, 2008, 34 (4) :10-12.
[9]Edward ChowC.WebBench[EB/OL].http://cs.uccs.edu/～cs526/webbench/webbench.htm.
请求调度模式 篇2
关键词：铁道通信信号 工作过程系统化 教学做一体化 工作页
长期以来，我国高等职业教育通常是普通高等教育的“课时缩减”版，没有体现出高等职业教育所应具备的“职业特性”。近年来，各学校各专业都在进行改革尝试，但是这种尝试若没有脱离“学科”体系的束缚，这种改革的效果不会很好，会影响人才培养的质量。要培养出符合社会需求的高素质技能型人才，关键问题是打破“学科体系”下的课程体系，创建具备浓厚“职业元素”的课程体系。基于“工作过程系统化”的理念，铁道通信信号专业进行了专业课程的构建。同时在教学过程中，注重对教学方式进行尝试，开发了和工作过程相吻合的“学生工作页”进行教学指导，辅以相对完善的实习实训条件，使培养出来的学生具备更多的职业素质，更好地贴进企业用人需求。
1 在“工作过程系统化”的框架下进行铁道通信信号专业课程构建
在当代的职业教育理念下，专业课程的内容和形式有了很大的变化，由原来的知识序化体系，转变为按照工作过程序化的体系。基于工作过程系统化的课程体系，在学生技能培养方面具有更强的针对性，从涵盖的专业知识方面具有学科的交叉性。在这一理念的指导下，在新时期铁路电务部门对现场信号系统、设备维护方面所提出的新要求的背景下，对铁道通信信号专业课程进行重构，从工作任务分析——典型工作任务的分析——行动领域——学习领域。在按照“工作过程系统化”的方法指导下进行课程开发，要注意每一门课程中所涉及的工作任务之间要具备3个以上有逻辑关系的工作过程，它们相互之间平行或包容。
■
图1 铁道通信信号专业课程体系简图
2 以工作页为载体、承载工学任务
“工作页”是根据行动导向理论，基于工作过程和认知规律设计的一种纸质化的课堂工学任务，其内容包括了工作要素、工作过程及学习任务，以及它们必然涵盖的显性的知识，工作过程知识，还有重构的知识结构和教学方案。既是学生的工作对象，也是老师的教学工具。可实现任务驱动、工学一体、情境教学、角色扮演等多种行动导向的教学方法。
工作页的核心思想是：用心设计，帮助学生学会工作。具体包括以下内容：
①工学目标：在这部分要明确给出任务完成后可以达到的技能目标和知识目标，描述中要具体，避免使用“掌握”、“了解”等较为宽泛的语言。如：在技能要求上，可用“会操作运转室内车务终端”、“能对信号机械室内出现的网络故障进行故障排查”；在设备或系统认知的要求上，可用“能描述行车调度设备车站机械室内设备构成要件”等。②准备工作：完成该任务与哪些其他任务相关，以及需要预先准备相关的信息。③验收标准规范：规定完成该任务可选择的策略、途径、计划、验收的要求。④工作内容制定：按照“工作过程系统化”的方式进行“工学任务”的设计开发。细化到工作步骤制定层面的时候，我们同样需要系统化和整体化考虑岗位中所设计的技术性问题，既要考虑工作过程的完整性，又要考虑前后任务之间的难度层次递进关系，同时保持各任务相对独立，把相关知识点合理地融入工作过程中。一部分知识可通过教师演示或角色扮演的形式获取，一部分知识通过对设备的实际操作获取，一部分知识可以通过操作产生疑问后通过咨询获取，这是信息化的时代学生所必须具备的几种获取知识的能力。
3 典型工作任务实施行动导向的教学过程
①布置任务：明确学习任务的目标和内容，通过引导，引起学生的学习兴趣，基础任务布置时，要交代与毕业入职之初所从事的初级工工作之间的相关性。②信息获取：根据学习工作页中提出的引导问题，通过多种途径获取与完成本工作任务直接相关的专业知识及信息。③制定工作计划。通过信息获取环节，5-6人的学习小组组内分工讨论，形成学做学习方案，制定最终实施计划，并查阅《铁道信号维护规则》，在教师指导下做出详尽的可实施流程。④演示。在铁路信号“故障-安全”原则指导下，必要的操作安全和规范务必通过教师演示或铁路现场技能专家演示视频示范使学生指导不仅“要做”，还要做得“规范”。⑤实施方案。在工作页的引导下，学生独立（分组）实施工作计划，教师进行监督、指导和答疑。⑥实施评价。对照规范操作，师生共同对学习全过程及实施结果进行评价，讨论完成下一工作任务的注意事项及过程改进意见。
4 教学工作页在实践中呈现的特点
在工作页中，针对行车调度设备的相关任务，使学生明确学习的技能目标、知识要求、学法指导、信息获取及任务评价等系列问题，学生可以根据工作页的指示、教师的辅助指导，尝试不同的方式在规定学时内完成任务操作及考核。
4.1 打造了“以学生为主体，教师为辅助”的课堂环境。以工作页为载体进行教学实施，实现了“教学做”合一。学生作为能动的学习主体，以完成“行车调度设备”某一工作任务为目标，在学习的过程中从资讯的环节开始就处于主动的地位，而教师则成为整个工作过程的组织者和服务者。
4.2 “仿工作过程”教学项目的设计，工作目标明确。以学生工作页作为学习载体，以典型工作任务的案例形式和要求呈现学习内容，在教实施之前，使学生明确学习任务和目标。激发学生化“学习目标”为“工作绩效”的意识，根据工作页部署的具体工作任务，使学生能够独立（合作）实施工作计划，多渠道、多维度完成工作任务中所蕴含的专业知识和有效信息。
4.3 基于电务现场的“绩效化”评价模式。具备铁路电务部门绩效考核特点的过程考核方式。电务段的绩效考核主要包括以下几个方面：①月度安全讲评考核；②月度信号故障考核；③月度安全生产责任考核；④制定职工奖惩细则；⑤干部责任追究考核；⑥职工业务素质考核。根据以上考核方式，制定本课程的过程考核方式：①项目操作安全考核10%；②项目组员协作考核10%；③制定学生奖惩细则10%；④责任连挂追究考核10%；⑤学生业务素质考核60%，以学生个体为单位对项目内容进行操作和答辩。考核方式①和②可根据项目复杂程度加权重值。
4.4 学生技能培养和情感培养一条线。
在完整的实践教学过程中，“教学做”全过程在一体化实训室中完成，加上“学习工作页”所承载的学习内容，使学生置身于较真实的工作环境中，能够促进学生主动参与、自主探查，使学生对工作现场“感同身受”，实现半开放式教学，在绩效化的评价模式的激励下，对学生的参与度、领悟度、完成度、工作质量等进行有效的肯定，从而提高教学质量，为学生步入铁路电务工作打下技能和情感基石。
5 总结
传统“学科”体系下铁道通信信号专业“铁路信号远程控制”课程教学实施过程中教学效果不理想。在通过对铁路电务部门信号工作进行“工作过程系统化”研究的背景下，对课程体系进行重构。在典型工作任务的教学过程中探究“工作页”式的教学模式，使得课堂学习氛围浓厚并紧张，调动了学生学习过程中的主观能动性；对学生“技能”和“情感”两手一起抓，培养了学生的综合职业能力；教学相长，教师在和学生互动“教学做”的过程中，不断提高了教师作为高职教师所必备的引导者的能力。
参考文献：
[1]姜大源.论高职教育工作过程系统化课程开发[J].徐州建筑职业技术学院学报，2010（3）.
[2]姜大源.关于工作过程系统化课程结构的理论基础[J].职教通讯，2006（1）.
[3]赵志群.职业教育工学结合一体化课程开发指南[M].清华大学出版社，2010.
请求调度模式 篇3
构建Web集群是提高Web服务器系统性能和扩展性的有效办法。在目前已提出的基于客户端、基于DNS、基于前端和基于服务端等多种Web集群结构中,基于前端的集群结构作为最佳方案[1]应用最为广泛,它由一个前端服务器(又称请求分发器或负载均衡器等)和若干台后端服务器组成。前端服务器负责接收客户端的请求,并按一定策略将请求分发到合适的后端服务器,由后端服务器直接为客户端提供服务。前端中使用的调度策略直接影响到集群系统的性能,合理的请求调度策略将决定Web集群的整体性能和扩展性[2]。
HTTP请求通常可以分为静态请求和动态请求,静态请求是对服务器文件系统中文件的请求,而处理动态请求时,服务器运行应用程序实时为每个请求生成回复数据。Yang等[3]建议对于静态请求应该采用基于局部性(Locality)的请求调度策略(如LARD[4]),通过将相同的请求调度到同一个服务节点,来获得很高的缓存命中率;而对于动态请求,由于不能利用内存缓存,所以应当尽量均衡负载。
静态请求产生的负载与所请求文件的大小成正比,所以很容易实现负载均衡。而处理多样化的动态请求所需要的服务器资源差异太大,而且无法预测,现有的各种调度策略都很容易造成负载失衡,影响系统的性能。
本文给出了一种实现简单的基于分类的动态请求调度策略(CBDRSP),不需要估计请求产生的负载,也能很好地在集群后端节点间均衡负载。本文余下部分结构如下:第2节介绍了动态请求调度策略的研究现状;第3节对CBDRSP进行了详细介绍;第4节对性能进行了测试;最后给出了结论。
2动态请求调度策略研究现状
关于动态请求调度策略的文献很少,这是因为相比于静态请求,动态请求的不确定因素太多。处理每一个动态请求所需要的系统资源截然不同,有的需要大量CPU资源、有的需要大量I/O资源,有的同时需要大量CPU资源和I/O资源,所以动态请求不像静态请求(仅需要I/O资源)那样可以被透彻分析,并有针对性地提出优化策略。
已有的研究中,动态请求调度策略大多采用了基于会话关联的方案。BEA提出的轮转(Round-Robin,RR)和会话关联(Session Affinity)相结合的调度策略就是一种基于会话关联的调度策略[5]。用户会话的第一个请求(如票务网站上的用户登录请求)根据RR来调度,而该会话上的所有后续请求根据基于会话关联的方案(Session-Affinity-based Schemes,SAbS)来分发,即同一会话中的所有请求被调度到同一台Web服务器上。基于会话的轮询策略不管请求的内容,不管用户会话的长短,也不考虑会话中每个请求的负载特性,可能会导致严重的负载失衡,如图1所示。
Casalicchio等人将HTTP请求分为四类:静态或轻度动态的Web发布业务、I/O密集型业务、计算密集型业务以及I/O和计算密集型业务。前端对每类业务维护一个调度关系的环形表,以此来均衡所有后端服务器上的多种资源承担的负载,而不至于使服务器上的单一资源(如CPU资源)过载。该方法考虑到了不同请求具有不同的负载特性,但是对负载类型划分的粒度太粗,而且对于如何区分请求属于哪类业务也没有给出很好的方法。
针对上述现有方法的缺点,本文提出了一种实现简单的调度策略,能很好地对动态请求实现负载均衡。
3基于分类的动态请求调度策略
CBDRSP的主要动机是按照产生的负载对请求进行分类,每类请求产生的负载大致相同,这样,只要对每类请求按照RR等比较简单的策略进行调度,就能实现所有请求在后端节点上的负载均衡。所以CBDRSP的关键就是如何在不估算请求产生的负载的情况下,对动态请求进行分类。
一个典型的动态网站有几千甚至几十万个页面,其中很多页面都是由相同的服务器应用程序以不同的输入参数运行出来的结果。对于编写良好的应用程序,这类请求会调用相同的服务器应用程序,而且按照几乎相同的流程执行几乎相同的代码(可能会因为参数不同而执行一些不同的小程序分支),因而具有几乎相同的计算复杂度,执行几乎相同的数据库查询,结果就是产生几乎相同的负载大小。根据以上分析,可以将动态请求按照执行的服务器应用程序进行分类。
最初,动态程序的参数都是直接加在带“?”的URL后,不同的参数之间以“&”进行分隔。如“http://www.eu169.com/photo/index.asp?user=1&page=2”,其中“/place/index.asp”是要执行的服务器应用程序,而“user=1&page=2”则是带的参数。对这种情况,很容易就能根据请求的URL对请求进行分类,只需要截取URL中域名以后至“?”之前的部分进行比较(大部分HTTP请求的GET、POST等操作后面带的URL中并不包含域名,域名在Host属性中指明),相同的就属于同一类请求。
现在的Web服务器软件为了方便记忆和搜索引擎收录,大都提供了URL重写(URL Rewrite)[6]功能,通过某种映射关系,将动态请求的URL变换为看起来更像静态请求URL的形式,如“http://www.eu169.com/photo/index-1-2.html”,也有一些第三方插件提供了这样的功能[7]。经过重写后的URL不能像之前的URL那么直观地进行分类。考虑到除了极少数网站会手动对动态页面进行URL重写设置外,大部分网站都用正则表达式对URL进行批量重写。显然,可以像Web服务器内部处理方式一样,通过正则表达式匹配的方式来还原出动态请求的原始应用程序名。在Web集群的前端中设置与Web服务器配置文件内相同的正则表达式,就能对请求按照改写过的URL进行分类。这可以通过在前端中直接读取并解析Web服务器的配置文件来实现。
将请求分好类后,就能按类来对请求进行调度。如果将每类请求能够均匀地分布到后端节点上,那么就实现了所有请求在集群后端节点上的负载均衡。根据前面的分析,属于同一个类的动态请求的负载大致相同,所以在各后端节点上分配相同数量的请求,就能实现均衡该类请求的负载。我们的实现中采用简单的RR算法来分配同类请求。
这里我们只考虑了同构集群的情况,即所有集群后端节点具有相同的处理能力。对于异构集群,可以很容易地通过为不同服务器赋予不同的权值,然后用加权轮转调度来实现负载的均衡。
4试验测试
我们用LoadRunner[8]对上述CBDRSP进行了量化分析。为了比较,我们实现了会话关联的请求调度策略SARD(Session Affinity Requests Distribution)。Web服务器使用Apache 2.2.3和PHP 5.2.4。Web服务器上有两个PHP页面:1.php和2.php,页面代码都是简单地进行循环计算,通过控制循环的次数,使得1.php在空闲服务器上的执行时间约为0.1s,而2.php的执行时间约为3s。
测试中有两个应用场景,第一个访问10次1.php,第二个访问10次2.php,用户的思考时间都为1s。试验中,我们用三台计算机运行LoadRunner,逐渐增加LoadRunner模拟的用户数,并统计集群系统的吞吐量。测试系统如图2所示,我们采用了三台相同的Web服务器(2.8Ghz CPU,1G内存)来组成同构的Web集群,前端也运行在和Web服务器相同配置的硬件平台上。
测试结果如图3所示,在用户数较少时,系统吞吐量几乎随着用户数的增加而线性增长;用户数增加到一定程度后,吞吐量增长变缓;当用户数达到Lmax(调度策略不同,系统的性能不一样,所以Lmax也不尽相同)后,吞吐量开始随着并发用户数的增加而减小。
由上图中的测试结果可以看出(图中的并发用户数是三个LoadRunner模拟出的用户总数),使用SARD时,由于是按照用户会话来调度的,调度粒度比较粗,在并发用户数远没有达到系统应有的Lmax(根据CBDRSP,系统应有的Lmax至少应该为350)时,由于出现了严重的负载失衡,导致吞吐量的增长开始变缓,并在用户数达到250时达到最大的吞吐量。相比SARD,CBDRSP的最大吞吐量增加了51.9%。随着并发用户数的不断增加,不管使用何种调度策略,所有后端节点最终都过载,使得各种调度策略的吞吐量趋于一致。
5结束语
我们提出了一种专门用于分发动态请求的调度策略CBDRS,它按照URL的模式将动态请求分类,使得属于同一类的请求对服务器产生几乎相同的负载,然后将每类请求按轮转方式分配到后端节点,从而实现了在不估算动态请求负载的前提下实现了负载均衡。测试结果表明在同构集群中,CBDRS的性能相比会话关联的请求调度策略SARD提高了51.9%。
参考文献
[1]Valeria C,Michele C,Philip S Y.Dynamic Load Balancing on Web-Server Systems.IEEE Internet Computing,1999,3(3):28～39
[2] Armando F, Steven D G, Yatin C. Cluster-based scalable network services. ACM SIGOPS Operating Systems Review, 1997, 31(5): 78～91
[3]Wu Y,ShuangQing L,DaiJie C.ALoad Balancing Strategy in Web Cluster System//Proceedings of the Third International Confer-ence on Natural Computation(ICNC2007).2007.809～813
[4]Vivek S P,Mohit A,Gaurov B.Locality-Aware Request Distribution in Cluster-based Network Servers.ACM SIGPLAN No-tices,1998,33(11):205～216
[5]BEA Systems Inc.BEA WebLogic Server10[EB/OL].http://www.bea.com/framework.jsp-CNT=index.htm&FP=/con-tent/products/weblogic/server/,2008.
[6] The Apache Software Foundation. URL Rewriting Guide [EB/OL]. http://httpd.apache.org/docs/2.2/misc/rewriteguide. html, 2008.
[7]Cristian D,Jaimie S.URL Rewriting Using ISAPI-Rewrite[EB/OL].http://www.isapirewrite.com/,2007.