1 / 22

Distributed Account Management Middleware

Distributed Account Management Middleware. Glenn Bresnahan (PI), Boston University Steve Quinn (CoPI), NCSA Aaron Fuegi, Boston University Chris Pond, NCSA Michael Shapiro, NCSA Ester Soriano, NCSA. Objective.

ailsa
Download Presentation

Distributed Account Management Middleware

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Account Management Middleware Glenn Bresnahan (PI), Boston University Steve Quinn (CoPI), NCSA Aaron Fuegi, Boston University Chris Pond, NCSA Michael Shapiro, NCSA Ester Soriano, NCSA

  2. Objective Provide mechanisms to allow for the automated management of resource allocations, resource access control, user information, user login accounts, and usage reporting in a grid environment spanning multiple administrative domains

  3. Background • Alliance partnership (PACI) • NCSA, Boston, Kentucky, New Mexico, Wisconsin, Maui • NSF PACI Allocation Peer Review (NRAC and AAB) • Manage accounts, allocations and reporting across Alliance resources

  4. Requirements • Compatible with current practices (e.g. PACI) • Independent of local account management system • Heterogeneous environment • Multiple administration domains • Economic model neutral

  5. Strategy • Provide grid services to exchange and manipulate shared accounting objects • Resource requests • Resources allocations • User information • Project/group information • Access permissions • Usage reports

  6. AMIE Data Representation • XML schema for Accounting Objects • Machines • Users • Accounts • Allocations • Usage

  7. AMIE Architecture • Transaction-based exchange mechanism • Transaction comprised of sequence of packets (messages) and acknowledgements • Sites send Requests and Notifications • Site A requests site B to perform an action • Site B notifies site A of actions taken • Independently or as the result of a request • Set of objects and states • Well defined state change sequences • Robust error detection and recovery • Asynchronous or real-time communication • No transport reliability assumptions • “Glue” modules to interface to site-specific accounting system

  8. Configuration: Star

  9. Configuration: Peer to Peer

  10. Current Implementations • Alliance Partner Sites (Version 1) • Alliance Grid Testbed (Version 1) • Teragrid (Version 2 – NMI) • NEES Grid (Version 2 – NMI) (implementation in progress)

  11. Transaction Example 1Account Creation

  12. Transaction Example 2Modify User Information

  13. Transaction Example 3Usage Reporting

  14. Transaction States Four possible states • On-hold - Waiting for another event. No further action should be taken until state changes. • In-progress – processing is underway • Completed – processing completed • Error – processing failed. More information is available via the packet state

  15. Transaction Packet States Incoming Packets • Construct – Message being assembled • Received – Complete and ready to be processed • Validate – Waiting for XML validation • Inbox – Waiting to be put into AMIE DB • Done – All processing sucessfully completed • Error – Awaiting error notification to be issued • Failed – Completed with failure

  16. Transaction Packet States Outgoing Packets • Construct – Message being assembled • Validate – Waiting for XML validation • Outbox – Waiting to be transmitted • Sent – Sucessfully sent to remote site • Wait – Waiting for a reply • Done – All processing sucessfully completed • Error – Awaiting error notification to be issued • Failed – Completed with failure

  17. AMIE Reference Implementation

  18. Current Status Items Complete • Core AMIE system • XML Schema • XML validation • Method call interface specification • Transport/processing engine • State tracking • Error handling • Testbed Implementation

  19. Current Status Reference Implementation • Reference implementation of AMIE method call interface • Relational "intermediate DB" schema (Oracle, Postgres, Sybase support) to interface AMIE to local AM system

  20. Current Status In Development • Reference implementation of Account Management system • fully functional AM DB Schema • method call implementation • glue between AM system and AMIE implementation • Should be "drop in" AM system with grid capability through AMIE

  21. Current Status Packaging • Core implementation • Reference implementation of method call interface • Reference AM implementation • Documentation

  22. Distributed Account Management Questions?

More Related