系统集成中网格计算的调度

陆 艺

0 引言

随着各个领域对于计算机运算速度和存储容量需求的日益提高。无论是企业还是个人都需要数据处理能力更强大的计算机。于是，一种造价低廉（相对超级计算机）而数据处理能力超强的计算模式出现了,那就是网格计算。它正逐渐成为科学和商业领域高性能计算的主流方法。

网格计算（Grid Computing）是一种整合电脑资源的新手段，它依靠互联网共享强大的计算能力和数据储存能力。它是一种虚拟化的计算资源， 可以共享异构资源(跨平台，跨硬件/软件体系架构)，不受地理位置限制，它使用公开标准的网络上的资源（如闲置 CPU，磁盘存储空间，数据，软件程序等）。

网格环境的最终目的是从简单的资源集中发展到数据共享，最后发展到协作。当前网格计算不仅受到需要大型科学计算的国家级部门，如航天、气象部门的关注，目前很多大公司也开始追捧这种计算模式，并开始有了相关“动作”[1]。

本文结合作者系统集成的实际工作经验，研究企业内部如何通过网格计算来实现计算能力最大化，高效地进行跨平台，跨架构系统集成。以此提出可供其他企业或组织参考的系统集成的解决方案。

1 系统集成中网格计算的调度

1.1 网格计算

虚拟的数据网格应当能够分配、存储、计算网络资源来满足请求的全局和局部策略资源。全局策略包括“全社区”策略的管理，比如资源如何致力于一个优先级可调，资源可再分配的任务[8]。局部策略是特定场合的限制管理，规定外部用户何时，如何使用局部资源。并且设定局部用户在什么情况下相对于远程用户有优先权。一旦执行的计划任务与全局或者局部的策略冲突，这将会导致计划任务的失败。

计划和调度的目的就是在给出的全局和局部策略限制下，优化虚拟数据请求的响应[5]。不同的优化处理主要是为了满足：最小的执行时间，最大的可靠性，最小的特定资源使用等需求。

网格资源动态的特性，结合复杂多变的全局或局部策略，引起了如何高效分配资源的探讨。用户的需求有时不仅包括虚拟数据的请求，而且还包括优化策略例如，使用尽可能少的时间或者资源。所以调度和计划网格计算成为值得研究和具有挑战性的议题。

我们定义了一个中间件调度机制：基于策略的 ESG，它能够高效地重新设定任务。假如一个或者多个站点关机或者响应时间慢，它能够通过从监测系统获得的信息，改善应用总的执行时间；同时，能够通过管理策略限制来限制资源的使用。

2.2 高效的调度技术

在系统集成时，采用基于策略的调度技术，可以在资源使用策略限制下，给应用分配网格资源。能对各种资源进行优化调度。并且用ESG调度中间件追踪任务的执行，来提高工作流的完成时间。

基于策略的调度能够实现全局和局部的资源分配的优化，通过以下架构模块来实现：

1) 通过调整资源使用帐户和请求优先级来控制网格资源的请求分配。这个模块可以平衡网格中跨资源的工作负载，从而实现总体较高的利用率和较短的周转时间。

2) 支持预留基础网格资源的分配。这个模块要求出现在调度中的资源能够允许以预留资源和指定的时间来被执行。能够以预留的资源执行完请求。

3) 允许按照用户、组等各种类别的请求来设定质量服务。一个请求的提交者能按照被分派的权力来指定质量服务请求。资源分配要实现质量服务在提交者和调度程序间的交互，以便彼此能调整质量服务需求。

资源提供器给预期的资源用户分配限额的使用资源，调度程序通过跟踪限额的改变情况来监控资源的使用。它分配更多的请求给闲置的资源，同时减少给过高负荷的资源再分派请求。

1.3 ESG的策略调度

中间件ESG被用来在动态变化和异构的资源池中调度资源。它是高效系统集成的关键环节，它的主要架构，如图1所示：

图1 ESG 调度系统架构

ESG的服务器端是其主要的组件。它需要实现如下几个功能模块。首先，它决定如何分配资源池中的资源来完成请求。其次，它还要维护数据列表，保证可执行性和可复制性。并且，它要评估通过可获取资源完成请求的时间。最后，它要实时监控所拥有的资源状态。通过改变请求的状态、控制模块调用服务模块来处理请求的资源分配。这个控制器会检测在调度程序中的任务的状态，按照它的状态调用指定的服务模块来处理这个任务。它的接口模块用来维护数据库表以存储输入，输出信息。另外，它要维护目前已连接的客服端列表，用来确保各个客服端之间有效的I/O。服务器端中数据服务模块提供的可复制管理，包括可重现的任务运行信息和服务索引。网格监控模块用来跟踪CPU复制、磁盘、带宽等资源使用情况。

