Cloudy Weather for P2P

Transcription

1 Cloudy Weather for P2P with a Chance of Gossip Alberto Montresor Luca Abeni Best paper award in P2P'11 Presented by: amir@sics.se 1

2 Introduction 2

3 Cloud Computing vs. P2P Similarity: Providing the infinite availability of computing and storage resources. Difference: The cloud provides highly available resources, but at a cost. P2P resources are for free, but their availability is shaky. 3

4 Cloud Computing vs. P2P P2P 1/Cost Availability Cloud 4

5 Related Work Several projects have tried to mix the two to get the advantages of both: high availability and low cost. First approach: adding peers to an existing centralized solution. Off loading the services to peers, if does not affect service availability. Second approach: augmenting P2P systems with cloud angels. Adding elastic computing nodes with the specific task of satisfying requirements beyond the reach of a P2P network. 5

6 Third Approach: The Paper Contribution Cloudcast The target application: content distribution. All functionalities of the content distribution application are supported by a passive storage service such: Topology bootstrap and membership management. Information dissemination. No active elastic computing instances are required. 6

7 The Costs Storage and bandwidth costs. To preserve the durability, the storage consumption cannot be reduced. So, let's focus on the bandwidth cost. How? 7

8 How? Cloudcast is based on two gossip protocols: Topology bootstrap and membership management. Information dissemination. How: keep the number of cloud accesses 1 per gossip cycle, independently of the number of clients. 8

9 Background 9

10 Information Dissemination Epidemic protocols a classical solution Nodes gossip about news in random fashion: Rumor mongering: to quickly push the rumors toward on line nodes. Anti entropy: to make sure that everybody gets all the news (push pull). Epidemic protocols require a list of nodes forming the network. Where do we get it from? Peer sampling. 10

11 Peer Sampling Peer sampling service provides each peer with continuously up to date random samples of the entire population of peers. Such samples fulfil two purposes: Used by the epidemic broadcast service to obtain random peers. Maintain a random topology connecting all peers. Information Dissemination get random peer Peer Sampling 11

12 A Generic Gossip Protocol A generic gossip protocol executed by node p. Active thread do once every δ time units q = getpeer(state) Sp = preparemsg(state, q) send(req, Sp) to q Passive thread do forever receive(t, Sq) from * if (t = REQ) then Sp = preparemsg(state, q) send(rep, Sp) to q state = update(state, Sq) 12

13 Cyclon State at each node: A partial view containing c neighbour descriptors (c = view size). Node descriptor: address + timestamp (age) getpeer() select the oldest descriptor in the view remove it from the view preparemsg(view, q) active thread: returns a subset of t 1 random nodes, plus a fresh local identifier of itself passive thread: returns a subset of t random nodes update(view, Sq) discard entries in Sq that p already knows add Sq, removing entries sent to q 13

14 Cyclon Peer Sampling Protocol (1/7) n2 n9 1 n5 n4 14

15 Cyclon Peer Sampling Protocol (2/7) n9 n5 1 n2 n5 n4 15

16 Cyclon Peer Sampling Protocol (3/7) n9 n5 1 1 shuffle request n2 n5 n4 16

17 Cyclon Peer Sampling Protocol (4/7) n9 1 shuffle response 1 n2 n5 n4 17

18 Cyclon Peer Sampling Protocol (5/7) n9 1 shuffle response 1 n2 n5 n4 18

19 Cyclon Peer Sampling Protocol (6/7) n9 Update State 1 shuffle response 1 Update State n2 n5 n4 19

20 Cyclon Peer Sampling Protocol (7/7) n2 n9 1 1 n5 n4 20

21 Cloudcast 21

22 Cloudcast Architecture The cloud join the group so there will be always one member. 22

23 Storage Clouds vs. Epidemic Protocols Reducing the number of accesses to the cloud is one of the most important requirements in Cloudcast. Cyclon ensures that the in degree of each peer p tends to stay around c (view size). If number of nodes n > c, the cloud in degree is c and if n < c, then cloud in degree is n. Proving that Cloudcast scales down as well. 23

24 Cloudcast Peer Sampling Cloud is a passive key/value storage, and can not perform computation. Active thread do once every δ time units q = getpeer(state) if (q is cloud) then send(get, VIEW) else Sp = preparemsg(state, q) send(req, Sp) to q Passive thread do forever receive(t, Sq) from * if (t = VIEW) then Sp = emulaterequestmsg() Sq = emulatereplymsg() V = emulateview(sp) send(put, VIEW, V) to q else if (t = REQ) then Sp = preparemsg(state, q) send(rep, Sp) to q State = update(state, Sq) 24

25 Cloudcast Peer Sampling Protocol (1/9) n9 C 1 C 25

26 Cloudcast Peer Sampling Protocol (2/9) n9 C 1 Get(VIEW) C 26

27 Cloudcast Peer Sampling Protocol (3/9) n9 C 1 Reply C 27

28 Cloudcast Peer Sampling Protocol (4/9) n9 C 1 C 28

29 Cloudcast Peer Sampling Protocol (5/9) n9 C 1 Emulate request/reply C 29

30 Cloudcast Peer Sampling Protocol (6/9) request reply n9 C 1 1 Emulate request/reply C 30

31 Cloudcast Peer Sampling Protocol (7/9) n9 C 1 1 Update views C 31

32 Cloudcast Peer Sampling Protocol (8/9) n9 C 1 1 Put(VIEW, V) C 32

33 Cloudcast Peer Sampling Protocol (9/9) n9 C 1 1 C 33

34 Keep or Remove the Cloud Descriptor? n9 C 1 Keep or remove the Cloud descriptor? 1 C 34

35 When to add the Cloud Descriptor? Cloud objects have last modified information. When contacting a cloud: If last modified is too close in time (¼ cycle), too many cloud references do not maintain the cloud reference. If last modified is too far in time (4 cycles), too few cloud reference maintain the cloud reference and create a new one. 35

36 Cloudcast Bootstraping The new node performs a GET operation and retrieve a first view It can be later used to start the normal Cyclon protocol. If the view retrieved from the cloud is smaller than c, this means that n < c, and a cloud descriptor is added. 36

37 Cloudcast Information Dissemination The creator of a new message Write the message in the cloud. Update a message counter in the cloud. Starts a rumor mongering broadcasting on the new message. Rumor mongering (push) Every node sends the hot rumor to a random peer. Stops forwarding the rumor with a given probability (0.2). Anti entropy (push pull) Less frequently, node exchange summaries of the message received so far and download missing ones if needed. 37

38 Experiments 38

39 Simulation based on the Peersim. Experiments 39

40 Simulation based on the Peersim. Experiments Different levels of churn Different levels of message loss 40

41 Conclusion 41

42 Conclusion This paper shows a novel approach that mix the dependability of cloud computing with the low cost of P2P networks. Many open questions: There is obviously an unbalance between peer sampling and message diffusion. Avoiding so many GET/PUT requests. Make the system more adaptive if the groups grows, the cloud is used less and less (just to guarantee durability). 42

43 Question? Acknowledgement Some slides were derived from the slides of Alberto Montresor (University of Trento, Italy) 43