Agenda In this chapter, we take a closer look at: The role of - - PDF document

Lecturer: Hadi Salimi Lecturer: Hadi Salimi Distributed Systems Lab, School of Computer Engineering I U i i f S i d T h l Iran University of Science and Technology, hsalimi@iust.ac.ir

Agenda

In this chapter, we take a closer look at:

The role of processes in distributed systems A brief introduction to virtualization technologies.

O h l d lik i i

Other process‐related concepts like migraion.

Threads

The granularity of processes in a distributed system is not

sufficient.

There is need for a more finer element inside processes. Using threads, can bring different advantages and

di d disadvantages.

Traditional Thread Usages

The spreadsheet example. From an IPC point of view.

p

Threads are more proper in some cases. Are web browsers a good example?

Thread Implementation

Threads could be implemented as:

User mode threads

Easier for implementation Low overhead A thread blocks leads to process block A thread blocks leads to process block

Kernel mode threads

Hard to implement A blocked thread does not block the whole process

Hybrid threads (LWPs) U h b id h d i d

Uses a hybrid approach as depicted.

Hybrid Thread Implementation

Threads are supported on both kernel and user modes.

Thread in Distributed Systems

They could avoid a process from being blocked when a

blocked system call has happened.

Threads could be used at:

Client Processes Server Processes

Multithreaded Clients

A multi‐threaded browser:

Performs communication and page rendering

simultaneously.

Could have multiple connections at the same time.

This could be more useful when the browser gets the page This could be more useful when the browser gets the page

form a replicated server.

Multithreaded Servers

As the first example consider a file server: In the case of a blocked thread, other thread could get

, g client requests.

Virtualization

The concept of virtualization:

To present a concept in a new form This technique has been applied for many decades.

Role of virtualization if distributed systems:

Legacy support

E i i ti

Easier migration More flexibility More flexibility

Virtualization

This figure shows the role of interacting interfaces on a

computer system.

Architecture of VMs

Interfaces at different levels

An interface between the hardware and software consisting

g

• f machine instructions

that can be invoked by any program.

An interface between the hardware and software, consisting

• f machine instructions

that can be invoked only by privileged programs, such as an

• perating system.

Architecture of VMs

Interfaces at different levels

An interface consisting of system calls as offered by an

g y y

• perating system.

An interface consisting of library calls

generally forming what is known as an application

programming interface (API) programming interface (API).

In many cases, the aforementioned system calls are

hidden by an API. y

Architecture of VMs

Interface stack on a computer system.

Architecture of VMs

A VM that can provide a virtual environment for an

application.

Architecture of VMs

Virtualizing the hardware for an operating sytem using a

Virtual Machine Monitor

Client‐Server Computing

Client

Networked User Interfaces

The X Window System Compound Document

Client side software for distributed transparency Client‐side software for distributed transparency

Server

General Design Issues General Design Issues Server Clusters

Distributed Servers

Managing Server Clusters

PlanetLab

Networked User Interfaces

Two kind of clients:

Application‐specific protocols for clients

pp p p

Example: X Window

General‐purpose protocols like TCP/IP

X Window Systems

The basic organization of the X Window System

Compound Documents

Today modern documents are composed on many

different parts, each of which belongs to an special application. A l d d ld

As an example, a word processor document could contain:

Text, graphic, movie, charts, database tables, etc.

Like the X Window system most of the computations are Like the X Window system, most of the computations are

done at server side.

Client‐Server Computing

Client

Networked User Interfaces

The X Window System Compound Document

Client side software for distributed transparency Client‐side software for distributed transparency

Server

General Design Issues General Design Issues Server Clusters

Distributed Servers

Managing Server Clusters

PlanetLab

Clients and Distribution Transparency

The client software could contain small processing

elements as well.

The small elements could use to bring different types of

d b h distribution transparency such as:

A t

Access transparency Replication transparency Replication transparency Failure transparency

p y

Clients and Replication Transparency

A client can easily provide replication transparency

through intercepting requests.

Client‐Server Computing

Client

Networked User Interfaces