ESG的客服端同服务器端进行交互，用户向客服端传递执行请求来开始一个调度流程。客服端发送调度请求以及自己的客服端信息给服务器。从服务器端收到资源分配决定后，服务器端依据这个反馈，创建适当的提交请求任务，并提交到资源池中[2]。客服端的跟踪模块对提交任务的执行状态的保持跟踪。如果执行被阻塞或者任务被杀，那么客服端给服务器发送状态改变的报告，并且请求服务器重新计划调度被阻塞或者被杀的任务。

2 系统集成中的优化技术

由ESG结合网格计算，可以大大提高软件系统集成的效率。如果再配合使用一些其他的辅助技术，就可以使得系统集成更加高效和灵活。

这里要引入一个中间件RW（regression wrapper），它的打包算法可以高效地打包回归测试用例，然后再以任务的方式提交到网格资源池中，交由ESG进行调度。同时介绍一个提供移动工作环境的工具 Citrix，介绍它在目前工作中的辅助效用。

2.1 系统集成中的瓶颈

软件系统集成时，比较重要的，同时消耗大量资源（时间，机器）的是进行编译和回归测试[6]。尤其是大型软件的回归测试，将耗费大量时间和系统资源。

开发人员在白天完成开发每天的开发工作，通过配置管理工作提交代码。然后系统集成工程师会在每天晚上进行的编译和回归测试。这样就可以获得在代码开发过程中的实时代码质量报告，以及测试用例的状态。这样，开发人员第二天就可以进行有针对性的开发，如添加功能，进一步完善测试用例，修复新发现的bug等。

通常大项目的回归测试用例可能是几千甚至上万个，如何以较快的时间和较小的硬件资源代价跑完测试用例，是提高回归测试效率的关键。

在使用ESG和网格资源后，可以把所有回归测试用例以任务的方式提交给资源池进行运行。等所有的测试用例都运行完之后，生成最终的质量报告。但是这里仅仅依靠 ESG还是不够的。假设有海量的回归测试的测试用例提交到网格的资源池，如果有的测试用例占有大量资源和时间，而有的则非常快可以运行完且占有的资源又很少。这时如果仅仅提交任务由 ESG来调度。那么可能造成大量的小任务都完成了，而只有一个占有大资源，耗时大的测试用例还在等待资源去运行。

那么，这样的回归测试用例就成为了系统集成的瓶颈。另外有的性能测试用例本身需要占有的时间和硬件资源巨大，如果再把它和其他的测试用例打包成一个任务，必然导致这单个任务耗费时间久，占有资源多，并且容易被中断导致这个任务里的部分测试用例没有被运行到。这个任务将影响整个回归测试，使得质量报告不能及时生产以供开发者查看。在降低系统集成效率的同时影响了开发进度。

2.2 系统集成中回归测试的优化

所以在这里要引入一个小型中间件 RW(regression wrapper)，在提交任务给网格资源池时，能均衡任务的负载，使完成整个回归测试的耗时更少，占用硬件资源更小。

具体的实现方法是，首先通过数据库记录下最近一定时间周期内每个回归测试用例需要的运行时间、资源消耗的情况。然后，计算出每个测试用例在最近这个周期内所需的平均 CPU时间。再对这些测试用例的耗时进行从大到小的排序。再根据开发者的经验，设置可接受的时间阀值和资源阀值。

如果测试用例超过设定的时间或者资源阀值，那么它将被作为一个任务单独优先被提交到资源池，由ESG进行后续的调度和运行。这样就保证了平均耗时最长的测试用例首先被提交。从而优化了每次系统集成，回归测试占用的时间总长度。

由于硬件资源和运行槽（slots）的限制，显然不可能将每个测试用例都单独只打包成一个任务（job）提交到资源池中。所以，要依据以往每个回归测试用例的运行日志，用RW进行打包。如果资源占用和时间占有少于设定的阀值的，从排序后的列表两头选取测试用例进行任务打包。只要时间和资源占用仍然小于设定的阀值，就继续添加列表两头剩余的测试用例到该任务。一旦超过设定阀值，则开始打包一个新任务。采用这个算法，递归地将所用测试用例打包到一定数量的任务中。

