Centralized vs. Decentralized Design for Internet Applications
230 likes | 408 Vues
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 …)
Centralized vs. Decentralized Design for Internet Applications
E N D
Presentation Transcript
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 …) • 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
Internet-Connected Resources • Unreliable communication • Unreliable resources • Highly heterogeneous environment • Potentially very large number of resources • Potentially highly variable number of resources TWIST 2000
Centralized or Decentralized? • Applications • Middleware services TWIST 2000
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
Application Design: Decentralized! What about: • Distributed management control? • Fault tolerance in distributed, asynchronous systems? • Termination detection? • Communication costs? • Security? TWIST 2000
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
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
Decentralized B&B: Performance TWIST 2000
Decentralized B&B: Fault Tolerance TWIST 2000
Decentralized B&B: Fault Tolerance TWIST 2000
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
Centralized or Decentralized? • Applications • Middleware services TWIST 2000
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
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
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
Resource Discovery: Requirements • Efficient • Accurate • Secure • No global hierarchy • Politically difficult for wide area (impossible?) • Hierarchical structures are resistant to change TWIST 2000
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
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
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
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
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
Conclusions • Applications running on collections of Internet-connected resources: may be centralized or decentralized. • Middleware services must be decentralized. TWIST 2000