Software Engineering of Distributed Systems - PowerPoint PPT Presentation

Software Engineering of Distributed Systems

University of Colorado

Boulder

ECEN5053

• Introductions
• http://ece.colorado.edu/~swengctf
• http://ece.colorado.edu/~swengctf/distributed
• Format
• Calendar
• Exams -- final exam only
• Homework -- in teams of 2 to 3
• Phone number for late arrival
• Contact information
• Text web site: www.cdk3.net -- see key pts.

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Definition of distributed systems
• Purposes
• Demands/challenges
• Hardware concepts
• Software concepts
• An example model

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• A distributed system is a collection of independent computers that appears to its users as a single coherent system. Andrew Tanenbaum
• A distributed system is one in which components located at networked computers communicate and coordinate their actions only by passing messages. Coulouris et al (your text)
• concurrency of components
• lack of a global clock
• independent failures of components

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• “You know you have one when the crash of a computer you’ve never heard of stops you from getting any work done.” Leslie Lamport

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Computer heterogeneity & the user
• Communication paths from user’s perspective
• User interaction with system from various locations
• User interaction with applications
• Scalability
• Availability
• Addition or temporary removal of certain components

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• internet --
• Not quite there -- some internet applications more so than others
• Some applications, user must be very aware of which computer is being accessed
• and what else?

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

1945

~1985

powerful microprocessors

mainframes

high speed networks

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Take an historical view
• 1945 - 1985
• Computers are large & expensive
• Most organizations had only a few
• lacked a way to connect them
• operated independently from one another
• By mid-80’s ... powerfulmicroprocessors with power of a then-contemporary mainframe
• High speed networks!
• Result: Easy to combine large numbers of computers via a high-speed network.

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Easily connect users to remote resources
• Share resources with remote users in a controlled way
• Hide the fact that the resources are physically distributed over a network -- transparency
• Should be an open system
• Offers services by standard rules that describe the syntax and semantics of those services
• Should be scalable
• size, geography, and administration

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Why share?
• economics
• ease of collaboration -- virtual organizations
• ease of info exchange
• commerce
• Connectivity and sharing lead to security issues
• Currently, inadequate protection

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Hiding all distribution aspects not always good idea
• Some times desirable to remain fixed
• Messages between processes that are thousands of miles apart will take hundreds of milliseconds
• Trade-off between high degreeof transparency and performance -- why?
• The degree of desirable transparency should be considered in context with other issues such as performance and cost

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Offers services according to standard rules describing syntax and semantics of the services.
• Rules are formalized in protocols
• Services generally specified through interfaces
• using Interface Definition Language (IDL)
• specify syntax only
• natural language used to describe semantics
• allows arbitrary process that needs an interface to talk to another process that provides it
• proper interfaces are complete and neutral

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Interoperability and portability
• completeness and neutrality are prerequisites
• Flexible
• easy to configure the system out of different components from different developers
• easy to add new components without impact
• easy to replace existing ones without impact
• i.e. extensible
• easier said than done

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• System must be organized as a collection of relatively small and easily replaceable or adaptable components
• Need for change: component does not provide optimal policy for a specific user or app
• Example: differing caching policies
• Need to be able to separate policy & mechanism

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Size
• Limitations of centralized services, data, and algorithms -- become bottleneck
• Unlimited processing power and storage cannot overcome communication limitations
• Decentralization introduces some kinds of uncertainty

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Existing distributed systems designed for LANs are based on synchronous communication
• Communication in WANs is inherently unreliable and almost always point-to-point
• LANs provide reliable comm based on broadcasting -- WAN needs special location services
• Centralized components prevent geographic scale

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• How to scale across multiple independent administrative domains
• Conflicting policies
• usage (payment)
• management
• security
• protect against malice from the new domains
• protect against malice from the distributed system -- e.g. downloaded programs

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Scalability problems appear as performance ones
• hide communication latencies
• avoid waiting for responses as much as possible
• i.e. construct the requestor to use asynchronous comm as much as possible
• reduce overall communication
• distribution -- spreading component parts across the system, e.g. DNS (see next slide)
• replication across the distributed system
• increases availability (helps hide latency)
• helps balance the load between components

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

Generic

Countries

int

com

edu

gov

mil

org

...

Z1

colorado

Z2

cs ece ...