如此把所有的测试用例都打包成单个任务后，时间和资源的占用都是相对接近设定的时间和资源阀值的。达到了每个任务负载相对均衡的目的。把这些任务分布式地提交到资源池后，它们会以均衡的资源占用，相似的运行时间来完成任务（跑完该任务中的回归测试用例）[7]。这样就避免了有的测试用例需要过长的运行时间，造成包含它的任务会占有极长的运行时间，而有的任务需要的运行时间极短。早早完成的任务需要在资源池里一直等待耗时最久的任务完成，之后，才能进行后期质量报告的生成。

有些任务可能由于硬件问题，如mount，NFS问题等，从而使任务悬挂（hang）而不能运行完成。这将使得整个回归测试不能按时完成。因此，中间件RW还添加了根据用户的需求来设置任务允许的运行时间的功能。一旦某个任务运行时间长于需求限制，它就将被杀（kill）。留下没有运行到的测试用例将进入自动再次打包流程，然后提交到资源池再次等待调度运行。这样就能避免由于意外的硬件问题拉长了整个回归测试的时间。

所以使用RW这个中间件进行测试用例任务打包时，可以使得所有回归测试的测试用例被合理得打包成多个任务。这些任务被提交进资源池后，能够以均衡的时间和资源负载来运行。从而使得系统集成中的耗时最久的回归测试能以较高的效率完成。

3 效果的分析

使用ESG和网格计算资源降低了软硬件的成本，共享了硬件资源，并且只需要维护一个数据中心的应用。同时，通过自动地管理闲置系统的电源设置，在非高峰时段减少功耗，拉低整体数据中心的运营成本，也秉承当今社会绿色环保的理念。

通过使用ESG和RW中间件，使公司系统集成自动化，提高系统集成的效率，从而提高产品研发效率。

在EDA设计公司，系统集成工程师从平均占有25个CPU提高到可以占有180个CPU来进行系统集成的工作（编译和运行回归测试）。而且，在主平台上（通常是amd64），回归测试的运行时间从10到12小时降低到平均4到5小时左右。

观察5次在amd64平台上的回归测试，如表1所示：

表1 回归测试资源耗费统计

由上表可见，测试总耗时远小于CPU的总耗时。并且单个最耗时任务的间是比较接近于整个测试总耗时的。创建的总任务数也比较稳定，大致是总测试用例的1/15。由此证明由RW中间件打包过的测试用例都能比较均衡的被运行。

设想没有ESG和RW中间件，那么CPU总耗时接近250小时的回归测试将要运行很久才能得到报告。这将大大影响开发的进程。而现在几乎每次回归测试都能在 5到 6小时左右运行完，并且生成报告。这意味着开发人员下班后，可以开始系统集成，那么第二天等开发人员上班时，报告已经在他们的邮箱供他们查阅了。

4 总结

随着网格计算的发展，怎么去寻求成本低，大运算能力的方式来实现高效得系统集成，已经成为大型企业关注的焦点[5]。

ESG是一个高效，灵活的解决方案，提高了资源利用率，增加了任务整体吞吐量。同时可以根据业务政策和目标来管理资源的使用，添加中间件来提高使用效率。

通过使用ESG和RW中间件，可以为大型企业带来更好的系统集成解决方案：

[1]用 gmake[3]并行处理 makefile：节省了大工程编译（build）的时间。

[2]多平台,多架构的回归测试：节省软硬件资源，减少回归测试的耗时。

当然，计算机技术日新月异，今后肯定会有更新的技术出现在系统集成领域。因此，需要进一步研究如何在企业中实现更高效的集成，为企业提供新的系统集成解决方案。从而提高整个产品线的开发效率，使得产品能够提前发布以抢占市场先机。

[1]徐志伟，冯百明，李伟编著，[M]《网格计算技术》，电子工业出版社，2004.

[2]Eadline, Ph.D., Douglas.The State of Oracle/Sun Grid Engine.［J］, Linux Magazine.Retrieved 2011.01.

[3]Robert Mecklenburg, GUN Make《项目管理》[M]，2006.

[4]N1 Grid Engine 6 用户指南 [K]， 2005.