Resource Management on Computational Grids

(1)

1/29

Univerist`

a Ca’ Foscari, Venezia

http://www.dsi.unive.it

Resource Management

on Computational Grids

Paolo Palmerini

Dottorato di ricerca di Informatica

(anno I, ciclo II)

(2)

2/29

Outline

• Introduction to Grid Technology

? What is a “Grid”

? Tools and projects

• The Globus toolkit Box

? Globus services

• Resource Information Infrastructure

? The globus MDS

? GRIS & GIIS

• A Grid Resource Broker

? State of the Art

(3)

3/29

General Motivation

• HPC applications are becoming complex and multidisciplinar

? High Energy Physics

? Aircraft design

• Resources are inherently distributed

• Need for new models and approaches to HPC, distributed computing, resource management.

(4)

4/29

What is a “Grid”?

I. Foster and C. Kasselman, The Grid: blueprint for a future infrastructure, Morgan Kaufman, 1999

• Starting from the analogy with electric power grid

• Gathering diverse and large scale distributed resources in a unique and coherent view

(5)

5/29

Grid Architecture

• Fabric layer ? Computational resources ? Storage resources ? Network resources ? Code repositories ? Catalogs • Connectivity layer ? Signle sign on ? Delegation

(6)

6/29

Grid Architecture (cont’d)

• Resource layer ? Information Protocols ? Management protocols • Collective layer ? Directory Service ? Scheduling, co-allocation

? Monitoring and diagnosing

? Grid-enabled programming systems

? Workload management systems

? Community authorization servers

(7)

7/29

Grid Middleware

• Globus ? http://www.globus.org • Legion ? http://www.legion.org • Condor ? http://www.cs.wisc.edu/condor • Harness ? http://www.epm.ornl.gov/harness

(8)

8/29

The Globus Toolkit

A software toolkit addressing key technical problems in the development of Grid enabled tools, services, and applications

• Offer a modular “bag of technologies”

• Enable incremental development of grid-enabled tools and applica-tions

• Implement standard Grid protocols and APIs

(9)

9/29

Basic Globus Services

• Security • Communication • Fault Detection • Information Infrastructure • Resource Management • Portability • Data Management

(10)

10/29

(11)

11/29

(12)

12/29

Resource Specification Language

Example: 3 stages pipe + ( &(resourceManagerContact="prosecco.cnuce.cnr.it") (count= 1) (label="subjob 0") (environment=(GLOBUS_DUROC_SUBJOB_INDEX 0)) (arguments= "pipe.conf" "128" "128" "20" "10") (directory="/home/prosecco/palmeri/ASI-PQE/MPI/src") (executable="/home/prosecco/palmeri/ASI-PQE/MPI/src/pipe-g") ) ( &(resourceManagerContact="barbera.cnuce.cnr.it") (count= 4) (label="subjob 1") (environment=(GLOBUS_DUROC_SUBJOB_INDEX 1)) (arguments= "pipe.conf" "128" "128" "20" "10") (directory="/home/prosecco/palmeri/ASI-PQE/MPI/src") (executable="/home/prosecco/palmeri/ASI-PQE/MPI/src/pipe-g") ) ( &(resourceManagerContact="prosecco.cnuce.cnr.it") (count= 1) (label="subjob 5") (environment=(GLOBUS_DUROC_SUBJOB_INDEX 2)) (arguments= "pipe.conf" "128" "128" "20" "10") (directory="/home/prosecco/palmeri/ASI-PQE/MPI/src") (executable="/home/prosecco/palmeri/ASI-PQE/MPI/src/pipe-g") )

(13)

13/29

First problem: which RSL level?

ground RSL is too complex:

ground RSL ( &(resourceManagerContact="barbera") (count= 4) (label="subjob 1") (environment=(GLOBUS_DUROC_SUBJOB_INDEX 1)) (arguments= "pipe.conf" "128" "10") (directory=".") (executable="./pipe-g") )

High level request

run pipe-g on 6 nodes

with 128 MBytes memory each

(14)

14/29

Metacomputing Diretory Services

• Basic elements are Virtual Organizations (VO)

• Scalability achieved through a distributed model

(15)

15/29

MDS Implementation

• Grid Information Service (GRIS)

? Provides resource description

? Modular content gateway

• Grid Index Information Service (GIIS)

? Provides aggregate directory

? Hierarchical groups of resources

• Lightweight Dir. Access Protocol (LDAP)

? Standard with many client implementations

(16)

16/29

Lightway Directory Access Protocol

• Structural information

? Resource hierarchy maps to objects

? Named positions in LDAP DIT

• Merged information

? Some parents join child data

? Simplifies common query patterns

• Auxiliary information

? Uniform representation of leaf/ par-ent data

(17)

17/29

Second Problem: resource discovery

• Which resources do we need?

• Where do we find them?

(18)

17/29

Second Problem: resource discovery

• Which resources do we need?

• Where do we find them?

• How do we use them?

The entity should:

• Understands our needs

• Looks for the best resources available

(19)

18/29

Nimrod/G: a Grid Resource Broker

• A specialized system for the execution of parametric jobs on distributed resources.

• Uses a simple language to express the experiment and provides machinery that automates the task of formulating, running and monitoring the jobs, and collecting the results.

• Uses Globus Services

• Four phases scheduling algorithm

? Discovery. Based on MDS

? Allocation. Evaluate a cost foreach job.

? Monitoring

(20)

19/29

Limitations of Nimrod/G

• Narrow application domain. Parametric problems are only a part of Grid Applications.

• No communications among components. Network influence is not properly considered.

• Cost model assumes constant job behavior. In many cases the cost of a job cannot be known in advance (e.g. datamining).

(21)

20/29

Sun Grid Engine Software

• Revenue from grid computing solutions is expected to grow from

$1.5 billion (2001) → $4 billion 2003;

• A set of tools for managing distributed resources;

• Aimed at optimizing resource usage within an organization;

• Based on a centralized queue where jobs are submitted and scheduled to the most adequate resource;

• Jobs are described in terms of resource requirements, (hardware and software licenses) and priorities;

• It’s an open source project!

http://www.sun.com/gridware http://www.gridengine.sunsource.net

(22)

21/29

Resource Management of Structured

Applications

• We want to manage the configuration and execution of structured parallel applications on computational grids.

? Describe the application and its requirement

? Discover the resources that match the requirements

? Schedule the components onto the discovered nodes (co-allocation)

• Important issues

? heterogeneous architecure

? executable staging

(23)

22/29

Describing Structured Applications

• The application can be described by means of a configuration file, built in a semi-automatic way.

? static info: application structure, component names and implementations

? dynamic info: parallelism degree, mapping of components onto machines. • Coded in XML, but Conceptually equivalent to ground RSL.

<global_config> <structure> </structure> <granularity> </granularity> <mapping> </mapping> </global_config>

(24)

23/29

Configuration file

Components of the XML file

• structure

Specify the general structure of the application, by means of a generic graph. Component names and mutual dataflow

dependencies. Also the name and location of the modules (i.e. files) that implements the components.

• granularity

The parallelism degree and the replication of each component. For example the number of workers in a farm, or the number of

processes for a parallel module.

• mapping

(25)

24/29

Resource Discovery

Varius approaches are possible:

• Sol. 1. Query a statically known list of other GRIS or GIIS.

? Many queries during configuration.

• Sol. 2. Build an ad-hoc root GRIS that covers a statically known list of other GRIS or GIIS.

? Queries are resolved locally.

? Use the globus mechanism for updating information.

• Sol. 3. Search engine for grid resources

? Off-line spidering of all the GRIS and indexing them

? On-line query engine that finds resources that matche user queries.

(26)

25/29

Scheduling

• Once the application is configured (in its granularity and mapping), we have the low level RSL specification and the application could be started.

(27)

25/29

Scheduling

• But the grid is a highly heterogeneous environment, whose status rapidly changes during time.

(28)

25/29

Scheduling

• But the grid is a highly heterogeneous environment, whose status rapidly changes during time.

• We can introduce a centralized scheduler that is in charge of managing the queue of requests for the computational grid.

(29)

26/29

Scheduling

The Grid Scheduler should:

• Co-schedule application’s component, when possible.

• Optimize resource utilization (i.e. overlapping communication and computation).

• Apply application specific (hence more accurate) cost models.

(30)

27/29

A Grid Resource Broker for

Structured Parallel Applications

(31)

28/29

References

[1] I. Foster and C. Kasselman, The Grid: blueprint for a future infrastructure, Morgan Kaufman, 1999

[2] I. Foster, C. Kesselman, S. Tuecke, The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International J. Supercomputer Applications, 15(3), 2001.

[3] I. Foster, C. Kesselman, Globus: A Metacomputing Infrastructure Toolkit,. Intl J. Supercomputer Applications, 11(2):115-128, 1997.

[4] K. Czajkowski, S. Fitzgerald, I. Foster, C. Kesselman, Grid Information Services for

Distributed Resource Sharing , Proceedings of the Tenth IEEE International Symposium on High-Performance Distributed Computing (HPDC-10), IEEE Press, August 2001.

[5] K. Czajkowski, I. Foster, N. Karonis, C. Kesselman, S. Martin, W. Smith, S. Tuecke, A Resource Management Architecture for Metacomputing Systems, Proc. IPPS/SPDP ’98 Workshop on Job Scheduling Strategies for Parallel Processing, po. 62-82, 1998.

[6] LDAP, http://www.openldap.org

[7] Abramson, D., Giddy, J., Foster, I., and Kotler, L., High Performance Parametric Modeling with Nimrod/G: Killer Application for the Global Grid? , in 2000 International Parallel and Distributed Processing Symposium Cancun, Mexico.

(32)

29/29

[8] R. Baraglia, R. Ferrini, D. Laforenza, S. Orlando, P. Palmerini, R. Perego, Sistemi di Calcolo ad Alte Prestazioni per Applicazioni di Osservazio ne della Terra, Deliverable 1,2,3,4,5, WP5, ASI-PQE

[9] S. Orlando, P. Palmerini, R. Perego, F. Silvestri, Knowledge Grid scheduling , (submitted work)