pegasus-a framework for planning for execution in grids ewa deelman [email protected] usc information...

21
Pegasus-a framework for planning for execution in grids Ewa Deelman [email protected] USC Information Sciences Institute

Upload: merilyn-miller

Post on 01-Jan-2016

222 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

Pegasus-a framework for planning for execution in grids

Ewa Deelman

[email protected]

USC Information Sciences Institute

Page 2: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

2Ewa Deelman pegasus.isi.edu

Outline

Pegasus overview

Components used by Pegasus

Deferred planning

Portal

Pegasus Acknowledgments:

Carl Kesselman, Gaurang Mehta, Mei-Hui Su, Gurmeet Singh, Karan Vahi, Ewa Deelman

Page 3: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

3Ewa Deelman pegasus.isi.edu

Pegasus

Flexible framework, maps abstract workflows onto the Grid

Possess well-defined APIs and clients for:– Information gathering

> Resource information> Replica query mechanism> Transformation catalog query mechanism

– Resource selection> Compute site selection> Replica selection

– Data transfer mechanism Can support a variety of workflow executors

Page 4: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

4Ewa Deelman pegasus.isi.edu

Pegasus Components

PEGASUS ENGINE

CPlanner (gencdag)

Rls-client Tc-clientGenpoolconfig

client

Data Transfer Mechanism

Gridlabtransfer

Transfer2

Multiple Transfer

Globus-url-copy

Stork

Transformation Catalog

Mechanism(TC)

DatabaseFile

Resource Information

Catalog

MDS File

Submit Writer

CondorStork Writer

GridLab GRMS

Pegasus command line clients

RoundRobin

Site Selector

Min-Min

Max-MinProphesy

Random

Grasp

RLS

Replica Query and Registration

Mechanism

Replica Selection

Existing Interfaces

Research Implementations

Production Implementations

Interfaces in development

RLS

Page 5: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

5Ewa Deelman pegasus.isi.edu

Pegasus:A particular configuration

Automatically locates physical locations for both components (transformations) and data– Use Globus RLS and the Transformation Catalog

Finds appropriate resources to execute the jobs– Via Globus MDS

Reuses existing data products where applicable– Possibly reduces the workflow

Publishes newly derived data products– RLS, Chimera virtual data catalog

Page 6: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

6Ewa Deelman pegasus.isi.edu

Replica Location Service

Pegasus uses the RLS to find input data

LRC LRCLRC

RLI Computation

Pegasus uses the RLS to register new data products

Page 7: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

7Ewa Deelman pegasus.isi.edu

Use of MDS in Pegasus

MDS provides up-to-date Grid state information– Total and idle job queues length on a pool of resources

(condor) – Total and available memory on the pool– Disk space on the pools– Number of jobs running on a job manager

Can be used for resource discovery and selection– Developing various task to resource mapping heuristics

(pluggable)

Can be used to publish information necessary for replica selection– Developing replica selection components

Page 8: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

8Ewa Deelman pegasus.isi.edu

KEYThe original node

Pull transfer node

Registration node

Push transfer node

Job e

Job g Job h

Job d

Job aJob c

Job f

Job i

Job b

Abstract Dag Reduction

Pegasus Queries the RLS and finds the

data products of jobs d,e,f already

materialized. Hence deletes those jobs

On applying the reduction algorithm additional jobs a,b,c

are deleted

Implemented by Karan Vahi

Page 9: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

9Ewa Deelman pegasus.isi.edu

Pegasus adds replica nodes for each job that materializes data (g, h, i ).

These three nodes are for transferring the output files of the leaf job (f) to the output pool, since job f has been deleted by the Reduction Algorithm.

Concrete Planner (1)

Pegasus schedules job g,h on pool X and job i on pool Y. Hence adding an interpool transfer node KEY

The original node

Pull transfer node

Registration node

Push transfer node

Node deleted by Reduction algo

Inter-pool transfer node

Job e

Job g Job h

Job d

Job aJob c

Job f

Job i

Job bPegasus adds transfer nodes for transferring the input files for the root nodes of the decomposed dag (job g)

Implemented by Karan Vahi

Page 10: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

10Ewa Deelman pegasus.isi.edu

Pegasus Components

Concrete Planner and Submit file generator (gencdag)– The Concrete Planner of the VDS makes the

logical to physical mapping of the DAX taking into account the pool where the jobs are to be executed (execution pool) and the final output location (output pool).

Page 11: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

11Ewa Deelman pegasus.isi.edu

Pegasus Components (cont’d)

The following catalogs are looked up to make the translation– Transformation Catalog (tc.data) (also DB based)– Pool Config File– Replica Location Services– Monitoring and Discovery Services

