Resource Selection Services for a Single Job Execution Soonwook Hwang National Institute of Informatics/NAREGI OGSA F2F RSS Session Sunnyvale, CA, US Aug.

Slides:



Advertisements
Similar presentations
2 Introduction A central issue in supporting interoperability is achieving type compatibility. Type compatibility allows (a) entities developed by various.
Advertisements

IBM Software Group ® Design Thoughts for JDSL 2.0 Version 0.2.
© 2006 Open Grid Forum Joint Session on Information Modeling for Computing Resources (OGSA Modeling Activities) OGF 21 - Seattle, 16 October 2007.
© 2006 Open Grid Forum GGF18, 13th September 2006 OGSA Data Architecture Scenarios Dave Berry & Stephen Davey.
17 March 2008Standards for Interoperable Grids 1 Job Execution Standards for Interoperable Grids: Experience from NextGRID and OMII-Europe Clive Davenhall.
Directory and Trust Services (D&TS) Define an Abstract Model Purpose: Document a common terminology that the group can use between the various tracks Identify.
Visual Basic: An Object Oriented Approach 2 – Designing Software Systems.
Promoting and Standardizing Grid Computing OGSA - A View From The Trenches Andrew Grimshaw GGF Architecture Area Co-Director January, 2005.
A Grid Resource Broker Supporting Advance Reservations and Benchmark- Based Resource Selection Erik Elmroth and Johan Tordsson Reporter : S.Y.Chen.
Operating Systems (CSCI2413) Lecture 4 Process Scheduling phones off (please)
NextGRID & OGSA Data Architectures: Example Scenarios Stephen Davey, NeSC, UK ISSGC06 Summer School, Ischia, Italy 12 th July 2006.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
Long-term Archive Service Requirements draft-ietf-ltans-reqs-00.txt.
Resource Management Reading: “A Resource Management Architecture for Metacomputing Systems”
Makrand Siddhabhatti Tata Institute of Fundamental Research Mumbai 17 Aug
Track 1: Cluster and Grid Computing NBCR Summer Institute Session 2.2: Cluster and Grid Computing: Case studies Condor introduction August 9, 2006 Nadya.
Interoperability Scenario Producing summary versions of compound multimedia historical documents.
© 2007 Open Grid Forum OGF Modeling Activities DMTF Alliance Partner Symposium Portland, 2007 July 18 Ellen Stokes
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
Connecting OurGrid & GridSAM A Short Overview. Content Goals OurGrid: architecture overview OurGrid: short overview GridSAM: short overview GridSAM: example.
Workload Management WP Status and next steps Massimo Sgaravatto INFN Padova.
A scheduling component for e-Science Central Anirudh Agarwal Jacek Cała.
Architecting Web Services Unit – II – PART - III.
Frascati, October 9th, Accounting in DataGrid Initial Architecture Albert Werbrouck Frascati, October 9, 2001.
Grid Computing I CONDOR.
Grid Workload Management & Condor Massimo Sgaravatto INFN Padova.
© 2008 Open Grid Forum Independent Software Vendor (ISV) Remote Computing Primer Steven Newhouse.
A Novel Approach to Workflow Management in Grid Environments Frank Berretz*, Sascha Skorupa*, Volker Sander*, Adam Belloum** 15/04/2010 * FH Aachen - University.
DataGrid WP1 Massimo Sgaravatto INFN Padova. WP1 (Grid Workload Management) Objective of the first DataGrid workpackage is (according to the project "Technical.
Active Server Pages  In this chapter, you will learn:  How browsers and servers interacted on the Internet when the Internet first became popular 
Grid Workload Management Massimo Sgaravatto INFN Padova.
Issues in (Financial) High Performance Computing John Darlington Director Imperial College Internet Centre Fast Financial Algorithms and Computing 4th.
© 2006 Open Grid Forum Service Level Terms Andrew Grimshaw.
Object-Oriented Analysis and Design Fall 2009.
Superscheduling and Resource Brokering Sven Groot ( )
Virtual Batch Queues A Service Oriented View of “The Fabric” Rich Baker Brookhaven National Laboratory April 4, 2002.
A university for the world real R © 2009, Chapter 9 The Runtime Environment Michael Adams.
Conference name Company name INFSOM-RI Speaker name The ETICS Job management architecture EGEE ‘08 Istanbul, September 25 th 2008 Valerio Venturi.
Derek Wright Computer Sciences Department University of Wisconsin-Madison Condor and MPI Paradyn/Condor.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Page 1© Crown copyright 2004 FLUME Marco Christoforou, Rupert Ford, Steve Mullerworth, Graham Riley, Allyn Treshansky, et. al. 19 October 2007.
1 ENG224 INFORMATION TECHNOLOGY – Part I 1. Introduction to Computers.
Service Proforma Middleware Workshop. Notes Please complete as much of this proforma as possible – it will help make the workshop more informative & productive.
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB Markus.
INFSO-RI Enabling Grids for E-sciencE Policy management and fair share in gLite Andrea Guarise HPDC 2006 Paris June 19th, 2006.
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
Application Web Service Toolkit Allow users to quickly add new applications GGF5 Edinburgh Geoffrey Fox, Marlon Pierce, Ozgur Balsoy Indiana University.
1 Comments on OGSA platform document draft-2 03/06/2003 Andreas Savva, Ph.D. Hiro Kishimoto, Ph.D. Fujitsu GGF7 OGSA-WG.
Diagrams. Typically, we view the static parts of a system using one of the four following diagrams. 1. Class diagram 2. Object diagram 3. Component diagram.
OGSA-RSS Face-to-Face Meeting Sunnyvale, CA, US Aug 15-16, 2005.
© 2006 Open Grid Forum BES, HPC, JSDL and GLUE Profiling OGF 23, Barcelona, Tuesday 16 October 2007.
Sample Application Archive and its usage. Overall structure of Sample AA sampleAA.zip aad.xml cdl/ full-example-1.xml full-example-2.xml full-example-3-acs.xml.
NAREGI PSE with ACS S.Kawata 1, H.Usami 2, M.Yamada 3, Y.Miyahara 3, Y.Hayase 4 1 Utsunomiya University 2 National Institute of Informatics 3 FUJITSU Limited.
Leading the pervasive adoption of grid computing for research and industry © 2005 Global Grid Forum The information contained herein is subject to change.
OGSA HPC cluster usecase for reference Model v.02
OGSA EMS Session OGF19 OGSA-WG session #3 30 January, :30pm
Quick Architecture Overview INFN HTCondor Workshop Oct 2016
OGSA-WG EMS Architecture
OGSA Data Architecture Scenarios
GGF OGSA-WG, Data Use Cases Peter Kunszt Middleware Activity, Data Management Cluster EGEE is a project funded by the European.
Unified Modeling Language
Grid Scheduling Architecture – Research Group
Interaction between Scheduling Instances
OGSA Data Architecture Scenarios
Activity Delegation Kick Off
Basic Grid Projects – Condor (Part I)
OGSA-RSS-WG EPS Discussion.
Overview of Workflows: Why Use Them?
Chapter 17 - Component-based software engineering
Introduction to OGF Standards
Presentation transcript:

Resource Selection Services for a Single Job Execution Soonwook Hwang National Institute of Informatics/NAREGI OGSA F2F RSS Session Sunnyvale, CA, US Aug 15, 2005

Provisioning Deployment Configuration Information Services Service Container Data Container Accounting Services Execution Planning Services Candidate Set Generator (Work -Resource mapping) Job Manager Reservation RSS Services to be defined What are the services OGSA-RSS wants to define?

What are the OGSA-EMS Problems? According to the OGSA Architecture v1.0 documents –Finding execution candidate locations (CSG) What are the locations at which a job can execution? –Selecting execution location (EPS) Once where a job can execute is known, where should it actually run? –Preparing for execution (the focus of ACS and CDDLM-WG) Deployment and configuration of binaries and libraries, staging data –Initiating and managing the execution (the focus of BES- WG)

RSS Problems: Essential, but Challenging Defining the interfaces and protocols of the OGSA Resource Selection Services (RSS) is an integral part of the OGSA-EMS architecture, but seems to be very challenging –Interactions with many other OGSA EMS components Job Manger (JM), Information Service (IS), Service Container (SC), Reservation Service (RS), etc –Various job types Single, atomic job A set of jobs w/o dependency –e.g., embarrassingly-parallel applications A set of jobs w/ dependency –e.g., workflows

Let’s focus on a simple case to identify some interactions between RSS and other EMS Services Focusing on resource selection services for the execution of a single, atomic job –A single job that exactly fits into the JSDL v1.0 spec –Not considering complex jobs such as workflows and embarrassingly parallel applications JSDL v1.0 specification –Job identification requirements –Resource requirements –Data requirements

Resource Selection Scenarios 1.JM sends to EPS a JSDL document with a job ’ s resource requirements written in it 2.EPS hands off the JSDL document to CSG 3.CSG creates a candidate set of resources, returning it to EPS –CSG looks up the Information Service to find resources that match the job ’ s resource requirements 4.EPS selects the best one among the candidate resources –EPS perhaps uses some selection policy to select the best one 5.JM submit the JSDL document to the se

Interactions between RSS and other EMS Services EPS CSG Info Service Service Container Job Manager User submits job as abstract JSDL document along with selection policy CSG might interact with SC directly SC publishes information about resource attributes Concretized JSDL Concretized JSDL Candidate EPRs Candidate EPRs Concrete JSDL Concrete JSDL EPR to the SC EPR to the SC Abstract JSDL Abstract JSDL Selection Policy Selection Policy ① ② ③ ④ ⑤ ⑥ ⑦ Concrete JSDL Concrete JSDL Abstract JSDL Abstract JSDL

Abstract and Concrete JSDL Abstract JSDL –a JSDL document where some of elements necessary for initiating the execution of a job have yet to be filled E.g., a JSDL document with no hostname specified in it Concrete JSDL –a self-sufficient JSDL document for job execution

Job Manager (JM) Responsible for managing and controlling of jobs during their entire lifetime Submits jobs described in a JSDL document to a Service Container which the EPR returned from EPS points to –uses the protocol and interfaces defined in the OGSA BES specification

Information Service (IS) A placeholder to keep attributes metadata about resources Service Containers publish their resource attributes along with their own EPRs to IS –Static information Architecture, OS version, Hostname, etc –Dynamic information CPU load, Queue length, etc

Candidate Set Generator (CSG) Performs a simple, dumb matchmaking with the IS to identify a list of container services that have resource capabilities that meet the job ’ s resource requirements Concretizes the abstract input JSDL document using resource information retrieved from the IS –e.g., might fill in the “ CandidateHost ” element Passes EPRs to candidate hosts and the more concretized JSDL document back to EPS Discussion –Should CSG be dumb or intelligent? E.g., Should selection policy be reflected in CSG as well when CSG locating candidate resources?

Execution Planning Service (EPS) Select the best one among the candidate resources sent from CSG If needed (?), may want to interact with the IS to get additional resource information that could be used to more concretize the JSDL document returned from CSG Uses the selection policy which is given as input to select the best one Discussion –Is it a good idea to allow EPS to interact with IS as well? –What kinds of selection policies should be considered? –Where should selection policy be put, EPS, or CSG, or both?

Selection Policy Some user preference or priority to be allowed to put on each of resource requirements specified in the JSDL document – e.g., Condor ClassAD Some objective function –e.g., minimum execution time, lowest cost, reservation, etc Application-specific selection algorithm Discussion –Is working on the Condor ClassAD-like user preference mechanism within this OGSA-RSS-WG as an example of selection policy worth trouble to do?

Reservation Service (RS) Will probably reside on local resources, directly interacting with local schedulers (e.g., maui, PBSPro) to get and manage reservations on locally reservable resources Will probably provide a common interface –“ MakeReservation ” –“ CancelReservation ” Maybe some advanced service container could act as the RS by providing such a common reservation interface

Reservation as Selection Policy EPS CSG Info Service Service Container Job Manager User submits job as abstract JSDL document along with selection policy SC publishes information about resource attributes Concretized JSDL Concretized JSDL Candidate EPRs Candidate EPRs Abstract JSDL Abstract JSDL Selection Policy Selection Policy ① ② ③ ④ ⑤ ⑥ ⑦ RS Concrete JSDL Concrete JSDL EPR to the SC EPR to the SC (w/ Reservation) Make Reservation from 21:00 – 23:00 August 15, 2005 Concrete JSDL Concrete JSDL Abstract JSDL Abstract JSDL

EPS makes reservations EPS CSG Info Service Service Container Job Manager User submits job as abstract JSDL document along with selection policy SC publishes information about resource attributes Concretized JSDL Concretized JSDL Candidate EPRs Candidate EPRs Abstract JSDL Abstract JSDL Selection Policy Selection Policy ① ② ③ ④ ⑤ ⑥ ⑦ RS EPS makes reservation(s) Concrete JSDL Concrete JSDL EPR to the SC EPR to the SC (w/ Reservation) Make Reservation from 21:00 – 23:00 August 15, 2005 Concrete JSDL Concrete JSDL Abstract JSDL Abstract JSDL

CSG makes reservations EPS CSG Info Service Service Container Job Manager User submits job as abstract JSDL document along with selection policy Concretized JSDL Concretized JSDL Candidate EPRs Candidate EPRs Abstract JSDL Abstract JSDL Selection Policy Selection Policy ① ② ③ ④ ⑤ ⑥ ⑦ RS CSG makes reservations Concrete JSDL Concrete JSDL EPR to the SC EPR to the SC (w/ Reservation) Make Reservation from 21:00 – 23:00 August 15, 2005 Concrete JSDL Concrete JSDL Abstract JSDL Abstract JSDL Selection Policy Selection Policy EPS confirms reservation(s) Make Reservation from 21:00 – 23:00 August 15, 2005

Discussions on Reservation Service Which one should interact with the RS, EPS, or CSG, or perhaps JM? –How about some kind of a global RS that interacts with the local RS to make reservation on behalf of either ESP or CSG? How does the RS have an effect on the design of EPS and CSG?

Summery of Discussion Topics Should CSG perform a simple matchmaking or have some intelligence in locating available resources? Is it a good idea to allow EPS to interact with IS as well e.g., to have it concretize the input JSDL document? Is there any use case for this? What kinds of selection policy should be considered? Where should selection policy be put, only EPS, or CSG as well? Is working on the Condor ClassAD-like user preference mechanism as an example of selection policy worth trouble to do? Which one should interact with the local RS, EPS or CSG? Is it a good idea to regard Reservation as a selection policy? How about some global reservation service? Do we need it? How does it affect the interface design of EPS and CSG? In General, how the RS affect on the design of EPS and CSG? Any other important issues to discuss together?

Thank you

What is the Architecture EPS CSG Info Service Service Container Job ManagerReservation Service User submits job as JSDL document CSG gets potential atomic reservations from reservation service CSG retrieves service info (info model not important) Job Manager asks EPS where to run EPS asks CSG for candidate execution plans (concretized JSDL) EPS commits the reservation(s) to be used CSG might inspect service containers directly Service container publishes information about itself

JM makes reservations EPS CSG Info Service Service Container Job Manager User submits job as abstract JSDL document along with selection policy SC publishes information about resource attributes Abstract AbstractJSDL Concretized JSDL Concretized JSDL Candidate EPRs Candidate EPRs Concrete ConcreteJSDL Abstract JSDL Abstract JSDL Selection Policy Selection Policy ① ② ③ ④ ⑤ ⑦ RS JM makes reservations Concrete JSDL Concrete JSDL EPS to the SC EPS to the SC ⑥