7/4/2015

Basic Goals of Distributed Systems

We want distributed systems to have the following properties:

BASIC GOALS OF DISTRIBUTED SYSTEMS • Transparency

• Dependability
• Scalability
• Performance
ARIEL ROY L. REYES , MEP - ECE
• Flexibility

TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5

TRANSPARENCY FORMS OF TRANSPARENCY

Concealment of the separation of the components of a
Location transpareny
distributed system (single image view).
Access transparency

For a better exploitation of resources within a
Replication transparency
distributed, heterogeneous network a high degree of
Failure transparency
transparency is necessary.

Concurrency transparency

Without a doubt, transparency is seen as one of the key
enablers for and one of the key concepts of a successful
Migration transparency
distributed system implementation.
Language transparency

Other transparencies

TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5,
DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002
DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002

1
 7/4/2015

Location transpareny Access transparency

Problem: location of an object (resource or service) in a Problem: How to access objects in a distributed system.
distributed system.
Access transparency provides access to local and remote

Location transparency implies that the user need not objects in exactly the same way.
necessarily know the physical location of the object within
the network; the access is realized through a location-
independent name of the object.

Important aspect of location transparency:

Object name contains no information about the current
object location.

DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002 DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002

Replication transparency Failure transparency

For reasons of availability or fast access, resources, e.g. Problem: Partial failure in distributed systems, for
objects may be replicated. example computer crashes or network failures.
Problem: Management of several copies of an object in a
distributed system.

Up to a certain degree, failures are masked by the

Replication transparency means that the user is
unaware of whether an object is replicated or not. The system.
user accesses replicated objects as if they exist only
once.

A variety of protocols have been proposed that deal
with the problem of consistency among replicated files.

DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002 DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002

2
 7/4/2015

Concurrency transparency Migration transparency

The problem of synchronization of parallel and Problem: Object relocation in distributed systems.
concurrent accesses to shared resources increases when
Migration transparency provides a solution to the
the resources and the users accessing these resources are problem of relocation of objects in distributed
geographically dispersed.
systems.
Problem: shared access to objects in distributed systems.
Objects may migrate from one computer to another

Several users or application programs can access without influencing the correct behavior of running
objects simultaneously (for example shared data) applications.
without mutual influence.

DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002 DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002

Host migration transparency Types of migration

Problem: Computer migrates from one subnetwork to
"off-line" migration
another subnetwork, for example if a user connects his

"on-line" migration
laptop computer to different subnetworks. This requires
a dynamic generation of the IP address (for example
DHCP), a name server, etc.

The computer supports the same environment, the
same applications, and the same look-and-feel, no
matter where the mobile workers are currently
connected to the network.

DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002 DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002

3
 7/4/2015

Language transparency Other transparencies

Problem: An application's components are realized There are a number of other transparencies relevant for
distributed systems.
by different programming languages.
Execution transparency

Interactions between individual components is
Execution transparency implies that processes may be
processed on different runtime systems.
independent from the programming language used for
implementing the respective components.
Performance transparency

allows for dynamic reconfiguration of the system to improve
the overall system performance when changes in load
characteristics are detected.

Scalability transparency

supports extensions and enhancements of the system or
the applications without the need of modifications to the
system structure or changes to the application
algorithms.

DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002 DISTRIBUTED APPLICATIONS: JOHANN SCHLICHTER, INSTITUT FÜR INFORMATIK, TU MÜNCHEN, MUNICH, GERMANY, MARCH 2002

DEPENDABILITY SCALABILITY
Dependability of distributed systems is a double-edged A system is said to be scalable if it can handle the addition
sword: of users and resources without suffering a noticeable loss

Distributed systems promise higher availability: of performance or increase in administrative complexity
[B. Clifford Neuman]

Replication

But availability may degrade Scale has three dimensions:

More components ➼ more potential points of
Size: number of users and resources (problem:
failure overloading)

Geography: distance between users and resources

Dependability requires consistency, security, and fault
(problem: communication)
tolerance

Administration: number of organizations that exert
administrative control over parts of the system (problem:
administrative mess)
TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5 TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5

4
 7/4/2015

SCALABILITY SCALABILITY
Scaling Up or Out? Decentralization
Vertical Scaling: Scaling UP Increasing the resources of a Avoid centralizing:
single machine
Services (e.g., single server)
Horizontal Scaling: Scaling OUT Adding more machines
Data (e.g., central directories)

Algorithms (e.g., based on complete information).
Techniques for scaling:

Hiding communication latencies (asynchronous
communication, reduce communication)

Distribution (spreading data and control around)

Replication (making copies of data and processes)

Decentralisation
TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5 TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5

PERFORMANCE FLEXIBILITY

Any system should strive for maximum performance
Build a system out of (only) required components

In distributed systems, performance directly conflicts
Extensibility: Components/services can be changed or
with some other desirable properties added

Transparency
Openness of interfaces and specification

Security
allows reimplementation and extension

Dependability

Interoperability

Scalability

Separation of policy and mechanism

standardised internal interfaces

TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5 TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5

5
 7/4/2015

COMMON MISTAKES PRINCIPLES

False assumptions commonly made: Several key principles underlying the functioning of all
distributed systems
➀ Reliable network
➁ Zero latency ➜ System Architecture
➂ Infinite bandwidth ➜ Communication
➃ Secure network ➜ Partitioning, Replication and Consistency
➄ Topology does not change
➜ Synchronisation & Coordination
➅ One administrator
➆ Zero transport cost ➜ Naming
➇ Everything is homogeneous ➜ Fault Tolerance
➜ Security
TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5 TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5

PARADIGMS MISCELLANEOUS ’RULES OF THUMB’

Most distributed systems are built based on a particular
Trade-offs Many of the challenges provide conflicting
paradigm (or model) requirements. For example better scalability can cause worse
➜ Shared memory overall performance. Have to make trade-offs - what is more
➜ Distributed objects important?
➜ Distributed file system
Separation of Concerns Split a problem into individual
➜ Distributed coordination concerns and address each separately.
➜ Service Oriented Architecture and Web Services
End-to-End Argument Some communication functions can
only be reliably implemented at the application level.
➜ Distributed Database

Policy vs. Mechanism A system should build mechanisms
➜ Shared documents
that allow flexible application of policies. Avoid built-in
➜ Agents policies.

Keep It Simple, Stupid make things as simple as possible, but
no simpler.
TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5 TANENBAUM & VAN STEEN, DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS, 2E, (C) 2007 PRENTICE-HALL, INC. ALL RIGHTS RESERVED. 0-13-239227-5