Distributed Architectures

Lecture 1 : Models of Distributed Systems

Distributed Architectures

Examples of Distributed Systems

Most popular is the Internet, which is used for applications such as WWW, E-Mail, FTP, and Telnet Intranets
calendars, etc.

May be connected to the Internet, or could be closed, or disconnected. Applications include enterprise human resource portals, collaboration, Laptops, PDAs/Handhelds, wearable devices, embedded devices National Oceanic Atmospheric Association (NOAA) uses Linux cluster for
weather mapping applications Search for Extraterrestrial Intelligence Institute (SETI) leverages unused processing power of your home PC to process data collected from space to locate alien life forms

Mobile Computing Networks Computing Clusters

2005 Thom Anderson

Distributed Architectures

Consequences of Distributed Systems Concurrency p and q are concurrent if either p can happen before q, or q can happen before p, thus having interleaving semantics

Language Parallel: Threads in the BEGIN_PARALLEL and END_PARALLEL block

begin at the same time x=1 y=2 BEGIN_PARALLEL x=x+y print x END_PARALLEL What is the result of this code? What system properties can alter the result of this code? When the completion p and q is unpredictable, this is known as a race condition Synchronization and Coordination are handled by passing messages Potential problems are deadlocks and starvation

2005 Thom Anderson

Distributed Architectures

Consequences of DS (Continued)
No global clock, no global state Not possible to synchronize many computers on a network and guarantee synchronization over time, thus events are logically ordered. Not possible to have a process that can be aware of a single global state. Independent Failures Running processes may be unaware of other failures within context Failed processes may go undetected Both are due to processes running in isolation

2005 Thom Anderson

Distributed Architectures

Reasons for DS
Resource Sharing Hardware Distributing CPU power Sharing storage drives Sharing printers Network Sharing home DSL line across multiple computers Computers on a MAN sharing an OC-48 to connect to a WAN Software Sharing a database server with multiple client applications File Sharing Video and Audio Video On Demand (VOD) Digital Telephony and Voice Mail
2005 Thom Anderson 5

Distributed Architectures

Reasons for DS (continued)

Functional Distribution Separating clients from servers Web browsers from web servers Web servers from database servers Load Distribution Load balancing clusters Physical Separation Connecting multiple locations of an enterprise to single data points Distributing a web infrastructure across multiple WAN segments for improved reliability Economics Leveraging many cheaper systems provides better price to performance rather than buying large mainframes Linux Beowulf Cluster vs. Super Computer
2005 Thom Anderson 6

Distributed Architectures

