DISTRIBUTED SYSTEMS

Principles
p
and Paradigms
g
Second Edition
ANDREW S
S. TANENBAUM
MAARTEN VAN STEEN
Chapter 3
Processes

Processes
How the different types of processes play a crucial role in distributed
systems.
Process : a program in execution.
From an O.S. perspective, the management and scheduling of scheduling
of processes are perhaps the most important issues to deal with.
From an D.S.

To efficiently
organize
client-server
convenient
multithreading.
efficientl organi
e client
ser er ssystems,
stems con
enient to use
se m
ltithreading
Using the concept of virtualization.
The design issue of servers.
Moving processes between different machines.
Process migration or code migration.
2

Threads
What a process is
is.
How processes and threads relate.

Process Table
Table.
Independent Processes.
Concurrency Transparency.
Switching between
CPU Context.
y Management
g
Unit ((MMU).
)
Memory
Translation Lookaside Buffer (TLB).
Swap Processes.
Thread Context.
Context
Multithreading.

Thread Usage in Nondistributed Systems.

Several benefits to
multithreading
gp
processes.
In single-thread
process,
whenever a
blocking system
call is executed,
the process as a
whole is
blocked
blocked.

Exploit
Parallelism

Large
g
Application
Designed as a
collection of
cooperating
programs.
Large Context
Switching.
IPC in UNIX

Different Parts
executed by
separate
threads.
Shared Data
Data.
Thread switching
user space.

Software
g
g -engineering
structure as a
collection of
cooperating.
4

Thread Usage in Nondistributed Systems

Figure
g
3-1. Context switching
g as the result of IPC.
5

Thread Implementation
p

Thread
Th
d
Package

Two approaches
Construct a tread library in user mode.
Kernel be aware of threads and schedule them.
User-level thread library
Advantages
Cheap to Create and Destroy threads.
Switching context can be done in few
instructions.
Disadvantages
Invocation of blocking system call will
i
immediately
di t l bl
block
k th
the entire
ti process.

Thread Implementation
p

KernelK
l
level
Threads

High price to pay.

Every thread operation carried out by
k
kernel
l requiring
i i a system
t
call.
ll
Switching contexts may now become as
expensive as switching process context.

Sol tion
Solution:

Hybrid form of user-level and kernel-level

threads.
Lightweight Processes (LWP)
Advantages.
Drawback.
7

Thread Implementation
p

Figure 3-2. Combining kernel-level lightweight

processes and user-level
user level threads
threads.
8

Threads in Distributed
Systems

Multithreaded Clients
Conceal latencies in communication.
Initiate communication and do
something else.
Web Browsers.

10

Multithreaded Servers
Exploit
p
parallelism
to
attain high
performance.
performance

Example file
server.

Dispatcher.
p
Worker thread.
11

Multithreaded Servers (1)

( )

Figure 3-3. A multithreaded server organized in a dispatcher/worker model.

12

Multithreaded Servers (2)

( )
Figure 3
3-4.
4. Three ways to construct a server.

13

Virtualization
Single-processor illusion.
Rapidly switching between threads Create illusion
of parallelism
parallelism.
Leading to what is known as Resource Virtualization.

We will discuss Virtualization.

How it can be realized
realized.
14

The Role of Virtualization in

Distributed Systems
Every (distributed) computer system offer an interface.
Basic instruction set offered by CPU.

Virtualization
Vi
li i d
deals
l with
i h extending
di or replacing
l i an existing
i i iinterface
f
so as to mimic
i i the
h
behavior of another system.
Most important reason is to run legacy software
software.
Become less of an issue.
Then 1990s became more favored for several reasons:

Hardware and low-level system software change fast.

Legacy cannot be maintained same pace.
Virtualization can help by porting the legacy interface to the new platforms.
Networking large Heterogeneous collection of server computers, running different application run each on
different Virtual machine.

15

The Role of Virtualization in

Distributed Systems

Figure 3-5. (a) General organization between a program, interface, and

y
(b)
( ) General organization
g
of virtualizing
g system
y
A on top of system
y
system.
B.
16

Architectures of Virtual Machines (1)

Interfaces
at
different
levels

An interface between the hardware

and software
f
consisting off machine
instructions
that can be invoked by any
program.
An interface between the hardware
and software
software, consisting of machine
instructions
that can be invoked only by
privileged programs, such as an
operating system.
17

Architectures of Virtual Machines (2)

Interfaces
at
different
levels

An interface consisting of system

calls as offered
ff
by an operating
system.
An interface consisting of library
calls
generally forming what is known
as an application programming
interface (API).
In many cases, the
aforementioned
f
system calls are
hidden by an API.
18

Architectures of Virtual Machines (3)

Figure 3-6. Various interfaces offered by computer systems.

19

Architectures of Virtual Machines (4)