XML Pool Config generator (genpoolconfig)– The Pool Config generator queries the MDS as well as local

pool config files to generate a XML pool config which is used by Pegasus.

– MDS is preferred for generation pool configuration as it provides a much richer information about the pool including the queue statistics, available memory etc.

Page 12: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

12Ewa Deelman pegasus.isi.edu

Transformation Catalog

Pegasus needs to access a catalog to determine the pools where it can run a particular piece of code.

If a site does not have the executable, one should be able to ship the executable to the remote site.– Newer version of Pegasus will prestage a statically linked

executable

Generic TC API for users to implement their own transformation catalog.

Current Implementations– File Based#poolname logical tr physical tr envisi preprocess /usr/vds/bin/preprocess VDS_HOME=/usr/vds/;

– Database Based

Page 13: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

13Ewa Deelman pegasus.isi.edu

Pool Config

Pool Config is an XML file which contains information about various pools on which DAGs may execute.

Some of the information contained in the Pool Config file is– Specifies the various job-managers that are available

on the pool for the different types of condor universes.– Specifies the GridFtp storage servers associated with

each pool.– Specifies the Local Replica Catalogs where data

residing in the pool has to be cataloged.– Contains profiles like environment hints which are

common site-wide.– Contains the working and storage directories to be

used on the pool.

Page 14: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

16Ewa Deelman pegasus.isi.edu

Properties

Properties file define and modify the behavior of Pegasus.

Properties set in the $VDS_HOME/properties can be overridden by defining them either in $HOME/.chimerarc or by giving them on the command line of any executable.– eg. Gendax –Dvds.home=path to vds home……

Some examples follow but for more details please read the sample.properties file in $VDS_HOME/etc directory.

Basic Required Properties– vds.home : This is auto set by the clients from the environment

variable $VDS_HOME

– vds.properties : Path to the default properties file > Default : ${vds.home}/etc/properties

Page 15: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

17Ewa Deelman pegasus.isi.edu

Concrete Planner Gencdag The Concrete planner takes the DAX produced by Chimera

and converts into a set of condor dag and submit files.

Usage : gencdag --dax <dax file> --p <list of execution pools> [--dir <dir for o/p files>] [--o <outputpool>] [--force]

You can specify more then one execution pools. Execution will take place on the pools on which the executable exists. If the executable exists on more then one pool then the pool on which the executable will run is selected randomly.

The Output pool is the pool where you want all the output products to be transferred to. If not specified the materialized data stays on the execution pool

Page 16: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

18Ewa Deelman pegasus.isi.edu

Full Ahead Planning

At the time of submission of the workflow, decisions are made as to where to schedule the jobs in the workflow.

Allows to perform certain optimizations by looking ahead for bottleneck jobs and then scheduling around them.

However, for large workflows the decision made at

submission time may no longer be valid or optimum at the point the job is actually run.

Page 17: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

19Ewa Deelman pegasus.isi.edu

Deferred Planning

Delay the decision of mapping the job to the site as late as possible.

Involves partitioning of the original dax into smaller daxes each of which refers to a partition on which Pegasus is run.

A Mega DAG is constructed. It ends up running Pegasus automatically on the partition daxes, as each partition is ready to run.

Page 18: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

20Ewa Deelman pegasus.isi.edu

Deferred Planning through Partitioning

PW A

PW B

PW C

A Particular PartitioningNew Abstract

Workflow

A variety of planning algorithms can be implemented

Page 19: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

21Ewa Deelman pegasus.isi.edu

Mega DAG is created by Pegasus and then submitted to DAGMan

DAGMan(Su(A))

Pegasus(A) = Su(A)

Pegasus(X): Pegasus generated the concrete workflow and the submit

files for Partition X -- Su(X)

DAGMan(Su(X): DAGMan executes the concrete

workflow for X DAGMan(Su(B))

Pegasus(B) = Su(B)

DAGMan(Su(C))

Pegasus(C) = Su(C)

Page 20: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

22Ewa Deelman pegasus.isi.edu

Create workflow partitions– partitiondax --dax ./blackdiamond.dax --dir dax

Create the MegaDAG (creates the dagman submit files)– gencdag - Dvds.properties=~/conf/properties --pdax

./dax/blackdiamond.pdax --pools isi_condor --o isi_condor --dir ./dags/

Note the --pdax option instead of the normal --dax option.

submit the .dag file for the mega dag– condor_submit_dag black-diamond_0.dag

Page 21: Pegasus-a framework for planning for execution in grids Ewa Deelman deelman@isi.edu USC Information Sciences Institute

23Ewa Deelman pegasus.isi.edu

More info

www.griphyn.org/chimera pegasus.isi.edu