NILESHVERMA.COM

Introduction

A distributed system in its most simplest definition is a group of computers working together as to appear as a single computer to the end-user.

• A distributed system is a collection of independent computers that appear to the users of the system as a single system.
• A collection of independent computers that appears to its users as a single coherent system.
• A Distributed system consists of multiple autonomous computers, each having its own private memory, communicating through a computer network.
• Information exchange in a distributed system is accomplished through message passing.
• A computer program that runs in a distributed system is known as a distributed program.
• The process of writing distributed programs is referred to as distributed programming.
• Ideal: to present a single-system image: The distributed system “looks like” a single computer rather than a collection of separate computers.
• A distributed system is a collection of autonomous hosts that are connected through a computer network.
• Each host executes components and operates a distribution middleware.
• Middleware enables the components to coordinate their activities.
• Users perceive the system as a single, integrated computing facility.

Examples

• World Wide Web (WWW) is the biggest example of distributed system.
• The internet
• An intranet which is a portion of the internet managed by an organization
• Network of branch office computers

Characteristics of Distributed system

• To present a single-system image:
  • Hide internal organization, communication details
  • Provide uniform interface
• Easily expandable
  • Adding new computers is hidden from users
• Continuous availability
  • Failures in one component can be covered by other components
• Supported by middleware
• No shared memory – message-based communication
• Each runs its own local OS
• Heterogeneity

Advantages of Distributed Systems over Centralized Systems

Economics: A collection of microprocessors offer a better price/performance than mainframes. Low price/performance ratio: cost effective way to increase computing power.

Speed: A distributed system may have more total computing power than a mainframe. Ex. 10,000 CPU chips, each running at 50 MIPS. Not possible to build 500,000 MIPS single processor since it would require 0.002 sec instruction cycle. Enhanced performance through load distributing.

Inherent distribution: Some applications are inherently distributed. Ex. a supermarket chain.

Reliability: If one machine crashes, the system as a whole can still survive. Higher availability and improved reliability.

Incremental growth: Computing power can be added in small increments. Modular expand-ability

Another deriving force: The existence of large number of personal computers, the need for people to collaborate and share information.

Open system: This is the most important point and the most characteristic point of a distributed system. Since it is an open system it is always ready to communicate with other systems. An open system that scales has an advantage over a perfectly closed and self-contained system.

Distributed System architecture

The architecture of a system is its structure in terms of separately specified components and their interrelationships.  Distributed system architectures are bundled up with components and connectors. Components can be individual nodes or important components in the architecture whereas connectors are the ones that connect each of these components.

Component: A modular unit with well-defined interfaces; replaceable; reusable

Connector: A communication link between modules which mediates coordination or cooperation among components

So the idea behind distributed architectures is to have these components presented on different platforms, where components can communicate with each other over a communication network in order to achieve specifics objectives.

Advantages of Distributed System architecture(DSA)

Companies are preferring their system decentralized and distributed, because Distributed System allows companies to have better customer services.

• Share ability: Allows systems to use each other’s resources
• Expand-ability: Permits new systems to be added as members of the overall system
• Local Autonomy: Manage local resources
• Improved performance: Resource replication. Combined processing power of multiple computers provides much more processing power than a centralized system with multiple CPU’s
• Improved reliability and availability: Disruption would not stop the whole system from providing its services as resources spread across multiple computers

Four styles that are most important

1. Layered architecture
2. Object-based architecture
3. Data-centered architecture — processes communicate through a common repository (passive or active).
4. Event-based architecture — processes communicate through the propagation of events

Layered Architecture

• The layered architecture separates layers of components from each other, giving it a much more modular approach.
• A well known example for this is the OSI model that incorporates a layered architecture when interacting with each of the components.
• Each interaction is sequential where a layer will contact the adjacent layer and this process continues, until the request is been catered to. But in certain cases, the implementation can be made so that some layers will be skipped, which is called cross-layer coordination.
• Through cross-layer coordination, one can obtain better results due to performance increase.
• The layers on the bottom provide a service to the layers on the top.
• The request flows from top to bottom, whereas the response is sent from bottom to top.
• The advantage of using this approach is that, the calls always follow a predefined path, and that each layer can be easily replaced or modified without affecting the entire architecture.

The following image is the basic idea of a layered architecture style.

  Object Based Architecture

• This architecture style is based on loosely coupled arrangement of objects.
• This has no specific architecture like layers. Like in layers, this does not have a sequential set of steps that needs to be carried out for a given call.
• Each of the components are referred to as objects, where each object can interact with other objects through a given connector or interface.
• These are much more direct where all the different components can interact directly with other components through a direct method call.

As shown in the above image, communication between object happen as method invocations. These are generally called Remote Procedure Calls (RPC). Some popular examples are Java RMI, Web Services and REST API Calls. This has the following properties.

1. This architecture style is less structured.
2. component = object
3. connector = RPC or RMI

Data Centered Architecture

