Title: Distributed Account Management Middleware
1Distributed 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
2Objective
- 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
3Background
- 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
4Requirements
- Compatible with current practices (e.g. PACI)
- Independent of local account management system
- Heterogeneous environment
- Multiple administration domains
- Economic model neutral
5Strategy
- Provide grid services to exchange and manipulate
shared accounting objects - Resource requests
- Resources allocations
- User information
- Project/group information
- Access permissions
- Usage reports
6AMIE Data Representation
- XML schema for Accounting Objects
- Machines
- Users
- Accounts
- Allocations
- Usage
7AMIE 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
8Configuration Star
9Configuration Peer to Peer
10Current Implementations
- Alliance Partner Sites (Version 1)
- Alliance Grid Testbed (Version 1)
- Teragrid (Version 2 NMI)
- NEES Grid (Version 2 NMI)
- (implementation in progress)
11Transaction Example 1Account Creation
12Transaction Example 2Modify User Information
13Transaction Example 3Usage Reporting
14Transaction 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
15Transaction 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
16Transaction 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
17AMIE Reference Implementation
18Current Status Items Complete
- Core AMIE system
- XML Schema
- XML validation
- Method call interface specification
- Transport/processing engine
- State tracking
- Error handling
- Testbed Implementation
19Current 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
20Current 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
21Current Status Packaging
- Core implementation
- Reference implementation of method call interface
- Reference AM implementation
- Documentation
22Distributed Account Management