EGEE Home | Technical Pages Home | Search | EDMS Documents | People | Calendar | Agenda maker | Glossary

JRA1: Workload Management

Tools Testing Integration Information
Services
Workload
Management
Data
Management
Security Management

JRA1 Home | Workload Management Home | Mandate | People | Meetings | Presentations | Savannah Portal| Useful links | Actions list | EDMS



WMS Architecture overview


The Workload Management System (WMS) comprises a set of Grid middleware components responsible for the distribution and management
of tasks across Grid resources, in such a way that applications are conveniently, efficiently and effectively executed.

The specific kind of tasks that request computation are usually referred to as "jobs". In the WMS, the scope of tasks needs to be broadened to take into account other kinds of resources, such as storage or network capacity. This change of definition is mainly due to the move from batch-like activity to applications with more demanding requirements in areas like data access or interactivity, both with the user and with other tasks. The WMS will broaden its scope accordingly.

Functionality


The core component of the Workload Management System is the Workload Manager (WM), whose purpose is to accept and satisfy requests for job management coming from its clients. The other fundamental component is the Job Logging and Bookkeeping Service, which is described in another section (LB).

For a computation job there are two main types of request: submission and cancellation (the status request is managed by the Logging and Bookkeeping Service).

In particular the meaning of the submission request is to pass the responsibility of the job to the WM.
The WM will then pass the job to an appropriate CE for execution, taking into account the requirements and the preferences expressed in the job description.
The decision of which resource should be used is the outcome of a matchmaking process between submission requests and available resources.
The availability of resources for a particular task depends not only on the state of the resources, but also on the utilisation policies that the resource administrators and/or the administrator of the VO the user belongs to have put in place.

Describing the functionality of the WM as submitting a classad-based job request, being able to control it (cancel, possibly send signals to
it, put it on hold and release it), and get its status, shows that the WM has an interface that is very similar to the one of the CE.
Whether this can be exactly the same (which is among our goals) depends largely on finding a suitable solution to issues for the CE such as
maintaining a consistent and reliable view of the job request as it travels through the system and making sure that no components in the CE can cause job requests to be lost.

The Overall Architecture


The figure shows the overall architecture of the Workload Manager, together with the interactions with external entities.
Among these the most coupled with the WM is the Logging and Bookkeeping Service, which keeps events generated by different components as a job traverses them.
Such events contribute to the generation of the status of a job.
Other entities are the Information System, used, for example, to fill the Information Supermarket, the Data Management services,
assisting the WM when the scheduling involves knowledge concerning location of data on the Grid and the Access Policies infrastructure.

Both the WM and the other services are expected to offer a Web Service interface.


       Disclaimer Contact   Last Modified: Monday, 06-Sep-2004 10:23:38 CEST