System Models in Distributed Systems: Concepts & Design PDF

Slides for Chapter 2: System Models - Architectural Models… From Coulouris, Dollimore, Kindberg and Blair Distributed Systems: Concepts and Design Edition 5, © Addison-Wesley 2015  System Models The design of distributed systems can us...

Slides for Chapter 2: System Models - Architectural Models… From Coulouris, Dollimore, Kindberg and Blair Distributed Systems: Concepts and Design Edition 5, © Addison-Wesley 2015  System Models The design of distributed systems can usefully be described/discussed in terms of 3-Modles: Physical Model –Physical models consider the types of computers and devices that constitute a system and their interconnectivity, without details of specific technologies. Architectural Model –An architectural model of a DS is concerned with the placement of its parts & relationships b/w them. It describe a system in terms o f t h e c o m p u t a t io n a l a n d c o m m u n i c a t i o n t a s k s p e r f o r m e d b y i t s computational elements; the computational elements being individual computers or aggregates of them supported by appropriate network interconnections. Client-server and peer-to-peer are two of the most commonly used forms of architectural model for DS. Fundamental Model –take an abstract perspective in order to examine individual aspects of a DS: interaction models - which consider the structure and sequencing of the communication b/w the elements of system; failure models - which consider the ways in which a system may fail to operate correctly; security models - which consider how system is protected against attempts to interfere with its correct operation or to steal its data. Figure 2.1: Generations of distributed systems This table highlighting the significant challenges associated with contemporary (modern) distributed systems in terms of managing the levels of heterogeneity and providing key properties such as openness and quality of service  Figure 2.2: Communicating entities and communication paradigms Architectural Elements: to understand building blocks of a DS - What are the entities that are communicating in the DS? How do they communicate or what communication paradigm is used? What roles and responsibilities do they have in the overall architecture? Communicating entities - the entities that communicate in a DS are typically processes or nodes use of object-oriented approaches in DS, objects are introduced; or components or Web services Communication Paradigms - how entities communicate in DS  Communication Paradigms – how they communicate? Inter-process Communication– refers to the relatively low-level support for communication b/w processes in DS, including message-passing primitives, direct access to the API offered by Internet protocols (socket programming) and support for multicast communication. Remote Invocation– the calling of a remote operation, procedure or method; as request-reply using http (client-server); Remote procedure calls; Java RMI - a calling object can invoke a method in a remote object. Indirect Communication– group communication is delivery of messages to a set of recipients and hence is a multiparty communication paradigm supporting one-to-many communication; Distributed shared memory (DSM) provide a concept for sharing data b/w processes that do not share physical memory.  Client Server Architecture Client-Server– This is the architecture that is most often cited when DS are discussed, historically the most important, most widely employed Simple structure in which processes take on the roles of being clients or servers Client processes interact with individual server processes to access the shared resources Servers may in turn be clients of other servers Web server is often a client of local file server that manages files Web servers & most other Internet services are clients of the DNS service (also search engines - summaries of information available on web pages at sites throughout the Internet; called web crawlers) Search engine is both a server & a client: it responds to queries from browser clients and it runs web crawlers that act as clients of other web servers Figure 2.3 Clients invoke individual servers  Peer-to-Peer Architecture Peer-to-Peer– all of the processes involved in a task/activity play similar roles, interacting cooperatively as peers without any distinction b/w client & server processes. As client-server model offers a direct and relatively simple approach to sharing of data and other resources, but p2p scales poorly. A large number of data objects are shared, an individual computer holds only a small part of the application database & storage, processing & comm. loads for access to objects are distributed across many computers and network links. Each object is replicated in several computers to further distribute load & to provide resilience in the event of disconnection of individual computers. Placing individual objects & retrieve them & to maintain replicas amongst many computers, thus more complex than client- server architecture. Figure 2.4a Peer-to-peer architecture  Mapping of services to multiple servers Mapping of services to multiple servers– Services may be implemented as several server processes in separate host computers interacting as necessary to provide a service to client processes. The servers may partition the set of objects on which the service is based and distribute those objects between themselves, or they may maintain replicated copies of them on several hosts. The Web provides a common example of partitioned data in which each web server manages its own set of resources. A user can employ a browser to access a resource at any one of the servers. Figure 2.4b A service provided by multiple servers  Caching - Web proxy server Caching– A cache is a store of recently used data objects that is closer to one client. When an object is needed by a client process, the caching service first checks the cache & supplies the object from there if an up-to-date copy is available. If not, an up-to-date copy is fetched Caches may be co-located with each client or they may be located in a proxy server that can be shared by several clients The purpose of proxy servers is to increase the availability and performance of the service by reducing the load on the WAN and web servers. Proxy servers may be used to access remote web servers through a firewall Figure 2.5 Web proxy server  Web Applets – Mobile code & Mobile agents Web Applets– Applets are a well-known and widely used example of mobile code – the user running a browser selects a link to an applet whose code is stored on a web server; the code is downloaded to the browser and runs there (locally) – give good interactive response since it doesn't suffer from the delays or variability of bandwidth associated with network communication Each customer would have to download a special applet that receives updates from the broker’s server, displays them to the user Mobile code is a potential security threat to the local resources in the destination computer; therefore, browsers give applets limited access to local resources Figure 2.6 Web applets Figure 2.7 Software and hardware service layers in distributed systems Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.8 Two-tier and three-tier architectures Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 17 Figure 2.9 AJAX example: soccer score updates new Ajax.Request('scores.php? game=Arsenal:Liverpool’, {onSuccess: updateScore}); function updateScore(request) {..... ( request contains the state of the Ajax request including the returned result. The result is parsed to obtain some text giving the score, which is used to update the relevant portion of the current page.)..... } 18 Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.10 Thin clients and compute servers Compute server Network computer or PC Thin network Application Client Process Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.11 The web service architectural pattern Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 20 Figure 2.12 Categories of middleware Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 21 Figure 2.13 Real-time ordering of events Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.14 Processes and channels Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.15 Omission and arbitrary failures Class of failure AffectsDescription Fail-stop Process Process halts and remains halted. Other processes may detect this state. Crash Process Process halts and remains halted. Other processes may not be able to detect this state. Omission Channel A message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer. Send-omission Process A process completes a send, but the message is not put in its outgoing message buffer. Receive-omission Process A message is put in a process’s incoming message buffer, but that process does not receive it. Arbitrary Process or Process/channel exhibits arbitrary behaviour: it may (Byzantine) channel send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step. Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.11 Timing failures Class of Failure Affects Description Clock Process Process’s local clock exceeds the bounds on its rate of drift from real time. Performance Process Process exceeds the bounds on the interval between two steps. Performance Channel A message’s transmission takes longer than the stated bound. Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.17 Objects and principals Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.18 The enemy Copy of m The enemy m’ Process p m Process q Communication channel Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 Figure 2.19 Secure channels Principal A Principal B Process p Secure channel Process q Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012