Agreement-based Distributed Resource Management

1. Agreement-based Distributed Resource Management Alain Andrieux Karl Czajkowski

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 WS-Agreement

3. 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 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 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 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 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 WS-Agreement

8. J1 J2 J3 J4 J5 S1 S2 ?? J1 J2 J3 J4 J5 R1 R2 R3 R4 R5 R6 Community Schedulers • Individual users • Require service • Have application goals • Community schedulers • Broker service • Aggregate scheduling • Individual resources • Provide service to clients • Have policy autonomy WS-Agreement

9. Intermediaries And Policy Client Community Resource Resource advertise advertise control Application Scheduler Manager request request respond respond User Policy Community Policy Resource 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 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 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 J1 S1 J2 J3 R1 R2 R3 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 WS-Agreement

13. AgreementFactory Agreement 1 Agreement 2 (binds) WS-Agreement Components 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 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” 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 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 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) 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? • … WS-Agreement