> Grid-Introduction > Grid Middleware & Training Systems > gLite

The gLite middleware was and still is developed in the EU projects EGEE and EGEE II, based on the Large Hadron Collider Computing Grid (LCG). It serves especially to operate in different scientific disciplines. It integrates components of other middleware such as Globus Toolkit and Condor. In gLite, resources are called compute elements (CE). The central element is the resource broker (RB). Users address their jobs to the resource broker, which is responsible for distribution and monitoring of the jobs. Jobs are described platform independently by a Job Description Language (JDL). Further components of a grid based on gLite serve for authorization and authentication of users, capturing of activities and states of computations in the grid (logging) or to control computations on a computing element. The gLite middleware is open source, available in version 3.1 and offers all base operations for grids.

The gLite grid middleware has a service oriented architecture including the following core capacities:

(1) The resource broker, also called Workload Management System (WMS), is responsible for the distribution and management of jobs. Jobs are sent to the RB by a user interface (UI) in form of a JDL file. It is the task of the resource broker to investigate the demand for resources out of the JDL description and to find the most reasonable and available resource in the grid depending on notifications by the replica catalogue (RC) and the information service (IS). This will guarantee an efficient execution of the job. This procedure is called match-making. The RB forwards the job together with the input sandbox to the selected computing element. After the request of the user interface, the output will be wrapped in an output sandbox and sent back to the user interface.

(2) The computing element contains a series of working nodes (WN) executing the jobs. The main function of a CE is the managing of job submission, i.e. from the batch management. The CE finds WNs appropriate for the job and forwards the job via the batch system. Further, it maps  user domain names to pool account IDs (grid mapping). Basically, a CE may work in two different modes: in a push mode (WMS pushes jobs in a queue) or in a pull mode (CE requests jobs from WMS).

(3) The working node consists of pool accounts, runs executables and reports the output or an error message to the CE.

(4) The logging and bookkeeping functions save all relevant incidents related to the execution of a job. Other gLite services report to these functions as well, enabling the logging service to prove detailed state histories for each job, starting with the resource brokering up to the presentation of results as well as the release of resources. The information can be viewed to some extent by the user with the request glite-wms-job-status in the user interface.

(5) The user accesses the grid via the user interface. The most famous commands are glite-wms-job-submit for the submission of jobs, glite-wms-job-cancel to cancel jobs and glite-wms-job-output to collect the output. The Credential Delegation Service (CDS) is also executed in the user interface via voms-proxy-init. The Grid Security Infrastructure (GSI) enables a secure authentication amongst others via X.509 certificate and the SSL protocol.

(6) The Virtual Organization Management System (VOMS): the user authorization via virtual organizations is based on central databases (VOMS – one database per VO). Information is read by the components RB, CE and Storage Element (SE) to create a local list of authorized users. Special service groups enable access to Storage Elements, offer catalogue services and provide interfaces for the Monitoring System.

Click here to get an overview about our gLite e-learning materials and training systems.