Download Introduction - COW :: Ceng

Document related concepts

CAN bus wikipedia , lookup

Network tap wikipedia , lookup

Remote Desktop Services wikipedia , lookup

Airborne Networking wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Lag wikipedia , lookup

Distributed firewall wikipedia , lookup

Computer cluster wikipedia , lookup

Service-oriented architecture implementation framework wikipedia , lookup

Peer-to-peer wikipedia , lookup

Distributed operating system wikipedia , lookup

Transcript
Introduction
Chapter 1
Definition of a Distributed System (1)
A distributed system is:
A collection of independent
computers that appears to its
users as a single coherent
system.
Definition of a Distributed System (2)
A DS is a collection of independent computers that appears as a single
system. It is expected to have BOB. This is actually a middleware as a
layer between the applications and the network. It gives the same
interface to all the applications. All applications communicate with its
components and with other applications.
1.1
A distributed system organized as middleware.
Note that the middleware layer extends over multiple machines.
Goals
For a distributed system to be worthwhile it should
have some reasonable useful goals:
 Connection of users and resources:
Accessibility
 Transparency
 Openness: syntax and semantics
 Scalability: asynchronous comm,
distribution, replications, etc.
Accessibility
 Almost every component available over the network
can be shared, and it is useful to share: computers,
devices, data, communication medium.
 But, how efficient and secure is all this sharing.
 DS must work to provide enough security and
