A Distributed Resource Management Architecture that Supports Advance Reservations and CoAllocation

1
A Distributed Resource Management Architecture
that Supports Advance Reservations and
Co-Allocation

• Presented by Alain Roy,
• University of Chicago
• With Ian Foster, Carl Kesselman,Craig Lee, Bob
  Lindell, and Klara Nahrstedt

2
Goals

• Provide end-to-end Quality of Service to
  applications. This requires
• Discovery and selection of resources
• Allocation of resources
• Advance reservation of resources

Workstation
Supercomputer
Router
Workstation
Router
3
Goals

• Provide end-to-end Quality of Service to
  applications. This requires
• Discovery and selection of resources
• Allocation of resources
• Advance reservation of resources

Workstation
Supercomputer
Router
Workstation
Router
4
Difficulties/Solutions

• Lack of support for advanced reservations
• We can use existing advanced reservation
  mechanisms if available or supply our own
• Heterogeneous resources
• We provide uniform interfaces
• Need to work with complex sets of resources
• We use co-reservation and co-allocation agents
• Resources in different administrative domains
• We use the Globus security infrastructure

5
Solution GARA Globus Architecture for
Reservation and Allocation

• Part of the Globus Toolkit (www.globus.org)
• Three important contributions
• Advance reservations and computational elements
  are first-class entities
• Uniform treatment of underlying resources
• Layered architecture enables generic
  co-reservation and co-allocation agents

6
Globus, In Brief

• A toolkit to help create distributed applications
  to run in wide-area environments
• Globus provides
• Security Mechanisms
• Communication Mechanisms
• Resource Management
• Information Services
• Globus is widely used in high-performance
  computing
• More information at www.globus.org
• GARA is one research project within Globus

7
GARA BasicsReservations

• There is a generic reservation, which has
  several properties
• Start Time (now or future) and Duration
• Resource type/Underlying resource identifier
• Resource-specific (bandwidth, CPU)
• All reservations are treated uniformly
• Create/Modify (Given properties)
• gt Returns Reservation Handle
• Destroy
• Monitor (Callbacks or Polling)

8
GARA BasicsObjects

• There is a generic object which can represent
• A Network Flow
• Processes/Jobs
• A File
• Something else (Memory)
• All objects are treated uniformly
• Create (Given reservation details)
• gt Returns Object Handle
• Destroy
• Monitor (Callbacks or Polling)

9
A picture of what happens(creating a reservation)
User Program or Agent
Create
Gatekeeper (Authenticate and Authorize)
Local Resource Manager (LRAM)
Reservation Handle
Resource
10
A picture of what happens(creating an object)
Create, given Reservation Handle
User Program or Agent
Gatekeeper (Authenticate and Authorize)
Local Resource Manager (LRAM)
Object Handle
Resource
11
Co-Reservation/Allocation Agents

• When multiple resources are needed, an agent
• Discovers applicable resources via info service
• Reserves resources
• Allocates objects on the resources
• The uniform interface enables these agents to be
  created easily.
• Given this ease, it is convenient to express
  different strategies such as
• Depth-first vs. best-first
• Coping with failures

12
The big picture
Co-Reservation Agent
Information Service
Gatekeeper
Gatekeeper
Gatekeeper
Gatekeeper
Scheduler LRAM
Diffserv LRAM
DSRT LRAM
GRIO LRAM
Workstation
Supercomputer
Router
Workstation
Router
13
ImplementationI

• We implemented a working prototype.
• Object Types
• Multiple processes on an SMP machine
• Single process with reserved CPU (DSRT)
• Network flows using RSVP
• Network flows using Differentiated Services
• A simple agent that reserves and allocates
  processes on two machines with one RSVP network
  flow between them.

14
Implementation IISlot Manager

• To track advanced reservations, we use a slot
  manager
• We assume exclusive access to resource through
  the slot manager

100
of available resource allocated
0
Time
15
Implementation IIIResults

• GARA has little overhead
• Time to make a reservation about 1ms (no auth.)
• Native time to create real-time process 6.8ms
• GARA time to create real-time process 17.63ms
  (no auth.)
• Extra overhead 11ms
• By far, the greatest cost is for
  authentication/authorization.
• Takes about 100-200ms
• It is important to authenticate, so it cant be
  completely removed
• Some of the cost can be alleviated by combining
  operations

16
Future Work

• Working with more resource types
• Differentiated services
• Supercomputer job schedulers
• Disk bandwidth (GRIO, from SGI)
• Building more sophisticated co-reservation agents
• Using RSVP with COPS to enforce advanced
  reservations
• Evaluation of differentiated services with
  realistic applications

17
Conclusions

• GARA provides a uniform mechanism for reserving
  and allocating heterogeneous resources
• GARA enables construction of generic
  co-reservation and co-allocation agents
• GARA leverages off of the Globus toolkit (e.g.
  security)
• GARA helps achieve end-to-end QoS across
  heterogeneous resources

18
Contact Information

• Alain Roy (alain_at_cs.uchicago.edu)
• Globus www.globus.org