Approche Algorithmique des Syst` emes Distribu es (AASR) - - PowerPoint PPT Presentation

approche algorithmique des syst emes distribu es aasr
SMART_READER_LITE
LIVE PREVIEW

Approche Algorithmique des Syst` emes Distribu es (AASR) - - PowerPoint PPT Presentation

Approche Algorithmique des Syst` emes Distribu es (AASR) Guillaume Pierre guillaume.pierre@irisa.fr Dapr` es un jeu de transparents de Maarten van Steen VU Amsterdam, Dept. Computer Science 02: Architectures Contents Chapter 01:


slide-1
SLIDE 1

Approche Algorithmique des Syst` emes Distribu´ es (AASR)

Guillaume Pierre

guillaume.pierre@irisa.fr

D’apr` es un jeu de transparents de Maarten van Steen VU Amsterdam, Dept. Computer Science

02: Architectures

slide-2
SLIDE 2

Contents

Chapter 01: Introduction 02: Architectures 03: Processes 04: Communication 05: Naming 06: Synchronization 07: Consistency & Replication 08: Fault Tolerance 09: Security

2 / 42

slide-3
SLIDE 3

Architectures

Architectural styles Software architectures Architectures versus middleware Self-management in distributed systems

3 / 42

slide-4
SLIDE 4

Architectural styles

Basic idea Organize into logically different components, and distribute those components over the various machines.

Layer N Layer N-1 Layer 1 Layer 2 Request flow Response flow (a) (b) Object Object Object Object Object Method call

(a) Layered style is used for client-server system (b) Object-based style for distributed object systems.

4 / 42

slide-5
SLIDE 5

Architectural Styles

Observation Decoupling processes in space (“anonymous”) and also time (“asynchronous”) has led to alternative styles.

Subscribe

Component Component Component Event bus Publish Notification delivery

Subscribe Data delivery Publish

Component Component Shared (persistent) data space

(a) (b) (a) Publish/subscribe [decoupled in space] (b) Shared dataspace [decoupled in space and time]

5 / 42

slide-6
SLIDE 6

Centralized Architectures

Basic Client–Server Model Characteristics: There are processes offering services (servers) There are processes that use services (clients) Clients and servers can be on different machines Clients follow request/reply model wrt to using services

Client Request Reply Server Provide service Time Wait for result

6 / 42

slide-7
SLIDE 7

Application Layering

Traditional three-layered view User-interface layer contains units for an application’s user interface Processing layer contains the functions of an application, i.e. without specific data Data layer contains the data that a client wants to manipulate through the application components Observation This layering is found in many distributed information systems, using traditional database technology and accompanying applications.

7 / 42

slide-8
SLIDE 8

Application Layering

Database with Web pages Query generator Ranking algorithm HTML generator User interface Keyword expression Database queries Web page titles with meta-information Ranked list

  • f page titles

HTML page containing list Processing level User-interface level Data level

8 / 42

slide-9
SLIDE 9

Multi-Tiered Architectures

Single-tiered: dumb terminal/mainframe configuration Two-tiered: client/single server configuration Three-tiered: each layer on separate machine Traditional two-tiered configurations:

User interface User interface User interface Application User interface Application User interface Application Database Application Application Application Database Database Database Database Database User interface (a) (b) (c) (d) (e) Client machine Server machine

9 / 42

slide-10
SLIDE 10

Decentralized Architectures

Observation In the last couple of years we have been seeing a tremendous growth in peer-to-peer systems. Structured P2P: nodes are organized following a specific distributed data structure Unstructured P2P: nodes have randomly selected neighbors Hybrid P2P: some nodes are appointed special functions in a well-organized fashion Note In virtually all cases, we are dealing with overlay networks: data is routed over connections setup between the nodes (cf. application-level multicasting)

10 / 42

slide-11
SLIDE 11

Structured P2P Systems

Basic idea Organize the nodes in a structured overlay network such as a logical ring, or a hypercube, and make specific nodes responsible for services based only on their ID.

0000 1000 0100 1100 0001 1001 0101 1101 0010 1010 0110 1110 0011 1011 0111 1111

Note The system provides an operation LOOKUP(key) that will efficiently route the lookup request to the associated node.

11 / 42

slide-12
SLIDE 12

Unstructured P2P Systems

Essence Many unstructured P2P systems are organized as a random overlay: two nodes are linked with probability p. Observation We can no longer look up information deterministically, but will have to resort to searching: Flooding: node u sends a lookup query to all of its neighbors. A neighbor responds, or forwards (floods) the request. There are many variations: Limited flooding (maximal number of forwarding) Probabilistic flooding (flood only with a certain probability). Random walk: Randomly select a neighbor v. If v has the answer, it replies, otherwise v randomly selects one of its

  • neighbors. Variation: parallel random walk. Works well with

replicated data.

12 / 42

slide-13
SLIDE 13

