Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

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

Uploaded on 09/08/2015

mtruhland
mtruhland 🇺🇸

5

(1)

1 document

1 / 53

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
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
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35

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.

Techniques for Scaling

Distribution

Partition data and computations across multiple machines:

Move computations to clients (Java applets)

Decentralized naming services (DNS)

Decentralized information systems (WWW)

Techniques for Scaling

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)