Distributed Systems: Concepts, Fundamental Problems, and Models, Study notes of Computer Science

Download Distributed Systems: Concepts, Fundamental Problems, and Models and more Study notes Computer Science in PDF only on Docsity! Lecture 1 introduction: systems, fundamental problems, and models distributed systems CS425 / ECE 428 / CSE 424 acknowledgment These slides are based on ideas and material from the following sources: • slides prepared by Professors M. T. Harandi and J. Hou and subsequently  modified by Professors Indranil Gupta, Nitin Vaidya, and Yih‐Chun Hu at  University of Illinois • slides from Professor S. Ghosh’s course at University of Iowa 1. the Internet *y Uurehycheawok map o1 Ihe Rtemet - ON FASS hupewwrw eheswick.commeanfnecr on ‘showing Un nner ISPS, Dalit colecto 28 Je 1999 kc ‘Copyright (C) 1898, Licant Technologies Internet Mapping Project, color coded by ISPs 1. the Internet intranet ISP desktop: backbone satellite link server: network link: a typical Intranet the rest of email server Web server Desktop computers File server router/firewall print and other servers other servers print Local area network email server the Internet 4. distributed mobile robots si Kiva robot 500 robots coordinate to manage inventory in a warehouse http://www. raffaello.name/KivaSystems.html 5. computation grids • Seti@Home • uses Internet‐connected  computers in the Search for  Extraterrestrial Intelligence  • downloads and analyzes  radio  telescope data on your desktop  and sends it back to Seti servers • http://setiathome.berkeley.edu/ why distributed systems ? * geographic distribution of processes * resource sharing (as used in P2P networks) * computation speed up (as in a grid) e fault tolerance CS 425 CS 425 is an introduction to the key concepts for — designing — analyzing and — implementing distributed systems key issues in design fundamental problems in  distributed systems • time synchronization • leader election • mutual exclusion • distributed snapshot • routing • consensus • replica management • transactions we will study algorithms (and lower bounds) for these  types of problems approaching  implementations the rest of email server Web server Desktop computers File server router/firewall print and other servers other servers print Local area network email server the Internet implementation • in implementing a distributed systems we have to first know the nature of  the underlying computing and networking infrastructure • what can we assume?  – how large are the message delays and latencies ? – are processor clocks synchronized ? – do processors and links fail ? – could processes become malicious ?  – are channels secure from eavesdropping and corruption ?  – what are the allowed primitive HW/OS operations ? (e.g. atomic broadcast)  • different answers to these questions give rise to a different model for a  distributed system • we will study the algorithms for the fundamental problems in the context of  certain models a reliable FIFO channel Axiom 1. Message m sent ⇔ message m received Axiom 2. Message propagation delay is arbitrary but finite. Axiom 3. m1 sent before m2 ⇒ m1 received before m2. P Q shared memory model address spaces of processes overlap M1 1 3 2 4 M2 concurrent operations on a shared variable are serialized modeling wireless networks • communication via broadcast • limited range • dynamic topology • collision of broadcasts  (handled by CSMA/CA) 0 1 2 3 4 5 6 0 1 2 3 4 5 6 (a) (b) RTS RTS CTS model transformation Stronger models ‐ simplify reasoning, but  ‐ needs extra work to  implement Weaker models ‐ are easier to implement.  ‐ have a closer relationship  with the real world “Can model X be implemented  using model Y?” is an  interesting question in  computer science. Sample problems non‐FIFO to FIFO channel Message passing to shared  memory from non-FIFO to FIFO channel ? Cr) m2 m3 m4 mi Ce} buffer typical design goals • heterogeneity – can the system handle different types of PCs and  devices? • robustness – is the system resilient to crashes and failures? • availability – are data, services always there? • transparency – does the system hide internal workings from the  users? • concurrency – can the server handle multiple clients simultaneously? • efficiency – is it fast enough? • scalability – can it handle 100 million nodes? • security – can the system withstand hacker attacks? • openness – is the system extensible? Heterogeneity • Variety and differences among: – Networks  – Hardware and Operating Systems  – Programming Languages – Implementations • Middleware – a software layer that provides a programming  abstraction as well as  – (i) masking the heterogeneity of the underlying networks, hardware,  operating systems and programming languages. – (ii) providing uniform computational models, e.g., remote object invocation, remote event notification. • Virtual machine – The compiler for a particular language generates code for a virtual  machine, instead of a particular hardware code to assist execution of  mobile code. Openness • Degree to which new resource‐sharing services  can be added & used. • Requires publication of interfaces for access to  shared resources • Requires uniform communicationmechanism • Conformance of each component  to the  published standard must be tested and verified Security • Security has three components: – Confidentiality (protection against disclosure to unauthorized  individuals). – Integrity (protection against alternation or corruption). – Availability (protection against interference with the means to  access the resources). • Two security challenges: – Denial of service attacks: bombarding the service with a large  number of pointless requests. – Mobile code security:  mobile codes may be accessing local  resources. Concurrency • Is a problem when two or more users  access to the same resource by two at the  same time – Each resource is encapsulated as an  object and invocations are executed in  concurrent  threads – Concurrency can be maintained by use  of semaphores and other mutual  exclusion mechanisms. Transparency • Concealment of the separation of components from  users: – Access transparency: local and remote resources can be accessed using identical operations. – Location transparency: resources can be accessed without  knowing their whereabouts. – Concurrency transparency: processes can operate concurrently  using shared resources without interferences. – Failure transparency: faults can be concealed from  users/applications. – Mobility transparency: resources/users can move within a  system without affecting their operations. – Performance transparency: system can be reconfigured to  improve the performance. – Scaling transparency: system can be expanded in scale without  change to the applications. Transparency Distributed file system allows access transparency and location transparency. URLs are location transparent, but are not mobility- transparent (someone’s personal web page cannot move to anew place and still be accessed using the same URL). Message retransmission governed by TCP is a mechanism for providing failure transparency. Mobile phone is an example of mobility transparency.