Superpeers

Observation Sometimes it helps to select a few nodes to do specific work: superpeer.

Weak peer Super peer Overlay network of super peers

Examples Peers maintaining an index (for search) Peers monitoring the state of the network Peers being able to setup connections

13 / 42

slide-14
SLIDE 14

Hybrid Architectures: Client-server combined with P2P

Example Edge-server architectures, which are often used for Content Delivery Networks

Edge server Core Internet Enterprise network ISP ISP Client Content provider

14 / 42

slide-15
SLIDE 15

Exercices

In a structured overlay network, messages are routed according to the topology of the overlay. What is an important disadvantage of this approach? Not every node in a super-peer network should become a

  • superpeer. What are reasonable requirements that a

superpeer should meet?

15 / 42

slide-16
SLIDE 16

The problem with centralized architectures

16 / 42

slide-17
SLIDE 17

The problem with centralized architectures

17 / 42

slide-18
SLIDE 18

The problem with centralized architectures

18 / 42

slide-19
SLIDE 19

The problem with centralized architectures

19 / 42

slide-20
SLIDE 20

BitTorrent

Designed for the transfer of large files to many clients

Based on swarming: a server sends different parts of a file to different clients, and the clients exchange chunks with

  • ne another

Terminology

One session = distribution of a single (large) file Seeder = a node that has the whole file Leecher = a node still downloading the file

Elements

An ordinary web server Torrent file: A static meta-info file A tracker A seeder (an initial client with the complete file) On the end-user side: web browser + BitTorrent client

20 / 42

slide-21
SLIDE 21

The torrent file contains:

Tracker address (IP + port) Bytes per chunk Number of chunks For each chunk: the SHA1 hash of its content

Helps validate the correctness of downloaded chunks

21 / 42

slide-22
SLIDE 22

Joining a BitTorrent session

22 / 42

slide-23
SLIDE 23

Connection states

On each side, a connection maintains two variables:

Interested: you have a chunk that I want Allows a peer to know its possible clients for upload Chocked: I don’t want to send you data at the time Possible reasons: I have found faster peers, you did not/can t reciprocate enough, . . .

23 / 42

slide-24
SLIDE 24

Which missing chunk should we fetch first?

Simple strategy: random selection

Choose at random among chunks available in peer set Randomness ensures diversity

Biased strategy: peers apply the rarest-first policy

Choose the least represented missing chunk in the peer set Rare chunks can more easily be traded with others Maximize the minimum number of copies of any given chunk in each peer set

BitTorrent uses rarest-first policy except for newcomers that use random to quickly obtain a first block

24 / 42

slide-25
SLIDE 25

Peer selection policy

Serving too many peers simultaneously is not efficient

BitTorrent serves a few (around 4 or 5) hosts in parallel Split availabler outgoing bandwidth equally between these connections

Which hosts to serve?

Seeders’ policy: The ones that offer the best download rates Leechers’ policy: The ones that also serve us: tit for tat Choke the rest peers

Can there be any better hosts?

Reconsider choking/unchoking every 10 sec (long enough for TCP to reach steady state) Optimistically unchoke a random peer every 30 sec to give a chance to another host to provide better service

25 / 42

slide-26
SLIDE 26

Exercises

Consider a BitTorrent system in which each node has an

  • utgoing bandidth capacity Bout and an incoming

bandwidth capacity Bin. Some of these nodes (called seeds) voluntarily offer files to be downloaded by others. We assume that each peer can contact at most one seed at a time. What is the maximum download capacity that a BitTorrent peer can have? BitTorrent uses a policy similar to tit-for-tat. Give a technical argument why the strict application of this policy would be a bad idea. BitTorrent users may want to cheat the protocol: imagine a strategy that allows BitTorrent users to download content

  • faster. Does this strategy harm the overall system?

26 / 42

slide-27
SLIDE 27

Architectures versus Middleware

Problem In many cases, distributed systems/applications are developed according to a specific architectural style. The chosen style may not be optimal in all cases ⇒ need to (dynamically) adapt the behavior of the middleware. Interceptors Intercept the usual flow of control when invoking a remote

  • bject.

27 / 42

slide-28
SLIDE 28

Interceptors

Client application

B.do_something(value) invoke(B, &do_something, value) send([B, "do_something", value])

Request-level interceptor Message-level interceptor Object middleware Local OS Application stub To object B Nonintercepted call Intercepted call

28 / 42

slide-29
SLIDE 29

Self-managing Distributed Systems

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

29 / 42

slide-30
SLIDE 30

Feedback Control Model

Observation In many cases, self-* systems are organized as a feedback control system.

Core of distributed system Metric estimation Analysis Adjustment measures +/- +/- +/- Reference input Initial configuration Uncontrollable parameters (disturbance / noise) Observed output Measured output Adjustment triggers Corrections

30 / 42

