Agreement-based Distributed Resource Management
description
Transcript of Agreement-based Distributed Resource Management
Agreement-based Distributed Resource Management
Alain Andrieux
Karl Czajkowski
OIGS, Edinburgh WS-Agreement 2
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 3
Distributed Resource Management1. 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 4
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 5
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 6
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 7
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 8
Community Schedulers
Individual users Require service Have application goals
Community schedulers Broker service Aggregate scheduling
Individual resources Provide service to clients Have policy autonomy
J1 J2 J3 J4 J5
R2 R3 R4 R5 R6R1
S1 S2
J1?? J3 J4 J5J2
OIGS, Edinburgh WS-Agreement 9
Intermediaries And Policy
Resource virtualization can: Abstract details of underlying resource(s) Map between different resource description domains
Policies from different domains influence agreement negotiations with intermediaries
SchedulerCommunityClient
ApplicationResourceManager
Resource
User Policy Resource PolicyCommunity Policy
control
request
respond
request
respond
advertise advertise
OIGS, Edinburgh WS-Agreement 10
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 11
Specialization: File Transfer
Single goal Reliable deadline transfer
Specialized scheduler Brokers basic services Synthesizes new service
Fault-handling logic
Distributed resources Storage space Storage bandwidth Network bandwidth
R1 R3R2
J1
S1
J3J2
OIGS, Edinburgh WS-Agreement 12
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 13
WS-Agreement Components
Policy
Consumer 1 Application Service Provider 1
Appl. Service 1
(invoke)
Agreement Provider 1
(negotiate)
(monitor)
Initiator 1Agreement AgreementFactory
Agreement 1 Agreement 2
(binds)
OIGS, Edinburgh WS-Agreement 14
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 15
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 16
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 17
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 18
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 19
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? …