CSE 5306

Distributed Systems

Processes

Processes in Distributed Systems

In traditional OS, management and
scheduling of processes is the main focus
In Distributed Systems, other issues turn
out to be equally or more important
Multi-threading for efficiency
Virtualization for isolation
Process migration (moving process between
different machines in the system)
2

Multi-threading Process
Problems with single-thread processes
Context switch between processes is quite expensive
Creating a new process is expensive

Benefit of multi-threading
Blocking system calls does not stop the process (just switch to
another thread)
It is possible to exploit parallelism on multi-processor computers
Useful in cooperating programs, i.e., different parts of an application
may need to talk to each other
IPC between single-thread processes are expensive
Communication between multiple threads in a process is easy

It is often easier to construct an application as a collection of

cooperating threads
3

Thread Implementation

Combining kernel-level lightweight

processes and user-level threads.
4

Multi-threaded Server

A multithreaded server organized in a

dispatcher/worker model.
5

Three Ways to Construct a Server

Single-threaded Servers
No parallelism, blocking system call
Sequential process model

Multi-threaded servers
Parallelism, blocking system call
Sequential process model

Finite-state machine
Parallelism, must use non-block system call
Sequential process model lost
6

Virtualization
Why virtualization?
In early days, to allow legacy software to run on
expensive mainframe hardware
The legacy software is developed for a specific OS, which
is not supported by mainframe

Hardware and low-level system software changes

quickly, but the software at high level remains stable
Run the same application on many different platforms
A high degree of portability and flexibility
Copy the entire virtual machine to another location
7

Logic view of Virtualization

(a) General organization between a program, interface, and system.

(b) General organization of virtualizing system A on top of system B.
8

Architectures of Virtual Machines

Computer systems often offer four types of interfaces
An interface between the hardware and software
consisting of machine instructions
that can be invoked by any program.

An interface between the hardware and software,

consisting of machine instructions
that can be invoked only by privileged programs, such as an
operating system.

An interface consisting of system calls offered by an OS

An interface consisting of library calls
known as an application programming interface (API).
In many cases, the system calls are hidden by an API.
9

Logic View of Four Interfaces

Various interfaces offered by computer systems.

10

Process Virtual Machine

A process virtual machine, with multiple

instances of (application, runtime) combinations.
11

Virtual Machine Monitor

A virtual machine monitor, with multiple instances

of (applications, operating system) combinations.
12

Client-Side Processes
The major task is
to provide user interface to access remote servers

A networked application with its own protocol.

13

Thin-Client Approach

A general solution to allow access

to remote applications.
14

Example: The XWindow System

The basic organization of theXWindow System.

15

Other Client-Side Tasks

In addition to network user interface, the client side may
handle part of the processing level and data level
have components to achieve distribution transparency
have components to achieve failure transparency, i.e., handle
communication failure

16

Server-Side Processes
Generally, a server
Waits for an incoming request from a client
Ensure that the request has been taken care of
Waits for the next request

General design issues

How to organize servers
iterative, concurrent

How to locate the needed service

Fixed port, assigned by a daemon, superserver

Where and how a server can be interrupted

Whether or not the server is stateless
17

Client-Server Binding (Daemon)

18

Client-Server Binding (Superserver)

19

Server Cluster
The need for a server cluster
A single computer cannot handle the needed bandwidth,
computing, failure resistance, etc.

A server cluster is logically organized in three tiers

20

Hiding the Cluster from Clients

The principle of TCP handoff.

21

Distributed Servers
Provide a robust server that is highly available
The server cluster early has a single static access point
what if this access point fails?

Increasing the number of static access points does not

solve the problem

Solution (Based on the mobility support for IP6)

Provide a single life-long contact address
At any time, one node is operate on such address
If this node fails, another node will come into place

Problem:
All traffic flow through home agent and the access point
22

Routing Optimization

23

PlanetLab
A global research network that supports the
development of network services such as
distributed storage, peer-to-peer network

Nodes in the network are distributed all over the

world (currently 1128 nodes at 544 sites)
Different organizations donate one or more computers,
adding up to thousands of nodes for one or more common
purposes (e.g. Particle Physics Research, Cancer research,
University research activities)

Nodes run Linux OS since it support diverse hardware

24

