Transcript Introduction

Introducing …
Distributed Systems
Paul Barry
Muhammed Cinsdikici
1. Definition of a Distributed System (1)
“A distributed system is a collection of independent computers that appear to
the users of the system as a single computer.” [Tanenbaum]
“A system in which hardware or software components located at networked
computers communicate and coordinate their actions only by message
passing.” [Coulouris]
“A system that consists of a collection of two or more independent computers
which coordinate their processing through the exchange of synchronous or
asynchronous message passing.”
“A distributed system is a collection of autonomous computers linked by a
network with software designed to produce an integrated computing facility.”
1.2 Goals of Distributed Systems
•
•
•
•
Easily Connect Users/Resources
Exhibit Transparency
Support Openness
Be Scalable
–
–
–
in size
geographically
administratively
Looking at these goals helps use answer the question:
“Is building a distributed system worth the effort?”
Definition of a Distributed System (2)
1.1
A distributed system organized as middleware.
Note that the middleware layer extends over multiple machines.
1.2.1 Connect Users & Resources
-Easy access of users to remote resources
-Geographically distributed users can be build groupware
-Exchange of various types of data (voice, data, video..)
-Share resources with other users in an appropriate way
-Limited resources can be assigned to multiple users
-Cost optimization is done
-BUT ! Security is important aspect that should be observed and
implemented carefuly.
1.2.2 Transparency in a Distributed System
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.
Degree of Transparency
•Hide blindly all distribution aspects from users is not always a
good idea.
•Ex1_Content: Morning paper.
•When you request your countrie’s morning newspaper at
7:00 am from other side of the world, time should not be
transparent. If time is accepted as transparent, then
requested paper should’nt be the expected one.
•Ex2_Performance: Replication of Failed Server
•When a data is searched, a failed server is tried several
times. In order to getting rid of dealing with failed server,
user can cancel the searching that server.
1.2.3 Openness
- Offers services according to standard rules
that describe the syntax and semantics of
those services.
- Interoperability
- Portability
- Flexibility of configuration by different developers
- IDL(Interface Definition Language) is used to
describe standard interfaces.
Seperating Policy Mechanism
(Flexibility)
- System is organized as a collection of relatively
small and easily replaceable or adaptable
components
- In Monolithic approach, system components are only
logically seperated but implemented as huge program.
- In Monolithic approach, changing one of the logical
components effects the whole.
- Ex: Web Caching. Browsers should provide basic
facilities of storing documents and at the same time
users can decide which docs are stored and how long
etc…
1.2.4 Scalability
Distributed Systems Scalability can be summurized as;
- In Size: Add more users and resources
- Geographically: Users and resources lie far apart
- Administratively: Many Independent administrative organizations.
Scalability Problems (1)
Concept
Example
Centralized services
A single server for all users
(single Windows Logon server)
Centralized data
A single on-line telephone book
(single DNS server data)
Centralized algorithms
Doing routing based on complete information
(Making all routing in a single routing process)
Decentralization has the following specs;
1.
No machine has complete info about system state
2.
Machines make decisions based on local info
3.
Failure of one machine does not ruin the algorithm
4.
There is no implicit assumption that a global clock exists
Scalability Problems (2)
BUT!!!
Decentralization has also consider the following limitations (out of the LAN);
1.
Synchronization should be done in great deal for geographicaly far
aparts.
2.
Communication is should be guaranteed on unreliable connections.
3.
Scaling distributed systems across multiple independent
administrative domains.
4.
System security issues should be provided carefully.
Scaling Techniques
(Asynchronous Communication)
1.4
The difference between letting (asynchronous comm):
a) a server or
b) a client check forms as they are being filled
Scaling Techniques
(Distribution)
1.5
An example of dividing the DNS name space into zones.
Scaling Techniques
(Caching & Replication)
Considering that scalability problems often appear in the form of
performance degradation. So,
- Replicate components
(it increases availability and also balance the load)
- Caching is a special form of replication
(in contrast to replication, caching is a decision made
by client of a resource and not by the owner of a resource)
BUT !!! CONSISTENCY OF THE DATA SHOULD BE PROVIDED
Modeling Distributed Systems
When building distributed applications,
system builders have often looked to the
non-distributed systems world for
models to follow (… inspiration?)
Consequently, distributed systems tend to
exhibit certain characteristics that are
already familiar to us
This applies equally to hardware concepts as
it does to software concepts
1.3 Modeling Hardware Concepts
1.6
Different basic organizations and memories in distributed systems
1.3.1 Multiprocessors (1)
1.7
A bus-based multiprocessor.
Multiprocessors (2)
1.8
A crossbar switch
An omega switching network
1.3.2 Homogeneous Multicomputer
Systems
1-9
Grid
Hypercube
1.4 Modeling Software Concepts
System
Description
Main Goal
DOS
Tightly-coupled operating system for multiprocessors and homogeneous
multicomputers
Hide and manage
hardware
resources
NOS
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
An overview of
• DOS (Distributed Operating Systems)
• NOS (Network Operating Systems)
• Middleware
1.4.1 Distributed Operating Systems (DOS)
a) Uniprocessor Operating Systems
1.11
Separating applications from operating system code through
a “microkernel” – can provide a good base upon which to
build a distributed operating system (DOS).
Distributed Operating Systems (DOS)
b) Multiprocessor Operating Systems (1)
monitor Counter {
private:
int count = 0;
public:
int value() { return count;}
void incr () { count = count + 1;}
void decr() { count = count – 1;}
}
A monitor to protect an integer against concurrent
access.
Distributed Operating Systems (DOS)
Multiprocessor Operating Systems (2)
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 monitor to protect an integer against
concurrent access, but blocking a process.
Distributed Operating Systems (DOS)
Multicomputer Operating Systems (1)
1.14
General structure of a (DOS) multicomputer operating system – all the
systems are of the same type: homogeneous
Distributed Operating Systems (DOS)
Multicomputer Operating Systems (2)
1.15
Alternatives for blocking and buffering in message
passing.
Distributed Operating Systems (DOS)
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 Operating Systems (DOS)
Distributed Shared Memory Systems (1)
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 Operating Systems (DOS) Distributed
Shared Memory Systems (2)
1.18
False sharing of a page between two independent
processes.
1.4.2 Network Operating System (1)
1-19
General structure of a network operating system – all the systems are of
different types: heterogeneous
Network Operating System (2)
1-20
Two clients and a server in a network operating system – relatively
primitive set of services provided.
Network Operating System (3)
1.21
Different clients may mount the servers in different places – difficult to
maintain a consistent “view” of the system.
The Best of Both Worlds?
DOS: too inflexible (all systems of the same type)
NOS: too primitive (lowest common demoninator –
too much diversity)
“Middleware” – best possible compromise?
Middleware = NOS + additional software layer
1.4.3 Positioning Middleware
1-22
General structure of a distributed system as middleware.
Middleware and Openness
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. This is a much higher
level of abstraction than (for instance) the NOS Socket API.
Middleware Models/Paradigms
Distributed File Systems
The Remote Procedure Call (RPC)
Distributed Objects
Distributed Documents
[All of which we return to in detail later in this course … ]
Comparing DOS/NOS/Middleware
Item
Distributed OS
Network
OS
Middlewarebased OS
Multiproc.
Multicomp.
Very High
High
Low
High
Yes
Yes
No
No
Number of copies of OS
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
A comparison between multiprocessor operating systems,
multicomputer operating systems, network operating
systems, and middleware based distributed systems.
The Classic DS Model
How are “processes” organised within a Distributed
System?
General agreement/concensus:
“Client/Server” Model
Multi-tiering:
User Interface Level, Processing Level, Data Level.
1.5 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.
1.5.2 Application Layering
1-28
In the general organization of an Internet search engine
into three different layers – often referred to as “tiers”.
1.5.3 Client-Server Multitiered
Architectures (1)
1-29
Alternative client-server organizations (a) – (e).
Client-Server Multitiered Architectures
(2)
1-30
An example of a server acting as a client – this is a very common
vertical distribution model for distributed systems.
Client-Server Example Modern
Architecture
1-31
An example of horizontal distribution of a Web service (often also
referred to as “clustering”).
Examples of Distributed Systems
dsys.part1.pdf
Summary (Introduction)
• Distributed Systems … autonomous computers
working together to give the appearance of a single,
coherent system.
• They are transparent, scalable and open.
• Unfortunately, they also tend to be complex.
• Types of DS: DOS, NOS, Middleware.
• Processes within DSs conform to the “client/server
model”.
• Architectures included vertical and horizontal
arrangements, often into many levels/tiers.