Agreement-based Distributed
Resource Management
Alain Andrieux
Karl Czajkowski
Overview
The Resource Management Problem
Decentralized resource coordination
Resource owner goals vs. application goals
An Open Architecture to Manage Resources
Agreement-based negotiation model
Several scenarios
WS-Agreement (GGF GRAAP-WG)
Status: work in progress
Agreements using OGSI concepts
OIGS, Edinburgh
WS-Agreement
2
Distributed Resource Management
1. Discovery
“What resources are relevant to interest?”
Finds service providers
2. Inspection
“What’s happening to them now?”
Compare/select service providers
3. Agreement
“Will they provide what I need?”
The core Resource Management problem
…Process can iterate due to adaptation
OIGS, Edinburgh
WS-Agreement
3
Social/Policy Conflicts
Resource Consumers/Applications Goals
Users: deadlines and availability goals
Applications: need coordinated resources
Localized Resource Owner Goals
Policies distinguish users
Community Goals Emerge As:
Global optimization goals
aggregate user/application and/or resource
Reconcile demands via Agreement
OIGS, Edinburgh
WS-Agreement
4
Early Co-Allocation in Grids
SF-Express (1997-8)
Real-time simulation
12+ supercomputers, 1400 processors
Required advance reservation
Brokered by telephone!
Practical use requires automation
Complex fault environment
Over 45 minutes to recover from failure
Reservations cannot prevent faults
OIGS, Edinburgh
WS-Agreement
5
Traditional Scheduling
Closed-System Model
Presumption of global owner/authority
Sandboxed applications with no interactions
“Toss job over the fence and wait”
Utilization as Primary Metric
Deep batch queues allow tighter packing
No incentives for matching user schedule
Sub-cultures Counter Site Policies
Users learn tricks for “gaming” their site
OIGS, Edinburgh
WS-Agreement
6
An Open Negotiation Model
Resources in a Global Context
Advertisement and negotiation
Normalized remote client interface
Resource maintains autonomy
Automated Agents Bridge Resources
Drive task submission and provisioning
Coordinate acts across domains
Community-based Mediation
Agents coordinating for collective interest
OIGS, Edinburgh
WS-Agreement
7
Community Schedulers
J1
J2
J3
S1
J4 J5
S2
??
J1
J2
J3
J4
J5
R1
R2
R3
R4
R5
R6
OIGS, Edinburgh
Individual users
Require service
Have application goals
Community schedulers
Broker service
Aggregate scheduling
Individual resources
Provide service to clients
Have policy autonomy
WS-Agreement
8
Intermediaries And Policy
Client
Application
User Policy
advertise Resource
request
request
respond
respond
Scheduler
Community Policy
Manager
control
Resource
Resource Policy
Resource virtualization can:
advertise Community
Abstract details of underlying resource(s)
Map between different resource description domains
Policies from different domains influence
agreement negotiations with intermediaries
OIGS, Edinburgh
WS-Agreement
9
Heterogeneity of Service
Many Kinds of Task
Data: stored file, data read/write
Compute: execution, suspended job
Many Kinds of Resource
Hardware: disks, CPU, memory, networks,
display…
Capabilities: space, throughput…
Coordination Problem is much the same
OIGS, Edinburgh
WS-Agreement
10
Specialization: File Transfer
J1
S1
J2
Single goal
J3
Reliable deadline transfer
Specialized scheduler
Brokers basic services
Synthesizes new service
R1
OIGS, Edinburgh
R2
R3
Fault-handling logic
Distributed resources
Storage space
Storage bandwidth
Network bandwidth
WS-Agreement
11
Technical Challenges
Complex Security Requirements
Global Scalability
Similar ideals to Internet
Interoperable infrastructure
Policy-configurable for social needs
Permanence or “Evolve in Place”
Cannot take World off-line for service
Over time: upgrade, extend, adapt
Accept heterogeneity
OIGS, Edinburgh
WS-Agreement
12
WS-Agreement Components
Agreement Provider 1
Agreement
Initiator 1
AgreementFactory
(negotiate)
(monitor)
Agreement 1
Appl. Service 1
Agreement 2
Policy
(invoke)
Consumer 1
OIGS, Edinburgh
Application Service Provider 1
WS-Agreement
13
WS-Agreement Model
Generic/extensible negotiation model
Agreement wraps domain-specific terms
Agreement supports extensible monitoring
Reuse OGSI mechanisms
Specializes ogsi:Factory pattern
Flexible lifetime negotiation for Agreements
ServiceData for monitoring/introspection
OIGS, Edinburgh
WS-Agreement
14
Negotiation Interfaces
AgreementFactory
Persistent service
Ex: façade to scheduler(s)
Creates Agreement services
Agreement
Transient service
Ex: job entry virtualized into a service
Encapsulates state of negotiation
Terms, service status, relationship to other Agreements
Lifetime maps to lifetime of “terms of service”
OIGS, Edinburgh
WS-Agreement
15
Two-level Negotiation
AgreementFactory::createService()
Coarse-grained
Conventional fault/response model
Batch negotiation of complex terms
Idiom: enables one-shot job submission
Agreement::renegotiate()
Fine-grained
Allows complex multi-message negotiation
Admits adaptation of provisioning terms
OIGS, Edinburgh
WS-Agreement
16
Agreement-based Jobs
Agreement represents “queue entry”
Commitment with job parameters etc.
Job structure
Wide range of QoS guarantees
Point for monitoring/control of job
Service is the Job computation
Agreement-specific computation
May or may not communicate with clients
Advance Reservation is “pre-agreement”
Facilitates future job negotiation
OIGS, Edinburgh
WS-Agreement
17
Agreement Terms
Real Agreements mix-in domain terms
Composed by logical grouping
Combined with negotiability mark-up
Each domain term brings a semantics
Unambiguous service-provisioning concept
Y=“amount of RAM allocable to process”
Agreement contextualizes domain term
(Y > 512 MB) AND (Y < 1024 MB)
OIGS, Edinburgh
WS-Agreement
18
The End
WS-Agreement is just beginning
GRAAP-WG at GGF
Work on core negotiation model
Work on reusable term meta-language
Domain Terms needed
Job submission
Data management
Accounting/Economic trading?
…
OIGS, Edinburgh
WS-Agreement
19