PlanetLab Organization
From a users perspective
What he needs is a network of computers under his
control

Since we have many users,

many networks may coexist in PlaneLab

We only have limited number of nodes

Thus, each node may hold computers from different users

Therefore, each node runs a VMM (an enhanced linux

OS), which manages a number vserver
vservers = the computers from the users point of view
A network of vservers presented to a user = slice
25

Organization of PlanetLab Node

26

Management of PlanetLab
The major management task is
assign a slice to a user upon request

Each node has a node manager whose only task is

to create other Vservers on the node it manages, and to
control resource allocation.

Only the slice authority can create a slice for a user

by contacting the slice creation service (SCS) at a collection
of PlanetLab nodes
The SCS in each selected node then requests the node
manager to create the needed vserver

UTA has two Vservers running on one Node.

27

The Management Relationship

1.

A node owner puts its node under the regime of a management authority, possibly
restricting usage where appropriate.

2. A management authority provides the necessary software to add a node to PlanetLab.

3. A service provider registers itself with a management authority, trusting it to provide
well-behaving nodes.
4. A service provider contacts a slice authority to create a slice on a collection of nodes.
5. The slice authority needs to authenticate the service provider.
6. A node owner provides a slice creation service for a slice authority to create slices. It
essentially delegates resource management to the slice authority.
7. A management authority delegates the creation of slices to a slice authority.
28

Other Management Issues

Nodes belong to different organizations.
Each organization should be allowed to specify who is
allowed to run applications on their nodes,
And restrict resource usage appropriately.

Available monitoring tools often assume a very

specific combination of hardware and software.
All tailored to be used within a single organization.

Programs from different slices but running on the

same node should not interfere with each other.

29

Code Migration
The communication in the distributed systems discussed so far
is limited to passing data
Being able to passing code, even while in execution, can
simplify the design of distributed systems
improve performance by moving process from heavily-loaded system
to lightly-loaded system
improve performance by exploiting parallelism (e.g., parallel search)
provide flexibility, i.e., clients dont have to pre-install all software

We will discuss
Different approaches for code migration
How to deal with the local resources that a migrating program uses
How to migrate code between heterogeneous systems
30

Dynamically Configuring a Client

31

Code Migration Examples (1)

Example 1: (Send Client code to Server)
In a client-Server system, the server holds a huge database.
If a client needs to perform many database operations, it may
be better to
ship part of the client application to the server and server sends only
the results across the network.

Example 2: (Send Server code to Client)

In many interactive DB applications, clients need to fill in forms
that are subsequently translated into a series of DB operation
The validation of the form can be done at server side, but
We can move the validation code to the client side to save the
computation power of the server
32

Code Migration Examples (2)

Example 3:
System administrator may be forced to shut
down a server but does not want to stop the
running processes (e.g. to change a part or
even permanent shut down)

Example 4:
Temporarily freeze an environment, move to
another machine and unfreeze (e.g. for
debugging server production issues)
33

Models for Code Migration

A process consists of
Code segment
Resource segment
Execution segment

Weak mobility
Migrate only the code segment

Strong Mobility
Migrate all three segments

Receiver-Initiated: Receiver requests code

Usually simple since receivers asks for info

Sender-initiated: Sender pushes code

Must make sure the Sender is genuine (Authenticate)
34

Alternatives for Code Migration

35

Migration and Local Resource

Resource Migration Examples:

What happens to a TCP port opened by a migrating process
URL reference to a File when the code is moved

Resource Types:
Fixed Resources: bound to a specific machine or environment and can not be
moved (e.g. Local disk drives, communication ports)
Unattached resources: can easily be moved (e.g. Data files)
Fastened resources: may be possible but very costly (e.g. local databases or
complete web sites)

Binding strength:
(Strongest) By identifier: e.g. when a process uses a URL to refer to a web
site by its IP address
(Weaker) By Value: e.g. program relies on standard libraries such as C or
JAVA. No need to migrate if the lib is a standard library
(Weakest) By type: e.g. references to local device such as printers,
36

Migration and Local Resource

Actions to be taken with respect to the references to local

resources when migrating code to another machine.

37

Migration in Heterogeneous Systems

Three options
Pushing memory pages to the new virtual
machine and resending the ones that are later
modified during the migration process.
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 machine immediately and copy
memory pages on demand.
38