|
Job Management System (JMS) is a component of cluster middleware responsible for management of users’ applications (i.e. jobs) execution at the computational cluster. Job Management System can be found in literature under the following names: Resource Management System, Workload Manager, Batching System, Local Resource Manager, Distributed Resource Manager and Queuing System.
Basic tasks of JMS are:
- optimization using cluster resources
- enablement of defining resources use policy
- establishment of users interface for job execution management.
Optimization of resources use refers to job scheduling in a way as to avoid situations where certain clients are overloaded and others are completely unloaded (load balancing). JMS places jobs into queues, and starts jobs in accordance with the load on clients and resources use policy.
Additionally, JMS can perform job migration after starting jobs in order to achieve better distribution of client load. For example, if users were allowed to start jobs directly on the clients, the following scenario would happen: users would be forced to monitor client load themselves before they start the jobs. Some users would start jobs at clients without checking. Furthermore, some users would continuously load the cluster with huge job quantities. JMS ensures avoidance of all three scenarios.
The second functionality of JMS is defining resources use policy. Administrators use JMS to define the mode of using certain clients of the cluster (allowed quantity of CPU memory, etc.) Furthermore, JMS allows assignment of higher or lower authority to certain users or groups of users. Thereby, for example, administrators can reserve some of the resources exclusively for jobs of one group of users, or they can reserve a cluster in certain time period (e.g. within the working hours).
JMS gives a unique users interface for starting jobs at the cluster. Using JMS, users can start jobs, monitor job execution, they reach data on resources use, they pause or stop jobs and retrieve job execution results. In addition to that, JMSs record data on job execution and resources use from a single user (accounting). Administrators use JMS to reach information and statistics on job execution. Information about usage use can be reused for charging the services provided.
Job Management System Architecture
Picture represents Job Management System Architecture. Job Management System consists of three modules: Queue Manager, Scheduler and Resource Manager.
Task of Queue Manager module is to receive requests for job execution from users and to save those jobs into queues. Queue Manager contacts Scheduler module and sends the job execution requests.
Scheduler is responsible for defining the mode in which jobs are executed, i.e. defining when and where will certain jobs be executed. In that process, Scheduler uses three sets of data: job information, resource information and scheduling policies. It receives job information from Queue Manager, and information on resources status and load from Resource Manager module. Scheduling policies are defined by cluster administrator, and based on them, cluster use policy is defined, i.e. it is defined which kinds of jobs (e.g. longer, shorter, parallel, interactive) have the advantage. Scheduler module is responsible for optimization of cluster resource utilization in accordance with scheduling policy.
Resource Manager is responsible for collecting data about client status and about starting and monitoring job execution. Resource Manager module consists of two components: server and nodes. Server collects information from nodes and sends them jobs which nodes are supposed to execute. Nodes are executed at clients and they are responsible for preparing the environment for job execution and client status monitoring.
Condor
Condor is a job management system which is primarily intended for HTC applications. Basic advantages are: CPU harvesting, special language ClassAds for job and client description and possibilities of process checkpointing and migration. Condor allows linking of several clusters, in such a way that one cluster, when it needs additional resources, forwards tasks to another cluster. Condor allows on demand computing, i.e. certain users can request certain group of resources at certain time. Condor is suitable for Grid systems because integration into Grid systems can easily be achieved, and it contains elements for authentication and linking with Globus Grid system. Another Condor’s advantage is that it can be used on a Windows platform.
Condor's disadvantages are as follows: Condor is intended primarily for HTC. Even though it can be used or performing parallel jobs, that is not the primary way it operates. Check pointing is possible only for programmes which are in translations connected with Condor booklets. Generally speaking, check pointing features refer only to serial applications.
SGE
Sun Grid Engine (SGE) is Sun's open source job management system. Basic advantage of SGE is intuitive graphic interface which enables access to all functionalities of the system. SGE's advantage is that cluster clients can be encapsulated into queues. Thereby it allows complex description of certain clients and implementation of arbitrary client load sensors. Using arbitrary sensors and client configuration SGE can be used for CPU harvesting. SGE allows calendar definitions. Calendars are used to define periods in which certain clients will not be available. That in turn allows using SGE for automatic cluster extension, with resources which are available in certain time period (e.g. during night). Users are allowed to define numerous job characteristics, including the choice of required (hard) and optional (soft) conditions. SGE allows starting job fields, i.e. multiple execution of the same programme, where, in each instance, different arguments can be given.
SGE’s disadvantages are the following: SGE in its current version has no possibilities of ‘’simple’’ creation of global queues. SGE allows creation of queue complex, but the procedure is rather unintuitive. According to documentation, SGE allows managing parallel jobs, but is practice has proven that mechanisms are not entirely operational. For example, MPI jobs can not be fully controlled, and data on resource usage can not be retrieved. In addition to that, SGE does not allow users to specify the way in which MPI processes will be distributed to the clients, but that is given in the SGE server configuration. SGE Scheduler module has limited defining scheduling policies features, and it has no features for pre-emptive scheduling and making reservations, which is very important in Grid systems.
It should be pointed out that SGE Version 5.3. was analysed. Version 6 is announced for end of 2004, which will eliminate some of the above mentioned disadvantages. Version 6.0 will allow global queue definition of making reservations, pre-emptive job scheduling and DRMAA interface.
OpenPBS, PBSPro and Torque
Portable Batch System PBS is an old and well tested job management system, developed for NASA’s needs. Later it was acquired by Veridian, which was later acquired by Altair. Since then, PBS is divided into OpenPBS and PBSPro. OpenPBS is an open source system intended for academic use. Veridian has focused further development on PBSPro, therefore the future of OpenPBS is uncertain. Cluster Resources Inc. has continued with OpenPBS development, under the name Torque (Tera-scale Open-source Resource and QUEue manager). Hereinafter, concept PBS is used in cases when all three systems are described.
Advantages of PBS are: interface for integration with parallel libraries, queue defining feature, advanced job scheduling and a feature for using arbitrary Scheduler module. PBS contains tm interface which allows parallel libraries to start parallel processes using PBS services. In that way, PBS has total control over parallel processes and can collect data on resource usage. Currently, LAM/MPI and MPICH (by additional mpiexec module) parallel libraries are supported. PBS allows simple creation of global queues with certain features. Using queues, it is possible to easily simply more policies of job scheduling.
The OpenPBS disadvantages are the following: biggest problem of OpenPBS is uncertainty of further development of the open source version. Graphic interface of PBS allows only working with jobs and monitoring client utilization. Configuration of clients, queues and other components of the system is done by commands from the command line or by adjustment of text files. In addition to that, graphic interface for working with jobs is impractical. As opposed to SGE, PBS does not represent clients as queues therefore there are no possibilities of defining sensors and complex client features. Furthermore, OpenPBS has no features for assigning job fields as SGE does. PBSPro is a commercial version of OpenPBS.
As opposed to OpenPBS, PBSPro comes with support and additional functionalities. Some of additional functionalities are: CPU harvesting, enhanced Scheduler module, integration with Globus services, and support for Windows OS.
LSF
Load Sharing Facility (LSF) is a product of company called Platform. LSF is extremely advanced system, which contains all features a JMS should have: it comes in a form of a distribution with all components of cluster middleware, it supports almost all platforms, has possibility of defining different forms of job scheduling (advanced reservations, pre-emptive scheduling), advance resource management (check pointing, job migration, error resistance, load balancing), advanced graphic interfaces for access to cluster functionalities, integration with Grid systems and possibility of linking several clusters.
Maui
Maui is an open source system intended for job scheduling. Maui is used primarily as job scheduler in other JMSs, but it can be used independently (see Clubmask cluster distribution). Maui can be integrated with the following job management systems: OpenPBS, PBSPro, Torque, SGE, LSF and Loadleveler.
Maui has following functionalities: job scheduling based on making reservations and defining extremely complex job scheduling policies. Maui allows scheduling according to the following principles: fair share, backfilling, fixed resource reservations, assigning priorities based on job characteristics (e.g. owner or a group of owners, job size related to space or time). In addition to that, Maui contains a set of tools for retrieval of job execution history and different forms of job statistics and resource usage.
Maui’s disadvantage is that efficiency of job scheduling depends on the fact how well users describe their requests. For example, backfilling will not be pronounced at all if users don’t define job duration. Request definition problem is not associated with Maui only, but with all job management systems which accomplish scheduling on the basis of making reservations.
Moab
Moab Workload Manager is a commercial product of Cluster Resources aiming at extending the functionalities of job management systems. Basic functionalities of Moab Workload Manager are: possibilities of defining advanced job scheduling policies, integration of more job management systems and other resource management systems (e.g. data warehouse management system), interfaces for integration with other cluster middleware systems (e.g. accounting and cluster monitoring systems), intuitive interface in a form of a web portal (Moab Access Portal) and support for integration with Grid systems. Functionalities related to job scheduling are identical to functionalities offered by Maui.
Loadleveler
Loadleveler is an IBM job management system intended for IBM AIX platform. Loadleveler architecture is based on Condor, therefore they have similar features. Despite that Loadleveler is intended primarily for HPC, and it allows working with parallel jobs. Loadleveler is currently being adjusted to Linux/x86 platform, therefore it is recommended to continue to track its further development.
CCS
Computing Center Software (CCS) is a system developed at German institute Paderborn Center for Parallel Computing. Basic functionalities are: scheduling based on making reservations (like Maui), features for check pointing of all job forms (in development), graphic interface, integrated cluster monitoring systems, defining advanced job scheduling policies (reservations, backfilling).
Others
Quadrics RMS (Resource Manager System) is intended primarily for clusters networked with Quadrics QsNet equipment. Basic features of RMS are: cluster monitoring interface, and advanced scheduling and parallel jobs control.
Another example of commercial JMS is JAMS (Job Access and Management System), Except for the Linux platform, JAMS also supports Windows platforms. Basic features of JAMS are: graphic interface for access to functionalities and interface for filling additional job requests.
Bamboo is a job management system developed at Scalable Systems Software Center. Basic feature of Bamboo is the possibility to manage a cluster with a large number of clients (e.g. 50000 clients). Alongside to developing Bamboo, Scalable Systems Software Center institute is developing standards for interfaces of certain modules of job management systems: Queue Manager, Scheduler, and Resource Manager. As a result of their work, a set of interfaces has been developed. Systems that currently support interfaces are: Maui, Torque and Bamboo.
|
|
