Distributed Systems
Principles and Paradigms
Maarten van Steen
VU Amsterdam, Dept. Computer Science
Room R4.20, steen@cs.vu.nl
Chapter 01: Introduction
Version: October 25, 2009
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community
Ask the community for help and clear up your study doubts
University Rankings
Discover the best universities in your country according to Docsity users
Free resources
Our save-the-student-ebooks!
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Distributed Systems: Principles and Paradigms - Lecture Slides | ECE 374, Study notes of Computer Architecture and Organization
Ch. 1 Material Type: Notes; Class: Computer Organization and Architecture; Subject: Electrical and Computer Eng; University: North Dakota State University-Main Campus; Term: Fall 2015;
Typology: Study notes
2014/2015
1 / 53
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Distributed Systems: Principles and Paradigms - Lecture Slides | ECE 374 and more Study notes Computer Architecture and Organization in PDF only on Docsity!
Distributed Systems
Principles and Paradigms
Maarten van Steen
VU Amsterdam, Dept. Computer Science Room R4.20, steen@cs.vu.nl
Chapter 01: Introduction
Version: October 25, 2009
Contents
Chapter 01: Introduction 02: Architectures 03: Processes 04: Communication 05: Naming 06: Synchronization 07: Consistency & Replication 08: Fault Tolerance 09: Security 10: Distributed Object-Based Systems 11: Distributed File Systems 12: Distributed Web-Based Systems 13: Distributed Coordination-Based Systems
Goals of Distributed Systems
Making resources available
Distribution transparency
Openness
Scalability
Distribution Transparency
Transp. Description Access Hides differences in data representation and invocation mechanisms Location Hides where an object resides Migration Hides from an object the ability of a system to change that object’s location Relocation Hides from a client the ability of a system to change the location of an object to which the client is bound Replication Hides the fact that an object or its state may be replicated and that replicas reside at different locations Concurrency Hides the coordination of activities between objects to achieve consistency at a higher level Failure Hides failure and possible recovery of objects
Note Distribution transparency is a nice a goal, but achieving it is a different story.
Degree of Transparency
Observation Aiming at full distribution transparency may be too much: Users may be located in different continents Completely hiding failures of networks and nodes is (theoretically and practically) impossible
You cannot distinguish a slow computer from a failing one You can never be sure that a server actually performed an operation before a crash
Full transparency will cost performance, exposing distribution of the system
Keeping Web caches exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance
Degree of Transparency
Observation Aiming at full distribution transparency may be too much: Users may be located in different continents Completely hiding failures of networks and nodes is (theoretically and practically) impossible
You cannot distinguish a slow computer from a failing one You can never be sure that a server actually performed an operation before a crash
Full transparency will cost performance, exposing distribution of the system
Keeping Web caches exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance
Degree of Transparency
Observation Aiming at full distribution transparency may be too much: Users may be located in different continents Completely hiding failures of networks and nodes is (theoretically and practically) impossible
You cannot distinguish a slow computer from a failing one You can never be sure that a server actually performed an operation before a crash
Full transparency will cost performance, exposing distribution of the system
Keeping Web caches exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance
Openness of Distributed Systems
Open distributed system
Be able to interact with services from other open systems, irrespective
of the underlying environment:
Systems should conform to well-defined interfaces
Systems should support portability of applications
Systems should easily interoperate
Achieving openness
At least make the distributed system independent from heterogeneity
of the underlying environment:
Hardware
Platforms
Languages
Policies versus Mechanisms
Implementing openness Requires support for different policies: What level of consistency do we require for client-cached data? Which operations do we allow downloaded code to perform? Which QoS requirements do we adjust in the face of varying bandwidth? What level of secrecy do we require for communication?
Implementing openness Ideally, a distributed system provides only mechanisms: Allow (dynamic) setting of caching policies Support different levels of trust for mobile code Provide adjustable QoS parameters per data stream Offer different encryption algorithms
Policies versus Mechanisms
Implementing openness Requires support for different policies: What level of consistency do we require for client-cached data? Which operations do we allow downloaded code to perform? Which QoS requirements do we adjust in the face of varying bandwidth? What level of secrecy do we require for communication?
Implementing openness Ideally, a distributed system provides only mechanisms: Allow (dynamic) setting of caching policies Support different levels of trust for mobile code Provide adjustable QoS parameters per data stream Offer different encryption algorithms
Scale in Distributed Systems
Observation Many developers of modern distributed system easily use the adjective “scalable” without making clear why their system actually scales.
Scalability At least three components: Number of users and/or processes (size scalability) Maximum distance between nodes (geographical scalability) Number of administrative domains (administrative scalability)
Observation Most systems account only, to a certain extent, for size scalability. The (non)solution: powerful servers. Today, the challenge lies in geographical and administrative scalability.
Scale in Distributed Systems
Observation Many developers of modern distributed system easily use the adjective “scalable” without making clear why their system actually scales.
Scalability At least three components: Number of users and/or processes (size scalability) Maximum distance between nodes (geographical scalability) Number of administrative domains (administrative scalability)
Observation Most systems account only, to a certain extent, for size scalability. The (non)solution: powerful servers. Today, the challenge lies in geographical and administrative scalability.