agreement-based distributed resource management alain andrieux karl czajkowski

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


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


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


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


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


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


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


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


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


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


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


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)


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


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”


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


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


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)


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? …

agreement-based distributed resource management alain andrieux karl czajkowski

Documents

agreement u

negotiation u

clients u

u realtime simulation

discovery u

individual resources

individual users u

tighter packing u