1 / 23

What is a Distributed System?

What is a Distributed System?. You know when you have one … … when the failure of a computer you’ve never heard of stops you from getting any work done ( L.Lamport, ‘84 ). What is a Distributed System?.

kelvin
Download Presentation

What is a Distributed System?

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. What is a Distributed System? • You know when you have one … … when the failure of a computer you’ve never heard of stops you from getting any work done (L.Lamport, ‘84) EECE 411: Design of Distributed Software Applications

  2. What is a Distributed System? A collection of independent computers that appears to its users as a single coherent system 1.1 • Independent hardware installations • Uniform software layer (middleware) EECE 411: Design of Distributed Software Applications

  3. Main goals of a distributed system • Connect users and resources • Distribution transparency • Openness • Scalability EECE 411: Design of Distributed Software Applications

  4. Goal II: Transparency Note: transparency may be set as a goal, but achieving it is a different story. EECE 411: Design of Distributed Software Applications

  5. Transparency – discussion Observation: Aiming at full transparency may be too much: • Full transparency will cost performance • Keeping Web caches exactly up-to-date with the master copy • Immediately flushing write operations to disk for fault tolerance • Completely hiding failures of networks and nodes may be impossible (depending on assumptions and/or requirements • You cannot distinguish a slow computer from a failing one • Sometimes full transparency is not desirable from an application perspective • Users may be located in different continents; distribution is apparent and not something you want to hide EECE 411: Design of Distributed Software Applications

  6. Goal III: Openness Openness ability to interact with or integrate services from other open systems, irrespective of the underlying environment: Achieving openness: Standard rules (protocols/interfaces) to describe services/components • Interface definitions should be: • Complete • Neutral • These help making system/services interoperable & portable At least make the distributed system independent from heterogeneityof the underlying environment: • Hardware • Platforms • Languages EECE 411: Design of Distributed Software Applications

  7. Separating policy and mechanism Managing complexity: split the systems in smaller components. • Components controlled by policies specified by applications and users • Example – web browser caching; • Mechanism: caching infrastructure • Policy: what to cache, how large the cache is, cache replacement algorithms Other examples: • What operations do we allow downloaded code to perform? • What level of secrecy do we require for communication? Achieving openness:Ideally, the (distributed) system provides only the mechanisms (and a way to specify policies) EECE 411: Design of Distributed Software Applications

  8. Middleware and Interoperability Interoperability provided by: • Protocols used by each middleware layer • Interfaces offered to applications • Independent hardware installations • Uniform software layer (middleware) EECE 411: Design of Distributed Software Applications

  9. Goal IV: Scalability Observation: Many developers easily use the adjective “scalable” without making clear whytheir system actually scales. • System should be able to grow over multiple axes: • size (#user, #resources), geographical distribution, maintainability EECE 411: Design of Distributed Software Applications

  10. Scaling Techniques (1) 1.4 Technique: Offload work to clients EECE 411: Design of Distributed Software Applications

  11. Scaling Techniques (2) Technique: Hide communication latency • Make use of asynchronous communication • Have separate handler for incoming response Problem: not every application fits this model EECE 411: Design of Distributed Software Applications

  12. Scaling Techniques (3) 1.5 Technique: Divide the problem space. • example: the way DNS divides the name space into zones. EECE 411: Design of Distributed Software Applications

  13. Scaling Techniques (4) Replication/caching: Make copies of data available at different machines: • Replicated file servers and databases • Mirrored Web sites • Web caches (in browsers and proxies) • File caching (at server and client) EECE 411: Design of Distributed Software Applications

  14. Scaling: The problem Applying scaling techniques is easy, except for one thing: • Having multiple copies (cached or replicated), leads to inconsistencies: modifying one copy makes that copy different from the rest. • Always keeping copies consistent (and in a generic way) requires global synchronizationon each modification. • This precludes large-scale solutions. EECE 411: Design of Distributed Software Applications

  15. Summary so far: (primary) goals of a distributed system • Connect users and resources • Distribution transparency • Openness • Scalability EECE 411: Design of Distributed Software Applications

  16. Developing distributed systems: Pitfalls Observation: Many distributed systems are needlessly complex • caused by mistakes that required patching later on. Many possible false assumptions: • The network is reliable • The network is secure • The network is homogeneous • The topology does not change • Latency is zero • Bandwidth is infinite • Transport cost is zero • There is one administrator EECE 411: Design of Distributed Software Applications

  17. Middleware 1-22 EECE 411: Design of Distributed Software Applications

  18. Architecture styles: Client/server Model: • Server: process implementing a certain service • Client: uses the service buy sending a request and waiting for the reply Main problem to deal with: unreliable communication Note: often both roles simultaneously for different services EECE 411: Design of Distributed Software Applications

  19. Architectural styles: Layered style EECE 411: Design of Distributed Software Applications

  20. Architectural styles: Layered style example • Layered style: three-layer (tier) architecture commonly used in many internet based applications today General organization of an Internet search engine into three different layers 1-28 EECE 411: Design of Distributed Software Applications

  21. Architectural styles: Object based Idea: Organize into logically differentcomponents, and subsequently distribute those components over the various machines. object-based style EECE 411: Design of Distributed Software Applications

  22. More architectural styles Alternatives:Decouple processes in space(“anonymous”) and/or time(“asynchronous”) Event-based Data-centered architectures EECE 411: Design of Distributed Software Applications

  23. Summary so far: • Definition of distributed systems • collection of independent components that appears to its users as a single coherent system • Goals, pitfalls, scalability techniques, architecture styles Requirement: Components need to communicate • Shared memory • Message exchange • need to agree on many things • Protocols: data formats, exception handling, naming, … EECE 411: Design of Distributed Software Applications

More Related