Pawn:Pawn Scheduling

This described how reservations are scheduled and allocated in PAWN. The other configuration functionality of the PAWN scheduler is described elsewhere.

Overview

PAWN uses the Condor classad system for matching storage pools with reservation requests. All requests and storage pools are represented as classads during matchmaking and allocation.

When a client requests a reservation, PAWN will create a classad describing the clients requirements. These requirements not only include size limits, but may also have limitations regarding what receiving servers are able to handle necessary backend resources. These requirements are merely additions to the client's classad requirements section. Receiving servers may also place limits on which clients it will accept. In the initial version, only request size is considered.

Similiar to condor resources, storage pool updates are regularily sent from receiving servers to the scheduler indicating current availability of a resource. Any storage pool that is not updated will eventually timeout and be removed from consideration. Registered resoruces are not persistant and will automatically re-register themselves after scheduler restarts. This also means that resources may not be immediately available after a scheduler restart.

It should also be noted that even though a storage pool is registered on a given receiving server, it may not show up in the list of avialable resources for some reasons. For example, if the pool is full, cannot be initialized, or the receiving server is down are all reasons a pool may not be active.

Workflow

Below is a high level overview of how scheduling works in PAWN.

1. Receiving Server updates - Every XX minutes a client will call updatePoolClassAd on the scheduler to inform the scheduler of the current pool status.
2. A client then requests a reservation via requestReservation, or retrieveReservation. The scheduler creates a classad describing the request and calls the matchmaker (in <nop>SchedulerContext) to locate a resource.
3. If the matchmaker is able to allocate a resource, the appropriate receiving server is contacted and an attempt is made to place the reservation. The client has information regarding hte reservation location returned if a match is made, otherwise the client is notified of failure.
4. If a reservation cannot be placed on the storage pool, the resource is removed from the matchmaker and an attempt is made to re-match the client (Step 2)

Classes / Components

Scheduler

MatchMaker

Created and stored in the <nop>SchedulerContext during scheduler startup. It's available by calling <nop>SchedulerContext.getMatchMaker();

PawnResource

resource created and registered in the matchmaker by calls from the receiving server to updatePoolClassAd

PawnSubmission

reservation requests created by client calls. It contains necessary information for contacting receiving servers.

Receiver

UpdateThread

Class / thread that runs every X minutes and updates the scheduler with currently available resources.

Related Webservice Calls

Scheduler

requestReservation

request a new reservation from a client.

updatePoolClassAd

udpate the classad for a particular resource / storage pool.

Receiver

createReservation

called from scheduler to allocate create a reservation on a receiver.