SlideShare a Scribd company logo

Intro ds 1

•
•
H
HajuseNtandu

Distributed systems consist of components located across a network that communicate and coordinate their actions by passing messages. Key challenges of distributed systems include independent component failures, insecure communication, and lack of a global clock. Distributed systems aim to provide distribution transparency to present a single system view to users. They can satisfy requirements like resource sharing, openness, scalability, fault tolerance, and heterogeneity. However, developing distributed systems risks false assumptions about reliability, security, and performance of the network.

1 of 14
Download to read offline
1 Introduction to Distributed Systems (DS) INF5040/9040 autumn 2011 Frank Eliassen, Ifi/UiO 1 lecturer: Frank Eliassen Outline What is a distributed system? What is a distributed system? Challenges and benefits of distributed system Distribution transparencies Pitfalls when developing distributed Frank Eliassen, Ifi/UiO 2 Pitfalls when developing distributed systems Types of distributed systems
2 What is a distributed system? Many definitions  [Coulouris]  A distributed system is one in which hardware or software y components located at networked computers communicate and coordinate their actions only by passing messages.  [Tanenbaum & van Steen]  A distributed system is a collection of independent computers that appears to its users as a single coherent system.  [Lamport]  A distributed system is a system that prevents you from doing any work when a computer you have never heard about, fails. Frank Eliassen, Ifi/UiO 3 y p y ,  The above definitions take different perspectives  Operational perspective  User perspective  DS characteristcs perspective Implications of distributed systems  Concurrency – components execute in concurrent processes that read and update shared resources Requires coordination shared resources. Requires coordination  No global clock – makes coordination difficult (ordering of events)  Independent failure of components – “partial failure” & incomplete information  Unreliable communication – Loss of connection and messages. Message bit errors  Unsecure communication Frank Eliassen, Ifi/UiO 4 U secu e co u ca o – Possibility of unauthorised recording and modification of messages  Expensive communication – Communication between computers usually has less bandwidth, longer latency, and costs more, than between independent processes on the same computer
3 Goals of distributed systems  resource sharing the possibility of using available resources any where – the possibility of using available resources any where  openness – an open distributed system can be extended and improved incrementally – requires publication of component interfaces and standards protocols for accessing interfaces  scalability – the ability to serve more users, provide acceptable response Frank Eliassen, Ifi/UiO 5 y p p p times with increased amount of data  fault tolerance – maintain availability even when individual components fail  allow heterogeneity – network and hardware, operating system, programming languages, implementations by different developers Examples of distributed systems Web search Web search  Index the entire contents of the Web. Massively multiplayer online games  Very large number of users sharing a virtual world. Financial trading  Real time access and process of a wide rage of information sources. Frank Eliassen, Ifi/UiO 6
4 A distributed system organized as middleware  Layer of software offering a single-system view  Offers portability and interoperability  Offers portability and interoperability  Simplifies development of distributed applications and services Distributed applications and services Frank Eliassen, Ifi/UiO 7 DISTRIBUTION MIDDEWARE Platform Independent API Platform Dependent API . . . Local OS 1 Local OS 2 Local OS n - transaction oriented (ODTP XA) - message oriented(IBM MQSeries) - remote procedure call (X/Open DCE) - object-based (CORBA, COM, Java) Resource sharing  The opportunity to use available hardware, pp y , software or data anywhere in the system  Resource managers control access, offer a scheme for naming, and controls concurrency  A service is a software module that manages a collection of related resources and presents their functionality to users Frank Eliassen, Ifi/UiO 8 functionality to users.  A resource sharing model describes how  resources are made available  resources can be used  service provider and user interact with each other
5 Models for resource sharing  Client-server resource model  Server processes act as resource managers, and offer services (collection of procedures)  Client processes send requests to servers  (HTTP defines a client-server resource model)  Object-based resource model  Any entity in a process is modeled as an object with a message based interface that provides access to its operations Frank Eliassen, Ifi/UiO 9  Any shared resource is modeled as an object  Object based middlewares (CORBA, Java RMI) defines object- based resource models Scalability  A system is scalable if it remains effective when there is y a significant increase in the amount of resources (data) and number of users  Internet: number of users and services has grown enormously  Scalability denotes the ability of a system to handle an increasing future load  Requirements of scalability often leads to a distributed Frank Eliassen, Ifi/UiO 10  Requirements of scalability often leads to a distributed system architecture (several computers)
6 Scalability problems (1) Often caused by centralized solutions Frank Eliassen, Ifi/UiO 11 Scalability problems (2) Characteristics of decentralized algorithms:  No machine has complete information about  No machine has complete information about the system state.  Machines make decisions based only on local information.  Failure of one machine does not ruin the algo ithm Frank Eliassen, Ifi/UiO 12 algorithm.  There is no implicit assumption that a global clock exists.
7 Scaling techniques  Distribution  splitting a resource (such as data) into smaller parts, p g ( ) p , and spreading the parts across the system (cf DNS)  Replication  replicate resources (services, data) across the system  increases availability, helps to balance load  caching (special form of replication)  Hiding communication latencies Frank Eliassen, Ifi/UiO 13  Hiding communication latencies  avoid waiting for responses to remote service requests (use asynchronous communication or design to reduce the amount of remote requests) Failure handling  Hardware, software and network fail!!  DS must maintain availability even in cases where hardware/software/network have low reliability  Failures in distributed systems are partial  makes error handling particularly difficult  Many techniques for handling failures  Detecting failures (checksum a.o.) M ki f il ( i i i l ) Frank Eliassen, Ifi/UiO 14  Masking failures (retransmission in protocols)  Tolerating failures (as in web-browsers)  Recovery from failures (roll back)  Redundancy (replicate servers in failure-independent ways)
8 Example: Google File-System Early days… …today Challenges: - Scalability - Reliability - Performance Frank Eliassen, Ifi/UiO 15 Performance - Openness Distribution transparency An important goal of a distributed system An important goal of a distributed system is to hide the fact that its processes and resources are physically distributed across multiple computers A distributed system that is able to present lf d l f Frank Eliassen, Ifi/UiO 16 itself to its users and applications as if it were only a single computer system is said to be transparent
9 Transparency in a distributed system Frank Eliassen, Ifi/UiO 17 Different forms of transparency in a distributed system (ISO, 1995). Trade-off between degree of transparency and performance of a system Pitfalls when Developing Distributed Systems False assumptions made by first time p y developer:  The network is reliable.  The network is secure.  The network is homogeneous.  The topology does not change. L t i Frank Eliassen, Ifi/UiO 18  Latency is zero.  Bandwidth is infinite.  Transport cost is zero.  There is one administrator.
10 Quality of Service (QoS) Nonfunctional properties of the system: Nonfunctional properties of the system:  Reliability  Security  Performance (Responsiveness and throughput) Adaptability to meet changes is an important aspect of QoS Frank Eliassen, Ifi/UiO 19 Types of distributed system  Distributed Computing Systems  Used for high performance computing tasks Used for high performance computing tasks  Cluster and Cloud computing systems  Grid computing systems  Distributed Information Systems  Systems mainly for management and integration of business functions  Transaction processing systems Frank Eliassen, Ifi/UiO 20  Enterprise Application Integration  Distributed Pervasive (or Ubiquitous) Systems  Mobile and embedded systems  Home systems  Sensor networks
11 Cluster Computing Systems Collection of similar PCs, closely connected, all run same OS Frank Eliassen, Ifi/UiO 21 An example of a cluster computing system. Grid Computing Systems Federation of autonomous and heterogeneous computer systems (HW OS ) several adm domains computer systems (HW,OS,...), several adm domains Frank Eliassen, Ifi/UiO 22 A layered architecture for grid computing systems.
12 Enterprise Application Integration Allowing existing applications to directly exchange information using communication middleware information using communication middleware Frank Eliassen, Ifi/UiO 23 Middleware as a communication facilitator in enterprise application integration Example communcation middleware: CORBA Clients may invoke methods of remote objects without worrying about: bj t l ti i l Z foo() object location, programming language, operating system platform, communcation protocols or hardware. Different programming languages (or object models) X invoke Z’s method foo() Y Frank Eliassen, Ifi/UiO 24 IDL Object Request Broker (ORB) Common object model IDL IDL RMI over IIOP
13 Distributed Pervasive Systems Devices in distributed pervasive systems Devices in distributed pervasive systems discovers the environment and establishes themselves in this environment as best as possible.  Requirements for pervasive applications  Embrace contextual changes. Frank Eliassen, Ifi/UiO 25 Embrace contextual changes.  Encourage ad hoc and dynamic composition.  Recognize sharing as the default. QUA/MUSIC context-aware adaptation middleware for distributed pervasive systems http://www.euronews.net/2010/06/16/music-to-you-mobile-s-ears/ device user context environment context user context-aware, self-adaptive applications provided utility temperature light adapts optimizes monitors varying context 26 device context battery memory use CPU use position activity (e.g., driving) MUSIC Middleware http://ist-music.berlios.de/
14 Summary  Distributed systems:  components located in a network that communicates and p coordinates their actions exclusively by sending messages.  Consequences of distributed systems  Independent failure of components  Unsecure communication  No global clock  Distribution transparency: providing a single computer system view Frank Eliassen, Ifi/UiO 27 system view  Requirements like resource sharing, openness, scalability, fault tolerance and heterogeneity can be satisfied by distributed systems  Many pitfalls when developing distributed systems

