Agreement-based Distributed Resource Management Alain Andrieux Karl Czajkowski

OIGS, EdinburghWS-Agreement2 Overview l The Resource Management Problem u Decentralized resource coordination u Resource owner goals vs. application goals l An Open Architecture to Manage Resources u Agreement-based negotiation model u Several scenarios l WS-Agreement (GGF GRAAP-WG) u Status: work in progress u Agreements using OGSI concepts

OIGS, EdinburghWS-Agreement3 Distributed Resource Management 1. Discovery u “What resources are relevant to interest?” u Finds service providers 2. Inspection u “What’s happening to them now?” u Compare/select service providers 3. Agreement u “Will they provide what I need?” u The core Resource Management problem …Process can iterate due to adaptation

OIGS, EdinburghWS-Agreement4 Social/Policy Conflicts l Resource Consumers/Applications Goals u Users: deadlines and availability goals u Applications: need coordinated resources l Localized Resource Owner Goals u Policies distinguish users l Community Goals Emerge As: u Global optimization goals u aggregate user/application and/or resource l Reconcile demands via Agreement

OIGS, EdinburghWS-Agreement5 Early Co-Allocation in Grids l SF-Express (1997-8) u Real-time simulation u 12+ supercomputers, 1400 processors l Required advance reservation u Brokered by telephone! u Practical use requires automation l Complex fault environment u Over 45 minutes to recover from failure u Reservations cannot prevent faults

OIGS, EdinburghWS-Agreement6 Traditional Scheduling l Closed-System Model u Presumption of global owner/authority u Sandboxed applications with no interactions u “Toss job over the fence and wait” l Utilization as Primary Metric u Deep batch queues allow tighter packing u No incentives for matching user schedule l Sub-cultures Counter Site Policies u Users learn tricks for “gaming” their site

OIGS, EdinburghWS-Agreement7 An Open Negotiation Model l Resources in a Global Context u Advertisement and negotiation u Normalized remote client interface u Resource maintains autonomy l Automated Agents Bridge Resources u Drive task submission and provisioning u Coordinate acts across domains l Community-based Mediation u Agents coordinating for collective interest

OIGS, EdinburghWS-Agreement8 Community Schedulers l Individual users u Require service u Have application goals l Community schedulers u Broker service u Aggregate scheduling l Individual resources u Provide service to clients u Have policy autonomy J1J2J3J4J5 R2R3R4R5R6R1 S1S2 J1??J3J4J5J2

OIGS, EdinburghWS-Agreement9 Intermediaries And Policy l Resource virtualization can: u Abstract details of underlying resource(s) u Map between different resource description domains l Policies from different domains influence agreement negotiations with intermediaries Scheduler CommunityClient Application Resource Manager Resource User PolicyResource PolicyCommunity Policy control request respond request respond advertise

OIGS, EdinburghWS-Agreement10 Heterogeneity of Service l Many Kinds of Task u Data: stored file, data read/write u Compute: execution, suspended job l Many Kinds of Resource u Hardware: disks, CPU, memory, networks, display… u Capabilities: space, throughput… l Coordination Problem is much the same

OIGS, EdinburghWS-Agreement11 Specialization: File Transfer l Single goal u Reliable deadline transfer l Specialized scheduler u Brokers basic services u Synthesizes new service l Fault-handling logic l Distributed resources u Storage space u Storage bandwidth u Network bandwidth R1R3R2 J1 S1 J3J2

OIGS, EdinburghWS-Agreement12 Technical Challenges l Complex Security Requirements l Global Scalability u Similar ideals to Internet u Interoperable infrastructure u Policy-configurable for social needs l Permanence or “Evolve in Place” u Cannot take World off-line for service u Over time: upgrade, extend, adapt u Accept heterogeneity

OIGS, EdinburghWS-Agreement13 WS-Agreement Components AgreementFactory Agreement 1 Agreement 2 (binds)

OIGS, EdinburghWS-Agreement14 WS-Agreement Model l Generic/extensible negotiation model u Agreement wraps domain-specific terms u Agreement supports extensible monitoring l Reuse OGSI mechanisms u Specializes ogsi:Factory pattern u Flexible lifetime negotiation for Agreements u ServiceData for monitoring/introspection

OIGS, EdinburghWS-Agreement15 Negotiation Interfaces l AgreementFactory u Persistent service u Ex: façade to scheduler(s) u Creates Agreement services l Agreement u Transient service u Ex: job entry virtualized into a service u Encapsulates state of negotiation l Terms, service status, relationship to other Agreements u Lifetime maps to lifetime of “terms of service”

OIGS, EdinburghWS-Agreement16 Two-level Negotiation l AgreementFactory::createService() u Coarse-grained u Conventional fault/response model u Batch negotiation of complex terms u Idiom: enables one-shot job submission l Agreement::renegotiate() u Fine-grained u Allows complex multi-message negotiation u Admits adaptation of provisioning terms

OIGS, EdinburghWS-Agreement17 Agreement-based Jobs l Agreement represents “queue entry” u Commitment with job parameters etc. l Job structure l Wide range of QoS guarantees u Point for monitoring/control of job l Service is the Job computation u Agreement-specific computation u May or may not communicate with clients l Advance Reservation is “pre-agreement” u Facilitates future job negotiation

OIGS, EdinburghWS-Agreement18 Agreement Terms l Real Agreements mix-in domain terms u Composed by logical grouping u Combined with negotiability mark-up l Each domain term brings a semantics u Unambiguous service-provisioning concept u Y=“amount of RAM allocable to process” l Agreement contextualizes domain term u (Y > 512 MB) AND (Y < 1024 MB)

OIGS, EdinburghWS-Agreement19 The End l WS-Agreement is just beginning u GRAAP-WG at GGF u Work on core negotiation model u Work on reusable term meta-language l Domain Terms needed u Job submission u Data management u Accounting/Economic trading? u …