Design Challenges Heterogeneity of Resources Networks (AppleTalk, Token Ring, Ethernet, etc.) Hardware (RISC vs, CISC) Example: if you compile a C++ program for Solaris Intel-based, it is not portable for Solaris SPARC-based OS (UNIX and its many flavors, Windows, Linux, BEOS, etc.) IPC issues File sharing issues Printer sharing issues Programming Languages (Java, C/C++/C#, Perl, Python, LISP, etc.) Implementation Strategies Integrating a .NET application to a J2EE application can pose its difficulties Integrating a WebSphere based J2EE application to an iPlanet based J2EE application can also pose difficulties!

2005 Thom Anderson

Distributed Architectures

Challenges (continued) Openness Published Applications Programming Interface (API) Standards Compliance Security Types Confidentiality Integrity Availability Non-Repudiation, prevalent in commerce applications Authentication and Authorization Scalability Physical resources Performance Prevent resource loss Bottlenecks Domain Name Server (DNS) example (see textbook) Caching/Replication

2005 Thom Anderson

Distributed Architectures

Challenges (continued) Failure Handling Detection e.g. checksums Some errors are undetectable, such as in the case of Asynchronous messages Masking failures Retransmission Striping Tolerance by means of meaningful action Transaction rollbacks Redundancy Multiple pathways DNS example Database replication Web clustering Linux Beowulf cluster

2005 Thom Anderson

Distributed Architectures

Challenges (continued) Concurrency Session management Resource management Locking Transparency Hiding it all from the users ISOs Reference Model for Open Distributed Processing identifies the following 8 forms of transparency Access (remote and local access are the same) Location (dont care about where resources are) Concurrency (share resources fairly) Replication (dont care which replicated resource is being used) Failure (hide faults from applications and users) Mobility (move resources without affecting users) Performance (adapt to load changes) Scaling (expand capability, leave logic alone)

2005 Thom Anderson

10

Distributed Architectures

Architectural Models Paradigms Layers Client Server Software Layers Breaking up the complexity of systems by designing them through layers and services layer: group of closely related and highly coherent functionalities service: functionality provided to a superior layer Examples of layered architectures Operating systems (kernel, drivers, windows, processes) Computer Network Protocols

2005 Thom Anderson

11

Distributed Architectures

Architectural Models (continued) Software Layers (continued) Platform combines hardware with operating system Windows/CISC (Intel) Solaris/RISC (Sparc) Solaris/CISC (Intel) Middleware Goal: To achieve communication and resource sharing For example, by remote method invocation Examples of Middleware CORBA, by OMG DCOM, by Microsoft Java RMI, by Sun

2005 Thom Anderson

12

Distributed Architectures

Architectural Models (continued) System Architecture Client Server Model and Variations Server is a process; Client is a process Clients invoke servers, servers send results to clients Servers can be clients of other Servers HTTP (Web) Server is a server process to its client processes (web browsers) HTTP Server may be a client of a database server Service may be provided by multiple servers, as is most often the case within a large enterprise Cache is a repository of recently accessed objects (files, graphics) that is physically closer to the client than the server from which it originated Proxy server sits in between clients and servers and can play many mitigation roles Maintain cache Firewall Restrict site access

2005 Thom Anderson

13

Distributed Architectures

Architectural models (continued) System Architecture (continued) Client Server Model and Variations (continued) Java Applets Mobile Agents Thin Clients Network Computers Web Browsers Mobile device discovery Peer to Peer Services Do not require a server process More interesting architecture than client/server over the Internet

2005 Thom Anderson

14

Distributed Architectures

Architectural Models (continued) Objects and Interfaces The concept of a contract or stub (Interface definition) Separation of Interface from Implementation Review of Objects, Classes, Interfaces, and Implementations Object is the cookie, Class is the cookie-cutter 3 Properties of Object Oriented Programming Inheritance Polymorphism Data Encapsulation Interfaces are only stubs or contracts No actual coded logic, Provides method signatures only Implementations code interface logic Interfaces defer actual work to the implementation Adapter Pattern: It is not necessary to implement every method of an interface Abstract Classes Can implement certain methods, and defer functionality to subclasses

2005 Thom Anderson

15

Distributed Architectures

Architectural Models (continued) Design Requirements Performance Responsiveness is the speed and consistency of a servers or a services response to its clients Throughput is computational speed in general, and computational speed over software layers in the server and client in specific Quality of Service (QoS) Reliability maps to the failure model (2.3.2) Security maps to the security model (2.3.3) Performance maps to interaction model (2.3.1) Adaptability: Mothers Day example Dependability Fault tolerance measures the probability of a system to function in the presence of software, hardware, and network failure Security requirements vary greatly the DoD emphasizes confidentiality and integrity, whereas amazon.com emphasize availability and nonrepudiation

2005 Thom Anderson

16

Distributed Architectures

Fundamental Models Interaction Model Distributed System Multiple processes Communication channels Distributed Algorithm Steps to be taken by each process Communication between processes Synchronization Data flow Communication Channel Performance Characteristics Latency is the delay between sending and receiving a message Bandwidth is the amount of information transmitted over time Jitter is the variation in the time taken to deliver messages Video frames in an ATM network

2005 Thom Anderson

17

Distributed Architectures

Fundamental Models (continued) Interaction Model (continued) Clocks Each computer has a clock Clock drift rate makes it impossible to synchronize without communication Synchronous DS time to execute each step of computation within a process has known lower and upper bounds message delivery times are bounded to a known value each process has a clock whose drift rate from real time is bounded by a known value Easy to handle, hard to find bounds Asynchronous DS exhibit no bounds on Process execution speeds Message transmission delay Clock drift rates Internet is asynchronous QoS requirements can be heavily affected
2005 Thom Anderson 18

Distributed Architectures

Fundamental Models (continued) Interaction Model (continued) Event ordering provides a synchronization model We will come back to this later Failure Model Omission Failures Process Omission Failures Process has crashed Can be detected using timeouts Fail-stop process crash is one that can be detected with certainty by other processes Guaranteed message delivery example Communication Omission Failures Message is not being delivered Network error or outage Overflow in the incoming message buffer
2005 Thom Anderson 19

Distributed Architectures

Failure Model (continued) Arbitrary Failures (Byzantine failures) Worst case scenario Process Arbitrary Failure Arbitrary omission or execution of steps Channel Arbitrary Failure Non-delivery, corruption, or duplication of a message Timing Failures Process Timing Failure Synchronous DS Processs local clock drifts beyond bounds (Clock failure) Process exceeds interval bound between sequential steps (Performance) Channel Timing Failure Message transmission takes longer than bound (Performance)

2005 Thom Anderson

20

Distributed Architectures

Security Model Protect access to object Authentication (username/password) Kerberos example Authorization (Access Control Lists ACLs) Protecting messages and interactions Authenticated messages Secure channels Countermeasures Firewalls IP Filtering Network Address Translation (NAT) Cryptography Sharing a secret key Public Key Infrastructure Secure Channel Secure Socket Layers Virtual Private Networks

2005 Thom Anderson

21