Distributed Systems

Principles and Paradigms

Maarten van Steen

VU Amsterdam, Dept. Computer Science

[email protected]

Chapter 02: Architectures

Version: September 3, 2012

1 / 29

Architectures Architectures

Architectures

Architectural styles
Software architectures
Architectures versus middleware
Self-management in distributed systems

2 / 29 2 / 29

Architectures 2.1 Architectural styles Architectures 2.1 Architectural styles

Architectural styles

Basic idea
Organize into logically different components, and distribute those
components over the various machines.

Layer N Object Object

Layer N-1
Object Method call
Request Response
flow flow

Object
Layer 2
Object

Layer 1

(a) (b)

(a) Layered style is used for client-server system

(b) Object-based style for distributed object systems.
3 / 29 3 / 29
 Architectures 2.1 Architectural styles Architectures 2.1 Architectural styles

Architectural Styles

Observation
Decoupling processes in space (“anonymous”) and also time
(“asynchronous”) has led to alternative styles.

Component Component
Component Component
Publish Subscribe Data
Subscribe Notification
delivery
delivery

Event bus

Publish

Component
Shared (persistent) data space

(a) (b)

(a) Publish/subscribe [decoupled in space]

(b) Shared dataspace [decoupled in space and time]

4 / 29 4 / 29

Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Centralized Architectures

Basic Client–Server Model

Characteristics:
There are processes offering services (servers)
There are processes that use services (clients)
Clients and servers can be on different machines
Clients follow request/reply model wrt to using services

Wait for result

Client

Request Reply

Server
Provide service Time

5 / 29 5 / 29

Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Application Layering

Traditional three-layered view

User-interface layer contains units for an application’s user
interface
Processing layer contains the functions of an application, i.e.
without specific data
Data layer contains the data that a client wants to manipulate
through the application components

Observation
This layering is found in many distributed information systems, using
traditional database technology and accompanying applications.

6 / 29 6 / 29
 Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Application Layering

User-interface
User interface level

HTML page
Keyword expression containing list
HTML
generator Processing
Query Ranked list level
generator of page titles
Ranking
Database queries algorithm

Web page titles

with meta-information
Database Data level
with Web pages

7 / 29 7 / 29

Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Multi-Tiered Architectures

Single-tiered: dumb terminal/mainframe configuration

Two-tiered: client/single server configuration
Three-tiered: each layer on separate machine
Traditional two-tiered configurations:
Client machine

User interface User interface User interface User interface User interface
Application Application Application
Database

User interface

Application Application Application

Database Database Database Database Database

Server machine

(a) (b) (c) (d) (e)

8 / 29 8 / 29

Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Decentralized Architectures

Observation
In the last couple of years we have been seeing a tremendous growth
in peer-to-peer systems.
Structured P2P: nodes are organized following a specific
distributed data structure
Unstructured P2P: nodes have randomly selected neighbors
Hybrid P2P: some nodes are appointed special functions in a
well-organized fashion

Note
In virtually all cases, we are dealing with overlay networks: data is
routed over connections setup between the nodes (cf. application-level
multicasting)

9 / 29 9 / 29
 Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Structured P2P Systems

Basic idea
Organize the nodes in a structured overlay network such as a logical
ring, or a hypercube, and make specific nodes responsible for services
based only on their ID.

0000 0001 1001

1000
0010 0011 1011
1010

0100
0101 1101
1100
0110 0111 1111
1110

Note
The system provides an operation LOOKUP(key) that will efficiently
route the lookup request to the associated node.
10 / 29 10 / 29

Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Unstructured P2P Systems

Essence
Many unstructured P2P systems are organized as a random overlay: two
nodes are linked with probability p.

Observation
We can no longer look up information deterministically, but will have to resort
to searching:

Flooding: node u sends a lookup query to all of its neighbors. A neighbor

responds, or forwards (floods) the request. There are many variations:
Limited flooding (maximal number of forwarding)
Probabilistic flooding (flood only with a certain probability).
Random walk: Randomly select a neighbor v . If v has the answer, it
replies, otherwise v randomly selects one of its neighbors. Variation:
parallel random walk. Works well with replicated data.

