Chapter 2 ARCHITECTURES Software architectures and System architectures

Chapter 2: ARCHITECTURES Software architectures and System architectures Logical organization and Physical realization Thanks to the authors of the textbook [TS] for providing the base slides. I made several changes/additions. These slides may incorporate materials kindly provided by Prof. Dakai Zhu. So I would like to thank him, too. Turgay Korkmaz korkmaz@cs. utsa. edu Distributed Systems 1. 1 TS

Chapter 2: ARCHITECTURES n ARCHITECTURAL STYLES (SOFTWARE ARCHITECTURES) n SYSTEM ARCHITECTURES 4 Centralized Architectures 4 Decentralized Architectures 4 Hybrid Architectures n ARCHITECTURES VERSUS MIDDLEWARE 4 Interceptors 4 General Approaches to Adaptive Software n SELF-MANAGEMENT IN DISTRIBUTED SYSTEMS 4 The Feedback Control Model 4 Example: Systems Monitoring with Astrolabe 4 Example: Differentiating Replication Strategies in Globule Distributed Systems 1. 2 TS

Objectives n To learn how to organize a distributed system whose components are dispersed across multiple machines n To understand the differences between l software architecture (logical organization) and l system architecture (physical realization) n To understand trade-offs when providing distribution transparency n To understand adaptability and self-mng issues and mechanisms for flexibility and efficiency Distributed Systems 1. 3 TS

Software Architecture (Architectural Style, Logical organization) n Divide the system into logically different software components, distribute them over multiple machines, and allow them to communicate through connectors Component: a modular unit with well-defined required and provided interfaces, l Connector: a mechanism that mediates communication, coordination, and l cooperation (e. g. , RPC, msg passing) n Using components and connectors, we can create different configurations, which are classified into the following architectural styles: Layered l Object-based l Event-based l Data-centered l Distributed Systems All try to achieve distributed transparency at a reasonable level and Each style would be more appropriate for a different application 1. 4 TS

Software Architecture (Architectural Style, Logical organization) n Layered style l used for client-server systems, request/reply model n Object-based l Used for distributed object systems, request/reply model n Event-based: Publish/subscribe systems l Loosely coupled components l (processes do 4 decoupled in space or referentially decoupled not need to refer to each other) n Data-centered: l Communicate through common repository (e. g. , shared distributed file system) l Can be combined with event-based, yielding shared dataspace (processes do not need to be 4 processes are now decoupled in space and time active at the same time) 1. 5 Distributed Systems TS

System Architecture (Physical realization) n Consider how and where to place software components and realize their interactions n There are three major physical realization approaches: Centralized l Decentralized l Hybrid: l Distributed Systems client-server P 2 P (Structured vs. unstructured) combination of centralized and P 2 P 1. 6 TS

System Architecture: Client-Server n There are processes offering services (servers) n There are processes that use services (clients) n Clients and servers can be on different machines n Clients follow request/reply model to use services n Connection-oriented vs. connectionless (most use TCP vs UDP) Distributed Systems 1. 7 TS

Application Layering (logical) How to draw a clear line between client end server? n User-interface layer l units for an application’s user interface n Processing layer: l functions of an application, i. e. without specific data n Data layer: l data that a client wants to manipulate through the application components Observation: layering is found in many distributed information systems, using traditional database technology and accompanying applications. Distributed Systems 1. 8 TS

Multitiered Architectures (physical realization) How to place three layers on client and server? Vertical distribution Single-tiered: dumb terminal/mainframe configuration Two-tiered: client/single-server configuration Thin client Distributed Systems Fat client 1. 9 TS

Multitiered Architectures (physical realization) n The server part could be distributed over multiple machines, n Three-tiered: each layer on separate machine Distributed Systems 1. 10 TS

Decentralized Architectures: P 2 P Systems n P 2 P architectures do n Multitiered architectures do horizontal distribution: n We split up clients and servers into logically equivalent parts and let (i. e. , user interface, processing, data) on different machines each part operate on its own share n Processes are not equal and Interactions are asymmetric n Processes are equal and l One acts as client while the Interactions are symmetric vertical distribution: n We place logically different components in client-server other acts as server l n Traditional approach Each acts as both client and server n Tremendous growth in the last couple of years Distributed Systems 1. 11 TS

Decentralized Architectures: P 2 P Systems Star War Peer 2 Peer 1 Application Peer 3 Sharable objects The Beatles Application Peer 4 Application Peers 5. . N Roman Holiday Distributed Systems 1. 12 TS

Decentralized Architectures: P 2 P Systems n Given the symmetric behavior, the key question is how to organize processes in an overlay network, where links are usually TCP channels… n How about fully connected overlay network? -/+ n There are three approaches to organize nodes into overlay networks through which data is routed l Structured P 2 P: nodes are organized following a specific distributed data structure and deterministic algorithms l Unstructured P 2 P: randomly selected neighbors l Hybrid P 2 P: some nodes are appointed special functions in a well-organized fashion Distributed Systems 1. 13 TS

Structured P 2 P Systems n Distributed Hash Table (DHT) is the most used one l l l Assume we have a large ID space (e. g. , 128 -bit) Assign random keys from to data items Assign random identifiers from to nodes The crux of every DHT is to implement an efficient and deterministic scheme that maps the key of a data item to node ID When looking up a data item, the system should route the request to the associated node and return the network address of that node n Example: Chord Distributed Systems 1. 14 TS

