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