11 / 29 11 / 29

Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Superpeers
Observation
Sometimes it helps to select a few nodes to do specific work: superpeer.

Super peer
Overlay network of super peers

Weak peer

Examples
Peers maintaining an index (for search)
Peers monitoring the state of the network
Peers being able to setup connections
12 / 29 12 / 29
 Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Hybrid Architectures: Client-server combined with P2P

Example
Edge-server architectures, which are often used for Content Delivery
Networks

Client Content provider

ISP
ISP

Core Internet

Edge server
Enterprise network

13 / 29 13 / 29

Architectures 2.2 System Architectures Architectures 2.2 System Architectures

Hybrid Architectures: C/S with P2P – BitTorrent

Client node
K out of N nodes

Node 1
Lookup(F)

A BitTorrent .torrent file List of nodes Node 2

Web page Ref. to for F Ref. to storing F
file tracker
Web server server File server Tracker
Node N

Basic idea
Once a node has identified where to download a file from, it joins a
swarm of downloaders who in parallel get file chunks from the source,
but also distribute these chunks amongst each other.

14 / 29 14 / 29

Architectures 2.3 Architectures versus Middleware Architectures 2.3 Architectures versus Middleware

Architectures versus Middleware

Problem
In many cases, distributed systems/applications are developed
according to a specific architectural style. The chosen style may not be
optimal in all cases ⇒ need to (dynamically) adapt the behavior of the
middleware.

Interceptors
Intercept the usual flow of control when invoking a remote object.

15 / 29 15 / 29
 Architectures 2.3 Architectures versus Middleware Architectures 2.3 Architectures versus Middleware

Interceptors

Client application
Intercepted call
B.do_something(value)

Application stub

Request-level interceptor Nonintercepted call

invoke(B, &do_something, value)

Object middleware

Message-level interceptor

send([B, "do_something", value])

Local OS

To object B

16 / 29 16 / 29

Architectures 2.4 Self-management in Distributed Systems Architectures 2.4 Self-management in Distributed Systems

Self-managing Distributed Systems

Observation
Distinction between system and software architectures blurs when
automatic adaptivity needs to be taken into account:
Self-configuration
Self-managing
Self-healing
Self-optimizing
Self-*

Warning
There is a lot of hype going on in this field of autonomic computing.

17 / 29 17 / 29

Architectures 2.4 Self-management in Distributed Systems Architectures 2.4 Self-management in Distributed Systems

Feedback Control Model

Observation
In many cases, self-* systems are organized as a feedback control
system.

Uncontrollable parameters (disturbance / noise)

Initial configuration Corrections Observed output

Core of distributed system
+/- +/-
+/-
Reference input
Adjustment Metric
measures estimation

Analysis
Adjustment triggers Measured output

18 / 29 18 / 29
 Architectures 2.4 Self-management in Distributed Systems Architectures 2.4 Self-management in Distributed Systems

Example: Globule

Globule
Collaborative CDN that analyzes traces to decide where replicas of
Web content should be placed. Decisions are driven by a general cost
model:

cost = (w1 × m1 ) + (w2 × m2 ) + · · · + (wn × mn )

19 / 29 19 / 29

Architectures 2.4 Self-management in Distributed Systems Architectures 2.4 Self-management in Distributed Systems

Example: Globule

Client

Origin server
ISP
ISP

Core Internet

Replica server
Enterprise network

Client Client

Globule origin server collects traces and does what-if analysis by

checking what would have happened if page P would have been
placed at edge server S.
Many strategies are evaluated, and the best one is chosen.

20 / 29 20 / 29

Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

An experiment
Research question
Does it make sense to distribute each Web page according to its own
best strategy, instead of applying a single, overall distribution strategy
to all Web pages?
AS 1 AS 2 AS 3

Client Client Client Client Client Client Client Client Client

Edge Edge Edge

server server server