Figure 3-7. (a) A process virtual machine, with multiple

instances of (application
(application, runtime) combinations
combinations.
20

Architectures of Virtual Machines (5)

Figure 3-7. (b) A virtual machine monitor, with multiple

instances of (applications
(applications, operating system) combinations
combinations.
21

CLIENTS

22

Networked User Interfaces (1)

( )

Figure
g
3-8. ((a)) A networked application
pp
with its own p
protocol.
23

Networked User Interfaces (2)

( )

Figure 3-8. (b) A general solution to allow access to remote applications

24

Example:
p The X Window System
y

Figure 3-9.
3 9 The basic organization of the X Window System
System.
25

Client-Side Software for Distribution Transparency

Figure 3-10. Transparent replication of a server

using a client
client-side
side solution
solution.
26

Servers

27

General Design
g Issues ((1))
Organi e Ser
Organize
Servers.
ers
Iterative Server.
Concurrent Server
Server.

How clients contact a server

End point port
Using daemon.
Superserver.
Superserver

How and whether a server can bee interrupted.

Abruptly exit break connection.
Out-of-band.
28

General Design
g Issues ((2))

Whether
or not
the
server is
stateless
t t l

Stateless Server: does not keep

information on the state of its clients
and can change its own state without
h i tto iinform
having
f
any ckient.
ki t
Stateful Server: maintains persistent
information on its clients.
Session state
Permanent state.
29

General Design
g Issues ((3))

Figure 3
3-11.
11. (a) Client-to-server
Client to server binding using a daemon.
30

General Design
g Issues ((4))

Figure 3-11.
3 11 (b) Client-to-server
Client to server binding using a superserver.
superserver
31

Sever Clusters

General Organization:

Collection of machines connected through a network.

Logically organized into three tires:

First tier: consists of a (logical) switch through which clients

requests are routed.
Second tier: contain servers dedicated to application
processing.
Third
hi d tier:
i consists
i off data-processing
d
i servers, notably
bl file
fil
and database servers.

32

Server Clusters (1)

( )

Figure 3
3-12.
12. The general organization of a
three-tiered server cluster.

33

Server Clusters (2)

( )

Figure 3-13.
3 13 The principle of TCP handoff
handoff.
34

Distributed Servers

Figure
g
3-14. Route optimization
p
in a distributed server.
35

Managing
g g Server Clusters
Example: PlanetLab

Figure 3-15.
3 15 The basic organization of a PlanetLab node.
node
36

PlanetLab (1)
( )
PlanetLab management issues:
N
Nodes
d b
belong
l
tto diff
differentt organizations.
i ti
Each organization should be allowed to specify
who is allowed to run applications on their nodes
nodes,
And restrict resource usage appropriately.
Monitoring tools a
available
ailable ass
assume
me a very
er specific
combination of hardware and software.
All tailored to be used within a single organization
organization.
Programs from different slices but running on the
same node should not interfere with each other
other.
37

PlanetLab (2)
( )

Figure 3-16. The management relationships

between various PlanetLab entities.
entities
38

PlanetLab (3)
( )
Relationships between PlanetLab entities:
A node owner puts its node under the regime of a
management authority, possibly restricting usage
where appropriate.
A management authority provides the necessary
software to add a node to PlanetLab.
PlanetLab
A service provider registers itself with a
management authority
authority, trusting it to provide well
wellbehaving nodes.
39

PlanetLab (4)
( )
Relationships between PlanetLab entities:
A service
i provider
id contacts
t t a slice
li authority
th it tto create
t
a slice on a collection of nodes.
The slice authority needs to authenticate the service
provider.
A node owner provides a slice creation service for a
slice authority to create slices. It essentially delegates
resource management to the slice authority.
A management authority delegates the creation of
slices to a slice authority.
40

Code Migration

41

Reasons for Migrating

g
g Code

Figure 3-17. The principle of dynamically configuring a client to communicate to a

server The client first fetches the necessary software
server.
software, and then invokes the server
server.
42

Models for Code Migration

g

Code Segments
Segments.
Process Resource
consist of
Segments.
g
three
segments: Execution
S
Segments.
t
43

Models for Code Migration

g

Figure 3-18. Alternatives for code migration.

44

Migration
g
and Local Resources

Figure
g
3-19. Actions to be taken with respect
p
to the references to local
resources when migrating code to another machine.
45

Migration in Heterogeneous Systems

Three
ways to
t
handle
migration
(which
can be
combined)
bi d)

Pushing
g memory
yp
pages
g to the new
machine and resending the ones that
are later modified during the migration
process.
p
Stopping the current virtual machine;
migrate memory, and start the new
virtual machine.
Letting the new virtual machine pull in
new pages as needed, that is, let
processes start on the new virtual
p
machine immediately and copy memory
pages on demand.
46