The X Window System Compound Document

Client side software for distributed transparency Client‐side software for distributed transparency

Server

General Design Issues General Design Issues Server Clusters

Distributed Servers

Managing Server Clusters

PlanetLab

Server Design Issues

A Server is a process the implements a specific service on

behalf of a group of clients.

Servers could process incoming requests or easily send it

h ( f k) to another process. (e.g. using fork) Cli d S d d i i

Clients and Servers need an end point to communicate, so

how to make it?

Publishing the endpoint globally Publishing the endpoint globally An agreement between client and server Using a Naming Service

g g

End Point Table

A case in which a client could find the end point by means

• f a special daemon server, equipped with an end point

table.

Many Servers ‐ On End Point

Having a server for each end point may waste the resources. This can be prevented by having a Super‐Server acts as a

multiplexer multiplexer.

State Manipulation

A stateless server does not keep information on the state

• f its clients and can change its own state without having

to inform any client.

A simple time server

A fil d l d

A file download server When the request processes, the server completely forgets

about the client.

Some unimportant information such as log files may be

kept in stateless servers.

But loosing this information does not lead to any critical

disasters.

These kind of states are called soft‐states These kind of states are called soft‐states.

Statefull Servers

Statefull servers keep persistent information about

clients.

As an example consider a document management server.

This server needs to keep track of the files or documents

l k d b h li t f d t locked by each client for update. Benefits:

Are usually faster Are usually faster

Disadvantages:

A server crash could not be recovered easily

A server crash could not be recovered easily.

State Management

Statefull servers are usually persist their data on data

layer.

Other info kept on processing layer, such as session info

are usually soft state.

Cluster Computing

Three different layers of server cluster.

Code Migration

There are cases in which passing programs in execution

instead of their data simplifies the design of distributed systems. h

Moving a process to a remote machine is a time

consuming activity.

This is usually done in support of load balancing. The key idea behind code migration decisions is the ratio

• f communication on computation.

p

Code Migration (Cont.)

As an example, if a client application needs to process

large amounts of data from a database, it would be more efficient if the application could be moved near the database.

In a similar case parts of the server could be used moved In a similar case, parts of the server could be used moved

into client side.

Any examples?

y p

Code Migration (Cont.)

Code migration is also beneficial for decomposing an

application into parts and distribute them on the system.

The principle of

The principle of dynamically configuring a client to communicate to a

• server. The client

first fetches the first fetches the necessary software, and then invokes the server.

Code Migration (Cont.)

From a specific viewpoint, a process could be viewed as a

triple:

Code segment: the part that contains executing code. Resource segment the part that keeps references to Resource segment: the part that keeps references to

resources.

Execution segment: the part that keeps execution state.

Code Migration (Cont.)

Weak mobility:

Only the code segments migrates. The migrated program should be started from beginning. Example: Applets

Strong mobility:

Code and execution segments could be moved.

Th ld b d i t d d th t t d

The process could be paused, migrated and then restarted.

Models of Migration

Alternatives for code migration

Migration and Local Resources

The reason that makes migration difficult is that usually

the resource segment cannot be moved.

As an example, suppose that a process that holds a TCP

k f l h dl b d l socket or an open file handle cannot be migrated easily. Th diff

Three different resource types.

By identifier By value By value By type

Process‐Resource Bindings

The strongest binding is when a resource is refereed to by

its identifier.

A URL f b

A URL for a web resource A remote machine’s end point

A weaker form of process to resource binding is by value.

In this case any resource by that name could be used.

A shared object or dll

The weakest form is when a process refers to a resource by The weakest form is when a process refers to a resource by

its type.

When a process needs a CD‐drive, a monitor, etc.

Resource Types

Unattached Resources: can be easily moved.

Data files that could be easily moved.

Fastened resource: can be moved, but brings a high cost

Local databases

Fixed resources: cannot be moved at all Fixed resources: cannot be moved at all.

Local devices

Migration and Local Resources

Actions to be taken with respect to the references to local

resources when migrating code to another machine resources when migrating code to another machine.