Client
Origin
Clients in an server
Client AS of document’s
unknown AS origin server

Client Client Client Client

21 / 29 21 / 29
 Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

An experiment

We collected traces on requests and updates for all Web pages

from two different servers (in Amsterdam and Erlangen)
For each request, we checked:
From which autonomous system it came
What the average delay was to that client
What the average bandwidth was to the client’s AS (randomly
taking 5 clients from that AS)
Pages that were requested less than 10 times were removed from
the experiment.
We replayed the trace file for many different system
configurations, and many different distribution scenarios.

22 / 29 22 / 29

Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

An experiment

Issue Site 1 Site 2

Start date 13/9/1999 20/3/2000
End date 18/12/1999 11/9/2000
Duration (days) 96 175
Number of documents 33,266 22,637
Number of requests 4,858,369 1,599,777
Number of updates 11,612 3338
Number of ASes 2567 1480

23 / 29 23 / 29

Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

Distinguished strategies: Caching

Abbr. Name Description

NR No replication No replication or caching takes place. All
clients forward their requests directly to the
origin server.
CV Verification Edge servers cache documents. At each
subsequent request, the origin server is
contacted for revalidation.
CLV Limited validity Edge servers cache documents. A cached
document has an associated expire time
before it becomes invalid and is removed from
the cache.
CDV Delayed Edge servers cache documents. A cached
verification document has an associated expire time after
which the origin server is contacted for
revalidation.

24 / 29 24 / 29
 Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

Distinguished strategies: Replication

Abbr. Name Description

SI Server Edge servers cache documents, but the origin
invalidation server invalidates cached copies when the
document is updated.
SUx Server updates The origin server maintains copies at the x
most relevant edge servers; x = 10, 25 or 50
SU50 + Hybrid SU50 & The origin server maintains copies at the 50
CLV CLV most relevant edge servers; the other
intermediate servers follow the CLV strategy.
SU50 + Hybrid SU50 & The origin server maintains copies at the 50
CDV CDV most relevant edge servers; the other edge
servers follow the CDV strategy.

25 / 29 25 / 29

Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

Trace results: One global strategy

Turnaround time (TaT) and bandwidth (BW) in relative measures; stale documents as fraction of
total requested documents.

Site 1 Site 2
Strategy TaT Stale docs BW TaT Stale docs BW
NR 203 0 118 183 0 115
CV 227 0 113 190 0 100
CLV 182 0.0061 113 142 0.0060 100
CDV 182 0.0059 113 142 0.0057 100
SI 182 0 113 141 0 100
SU10 128 0 100 160 0 114
SU25 114 0 123 132 0 119
SU50 102 0 165 114 0 132
SU50+CLV 100 0.0011 165 100 0.0019 125
SU50+CDV 100 0.0011 165 100 0.0017 125

Conclusion: No single global strategy is best

26 / 29 26 / 29

Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

Assigning an optimal strategy per document: Site 1

SU50+CDV SU50
Total consumed bandwidth

SU50+CLV SU25

SI
Ideal
arrangement
CLV
Cost function
arrangements CDV

Total turnaround time

27 / 29 27 / 29
 Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

Assigning an optimal strategy per document: Site 2

SU50+CLV
SU50
Total consumed bandwidth

SU50+CDV

CLV
SU25
SU10
CDV

SI
Cost function arrangements

Ideal arrangement

Total turnaround time

28 / 29 28 / 29

Architectures Extra: Strategy evaluation in Globule Architectures Extra: Strategy evaluation in Globule

Useful strategies

Fraction of documents to which a strategy is assigned.

Strategy Site 1 Site 2

NR 0.0973 0.0597
CV 0.0001 0.0000
CLV 0.0131 0.0029
CDV 0.0000 0.0000
SI 0.0089 0.0061
SU10 0.1321 0.6087
SU25 0.1615 0.1433
SU50 0.4620 0.1490
SU50+CLV 0.1232 0.0301
SU50+CDV 0.0017 0.0002

Conclusion: It makes sense to differentiate strategies

29 / 29 29 / 29