Chapter 1
Chapter 1
Chapter 1
Introduction
Definition of a Distributed System
2
Definition of a Distributed System
3
Important characteristics of distributed systems
• Differences between the various computers and the ways in which
they communicate are mostly hidden from users. The same holds for
the internal organization of the distributed system.
• users and applications can interact with a distributed system in a consistent
and uniform way, regardless of where and when interaction takes place.
• Should also be relatively easy to expand or scale. This characteristic is a
direct consequence of having independent computers, but at the same time,
hiding how these computers actually take part in the system as a whole.
• A distributed system will normally be continuously available, although
perhaps some parts may be temporarily out of order.
• Users and applications should not notice that parts are being replaced or
fixed, or that new parts are added to serve more users or applications .
4
Definition of a Distributed System
Distributed systems are often organized by means of a layer of software -
• logically placed between a higher layer consisting of users and
applications, and a lower layer consisting of operating systems and basic
communication facilities
• Middleware.
6
Making Resources Accessible
7
Making Resources Accessible
8
Distribution Transparency
9
Types of Transparency
10
Types of Transparency
11
Types of Transparency
12
Types of Transparency
13
Types of Transparency
15
Openness
16
Openness
18
Openness
Extensibility
- It should be easy to configure the system out of different
components
- It should be easy to add new components or replace
existing ones.
19
Scalability
20
Size Scalability Problems
21
Scalability Problems
22
Geographical scalability Problems
23
Scalability Problems
Security issues:
Many components of a distributed system that resides within
a single domain, may not be trusted by users in other
domains.
24
Scaling Techniques
25
Scaling Techniques
Hiding communication latencies:
Basic idea: Try to avoid waiting for responses to remote service
requests as much as possible.
In applications that cannot make effective use of asynchronous
communication, a better solution is to reduce the overall
communication.
26
Scaling Techniques
28
Scaling Techniques
for example to resolve the name nl. vu.cs.flits
30
Scaling Techniques
31
Scaling Techniques
32
Pitfalls when Developing
Distributed Systems
False assumptions made by first time developer:
The network is reliable
The network is secure
The network is homogeneous
The topology does not change
Latency is zero
Bandwidth is infinite
Transport cost is zero
There is one administrator
34
Distributed Computing Systems
Cluster Computing Systems
• In cluster computing the underlying hardware consists of a collection
of similar workstations or PCs, closely connected by means of a high
speed local-area network.
• In addition, each node runs the same operating system.
• Used for parallel programming in which a single (compute intensive)
program is run in parallel on multiple machines.
35
Distributed Computing Systems
Grid Computing Systems
• Have a high degree of heterogeneity: no assumptions are made concerning
hardware, operating systems, networks, administrative domains, security
policies, etc.
• A key issue in a grid computing system is that resources from different
organizations are brought together to allow the collaboration of a group of people or
institutions.
•Such a collaboration is realized in the form of a virtual organization.
• Typically, resources consist of compute servers (including supercomputers, possibly
implemented as cluster computers), storage facilities, and databases.
• In addition, special networked devices such as telescopes, sensors, etc., can be
provided as well. 36
Distributed Computing Systems
Grid Computing Systems
37
Distributed Computing Systems
• The Fabric layer provides interfaces to local resources at a specific site. Note that these
interfaces are tailored to allow sharing of resources within a virtual organization. Typically,
they will provide functions for querying the state and capabilities of a resource, along with
functions for actual resource management (e.g., locking resources).
grid transactions that span the usage of multiple resources. For example, protocols are
needed to transfer data between resources, or to simply access a resource from a remote
location. In addition, the connectivity layer will contain security protocols to authenticate users
and resources. Note that in many cases human users are not authenticated; instead,
programs acting on behalf of the users are authenticated. In this sense, delegating rights from
a user to programs is an important function that needs to be supported in the connectivity
layer
38
Distributed Computing Systems
• The resource layer is responsible for managing a single resource. It uses the
functions provided by the connectivity layer and calls directly the interfaces
made available by the fabric layer. For example, this layer will offer functions for
obtaining configuration information on a specific resource, or, in general, to
perform specific operations such as creating a process or reading data. The
resource layer is thus seen to be responsible for access control, and hence will
rely on the authentication performed as part of the connectivity layer
• The collective layer deals with handling access to multiple resources and
typically consists of services for resource discovery, allocation and scheduling of
tasks onto multiple resources, data replication, and so on. Unlike the
connectivity and resource layer, which consist of a relatively small, standard
collection of protocols, the collective layer may consist of many different
protocols for many different purposes, reflecting the broad spectrum of services
it may offer to a virtual organization.ity layer.
• Finally, the application layer consists of the applications that operate within a
virtual organization and which make use of the grid computing environment
39
Distributed Pervasive Systems
• Devices are often characterized by being small, battery-powered, mobile,
and having only a wireless connection
• An important feature is the general lack of human administrative control.
• At best, devices can be configured by their owners, but otherwise they
need to automatically discover their environment
• following three requirements for pervasive applications:
1. Embrace contextual changes.
2. Encourage ad hoc composition.
3. Recognize sharing as the default.
40
Distributed Pervasive Systems
• Embracing contextual changes :
– means that a device must be continuously be aware of the fact that its
environment may change all the time.
– One of the simplest changes is discovering that a network is no longer
available, for example, because a user is moving between base stations.
– In such a case, the application should react, possibly by automatically
connecting to another network, or taking other appropriate actions.
• Encouraging ad hoc composition:
– refers to the fact that many devices in pervasive systems will be used in very
different ways by different users.
– As a result, it should be easy to configure the suite of applications running on a
device, either by the user or through automated (but controlled) interposition.
• Recognize sharing as the default:
– One very important aspect of pervasive systems is that devices generally join
the system in order to access (and possibly provide) information.
– This calls for means to easily read, store, manage, and share information.
41
Home System
• Built around one or more PCs, but can also include other
electronic devices:
– Automatic control of lighting, sprinkler systems, alarm
systems, etc.
– Network enabled appliances
– PDAs and smart phones, etc.
Electronic Health Care Systems
50
Architectural Styles (4)
53
Centralized Architectures (1)
In the basic client-server model, processes in a
distributed system are divided into two (possibly
overlapping) groups.
A server is a process implementing a specific service, for
example, a file system service or a database service.
A client is a process that requests a service from a server by
sending it a request and subsequently waiting for the server's
reply.
This client-server interaction, also known as request-
reply behavior
54
Centralized Architectures (2)
55
Centralized Architectures (3)
Communication between a client and a server can be
implemented by means of a simple connectionless
protocol when the underlying network is fairly reliable
as in many local-area networks
When a client requests a service, it simply packages a
message for the server, identifying the service it wants,
along with the necessary input data. The message is
then sent to the server.
Server will always wait for an incoming request,
subsequently process it, and package the results in a
reply message that is then sent to the client.
56
Centralized Architectures (4)
Advantage of connectionless protocol:
efficient
As long as messages do not get lost or corrupted, the
request/reply protocol works fine.
Making the protocol resistant to occasional
transmission failures is not trivial.
Solution: the client must resend the request when no reply
message comes in.
Problem: the client cannot detect whether the original
request message was lost, or that transmission of the reply
failed.
57
Centralized Architectures (5)
If the reply was lost, then resending a request may result in
performing the operation twice.
Examples:
If the operation was
"transfer $10,000 from my bank account,"
then, it would be better to report an error instead.
If the operation was
"tell me how much money I have left,"
then, it would be perfectly acceptable to resend the request.
When an operation can be repeated multiple times without
harm, it is said to be idempotent.
58
Centralized Architectures (6)
As an alternative, many client-server systems use a
reliable connection-oriented protocol.
Although this solution is not appropriate in a local-
area network due to relatively low performance, it
works perfectly in wide-area systems in which
communication is inherently unreliable.
59
Centralized Architectures (7)
Example:
Virtually all Internet application protocols are based on
reliable TCP/IP connections.
In this case, whenever a client requests a service, it first sets
up a connection to the server before sending the request.
The server generally uses that same connection to send the
reply message, after which the connection is torn down.
Trouble: setting up and tearing down a connection is
relatively costly, especially when the request and reply
messages are small.
60
Application Layering (1)
• considering that many client-server applications are
targeted toward supporting user access to databases,
• many people have advocated a distinction between the
following three levels
The user-interface level
The processing level
The data level
61
Application Layering (1)
• Considering that many client-server applications are targeted toward
supporting user access to databases,
• Many people have advocated a distinction between the following three
levels
The user-interface level: contains all that is necessary to directly
interface with the user, such as display management.
The processing level: typically contains the applications
The data level: manages the actual data that is being acted on
62
Application Layering (2)
• Figure 2-4. The simplified organization of an Internet
search engine into three different layers.
63