OpenPBS调研报告.docVIP

TORQUE与OpenPBS、maui的关系 TORQUE是OpenPBS的改进版本，用户提交的任务先在资源管理系统的等待队列排队 ,直到任务需要的资源(CPU 类型、数量内存大小等)满足条件才能执行。它支持多种操作系统 ,支持不同类型节点的集群 ,提供 CLI、GUI和 C API用户接口 ,还支持批处理、并行、交互型作业。TORQUE在下面几个方面做了改进： (1)可扩展性:更满足大规模集群运算的需要 ,标准 OpenPBS支持约 300 个节点 , TORQUE 可以支持超过 1 500 个节点; (2)容错性:修正了大量 bug ,提供更多故障支持; (3)调度界面:为调度软件提供更多、更准确的信息; (4)易用性:更加人性化、易读的日志功能。 TORQUE最重要的一个特点就是能使用内部调度模块。一般我们使用的是maui ,它根据事先定义的集群调度策略决定等待队列中的任务在什么时间和哪些节点上运行 ,在满足不同用户需求和最大化整个集群利用率之间达到动态平衡 ,并且提供了高级预定、复杂调度策略、平均调度和各种管理、诊断集群的工具。它们两者的结合大大提高了作业调度的性能。 目前存在几十种集群作业管理系统,颇具代表性和影响力的如 OpenPBS、CONDOR、LSF、LOADLEVELER,其中 OpenPBS、CONDOR是研究产品，LSF、LOADLEVELER是商业软件。比较各个系统都不同程度的存在优缺点,如 OpenPBS和 CONDOR同属于研究产品, OpenPBS提供了灵活的调度策略和用户的身份认证机制,但 CONDOR则比较全面地实现了检查点的操作 。通过分析比较,在本集群项目中选择 OpenPBS作为集群作业管理系统,主要 原因是 OpenPBS是开源产品及 OpenPBS目前来说对集群还是相对提供了很好的支持,但如果集群项目的并行处理,对于作业调度的执行时间和吞吐量有很高的要求,仍然需要在OpenPBS基础平台上对作业调度策略进行二次开发 OpenPBS体系结构及工作原理 PBS最初由 NASA的 Ames研究中心开发 ,目的是提供一个能满足异构计算网络需要的软件包 ,特别是满足高性能计算的需要。它提供 TCL、BACL、C三种过程语言 ,其调度策略允许被修改 ,以适应不同的计算需要和目标。目前存在两种版本的 PBS,分别是商业软件 PBSPro和研究产品OpenPBS 。 2. 1　OpenPBS体系结构 OpenPBS分别由 Server, Scheduler和 MOM构成 ,如图 1所示 , Server是系统与用户的接口 ,负责接收和修改用户的批处理作业 ,调用 scheduler进行作业调度 ,并通知 MOM执行作业; Scheduler通过与 MOM通信获取各节点的状态 ,通过与 server通信获取用户对作业执行的要求和所有的作业信息 ,并结合系统的调度策略给出合理的调度方案MOM负责控制作业的执行 ,与 server进行实时通信 ,对作业执行情况进行修改和控制 ,并负责收集本节点状态和作业状态信息。整个系统只有一个server和 scheduler,但每个节点有一个 MOM。 图 1　OpenPBS体系结构 2. 2　OpenPBS作业调度执行过程 OpenPBS系统中的作业执行主要依靠服务进程调度进程及执行进程,如图 2所示,执行过程如下: 图 2　OpenPBS作业调度执行过程 (1)由客户产生事件 ,事件通知服务进程开始一个调度周期; (2)服务进程发送一个调度命令给作业调度器; (3)作业调度器向执行进程请求可用资源信息; (4)执行进程返回给作业调度器一个资源信息; (5)得到资源信息后 ,作业调度器向服务进程请求作业信息; (6)服务进程接收请求 ,并发送作业信息至作业调度器 ,产生执行作业的策略; (7)作业调度器发送执行作业请求至服务进程; (8)服务进程接收请求后 ,发送作业至执行进程执行作业。 2. 3　OpenPBS默认 FIFO存在的问题 OpenPBS包括几种内置的调度器 ,默认的调度器是基于 C的 FIFO,如图 3所示 ,但并非如同名字所示 ,不是一个严格意义上的 FIFO,而是追求 CPU的最大利用率。调度器循环扫描作业队列 ,执行第一个满足当前有效系统资源需求的作业,这种机制导致大作业需要的资源不能满足而阻止了其运行 ,使其可能长时间不能得到执行 ,从而产生饥饿现象。为了保证大作业的公平性 , FIFO调度器实现了一种饥饿作业调度方法 ,当某一作业等待时间超过一定时间界限 (如默认为 24小时 ) ,即对该作业所需要的资源进行预约 ,即这些资源中的一部分成为可用时 ,不再分配给其它的作业 ,一直到预约的所有资源都已得到满足时 ,将该作业投入运行。在此期间