0% found this document useful (0 votes)
4 views40 pages

Chapter01 - Part 03

Uploaded by

socialdanish1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views40 pages

Chapter01 - Part 03

Uploaded by

socialdanish1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 40

Introduction Design goals

Techniques for scaling


Hide communication latencies
• Make use of asynchronous communication
• Have separate handler for incoming response
• Problem: not every application fits this model

Scalability
Introduction Design goals

Techniques for scaling


Facilitate solution by moving computations to client

Scalability
Introduction Design goals

Techniques for scaling


Partition data and computations across multiple machines
• Move computations to clients (Java applets and scripts)
• Decentralized naming services (DNS)
• Decentralized information systems (WWW)

Scalability
Introduction Design goals

Techniques for scaling


Replication and caching: Make copies of data available at different
machines
• Replicated file servers and databases
• Mirrored Websites
• Web caches (in browsers and proxies)
• File caching (at server and client)

Scalability
Introduction Design goals

Scaling: The problem with replication


Applying replication is easy, except for one thing

Scalability
Introduction Design goals

Scaling: The problem with replication


Applying replication 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.

Scalability
Introduction Design goals

Scaling: The problem with replication


Applying replication 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 general way requires global
synchronization on each modification.

Scalability
Introduction Design goals

Scaling: The problem with replication


Applying replication 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 general way requires global
synchronization on each modification.
• Global synchronization precludes large-scale solutions.

Scalability
Introduction Design goals

Scaling: The problem with replication


Applying replication 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 general way requires global
synchronization on each modification.
• Global synchronization precludes large-scale solutions.

Observation
If we can tolerate inconsistencies, we may reduce the need for global
synchronization, but tolerating inconsistencies is application dependent.

Scalability
Introduction A simple classification of distributed systems

Parallel computing
Observation
High-performance distributed computing started with parallel computing

Multiprocessor and multicore versus multicomputer

High-performance distributed computing


Introduction A simple classification of distributed systems

Distributed shared memory systems


Observation
Multiprocessors are relatively easy to program in comparison to
multicomputers, yet have problems when increasing the number of processors
(or cores). Solution: Try to implement a shared-memory model on top of a
multicomputer.

Example through virtual-memory techniques


Map all main-memory pages (from different processors) into one single virtual
address space. If a process at processor A addresses a page P located at
processor B, the OS at A traps and fetches P from B, just as it would if P had
been located on local disk.

Problem
Performance of distributed shared memory could never compete with that of
multiprocessors, and failed to meet the expectations of programmers. It has
been widely abandoned by now.

High-performance distributed computing


Introduction A simple classification of distributed systems

Cluster computing
Essentially a group of high-end systems connected through a LAN
• Homogeneous: same OS, near-identical hardware
• Single, or tightly coupled managing node(s)

High-performance distributed computing


Introduction A simple classification of distributed systems

Grid computing
The next step: plenty of nodes from everywhere
• Heterogeneous
• Dispersed across several organizations
• Can easily span a wide-area network

Note
To allow for collaborations, grids generally use virtual organizations. In
essence, this is a grouping of users (or better: their IDs) that allows for
authorization on resource allocation.

High-performance distributed computing


Introduction A simple classification of distributed systems

Architecture for grid computing


The layers
• Fabric: Provides interfaces to local
resources (for querying state and
capabilities, locking, etc.)
• Connectivity: Communication/transaction
protocols, e.g., for moving data between
resources. Also various authentication
protocols.
• Resource: Manages a single resource,
such as creating processes or reading
data.
• Collective: Handles access to multiple
resources: discovery, scheduling,
replication.
• Application: Contains actual grid
applications in a single organization.

High-performance distributed computing


Introduction A simple classification of distributed systems

Integrating applications
Situation
Organizations confronted with many networked applications, but achieving
interoperability was painful.

Basic approach
A networked application is one that runs on a server making its services
available to remote clients. Simple integration: clients combine requests for
(different) applications; send that off; collect responses, and present a
coherent result to the user.

Next step
Allow direct application-to-application communication, leading to Enterprise
Application Integration.

Distributed information systems


Introduction A simple classification of distributed systems

Example EAI: (nested) transactions


Transaction
Primitive Description
BEGIN TRANSACTION Mark the start of a transaction
END TRANSACTION Terminate the transaction and try to commit
ABORT TRANSACTION Kill the transaction and restore the old values
READ Read data from a file, a table, or otherwise
WRITE Write data to a file, a table, or otherwise

Issue: all-or-nothing
• Atomic: happens indivisibly (seemingly)
• Consistent: does not violate system invariants
• Isolated: not mutual interference
• Durable: commit means changes are permanent

Distributed information systems


Introduction A simple classification of distributed systems

TPM: Transaction Processing Monitor

Observation
Often, the data involved in a transaction is distributed across several servers. A
TP Monitor is responsible for coordinating the execution of a transaction.

Distributed information systems


Introduction A simple classification of distributed systems

Middleware and EAI

Middleware offers communication facilities for integration


