DISTRIBUTED SYSTEMS

Lecture 2 – System architectures

Pan Hui
[email protected]

Huber Flores
[email protected]

Helsinki, Finland, 2018.

 2

Recap
• Fundamentals of distributed systems
– Concepts
– Models

Helsinki, Finland, 2018.

 3

ARCHITECTURES

Helsinki, Finland, 2018.

 4

Agenda
• Understanding different architecture
styles
• Mapping a system to a model
– State machine (Automaton)

Helsinki, Finland, 2018.

 5

Architecture
• Define the organization of a distributed system
– Interaction
– Behavior
• Software architecture
– Logical organization and interaction of software
components
• System architecture
– Instantiation of a software architecture on real
machines

Helsinki, Finland, 2018.

 6

Architecture styles
• The notion of an architectural style
– Formulated in terms of components, their connections and
the data exchanged between them
– A component is a modular unit with well-defined required
and provided interfaces, replaceable within its environment
– A connector is a mechanism mediating communication,
collaboration, coordination or cooperation among
components

• Important architectural styles for distributed systems

– Layered architectures
– Object-based architectures
– Data-centered architectures
– Event-based architectures
Helsinki, Finland, 2018.
 7

Layered architectures
• Component at layer Li is
allowed to call component
at the underlying layer Li-1
but not the other way around

• Control generally flows

from layer to layer
– Requests go down
– Results flow upward

• Widely adopted in
networking

Helsinki, Finland, 2018.

 8

Layered architectures
• Layered networking architectures
Hybrid Internet protocol stack

• Layering allows mastering the complexity

– Explicit structure allows identification, relationship of
complex system’s pieces
– Modularization eases maintenance, updating of system
• Change of implementation of a layer’s service transparent to the
rest of system Helsinki, Finland, 2018.
 9

Object-based architectures
• Objects correspond to
components

• Components are
connected via a
(remote) procedure
call mechanism
– RMI, RPC
– Web services
• REST, SOA

Helsinki, Finland, 2018.

 10

Resource-centered architectures
• Processes communicate through a common (passive
or active) resource, e.g., repository
• Examples
– Distributed file systems
– Web-based data services

Helsinki, Finland, 2018.

 11

Event-based architectures
• Processes communicate through propagation of events
• Events can optionally carry data
• Publish/subscribe systems
– Processes publish events
– Only processes having subscribed to particular events will
receive them
• Allows loose coupling
of processes
– Processes need not
explicitly refer to
each other
(referential decoupling)

Helsinki, Finland, 2018.

 12

Shared data spaces

• Event-based architecture
combined with data-
centered architecture

• Processes are also decoupled

in time (they need not both
be active when
communication takes place)

• Data can be accessed also

using a description instead of
explicit reference
Helsinki, Finland, 2018.
 13

System architectures
• Centralized architectures

• Decentralized architectures

Helsinki, Finland, 2018.

 14

Comparison (Junginger & Lee, 2004)

Feature Peer-to-peer Centralized
Scalability High Limited
Resource availability High Limited
Fault tolerance High Limited
Infrastructure Self-organizing Needs setup and
administration
Infrastructure costs Low High
Storage of global data No Yes
Control No Yes
Trusted No Yes
Enterprise/legacy No Yes
system integration

Helsinki, Finland, 2018.

 15

System architectures
• Hybrid architectures
– Centralized and decentralized

Helsinki, Finland, 2018.

 16

Centralized architectures
• Client-server model
– Server (process) implements a specific service
– Client (process) request a service from a server by sending a request
and waiting for a reply
• Request-reply behavior
• Call semantics and transmission
failures
– Ideally: exactly-once
– Zero-or-more (“maybe”): service may or may have not been called
– At-least-once: keep requesting service until valid response arrives at
client
– At-most-once: no reply may mean that no execution took place
– Idempotent vs non-idempotent operations
Idempotent (repeatable) operation can be repeated multiple
times without harm
Helsinki, Finland, 2018.
 17

Application layering

The general organization of an Internet search engine

Helsinki, Finland, 2018.
 18

Application layering
• User-interface level
– Typically implemented by the client
– Consists of programs that allow end users to interact with applications
– Great variation in functionality provided by user interfaces

• Processing level
– Contains core functionality of an application

• Data level
– Contains programs that maintain the data on which the applications
operate
– Persistency
– Consistency

Helsinki, Finland, 2018.

 19

Multitiered architecture
• Simplest organization is to have only two types of machines
– A client machine containing only the programs implementing
(part of) the user-interface level
– A server machine containing the rest (programs implementing
the processing and data level)
Alternative two-tiered client-server organizations Fat clients ((d)-(e)) vs thin clients ((a)-(c))

Helsinki, Finland, 2018.

 20

Multitiered architecture
• Three-tiered architecture
– Single server is replaced by multiple servers running on
distributed machines
– Server sometimes acts as a client

• Vertical distribution
– Logically different components are placed on different machines
Helsinki, Finland, 2018.
 21

Decentralized architectures
• Peer-to-peer systems
– Horizontal distribution (in contrast to vertical distribution)
– Processes are equal (functions need to be carried out are
represented by every process)
– Interaction between processes is symmetric (each process acts
as a client and a server at the same time ~ servent)

• Representation of peer-to-peer architectures using overlay

networks
– Nodes represent processes
– Links represent communication channels

• Structured vs unstructured peer-to-peer architectures

Helsinki, Finland, 2018.

 22

Structured peer-to-peer architectures

• Overlay network is constructed using a deterministic
procedure

• DHT (Distributed Hash Table) is the most-used procedure