slide-31
SLIDE 31

Example: Globule

Globule Collaborative CDN that analyzes traces to decide where replicas of Web content should be placed. Decisions are driven by a general cost model: cost = (w1 ×m1)+(w2 ×m2)+···+(wn ×mn)

31 / 42

slide-32
SLIDE 32

Example: Globule

Replica server Core Internet Enterprise network ISP ISP Client Origin server Client Client

Globule origin server collects traces and does what-if analysis by checking what would have happened if page P would have been placed at edge server S. Many strategies are evaluated, and the best one is chosen.

32 / 42

slide-33
SLIDE 33

An experiment

Research question Does it make sense to distribute each Web page according to its own best strategy, instead of applying a single, overall distribution strategy to all Web pages?

Edge server Edge server Edge server Origin server Client Client Client Client Client Client Client Client Client Client Client Client Client Client Client Clients in an unknown AS AS 1 AS 2 AS 3 AS of document’s

  • rigin server

33 / 42

slide-34
SLIDE 34

An experiment

We collected traces on requests and updates for all Web pages from two different servers (in Amsterdam and Erlangen) For each request, we checked:

From which autonomous system it came What the average delay was to that client What the average bandwidth was to the client’s AS (randomly taking 5 clients from that AS)

Pages that were requested less than 10 times were removed from the experiment. We replayed the trace file for many different system configurations, and many different distribution scenarios.

34 / 42

slide-35
SLIDE 35

An experiment

Issue Site 1 Site 2 Start date 13/9/1999 20/3/2000 End date 18/12/1999 11/9/2000 Duration (days) 96 175 Number of documents 33,266 22,637 Number of requests 4,858,369 1,599,777 Number of updates 11,612 3338 Number of ASes 2567 1480

35 / 42

slide-36
SLIDE 36

Distinguished strategies: Caching

Abbr. Name Description NR No replication No replication or caching takes place. All clients forward their requests directly to the origin server. CV Verification Edge servers cache documents. At each subsequent request, the origin server is contacted for revalidation. CLV Limited validity Edge servers cache documents. A cached document has an associated expire time before it becomes invalid and is removed from the cache. CDV Delayed verification Edge servers cache documents. A cached document has an associated expire time after which the origin server is contacted for revalidation.

36 / 42

slide-37
SLIDE 37

Distinguished strategies: Replication

Abbr. Name Description SI Server invalidation Edge servers cache documents, but the

  • rigin server invalidates cached copies

when the document is updated. SUx Server updates The origin server maintains copies at the x most relevant edge servers; x = 10, 25

  • r 50

SU50 + CLV Hybrid SU50 & CLV The origin server maintains copies at the 50 most relevant edge servers; the other intermediate servers follow the CLV strategy. SU50 + CDV Hybrid SU50 & CDV The origin server maintains copies at the 50 most relevant edge servers; the other edge servers follow the CDV strategy.

37 / 42

slide-38
SLIDE 38

Trace results: One global strategy

Turnaround time (TaT) and bandwidth (BW) in relative measures; stale documents as fraction of total requested documents. Site 1 Site 2 Strategy TaT Stale docs BW TaT Stale docs BW NR 203 118 183 115 CV 227 113 190 100 CLV 182 0.0061 113 142 0.0060 100 CDV 182 0.0059 113 142 0.0057 100 SI 182 113 141 100 SU10 128 100 160 114 SU25 114 123 132 119 SU50 102 165 114 132 SU50+CLV 100 0.0011 165 100 0.0019 125 SU50+CDV 100 0.0011 165 100 0.0017 125

Conclusion: No single global strategy is best

38 / 42

slide-39
SLIDE 39

Assigning an optimal strategy per document: Site 1

Ideal arrangement SU50+CLV SU50+CDV SU50 SU25 CLV SI CDV Cost function arrangements Totalconsumedbandwidth Totalturnaroundtime

39 / 42

slide-40
SLIDE 40

Assigning an optimal strategy per document: Site 2

Idealarrangement SU50+CLV SU50+CDV SU50 SU25 SU10 CDV CLV SI Costfunctionarrangements Totalconsumedbandwidth Totalturnaroundtime

40 / 42

slide-41
SLIDE 41

Useful strategies

Fraction of documents to which a strategy is assigned.

Strategy Site 1 Site 2 NR 0.0973 0.0597 CV 0.0001 0.0000 CLV 0.0131 0.0029 CDV 0.0000 0.0000 SI 0.0089 0.0061 SU10 0.1321 0.6087 SU25 0.1615 0.1433 SU50 0.4620 0.1490 SU50+CLV 0.1232 0.0301 SU50+CDV 0.0017 0.0002

Conclusion: It makes sense to differentiate strategies

41 / 42

slide-42
SLIDE 42

Exercices

Modern cars are stuffed with electronic devices. Give some examples of feedback control systems in cars.

42 / 42