1 / 15

Resource Allocation using Java RMI

Resource Allocation using Java RMI. Amrish Kaushik Minal Malde CS599-Grid Computing Project Report USC Computer Science. Resource Allocator. Client. Remote Server. Information Service. Answer. Architecture (1). Architecture (2). Information Service runs on well-known host and port.

chanel
Download Presentation

Resource Allocation using Java RMI

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. Resource Allocation using Java RMI Amrish Kaushik Minal Malde CS599-Grid Computing Project Report USC Computer Science

  2. Resource Allocator Client Remote Server Information Service Answer Architecture (1)

  3. Architecture (2) • Information Service runs on well-known host and port. • Resource Allocator and Remote Server(s) (can be multiple – implemented 24 virtual server) run on ports known to the Information Service (via registration) • Client queries Information Service to locate Resource Allocator. Client DOESN’T know location of Remote Services.

  4. Architecture (3) • All components written in Java RMI. • Server Components: • Resource Allocator • Information Service • Remote Service (multi-threaded) • Client Components: • Client • Resource Allocator • Remote Service (multi-threaded)

  5. Architecture (4) • Why Java RMI • Similar to Remote Procedural Call • Simplicity of coding/programming • Don’t need to use socket programming, handled by the RMI runtime • Short development time.

  6. Information Service (1) • Currently using CPU Utilization • Design is extensible to multiple parameters or combinations thereof. • Currently the client explicitly calls a procedure (The procedure is well known) • Thought about developing a procedure wrapper that the Resource Allocator can forward to the remote server.

  7. Information Service (2) • Implements a write-through cache design • Fixed size array stores the entries with the least timestamp. • Optimized for ‘stock queries’ on an LDAP server • E.g. Server with least LoadAvg, Minimum users etc.

  8. Information Service (3) • Security • If Information Service is built using LDAP, single sign-on can be implement • Need to store digital certificates on the LDAP server.

  9. Remote Server (1) • Sends statistical updates to the information server • HBM – update messages could be piggy-backed onto the heart-beat messages or vice versa • The delivery is not guaranteed

  10. Remote Server (2) • Currently updates use blocking protocol • Ideally implemented using a non-blocking connection-less protocol like UDP. • Storing clique information (may want to submit jobs to a clique – not to a single server or collection thereof)

  11. Remote Server (3) • Extrapolation of data for network weather service.. • Need representative information • Can be extrapolated using standard forecasting methods • May not always generate valid information.

  12. Resource Allocation (1) • Done on the basis of USER parameter • Uses dynamically generated data in the information server • Computations are explicit • Needs to know which function to call • Needs to know that function has been implemented • Can use a function wrapper such that the RA doesn’t require to know the function implementations.

  13. Resource Allocation (2) • Computations can only be submitted to one remote server • Packing and transportation of data required. • Resource Allocation is fundamentally the same as in Matchmaking • Client asks for resource by parameter • Resource advertises/publishes parameter information • Resource Allocator scans the two and provides a match

  14. Possibilities • Use GLOBUS GSSAPI for security • Use GLOBUS GRIS for implementing the information service • RA doesn’t have a direct parallel in the GLOBUS environment • GLOBUS RSL parsing instead of Client’s explicit (blocking) calls.

  15. Conclusion • Key points • Use of stock queries for improving performance of Information Service • Dynamic Allocation of Resources allows simplification of RSL instructions (RA/IS is more complex, Client less so..) • Short Demo

More Related