1 / 22

Metacomputing Directory Service (MDS)

Metacomputing Directory Service (MDS). A Directory Service for Configuring High-Performance Distributed Computations (Fitzgerald et. al.) Joel Thomas. Overview. Introduction Design Considerations Current Approaches Design of MDS Implementation MDS With Globus Future Conclusion.

lamont
Download Presentation

Metacomputing Directory Service (MDS)

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. Metacomputing Directory Service (MDS) A Directory Service for Configuring High-Performance Distributed Computations (Fitzgerald et. al.) Joel Thomas

  2. Overview • Introduction • Design Considerations • Current Approaches • Design of MDS • Implementation • MDS With Globus • Future • Conclusion

  3. Introduction • High performance distributed computing requires selection, configuration • To make good decisions, timely, accurate information is invaluable • Currently, have nonstandard ways to store/access the right kind of data • The Metacomputing Directory Service (MDS) hopes to provide a scalable service to handle this need

  4. Design Considerations • Performance • Scalability and cost • Uniformity • Expressiveness • Extensibility

  5. Design Considerations(cont.) • Multiple Information Sources • Dynamic data • Flexible access • Security • Deployability • Decentralized maintenance

  6. Current Approaches • Uname, sysinfo • Simple Network Management Protocol(SNMP), NIS(Network Information Service) • PVM(Parallel Virtual Machine), MPICH (Message Passing Interface) • DNS (Domain Name Service) • X.500, LDAP (Lightweight Directory Access Protocol) • Chose to integrate existing systems as much as possible • But use LDAP to organize

  7. Design of MDS • Representation and Data Access • Data Model • Implementation

  8. Representation • Borrows straight from LDAP • Entry: instance of person, network, computer, etc. • Type is created by associating an object class • Directory Information Tree (DIT) • hierarchical, tree-structured name space • Distinguished Name (DN) • path from leaf to root entry • <hn = dark.mcs.anl.gov ou = MCS, o = Argonne National Laboratory, o = Globus, c = US >

  9. DIT example

  10. Object Classes • LDAP has set of standard class definitions, which can be extended (top, group classes, etc.) • Defines attributes for an entry, and what values those attributes may contain • Attributes may be required or optional • Can use inheritance to build new classes

  11. Data Model • Consists of DIT hierarchy and object class definitions • Computer centric, not network centric • People, hosts, communication networks under organization

  12. Data Model (cont.) • GlobusHost • GlobusNetwork • Link protocol (ATM, Ethernet) • Network topology (bus, ring) • Physical media (copper, fiber) • GlobusNetworkInterface • Physical characteristics (speed) and hardware address • Hosts contain network interfaces • Network interfaces attached to networks

  13. Configuration example

  14. MDS representation

  15. Data Model (cont.) • Physical vs. Logical Network info • Single network, multiple protocol stacks • Each may have distinct interface and performance • Images: multiple logical views of the same physical network (RFC 1609) • contains new information, and pointer back to physical • Physical has reference to all images that point to it • GlobusHostImage • GlobusNetworkImage • GlobustNetworkInterfaceImage

  16. Implementation • While LDAP interface met most needs, default implementation was somewhat slow • Problems: • Single information provider • Client/server architecture • Scope of Data • Allows info providers to provide information per attribute • Time to Live (TTL) for attribute (before refreshing) • Update scope: process, computation, global

  17. Sample queries • What are the network interfaces for ATM? • Find GlobusNetworkInterface->GlobusNetwork (link_protocol=ATM) • For that GNI, GlobusNetworkInterface->GlobusNetworkInterfaceImage (ip_address) • Which nodes can use vendor protocols on fast internal networks? • Two GlobusHostImages belong to the same GlobusNetworkImage object

  18. MDS Recap

  19. MDS with Globus • Nexus communication module • Uses MDS to find out what low-level mechanisms are between modules • Select between mechanism, based on rules • Rules based on dynamic information or programmer preference • Code runs unchanged, but can adapt to meet performance needs • I-WAY TestBed (heterogeneous virtual machines) • Resource Location • Resource Brokers

  20. Future • Use in GUSTO • Extend Globus components to use MDS • Expand information sources • Optimize for common operations • Sophisticated applications (e.g. resource scheduling) • Performance metrics

  21. Conclusion • Designed to provide dynamic information in a timely, scalable manner • Take advantage of LDAP flexibility and growing usage in industry • Provide information richness in extensible manner

More Related