Transcript ppt

DISTRIBUTED SYSTEMS
Principles and Paradigms
Second Edition
ANDREW S. TANENBAUM
MAARTEN VAN STEEN
Chapter 3
Processes
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Outline
3.1 Threads
3.2 Virtualization
3.3 Clients
3.4 Servers
3.5 Code Migration
3.6 Summary
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Process communications
Multithreads
Client, server
Virtualization (independent and complete
environments, regardless of the underlying hardware
and OS platforms)
high degree of protability
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Multithreaded Servers (1)
Figure 3-3. A multithreaded server organized in a
dispatcher/worker model.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
The Role of Virtualization in
Distributed Systems
Figure 3-5. (a) General organization between a program,
interface, and system. (b) General organization of virtualizing
system A on top of system B.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
3.4 Servers
Server architectures
Multithreaded
Listen socket
public port number
Working socket
for each client request
Multiple servers
running simultaneously
on the same machine.
e.g, inetd in UNIX for well
known Internet services
(HTTP, FTP, etc, etc)
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Client/server socket interaction: TCP
client
server (running on hostid)
create socket,
port=x, for incoming
request:
serverSocket = socket()
wait for incoming
TCP
connection request
connectionSocket = connection
serverSocket.accept()
read request from
connectionSocket
write reply to
connectionSocket
close
connectionSocket
setup
create socket,
connect to hostid, port=x
clientSocket = socket()
send request using
clientSocket
read reply from
clientSocket
close
clientSocket
Server architectures
1. FTP client contacts FTP server at port
21, specifying TCP as transport protocol;
Client obtains authorization over control
connection; Client browses remote
directory by sending commands over
control connection.
Multithreaded
out-of-band data
TCP control connection
port 21
FTP
client
TCP data connection
port 20
FTP
server
2. When server receives a command for
a file transfer, the server opens a
second TCP data connection to
client; After transferring one file,
server closes data connection.
Server opens another TCP data
connection to transfer another file.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Server architectures
States at servers
Stateless vs stateful
(soft state)
Stateless:
No disruption to services
Web server: stateless
(cookie is not server side
feature)
Stateful
can provide performance
optimization;
Recover from crach is
hard;
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Server architectures
Server Clusters (1)
Figure 3-12. The general organization of a
three-tiered server cluster.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Server architectures
Server clusters
Two tiered (server with database)
The multimedia server case
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Access Transparency
Single portal handle TCP connections (requests)
TCP handoff for internal load balance
Figure 3-13. The principle of TCP handoff.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Server architectures
Distributed servers
e.g., DNS
Stable access
Ease case: a high performance, stable server (of server cluster)
Hard case: achieving stable access via mobile IP
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Distributed Servers
Achieving stable access via mobile IP
Figure 3-14. Route optimization in a distributed server.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Managing Server Clusters
Example: PlanetLab
• PlanetLab is a global research network that supports the development of
new network services.
• since 2003,
• developed new technologies for distributed storage, network mapping,
peer-to-peer systems, distributed hash tables, and query processing.
PlanetLab can
concurrently support
many experiments of
different distributed
systems and applications
http://www.planet-lab.org/
Slice: a collection of distributed resources for a specific application
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
a PlanetLab node
VMM:
Separation
Isolation
Slice: a set of d vservers, each on a different node
A node can concurrently support many slices (experiments)
Figure 3-15. The basic organization of a PlanetLab node.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
PlanetLab (1)
PlanetLab management issues:
•
Nodes belong to different organizations.
–
–
•
Monitoring tools available assume a very specific
combination of hardware and software.
–
•
Each organization should be allowed to specify who is allowed
to run applications on their nodes,
And restrict resource usage appropriately.
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.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
PlanetLab (2)
At a node:
Node manager (vserver)
Resource specification (Rspec)
Monitor a collection of nodes
Use via a service provider (account)
Slice creation/management via a slice authority
Figure 3-16. The management relationships
between various PlanetLab entities.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
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.
A service provider registers itself with a management
authority, trusting it to provide well-behaving nodes.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
PlanetLab (4)
Relationships between PlanetLab entities:
•
A service provider contacts a slice authority to create a
slice on a collection of nodes.
The slice authority needs to authenticate the service
provider.
•
•
•
•
Via out of band control for credentials
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.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
More on supporting the development of new
network services (distributed systems)
Virtualization and federation
Example of PlanetLab
Example of EmuLab
Example of ProtoGENI
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5