Z3

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Definition
• Purposes
• Demands/challenges
• Hardware concepts
• Software concepts
• An example model

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Introduction to how distributed systems can be organized
• how they are interconnected
• how they communicate

Memory

Interconnection

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Multiprocessors (not multicomputers)
• Single physical address space shared by all CPUs
• CPU A writes 37 to address 1000
• CPU B then reads from address 1000 and gets 37
• e.g., multiple processors on a board with shared memory
• Multicomputers
• Every machine has its own private memory
• CPU A writes 37 to its address 1000
• CPU B reads from its address 1000 and gets whatever happens to be there; not affected by the other write
• For example, PCs connected by a network

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Bus architecture of the interconnection network
• single network, backplane, bus, cable or other medium that connects all the machines
• For example, cable television
• Switched architecture
• Individual wires from machine to machine with many different wiring patterns in use
• Msgs move along wires with an explicit switching decision made at each step to route the message along one of the outgoing wires.
• e.g., worldwide public telephone system

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Performance Impacts
• bus, shared memory
• switched, shared memory
• not quite shared memory
• homogeneous multicomputers
• private memory, bus-based network
• private memory, switch-based network
• heterogeneous multicomputer systems

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Bus-based multiprocessor, shared memory
• Coherent memory
• Bus contention
• If cache memory for each CPU has a high hit rate, bus traffic drops dramatically
• but introduces serious problem -- what is it?
• Caching and memory coherence is an issue for distributed systems
• Limited scalability

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• 1. Divide memory into modules; connect them to CPU’s with a matrix of switches called a crossbar switch
• Allows multiple CPU’s to access shared memory simultaneously
• One still has to wait if both want to access same module
• 2. Network of switches to route any input to any output
• May be several switching stages in-between
• Need extremely fast switching to reduce latency=$$

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Reduce cost of switching with hierarchical system
• SOME memory associated with each CPU (not shared)
• Access to own local memory is quick
• Accessing anybody else’s memory is available but slower
• NUMA - “Non Uniform Memory Access”
• better average access times than switched nw’s
• what’s the problem?

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• System of individual computers. Therefore...
• Each CPU has direct connection to its own local memory
• Challenges surround communication between the CPUs
• Traffic volume will be orders of magnitude lower than when interconnection network is also used for CPU-to-memory traffic

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Processors connected thru shared multiaccess network such as Fast Ethernet
• Limited scalability -- performance degrades with 25-100 nodes depending on amt of communication

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Messages are routed through an interconnection network instead of broadcast as in bus-based
• Interconnection networks vary
• Grid -- suitable to 2-dimensional problems
• Hypercube -- n-dimensional cube
• MPPs - massively parallel processors (1000’s)
• high-performance proprietary interconnection network designed for low latency, high bandwidth
• COWs - clusters of workstations
• Std wkstns connected by off-the-shelf communication components; no special measures for high bandwidth or reliability --> ??

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Most distributed systems are these
• Computers are heterogeneous w.r.t. processor type, memory size, I/O bandwidth, etc.
• Interconnection networks can be heterogeneous, too
• Many large-scale heterogeneous multicomputers lack a global system view
• cannot assume same performance or services are available everywhere
• THEREFORE sophisticated software is needed
• shield application developers from what is going on at hardware level (transparency)

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Distributed systems software
• acts as resource manager(s) for the underlying hardware
• Hide intricacies and heterogeneity of underlying hardware
• The issues that this software faces are the core of distributed systems principles we will study this semester

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Distributed operating system:
• Not intended to handle a collection of independent computers
• Network operating system:
• Does not provide a view of a single coherent system
• “true” distributed system
• Goal: scalability and openness of network o.s. andtransparency and ease of use of distributed o.s.
• Additional layer called middleware

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• A particular paradigm is a set of decisions about how to describe distribution and communication
• Distributed file systems
• Remote procedure calls
• Distributed objects
• Distributed documents
• See table

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Communication
• Processes & their synchronization
• Processes & their interaction
• Naming
• Consistency and replication
• Fault tolerance
• Security

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction

• Requirements specification of these issues in distributed systems -- how to recognize, analyze, specify, trace, and manage
• Design -- how to choose, represent, and verify
• Implementation -- tools, language support
• Testing -- static and dynamic

University of Colorado ECEN5053 Software Engineering of Distributed Systems Week 1 Introduction