efficiency.
Type of transparency
Transparency
Description
Access
Hide differences in data representation and
how a resource is accessed
Location
Hide where a resource is located
Migration
Hide that a resource may move to another
location
Relocation
Hide that a resource may be moved to another
location while in use
Replication
Hide that a resource may be shared by several
competitive users
Concurrency
Hide that a resource may be shared by several
competitive users
Failure
Hide the failure and recovery of a resource
Persistence
Hide whether a (software) resource is in
memory or on disk
Different forms of transparency in a distributed system: Hide the
multiplicity, with best of the both
Clarification of Transparency
•
•
•
•
•
•
Hide difference in data representation
Resources have logical names,
independent of where they are located
Resources can be migrated without
changing how they are accessed
logically
Hide the fact that several copies of the
same resource exist
Concurrent access should leave the
resource in a consistent state
The user of DS is not aware of a
failure and the recovery from the
failure
Degree of Transparency
•
•
•
High degree of transparency may be
impractical: For example, you travel to
Tokyo from Istanbul, you have time
difference that may make electronic
morning paper irrelevant.
Certain things are impossible to high:
signal transfer time, delay caused by
high traffic on the shared servers.
Replication is costly in time, because
of consistency requirement in all
copies.
Openness
•
•
•
An open system offers services
according to the standard rules
that allow interoperability and
portability.
It should be possible to built
systems out of different
components. It should be easy to
add new components replace the
existing ones.
So, the system should be
extensible
Scalability
•
•
•
With respect to size: more or less
users or resources
Geographical: users and resources
may be far apart
Administratively: DS may span
over more than one administrative
bodies
Scalability Problems
Concept
Example
Centralized services
A single server for all users
Centralized data
A single on-line telephone book
Centralized algorithms
Doing routing based on complete information
Examples of scalability limitations.
Decentralized Algorithms for
Scalability
•
•
•
•
•
No machine has complete inf
about the system
Decision are made on locally
available inf
Failure of one machine does not
invalidate the system
There is no global clock
Geographic centralization hinders
geographic scalability
Scaling techniques (1)
•
•
•
Asynchronous communication
Moving the processing from
server to the client, if it is more
efficient. In this case instead of
(a) it is more efficient as in (b)
Spreading the work across the
system, as in DNS
Scaling Techniques (2)
1.4
The difference between letting:
a) a server or
b) a client check forms as they are being filled
Scaling Techniques (3)
1.5
An example of dividing the DNS name space into zones.
Scaling techniques (4)
•
•
Replication
Caching, as a special form of
replication:
–
•
consistency is an important issue in
caching
Combination of distribution,
replication and caching with
appropriate consistency often
provide sufficient scalability.
False assumptions on developing DS
•
•
•
•
•
•
•
•
Network is reliable
Network is secure
Network is homogeneous
Topology does not change
Latency is zero
Bandwidth is infinite
Transport cost is zero
There is one administrator
Type of Distributed Systems
•
•
•
•
•
•
•
•
Network is reliable
Network is secure
Network is homogeneous
Topology does not change
Latency is zero
Bandwidth is infinite
Transport cost is zero
There is one administrator
Hardware Concepts
1.6
Different basic organizations and memories in distributed
computer systems
Multiprocessors (1)
1.7
A bus-based multiprocessor.
Multiprocessors (2)
1.8
a) A crossbar switch
b) An omega switching network
Homogeneous Multicomputer Systems
1-9
a) Grid
b) Hypercube
Software Concepts
System
DOS(Distribut
Description
Main Goal
Tightly-coupled operating system for
multi-processors and homogeneous
multicomputers
Hide and manage
hardware
resources
(Network
Operating
Systems)
Loosely-coupled operating system for
heterogeneous multicomputers (LAN and
WAN)
Offer local
services to remote
clients
Middleware
Additional layer atop of NOS
implementing general-purpose services
Provide
distribution
transparency
ed Operating
Systems)
NOS
Uniprocessor Operating Systems
1.11
Separating applications from operating system code
through a microkernel.
Multiprocessor Operating Systems (1):MONITOR
monitor Counter {
private:
int count = 0;
public:
int value() { return count;}
void incr () { count = count + 1;}
void decr() { count = count – 1;}
}
A simple monitor, allowing one access at time: one processes finishes what it is
doing, before the other can start
• Monitor protects integer count against concurrent access.
• A monitor is implemented using semaphores
Multiprocessor Operating Systems (2):MONITOR
monitor Counter {
private:
int count = 0;
void decr() {
if (count ==0) {
int blocked_procs = 0;
blocked_procs = blocked_procs + 1;
condition unblocked;
wait (unblocked);
public:
blocked_procs = blocked_procs – 1;
int value () { return count;}
}
void incr () {
else
if (blocked_procs == 0)
count = count + 1;
else
count = count – 1;
}
}
signal (unblocked);
}
•
•
A evolved monitor to protect an integer against concurrent access: count is incremented
or decremented concurrently and correctly.
Monitor is implemented using semaphores, a process is blocked using condition
variables in the Monitor
Multicomputer Operating Systems (1)
1.14
General structure of a multicomputer operating system
Multicomputer Operating Systems (2)
1.15
Alternatives for blocking and buffering in message passing.
Multicomputer Operating Systems (3)
Synchronization point
Send buffer
Reliable comm.
guaranteed?
Block sender until buffer not full
Yes
Not necessary
Block sender until message sent
No
Not necessary
Block sender until message received
No
Necessary
Block sender until message delivered
No
Necessary
Relation between blocking, buffering, and reliable
communications.
Distributed Shared Memory Systems (1)
remote RAM is used as backup storage
a)
b)
c)
Pages of address
space distributed
among four
machines
Situation after
CPU 1 references
page 10
Situation if page
10 is read only
and replication is
used
Distributed Shared Memory Systems (2)
1.18
False sharing of a page between two independent processes.
Network Operating System (1)
1-19
General structure of a network operating system.
Services: rlogin, rcp, file servers,
Network Operating System (2)
1-20
Two clients and a server in a network operating system.
Network Operating System (3)
1.21
Different clients may mount the servers in different places.
Middleware
• Models
– Distributed file systems
– Remote Procedure Calls
– Distributed objects
– Distributed Documents
• Services
–
–
–
–
–
Communication
Naming
Persistence
Distributed Transactions
Security
Positioning Middleware
1-22
General structure of a distributed system as middleware:communication,
naming, data persistence, distributed tx, security.
Middleware and Openness: for
interoperability
1.23
In an open middleware-based distributed system, the protocols
used by each middleware layer should be the same, as well as
the interfaces they offer to applications.
Comparison between Systems
Item
Distributed OS
Network
OS
Middlewarebased OS
Multiproc.
Multicomp.
Very High
High
Low
High
Yes
Yes
No
No
1
N
N
N
Basis for
communication
Shared
memory
Messages
Files
Model specific
Resource management
Global,
central
Global,
distributed
Per node
Per node
Scalability
No
Moderately
Yes
Varies
Openness
Closed
Closed
Open
Open
Degree of transparency
Same OS on all nodes
Number of copies of OS
A comparison between multiprocessor operating systems,
multicomputer operating systems, network operating
systems, and middleware based distributed systems.
Cluster Computing Systems
• Cluster Computing System is a kind of DS
• Cluster computing is based on a collection
of similar workstations and the same
operating systems connected by a high
speed LAN
• It is used for parallel computing
• A true cluster is expected to gibe a
transparent process migration
Grid Computing Systems
• Grid computing has heterogeneity,
regarding computers, operating systems,
networks, administrative domains, security
policies
• The heterogeneous resources are provided
to a virtual organization that is formed by
different users.
• The resources are individual computers with
possibly different OS, super computers,
cluster computers, storage facilities,
databases, etc.
Transaction based distributed systems
• Transaction processing systems with ACID
(Atomic, Consistent, Isolated, Durable) property
• In such systems nested transactions is possible
• Transaction processing monitor is often need to be
installed to schedule the nested or concurrent sub
transactions
• Such applications may employ RPC-Remote
Procedure Call, RMI-Remote Method Invocations,
or MOM-Message Oriented Message exchange
Distributed Pervasive Systems
• These are systems are characterized as being
populated by relatively small members: that
embrace changes in the environment, ad-hoc
composition, sharing as default property, and
mobile
• Examples:
– Home systems: self configured and self managed
– Electronic health care systems: body area networksBAN are examples of sensor based such systems that
can process data locally or centrally
– Sensor networks: management-configuration,
aggregation of results, and failure management are
important issues to be developed further
Clients and Server Models
Client Server model has been agreed on as one of the
universal DS model, by many researchers
Clients and Servers
1.25
General interaction between a client and a server.
An Example Client and Server (1)
The header.h file used by the client and server.
An Example Client and Server (2)
A sample server.
An Example Client and Server (3)
1-27 b
A client using the server to copy a file.
Processing Level
1-28
The general organization of an Internet search engine into
three different layers
Client Server Arch: Multitiered
Architectures (1)
The 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,
– the programs implementing the
processing and data level
Multi-tiered Architectures:
• Vertical: put different components on
different machines
• Horizontal: clients and servers may be
physically split into different parts and
distributed to run on own data.
• Peer-to-peer: No client server role is taken,
the applications cooperate to conduct certain
task…
Multitiered Architectures (1)
1-29
Two-tiered architecture: Example1 for vertical distribution:
Alternative client-server organizations (a) – (e).
Multitiered Architectures (2)
1-30
Three-tiered Architecture: vertical distribution example2
An example of a server acting as a client.
Modern Architectures
1-31
An example of horizontal distribution of a Web service.
Peer-to-Peer as a horizontal distribution
• Interaction between the processes is
symmetric
• Each process is client and server at the same
time
• Processes are interconnected by a network
(overlay network)
• They can be structured and unstructured
Example: Structured Peer-to-Peer Arc (1)
•
•
•
•
Figure 2-7. The
mapping of data
items onto nodes
in Chord.
A Dist. Hash
Table(DHT) is
used
Data key k is
mapped to node
key id by DHT
The lag uses an
Example: Structured Peer-to-Peer Arc:
Node management (1)
• A node has shortcut to other nodes, that why
O(logN)
• A node joining system: a node id is inserted
between succ(id) and its predecessor in the
logical ring
Unstructered Peer-to-Peer Arch.
• Such networks are based on random organization
rather than a virtual structured architecture.
• An example : Each node may have a list of random
set of so called neighbors
• A new node wants join may contact a random alive
node
• Departing node may just leave, the other nodes
adapt in time.
Unstructured Peer-to-Peer Architectures (1)
Figure 2-9. (a) The steps taken by the active thread.
Unstructured Peer-to-Peer Architectures (2)
Figure 2-9. (b) The steps take by the passive thread
Architecture vs Middleware
•
•
Middleware is realized according to
different architectures
Architectures may be used to provide
adaptability, reconfiguration etc.
– Object orientation
•
Interceptors are used to allow adaptation
Interceptors
Figure 2-15. Using interceptors to handle
remote-object invocations.
General Approaches to Adaptive Software
Three basic approaches:
• Separation of concerns, based on
functionality
• Computational reflection: inspect and
itself and adapt accordingly
• Component-based design: adaptation
through comostion…
Self-Management in Distributed SystemsSMDS
• Management
– Self-management
– Self-healing
– Self-configuring
– Self-optimizing
• Feedback control loop can be used to
self-manage
SMDS-The Feedback Control Model
Figure 2-16. The logical organization of a
feedback control system.
SMDS- Example1
• Astrolabe: general monitoring of a very
large system
• A large collection of hosts into a
hierarchy of zones of increasing size
• Every host runs an agent process that
collect information about zone
• The agents communicate to spread the
local information
Example: Systems Monitoring
with Astrolabe
Figure 2-17. Data collection and information
aggregation in Astrolabe.
SMDS- Example2
• Globule: Collaborative content distribution
network
• End-user servers collaborate to optimize the
performance to optimize performance
through replication of web pages
• A replication policy is required based on
some performance metric
• It is possible to choose the best policy,
among the many. Each policy may depend
on the history of requests
Example: Differentiating Replication
Strategies in Globule (1)
Figure 2-18. The edge-server model assumed by
Globule.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Example: Differentiating Replication
Strategies in Globule based on history(2)
Figure 2-19. The dependency between prediction
accuracy and trace length.
SMDS- Example3-1
• Jade:
•
•
JADE (Java Agent DEvelopment Framework) is
a software Framework fully implemented in Java
language.
It simplifies the implementation of multi-agent
systems through a middle-ware that complies
with the FIPA -Foundation for Intelligent
Physical Agents specifications and through a
set of graphical tools that supports the debugging
and deployment phases.
SMDS- Example3-2
•
•
•
The agent platform can be distributed across
machines (which not even need to share the same
OS) and the configuration can be controlled via a
remote GUI.
The configuration can be even changed at runtime by moving agents from one machine to
another one, as and when required.
JADE is completely implemented in Java
language and the minimal system requirement is
the version 1.4 of JAVA (the run time
environment or the JDK).
SMDS- Example3-3: automatic repair
• Jade is used to monitor a component based
computer cluster system
• Servers are built by Jade agents and
maintained by Jades:
– Terminate every binding of node to leave the
network
– Start and add a new node
– Configure a new node to replace a crashed node
– Integrate a new node into the system