More Related Content

Intro ds 1

  • 1. 1 Introduction to Distributed Systems (DS) INF5040/9040 autumn 2011 Frank Eliassen, Ifi/UiO 1 lecturer: Frank Eliassen Outline What is a distributed system? What is a distributed system? Challenges and benefits of distributed system Distribution transparencies Pitfalls when developing distributed Frank Eliassen, Ifi/UiO 2 Pitfalls when developing distributed systems Types of distributed systems
  • 2. 2 What is a distributed system? Many definitions  [Coulouris]  A distributed system is one in which hardware or software y components located at networked computers communicate and coordinate their actions only by passing messages.  [Tanenbaum & van Steen]  A distributed system is a collection of independent computers that appears to its users as a single coherent system.  [Lamport]  A distributed system is a system that prevents you from doing any work when a computer you have never heard about, fails. Frank Eliassen, Ifi/UiO 3 y p y ,  The above definitions take different perspectives  Operational perspective  User perspective  DS characteristcs perspective Implications of distributed systems  Concurrency – components execute in concurrent processes that read and update shared resources Requires coordination shared resources. Requires coordination  No global clock – makes coordination difficult (ordering of events)  Independent failure of components – “partial failure” & incomplete information  Unreliable communication – Loss of connection and messages. Message bit errors  Unsecure communication Frank Eliassen, Ifi/UiO 4 U secu e co u ca o – Possibility of unauthorised recording and modification of messages  Expensive communication – Communication between computers usually has less bandwidth, longer latency, and costs more, than between independent processes on the same computer
  • 3. 3 Goals of distributed systems  resource sharing the possibility of using available resources any where – the possibility of using available resources any where  openness – an open distributed system can be extended and improved incrementally – requires publication of component interfaces and standards protocols for accessing interfaces  scalability – the ability to serve more users, provide acceptable response Frank Eliassen, Ifi/UiO 5 y p p p times with increased amount of data  fault tolerance – maintain availability even when individual components fail  allow heterogeneity – network and hardware, operating system, programming languages, implementations by different developers Examples of distributed systems Web search Web search  Index the entire contents of the Web. Massively multiplayer online games  Very large number of users sharing a virtual world. Financial trading  Real time access and process of a wide rage of information sources. Frank Eliassen, Ifi/UiO 6
  • 4. 4 A distributed system organized as middleware  Layer of software offering a single-system view  Offers portability and interoperability  Offers portability and interoperability  Simplifies development of distributed applications and services Distributed applications and services Frank Eliassen, Ifi/UiO 7 DISTRIBUTION MIDDEWARE Platform Independent API Platform Dependent API . . . Local OS 1 Local OS 2 Local OS n - transaction oriented (ODTP XA) - message oriented(IBM MQSeries) - remote procedure call (X/Open DCE) - object-based (CORBA, COM, Java) Resource sharing  The opportunity to use available hardware, pp y , software or data anywhere in the system  Resource managers control access, offer a scheme for naming, and controls concurrency  A service is a software module that manages a collection of related resources and presents their functionality to users Frank Eliassen, Ifi/UiO 8 functionality to users.  A resource sharing model describes how  resources are made available  resources can be used  service provider and user interact with each other
  • 5. 5 Models for resource sharing  Client-server resource model  Server processes act as resource managers, and offer services (collection of procedures)  Client processes send requests to servers  (HTTP defines a client-server resource model)  Object-based resource model  Any entity in a process is modeled as an object with a message based interface that provides access to its operations Frank Eliassen, Ifi/UiO 9  Any shared resource is modeled as an object  Object based middlewares (CORBA, Java RMI) defines object- based resource models Scalability  A system is scalable if it remains effective when there is y a significant increase in the amount of resources (data) and number of users  Internet: number of users and services has grown enormously  Scalability denotes the ability of a system to handle an increasing future load  Requirements of scalability often leads to a distributed Frank Eliassen, Ifi/UiO 10  Requirements of scalability often leads to a distributed system architecture (several computers)
  • 6. 6 Scalability problems (1) Often caused by centralized solutions Frank Eliassen, Ifi/UiO 11 Scalability problems (2) Characteristics of decentralized algorithms:  No machine has complete information about  No machine has complete information about the system state.  Machines make decisions based only on local information.  Failure of one machine does not ruin the algo ithm Frank Eliassen, Ifi/UiO 12 algorithm.  There is no implicit assumption that a global clock exists.
  • 7. 7 Scaling techniques  Distribution  splitting a resource (such as data) into smaller parts, p g ( ) p , and spreading the parts across the system (cf DNS)  Replication  replicate resources (services, data) across the system  increases availability, helps to balance load  caching (special form of replication)  Hiding communication latencies Frank Eliassen, Ifi/UiO 13  Hiding communication latencies  avoid waiting for responses to remote service requests (use asynchronous communication or design to reduce the amount of remote requests) Failure handling  Hardware, software and network fail!!  DS must maintain availability even in cases where hardware/software/network have low reliability  Failures in distributed systems are partial  makes error handling particularly difficult  Many techniques for handling failures  Detecting failures (checksum a.o.) M ki f il ( i i i l ) Frank Eliassen, Ifi/UiO 14  Masking failures (retransmission in protocols)  Tolerating failures (as in web-browsers)  Recovery from failures (roll back)  Redundancy (replicate servers in failure-independent ways)
  • 8. 8 Example: Google File-System Early days… …today Challenges: - Scalability - Reliability - Performance Frank Eliassen, Ifi/UiO 15 Performance - Openness Distribution transparency An important goal of a distributed system An important goal of a distributed system is to hide the fact that its processes and resources are physically distributed across multiple computers A distributed system that is able to present lf d l f Frank Eliassen, Ifi/UiO 16 itself to its users and applications as if it were only a single computer system is said to be transparent
  • 9. 9 Transparency in a distributed system Frank Eliassen, Ifi/UiO 17 Different forms of transparency in a distributed system (ISO, 1995). Trade-off between degree of transparency and performance of a system Pitfalls when Developing Distributed Systems False assumptions made by first time p y developer:  The network is reliable.  The network is secure.  The network is homogeneous.  The topology does not change. L t i Frank Eliassen, Ifi/UiO 18  Latency is zero.  Bandwidth is infinite.  Transport cost is zero.  There is one administrator.
  • 10. 10 Quality of Service (QoS) Nonfunctional properties of the system: Nonfunctional properties of the system:  Reliability  Security  Performance (Responsiveness and throughput) Adaptability to meet changes is an important aspect of QoS Frank Eliassen, Ifi/UiO 19 Types of distributed system  Distributed Computing Systems  Used for high performance computing tasks Used for high performance computing tasks  Cluster and Cloud computing systems  Grid computing systems  Distributed Information Systems  Systems mainly for management and integration of business functions  Transaction processing systems Frank Eliassen, Ifi/UiO 20  Enterprise Application Integration  Distributed Pervasive (or Ubiquitous) Systems  Mobile and embedded systems  Home systems  Sensor networks
  • 11. 11 Cluster Computing Systems Collection of similar PCs, closely connected, all run same OS Frank Eliassen, Ifi/UiO 21 An example of a cluster computing system. Grid Computing Systems Federation of autonomous and heterogeneous computer systems (HW OS ) several adm domains computer systems (HW,OS,...), several adm domains Frank Eliassen, Ifi/UiO 22 A layered architecture for grid computing systems.
  • 12. 12 Enterprise Application Integration Allowing existing applications to directly exchange information using communication middleware information using communication middleware Frank Eliassen, Ifi/UiO 23 Middleware as a communication facilitator in enterprise application integration Example communcation middleware: CORBA Clients may invoke methods of remote objects without worrying about: bj t l ti i l Z foo() object location, programming language, operating system platform, communcation protocols or hardware. Different programming languages (or object models) X invoke Z’s method foo() Y Frank Eliassen, Ifi/UiO 24 IDL Object Request Broker (ORB) Common object model IDL IDL RMI over IIOP
  • 13. 13 Distributed Pervasive Systems Devices in distributed pervasive systems Devices in distributed pervasive systems discovers the environment and establishes themselves in this environment as best as possible.  Requirements for pervasive applications  Embrace contextual changes. Frank Eliassen, Ifi/UiO 25 Embrace contextual changes.  Encourage ad hoc and dynamic composition.  Recognize sharing as the default. QUA/MUSIC context-aware adaptation middleware for distributed pervasive systems http://www.euronews.net/2010/06/16/music-to-you-mobile-s-ears/ device user context environment context user context-aware, self-adaptive applications provided utility temperature light adapts optimizes monitors varying context 26 device context battery memory use CPU use position activity (e.g., driving) MUSIC Middleware http://ist-music.berlios.de/
  • 14. 14 Summary  Distributed systems:  components located in a network that communicates and p coordinates their actions exclusively by sending messages.  Consequences of distributed systems  Independent failure of components  Unsecure communication  No global clock  Distribution transparency: providing a single computer system view Frank Eliassen, Ifi/UiO 27 system view  Requirements like resource sharing, openness, scalability, fault tolerance and heterogeneity can be satisfied by distributed systems  Many pitfalls when developing distributed systems