Remote Procedure Call (RPC): Requests are sent through local procedure
call, packaged as message, processed, responded through message, and
result returned as return from call.
Message Oriented Middleware (MOM): Messages are sent to logical contact
point (published), and forwarded to subscribed applications.

Distributed information systems


Introduction A simple classification of distributed systems

How to integrate applications

File transfer: Technically simple, but not flexible:


• Figure out file format and layout
• Figure out file management
• Update propagation, and update notifications.
Shared database: Much more flexible, but still requires common data scheme
next to risk of bottleneck.
Remote procedure call: Effective when execution of a series of actions is
needed.
Messaging: RPCs require caller and callee to be up and running at the same
time. Messaging allows decoupling in time and space.

Distributed information systems


Introduction A simple classification of distributed systems

Distributed pervasive systems


Observation
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system, characterized by the fact that
the system naturally blends into the user’s environment.

Three (overlapping) subtypes

Pervasive systems
Introduction A simple classification of distributed systems

Distributed pervasive systems


Observation
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system, characterized by the fact that
the system naturally blends into the user’s environment.

Three (overlapping) subtypes


• Ubiquitous computing systems: pervasive and continuously present, i.e.,
there is a continuous interaction between system and user.

Pervasive systems
Introduction A simple classification of distributed systems

Distributed pervasive systems


Observation
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system, characterized by the fact that
the system naturally blends into the user’s environment.

Three (overlapping) subtypes


• Ubiquitous computing systems: pervasive and continuously present, i.e.,
there is a continuous interaction between system and user.
• Mobile computing systems: pervasive, but emphasis is on the fact that
devices are inherently mobile.

Pervasive systems
Introduction A simple classification of distributed systems

Distributed pervasive systems


Observation
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system, characterized by the fact that
the system naturally blends into the user’s environment.

Three (overlapping) subtypes


• Ubiquitous computing systems: pervasive and continuously present, i.e.,
there is a continuous interaction between system and user.
• Mobile computing systems: pervasive, but emphasis is on the fact that
devices are inherently mobile.
• Sensor (and actuator) networks: pervasive, with emphasis on the actual
(collaborative) sensing and actuation of the environment.

Pervasive systems
Introduction A simple classification of distributed systems

Ubiquitous systems
Core elements
1. (Distribution) Devices are networked, distributed, and accessible
transparently
2. (Interaction) Interaction between users and devices is highly unobtrusive
3. (Context awareness) The system is aware of a user’s context to optimize
interaction
4. (Autonomy) Devices operate autonomously without human intervention,
and are thus highly self-managed
5. (Intelligence) The system as a whole can handle a wide range of dynamic
actions and interactions

Pervasive systems
Introduction A simple classification of distributed systems

Mobile computing
Distinctive features
• A myriad of different mobile devices (smartphones, tablets, GPS devices,
remote controls, active badges).
• Mobile implies that a device’s location is expected to change over time
change of local services, reachability, etc. Keyword: discovery.
• Maintaining stable communication can introduce serious problems.
• For a long time, research has focused on directly sharing resources
between mobile devices. It never became popular and is by now
considered to be a fruitless path for research.

Pervasive systems
Introduction A simple classification of distributed systems

Mobile computing
Distinctive features
• A myriad of different mobile devices (smartphones, tablets, GPS devices,
remote controls, active badges).
• Mobile implies that a device’s location is expected to change over time
change of local services, reachability, etc. Keyword: discovery.
• Maintaining stable communication can introduce serious problems.
• For a long time, research has focused on directly sharing resources
between mobile devices. It never became popular and is by now
considered to be a fruitless path for research.

Bottomline
Mobile devices set up connections to stationary servers, essentially bringing
mobile computing in the position of clients of cloud-based services.

Pervasive systems
Introduction A simple classification of distributed systems

Mobile computing

Mobile cloud computing

Mobile edge computing

Pervasive systems
Introduction A simple classification of distributed systems

Sensor networks
Characteristics
The nodes to which sensors are attached are:
• Many (10s-1000s)
• Simple (small memory/compute/communication capacity)
• Often battery-powered (or even battery-less)

Pervasive systems
Introduction A simple classification of distributed systems

Sensor networks as distributed databases


Two extremes

Pervasive systems
Introduction A simple classification of distributed systems

The cloud-edge continuum

Pervasive systems
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) assumptions


Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) assumptions


• The network is reliable
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) assumptions


• The network is reliable
• The network is secure
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) assumptions


• The network is reliable
• The network is secure
• The network is homogeneous
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) assumptions


• The network is reliable
• The network is secure
• The network is homogeneous
• The topology does not change
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) assumptions


• The network is reliable
• The network is secure
• The network is homogeneous
• The topology does not change
• Latency is zero
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) assumptions


• The network is reliable
• The network is secure
• The network is homogeneous
• The topology does not change
• Latency is zero
• Bandwidth is infinite
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) 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
Introduction Pitfalls

Developing distributed systems: Pitfalls


Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) 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

You might also like