A DHT Example: Chord n Chord organizes the nodes in a structured overlay network such as a logical ring, and data item with key k is mapped to a node with the smallest ID >= k. n This node is called as the successor of key k and denoted by succ(k) LOOKUP(key=8) ? This should return succ(8) which is node 12. (Details of how this is done is in Ch 5) Distributed Systems 1. 15 TS

A DHT Example: Chord n Membership management l Join l Leave n Lookup(key) (search and routing is in Ch 5) Distributed Systems 1. 16 TS

Another DHT Example: CAN n Content Addressable Network n Organize nodes in a d- dimensional space and let every node take the responsibility for data in a specific region. n When a node joins, split a region. n When a node leaves, merge regions. Distributed Systems 1. 17 TS

Unstructured P 2 P Systems Peer 2 n Maintain a random graph n Data items are randomly Peer 1 Peer 3 Sharable objects Application placed on nodes Peer 4 Application n How to do Lookup? l Application Peers 5. . N flooding n Membership management l Join 4 Get a random list (from a well-known list or server) 4 Contact these nodes and run the algorithm presented next l Leave 4 Easy Distributed Systems just leave… 1. 18 TS

How to maintain random graph n Let each peer maintain a partial view of the network, consisting of c other nodes n Each node P periodically selects a node Q from its partial view n P and Q exchange information and exchange members from their respective partial views Distributed Systems 1. 19 TS

Superpeers n When random graph gets bigger, it will be very hard to perform look up n Use supperpeers to maintain an index n Join/leave is easy n How about Lookup? n Regular peers may elect the supperpeer (Ch 6) Distributed Systems 1. 20 TS

Hybrid Architectures: Edge-server systems n Content Distribution Network (CDN) n Edge servers can be used to optimize content distribution Distributed Systems 1. 21 TS

Hybrid Architectures: Collaborative Distributed Systems n Combining a P 2 P with a client-server architecture n Basic idea: a node identifies where to download a file from and joins a swarm of downloaders; who get file chunks in parallel from the source, and distribute these chunks amongst each other Distributed Systems 1. 22 TS

WHERE MIDDLEWARE FITS IN ALL THESE ARCHITECTURES? Distributed Systems 1. 23 TS

Architectures Vs. Middleware n Middleware is between application and local OS and provides some degree of transparency n In practice, middleware systems follow a specific architectural style (software architecture, logical organization): l l Layered Object-based Data centered Event-based n Adv/Dis. Adv + makes app design simple l - may not be optimized for what an app needs l - adding more features complicates the middleware l 4 CORBA was initially object-based, later added msg passing n Middleware should be adaptable to applications l Several different versions, configurable, separate policy and mechanisms Distributed Systems 1. 24 TS

How to achieve adaptability? n Interceptors: a software construct that will break the usual flow of control and allow other (app specific) code to be executed Distributed Systems 1. 25 TS

General Approaches to Adaptive Software n In many cases, distributed systems/applications are developed according to a specific architectural style. The chosen style may not be optimal in all cases Then there is a need to (dynamically) adapt the behavior of the middleware. n Three basic approaches to adaptive software: l Separation of concerns: 4 l Computational reflection: 4 l Try to separate extra functionalities and later glue them together into a single implementation aspect-oriented SW , only toy examples so far. Let a program inspect itself at runtime and adapt/change its settings dynamically if necessary mostly at language level and applicability unclear. Component-based design: 4 Organize a distributed application through components that can be dynamically replaced when needed (complex for DS, components are not independent) n Do we really need adaptive software or adaptive system that reacts to changes (self-management) Distributed Systems 1. 26 TS

Do we really need adaptive software? n Software should expect all the environment changes and should have code in it to handle them n DS should be able to react to changes in environment by switching policies or mechanisms in the system n The challenge is how to achieve this reactive behavior without human intervention Distributed Systems 1. 27 TS

Self-managing Distributed Systems n Distinction between system and software architectures blurs when automatic adaptivity needs to be taken into account: n Self-configuration n Self-managing n Self-healing n Self-optimizing Warning There is a lot of hype going on in this field of autonomic computing. n Self-* Distributed Systems 1. 28 TS

Feedback Control Model n In many cases, self-* systems use a feedback ion d ! t w iza te e i v eal ribu l ica al r dist g Lo ysic be Ph ight m control loop. Distributed Systems 1. 29 TS

if time permits FEEDBACK CONTROL EXAMPLES Distributed Systems 1. 30 TS

Example: Systems Monitoring with Astrolab A general tool for observing system behavior Organize hosts into a hierarchy of zones. Collect information about each host and summarize it, Exchange this information so all agents will see the same view. Distributed Systems 1. 31 TS

Example: Differentiating Replication Strategies in Globule (1) n A collaborative CDN tries to minimize performance by replicating web pages. Distributed Systems 1. 32 TS

Example: Differentiating Replication Strategies in Globule (2) n Figure 2 -19. The dependency between prediction accuracy and trace length. Analogous to predicting weather for tomorrow Distributed Systems 1. 33 TS

Example: Automatic Component Repair Management in Jade n Steps required in a repair procedure: • Terminate every binding between a component on a nonfaulty node, and a component on the node that just failed. • Request the node manager to start and add a new node to the domain. • Configure the new node with exactly the same components as those on the crashed node. • Re-establish all the bindings that were previously terminated. Distributed Systems 1. 34 TS