• As the title suggests, this architecture is based on a data center, where the primary communication happens via a central data repository.
• This common repository can be either active or passive.
• This is more like a producer consumer problem.
• The producers produce items to a common data store, and the consumers can request data from it.
• This common repository, could even be a simple database. But the idea is that, the communication between objects happening through this shared common storage.
• This supports different components (or objects) by providing a persistent storage space for those components (such as a MySQL database).
• All the information related to the nodes in the system are stored in this persistent storage.
• In event-based architectures, data is only sent and received by those components who have already subscribed.
• Some popular examples are distributed file systems, producer consumer, and web based data services.

Event Based Architecture

• The entire communication in this kind of a system happens through events.
• When an event is generated, it will be sent to the bus system.
• With this, everyone else will be notified telling that such an event has occurred. So, if anyone is interested, that node can pull the event from the bus and use it.
• Sometimes these events could be data, or even URLs to resources. So the receiver can access whatever the information is given in the event and process accordingly.
• processes communicate through the propagation of events.

• These events occasionally carry data.
• An advantage in this architectural style is that, components are loosely coupled. So it is easy to add, remove and modify components in the system.
• Some examples are, publisher – subscriber system, Enterprise Services Bus (ESB) and akka.io.
• This architectural style is based on the publisher-subscriber architecture.
• Between each node there is no direct communication or coordination. Instead, objects which are subscribed to the service communicate through the event bus.
• The event based architecture supports, several communication styles. :-Publisher-subscriber, Broadcast, Point-to-Point.
• The major advantages of this architecture is that the Components are decoupled in space – loosely coupled.

System Level Architecture

The two major system level architectures that we use today are Client-server and Peer-to-peer (P2P).  We use these two kinds of services in our day to day lives, but the difference between these two are often misinterpreted.

Client Server Architecture

• The client server architecture has two major components:- The client and the server.
• The Server is where all the processing, computing and data handling is happening, whereas the Client is where the user can access the services and resources given by the Server (Remote Server).
• The clients can make requests from the Server, and the Server will respond accordingly.
• Generally, there is only one server that handles the remote side. But to be on the safe side, we do use multiple servers will load balancing techniques.

Advantages:

• Easier to Build and Maintain
• Better Security
• Stable

Disadvantages:

• Single point of failure
• Less scalable

Peer to Peer (P2P)

• The general idea behind peer to peer is where there is no central control in a distributed system.
• The basic idea is that, each node can either be a client or a server at a given time.
• If the node is requesting something, it can be known as a client, and if some node is providing something, it can be known as a server.
• In general, each node is referred to as a Peer.
• In this network, any new node has to first join the network. After joining in, they can either request a service or provide a service.
• The initiation phase of a node (Joining of a node), can vary according to implementation of a network.
• There are two ways in how a new node can get to know, what other nodes are providing.

Centralized Lookup Server – The new node has to register with the centralized look up server an mention the services it will be providing, on the network. So, whenever you want to have a service, you simply have to contact the centralized look up server and it will direct you to the relevant service provider.
Decentralized System – A node desiring for specific services must, broadcast and ask every other node in the network, so that whoever is providing the service will respond.

Design Issues of Distributed Systems

followings are important design issues in a Distributed System.

1. Transparency

Transparency can be achieved at two different levels:-

• How to achieve the single‐system image, i.e., how to make a collection of computers appear as a single computer.
• Hiding all the distribution from the users as well as the application programs can be achieved at two levels:

1) hide the distribution from users

2) at a lower level, make the system look transparent to programs.

1) and 2) requires uniform interfaces such as access to files, communication.

The concept of transparency can be applied to several aspects of a distributed system.

• Location Transparency: The users cannot tell where hardware and software resources such as CPUs, printers, files, data bases are located.
• Migration Transparency: Resources must be free to move from one location to another without their names changed.
• Replication Transparency: OS can make additional copies of files and resources without users noticing.
• Concurrency Transparency: The users are not aware of the existence of other users. Need to allow multiple users to concurrently access the same resource. Lock and unlock for mutual exclusion.
• Parallelism Transparency: Automatic use of parallelism without having to program explicitly. The holy grail for distributed and parallel system designers.

2. Flexibility

The second key design issue is flexibility. It is important that the system be flexible because we are just beginning to learn about how to build distributed systems. It is likely that this process will incur many false starts and considerable backtracking. Design decisions that now seem reasonable may later prove to be wrong. The best way to avoid problems is thus to keep one’s options open.

3. Reliability

• One of the original goals of building distributed systems was to make them more reliable than single-processor systems.
• The idea is that if a machine goes down, some other machine takes over the job. A highly reliable system must be highly available, but that is not enough.
• Data entrusted to the system must not be lost or garbled in any way, and if files are stored redundantly on multiple servers, all the copies must be kept consistent.
• In general, the more copies that are kept, the better the availability, but the greater the chance that they will be inconsistent, especially if updates are frequent.

4. Performance:-

• Always the hidden data in the background is the issue of performance. Building a transparent, flexible, reliable distributed system, more important lies in its performance.
• In particular, when running a particular application on a distributed system, it should not be appreciably worse than running the same application on a single processor. Unfortunately, achieving this is easier said than done.

5. Scalability :-

• A system is described as scalable if it will remain effective when there is a significant increase in the number of resources and the number of users.
• Systems grow with time or become obsolete. Techniques that require resources linearly in terms of the size of the system are not scalable. e.g., broadcast based query won’t work for large distributed systems.