– Data items are assigned a random key from a large identifier
space
– Nodes are assigned a random number from the same space
– Efficient and deterministic scheme uniquely mapping the key of
a data item to the identifier of a node using some distance
metric
– When looking up a data item, the network address of the node
responsible for that data item is returned
– Many DHT variations (e.g. Chord, CAN, Pastry, Bamboo,
Tapestry, Kademlia)

Helsinki, Finland, 2018.

 23

Structured peer-to-peer architectures

• Chord system
– Nodes are logically organized in a ring such that a data item with
key k is mapped to the node with the smallest identifier id  k
– This node is called successor of key k, succ(k)
– LOOKUP(k) returns address of succ(k)

• Membership management
– Each node maintains shortcuts
to other nodes
– Joining: create random node id,
data items associated with id are
transferred from succ(id)
– Leaving: node id transfers its data
items to succ(id)

Helsinki, Finland, 2018.

 24

Structured peer-to-peer architectures

• CAN (Content Addressable Network)
– d-dimensional Cartesian coordinate space is completely
partitioned among nodes
– Each data item is assigned a unique point in this space
(corresponding node is responsible for the data item)

Mapping Splitting a
of data region when
items onto a node joins
nodes

Helsinki, Finland, 2018.

 25

Structured peer-to-peer architectures

• DHT comparison (Hautakorpi & Camarillo 2007)

Helsinki, Finland, 2018.

 26
Unstructured peer-to-peer
architectures
• Overlay network is constructed using randomized
algorithms, resulting in a random graph
– Each node maintains a list of neighbors (partial view),
which is constructed in random way
– Data items are placed randomly on nodes

Helsinki, Finland, 2018.

 27
Topology management of overlay
networks
• It is possible to construct and
maintain specific topologies of
overlay networks
• A two-layered approach for
constructing and maintaining
specific overlay topologies using
techniques from unstructured
peer-to-peer systems
– Lower layer maintains an
accurate random graph and
passes randomly selected
nodes to upper layer
– Upper layer creates a desired
topology from provided nodes
using a ranking function

Helsinki, Finland, 2018.

 28
Topology management of overlay
networks
• Example: Generating a specific overlay network using a two-layered
unstructured peer-to-peer system
– Logical grid of size NxN, nodes placed on each point of grid
– Every node maintains a list of c nearest neighbors
– Distance between nodes (a1,a2) and (b1,b2) is defined as d1+d2, where
di=min(N-|ai-bi|,|ai-bi|)
– Using the protocol in slide 02-20 topology evolves into a torus

Different ranking
functions can be used
Semantic
proximity 
semantic overlay
networks

Helsinki, Finland, 2018.

 29

Superpeers
• Scalability problems with flat peer-to-peer structures
• Superpeer ~ special node maintaining an index of data
items or acting as a broker
– Long-lived processes with
high availability
• Hierarchical organization of
nodes into superpeer network
– Superpeers are often organized in
a peer-to-peer network
– Regular peer is connected as a client
to a superpeer (fixed relationship)
• Flexible means for nodes to join and leave the network
• Leader-election problem: how to select the nodes eligible
to become superpeers?
Helsinki, Finland, 2018.
 30

Hybrid architectures
• Client-server solutions are combined with decentralized
architectures
• Edge-server systems
– Clients connect to Internet via edge servers
– Motivation: reduced response times, load balancing, scalability
– E.g. web proxy (content-blind vs content-aware cache),
CDN (content distribution network) server

Helsinki, Finland, 2018.

 31

Hybrid architectures
• Collaborative distributed systems (e.g., BitTorrent)
– File is divided into chunks stored in different nodes
– Global directory holds reference to .torrent metadata file
– Tracker keeps track of nodes having chunks of the file

Helsinki, Finland, 2018.

 32

Architectures versus middleware

• Tradeoff between
The distribution transparency provided by a middleware following a
particular architectural style
– Should simplify designing applications
and
Application requirements
– Middleware may no longer adapt for given application

 Mechanisms for modifying the behavior of middleware wrt.

application requirements
– Interceptors
– Adaptive software

Helsinki, Finland, 2018.

 33

Interceptors
• Break the normal flow of control and allow other (application
specific) code to be executed

• Request-level
interceptor
– E.g. make call for
each replica of
object B

• Message-level
interceptor
– E.g. assist in
transferring
invocation to
target object

Helsinki, Finland, 2018.

 34

SYSTEM MODELLING

Helsinki, Finland, 2018.

 35

Models
• Components of a system are processes
– Finite state machine
• Each process is depicted by a state

Helsinki, Finland, 2018.

 36

State machine (Automaton)

Helsinki, Finland, 2018.

 37

Actions on the automaton

• As the automaton changes state it can
generate actions

Helsinki, Finland, 2018.

 38

Extended state machines

• Automaton can be extended with variables

Helsinki, Finland, 2018.

 39

Extended state machines

• States
• Events
– Call event
– Signal event
– Change event
– Time event
• Transitions and guard conditions
• Transitions effects
Helsinki, Finland, 2018.
 40

Your tasks
• For next lecture session:
– Read Chapter 3 Processes (From Van Steen)
– Code migration
• Flores, Huber, Pan Hui, Sasu Tarkoma, Yong Li, Satish Srirama, and Rajkumar Buyya.
"Mobile code offloading: from concept to practice and beyond." IEEE
Communications Magazine 53, no. 3 (2015): 80-88.
– Hybrid systems
• Flores, Huber, Rajesh Sharma, Denzil Ferreira, Vassilis Kostakos, Jukka Manner, Sasu
Tarkoma, Pan Hui, and Yong Li. "Social-aware hybrid mobile offloading." Pervasive
and Mobile Computing 36 (2017): 25-43.

Helsinki, Finland, 2018.

 41

QUESTIONS 

Helsinki, Finland, 2018.