1 / 23

Centralized vs. Decentralized Design for Internet Applications

Centralized vs. Decentralized Design for Internet Applications. I. Adriana Iamnitchi Department of Computer Science The University of Chicago. Internet Applications. Components that build the Internet itself (DNS …)

dutch
Download Presentation

Centralized vs. Decentralized Design for Internet Applications

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. Centralized vs. Decentralized Design for Internet Applications I Adriana Iamnitchi Department of Computer Science The University of Chicago

  2. Internet Applications • Components that build the Internet itself (DNS …) • Tools that connect the user to Internet resources (browsers, applets, CGIs, ...) • Services that can be accessed through Internet (e-commerce, e-banking, newspapers, e-libraries, …) • Applications that run on a collection of Internet-connected resources (SETI@home, …) • Tools that create new environments over the Internet (middleware services) TWIST 2000

  3. Internet-Connected Resources • Unreliable communication • Unreliable resources • Highly heterogeneous environment • Potentially very large number of resources • Potentially highly variable number of resources TWIST 2000

  4. Centralized or Decentralized? • Applications • Middleware services TWIST 2000

  5. Internet-Connected Resources • Unreliable communication • Unreliable resources • Fault-tolerance mechanisms • Highly heterogeneous environment • Asynchronous algorithms • Potentially very large number of resources • Potentially highly variable number of resources • Scalability TWIST 2000

  6. Application Design: Decentralized! What about: • Distributed management control? • Fault tolerance in distributed, asynchronous systems? • Termination detection? • Communication costs? • Security? TWIST 2000

  7. Experience with MetaNEOS • Solving very large optimization problems on metacomputing platforms • Branch-and-bound search algorithms: • Search for optimal solution • Successive decomposition of the original problem • Elimination of unpromising subproblems based on the best known solution TWIST 2000

  8. Fully decentralized B&B: Solution • Process management: group membership based on epidemic communication • Fault-tolerance: tree-based encoding of the problem space. • Report completed problems • Unsolved problems detected/restored based on completed problems • Price: redundant work • Termination detection: tree contraction • Dynamic load balancing TWIST 2000

  9. Decentralized B&B: Performance TWIST 2000

  10. Decentralized B&B: Fault Tolerance TWIST 2000

  11. Decentralized B&B: Fault Tolerance TWIST 2000

  12. Experience with MetaNEOS • Decentralized design is wonderful • Meantime, the centralized implementation produces results, because: • Centralized code already exists (master-worker) • Available resources: hundreds resources working simultaneously (Condor testbed) • Centralized code still efficient on relatively small collections of resources TWIST 2000

  13. Centralized or Decentralized? • Applications • Middleware services TWIST 2000

  14. Middleware Services for Computational Grids • Computational Grids: hardware and software infrastructure that provides access to computational capabilities. • Middleware services: responsible for application performance • Information Services • Service Location Services (Resource Discovery) • Resource Management • Security • Fault tolerance/detection TWIST 2000

  15. Information Service & Resource Discovery • Information Service • Resources (networks, computers, applications, …) • Users • Resource Discovery: “Give me n resources with attribute X” • Input: set of resource attributes • Output: set of resources • Attributes: hardware characteristics, current load, network connection, existent/available software, data, etc. TWIST 2000

  16. Resource Discovery: Requirements • Scalable • Increasing number of resources • Increasing number of users • Reliable • Flexible (heterogeneity support) • Heterogeneity: • Administrative level (policies) • Technical level (hardware and software) • Support for changing environment TWIST 2000

  17. Resource Discovery: Requirements • Efficient • Accurate • Secure • No global hierarchy • Politically difficult for wide area (impossible?) • Hierarchical structures are resistant to change TWIST 2000

  18. Globus • Toolkit that builds computational grids • Components: • Metacomputing Directory Service • Heartbeat Monitor • Grid Security Infrastructure • Globus Resource Allocation Manager • Global Access to Secondary Storage • Nexus • … TWIST 2000

  19. Globus’ MDS – Step 1 C=US, o=Globus, o=UC, ou=CS C=US, o=Globus, o=ANL, ou=MCS C=US, o=Globus, o=USC, ou=ISI TWIST 2000

  20. Globus’ MDS: Step 2 C=US, o=Globus, o=ANL, ou=MCS C=US, o=Globus, o=UC, ou=CS C=US, o=Globus, o=USC, ou=ISI TWIST 2000

  21. Index Server A2 Index Server A1 Globus’ MDS: Step 3 o=Grid, dc=mcs, dc=anl, dc=gov Organizational Server Organizational Server o=Grid, dc=isi, dc=edu o=Grid, dc=cs, dc=uchicago, dc=edu Organizational Server TWIST 2000

  22. Decentralized Information Service • More difficult than the centralized design: • Resource discovery based on attributes: • Rich set of queries to support • Compound queries • Static and dynamic data • Access policies • Necessary TWIST 2000

  23. Conclusions • Applications running on collections of Internet-connected resources: may be centralized or decentralized. • Middleware services must be decentralized. TWIST 2000

More Related