08 Distributed Hash Tables

Transcription

1 08 Distributed Hash Tables

2 What are P2P systems? Peer-to-Peer as opposed to Client-Server All participants in a system have uniform roles they act as clients, servers and routers popular P2P apps: Seti@home, Kazaa, Napster Technological trends favoring P2P client desktops have increasingly larger storage, computation power and bandwidth millions of clients connected to the Internet P2P systems leverage the power of these clients Seti@home leverage computation power Kazaa, Napster leverage bandwidth CFS, PAST leverage storage

3 Why are DHTs appealing to P2P System Designers? They are Scalable, Decentralized, Self-organizing They are Content-Addressable mask server churn from clients and vice-versa DHTs provide flat-application independent naming, many apps/services can co-exist on one DHT

4 Content Addressability in a DHT A HASH(xyz.mp3) = K1

5 Content Addressability in a DHT K1 (xyz.mp3, A) insert A HASH(xyz.mp3) = K1

6 Content Addressability in a DHT K1 (xyz.mp3, A) A lookup B HASH(xyz.mp3) = K1

7 Content Addressability in a DHT K1 (xyz.mp3, A) A B

8 One DHT, many uses K1 (xyz.mp3, A) A B could as easily have been a web page, disk block, service, DNS name,

9 Content-addressability: key insight Content-addressability provides a level of indirection between consumers and providers of content/service Any computer systems problem can be solved by adding a level of indirection Eliminates need for consumers to know providers & vice-versa allows a new raft of applications like anycast, multicast, service composition etc., anycast: single consumer, multiple providers fetch content X from the best server client should know only a few servers multicast: single provider, multiple consumers supply content X to a large number of clients server should know only a few clients

10 Content Adressability Anycast Multicast

11 Anycast (find closest server with xyz.mp3) C B insert K1 (xyz.mp3, A) (xyz.mp3, B) (xyz.mp3, C) A A Topologically Sensitive DHT

12 DHT can support Anycast C B K1 (xyz.mp3, A) (xyz.mp3, B) (xyz.mp3, C) (xyz.mp3, C) (xyz.mp3, A) A anycast lookup could be based any metric. Here, we consider latency

13 Multicast (find all clients needing xyz.mp3) D B (xyz.mp3, K2 ) (xyz.mp3, B) K1 E (xyz.mp3, D) (xyz.mp3, E) (xyz.mp3, F) K3 F K2 (xyz.mp3, K3 ) (xyz.mp3, C) C A HASH(xyz.mp3) = K1 Scalable multicast dissemination

14 Content Addressable Internet Can we retrofit content addressability over DNS through creative hacks? Possible, but very unattractive DNS based anycast (Akamai) reduces effectiveness of caching DNS based multicast, mobileip require constant updates to DNS databases huge stress on the DNS servers higher up in the hierarchy once again, effectiveness of caching is reduced Content addressability fits naturally in DHTs

15 Content Addressable Internet A vision for DHT based Content Addressable Internet A ubiquitous, generic DHT infrastructure that provides an explicit indirection service over which a rich assortment of services are layered opening up a new generation of large-scale distributed applications

16 A DHT-enabled Internet dchat Client/Server Web P2P d content publishing/distribution dgoogle (by keyword) SFR (content) DNS (by location) directory services CDN-like (by name) Wb blogs collaborative apps psearch (by interest) i3 mcast rv commn. services File Systems (Casper, Past CFS, OStore) PIER Internet distr. systems dhash CASLIB storage services PHT ReHash compute services Indirection service DHT Connectivity IP

17 Distributed Hash Tables Academic answer to p2p Goals Guaranteed lookup success Provable bounds on search time Provable scalability Makes some things harder Fuzzy queries / full-text search / etc. Hot Topic in networking since introduction in ~2000/

18 DHT: Overview Abstraction: a distributed hash-table (DHT) data structure supports two operations: put(id, item); item = get(id); Implementation: nodes in system form a distributed data structure 18 Can be Ring, Tree, Hypercube, Skip List, Butterfly Network,...

19 What Is a DHT? A building block used to locate key-based objects over millions of hosts on the internet Inspired from traditional hash table: key = Hash(name) put(key, value) get(key) -> value Challenges Decentralized: no central authority Scalable: low network traffic overhead Efficient: find items quickly (latency) Dynamic: nodes fail, new nodes join General-purpose: flexible naming 19

20 The Lookup Problem N1 Put (Key= title Value=file data ) Publisher N2 Internet N4 N5 N3? Client Get(key= title ) N6 20

21 DHTs: Main Idea N2 N1 Publisher N3 N4 Client Lookup(H(audio data)) Key=H(audio data) Value={artist, album title, track title} N6 N7 N8 N9 21

22 DHT: Overview Structured Overlay Routing: Join: On startup, contact a bootstrap node and integrate yourself into the distributed data structure; get a node id Publish: Route publication for file id toward a close node id along the data structure Search: Route a query for file id toward a close node id. Data structure guarantees that query will meet the publication. Fetch: Two options: 22 Publication contains actual file => fetch from where query stops Publication says I have file X => query tells you has X, use IP routing to get X from

23 From Hash Tables to Distributed Hash Tables Challenge: Scalably distributing the index space: Scalability issue with hash tables: Add new entry => move many items Solution: consistent hashing (Karger 97) Consistent hashing: Circular ID space with a distance metric Objects and nodes mapped onto the same space A key is stored at its successor: node with next higher ID 23

24 DHT: Consistent Hashing Key 5 Node 105 K5 N105 K20 Circular ID space N90 K80 A key is stored at its successor: node with next higher ID 24 N32

25 What Is a DHT? Distributed Hash Table: key = Hash(data) lookup(key) -> IP address put(key, value) get( key) -> value API supports a wide range of applications DHT imposes no structure/meaning on keys Key/value pairs are persistent and global Can store keys in other DHT values And thus build complex data structures 25

26 Approaches Different strategies Chord: constructing a distributed hash table CAN: Routing in a d-dimensional space Many more Commonalities Each peer maintains a small part of the index information (routing table) Searches performed by directed message forwarding Differences Performance and qualitative criteria 26

27 DHT: Example - Chord Associate to each node and file a unique id in an uni-dimensional space (a Ring) E.g., pick from the range [0...2m-1] Usually the hash of the file or IP address Properties: Routing table size is O(log N), where N is the total number of nodes Guarantees that a file is found in O(log N) hops 27

28 Example 1: Chord Hashing of search keys AND peer addresses on binary keys of length m Key identifier = SHA-1(key); Node identifier = SHA-1(IP address) SHA-1 distributes both uniformly e.g. m=8, key( yellow-submarine.mp3")=17, key( )=3 Data keys are stored at next larger node key p k predecessor Search possibilities? 1. every peer knows every other O(n) routing table size 2. peers know successor O(n) search cost m=8 stored 32 keys at p2 p3 peer with hashed identifier p, data with hashed identifier k k stored at node p such that p is the smallest node ID larger than k

29 Chord: Basic Lookup N120 N10 Where is key 80? N105 N90 has K80 K80 N90 N60 N32

30 Chord Finger Table 1/4 1/2 1/8 1/16 1/32 1/64 1/128 N80 Entry i in the finger table of node n is the first node that succeeds or equals n + 2i In other words, the ith finger points 1/2n-i way around the ring

31 Example 2: CAN Based on hashing of keys into a d-dimensional space (a torus) Each peer is responsible for keys of a subvolume of the space (a zone) Each peer stores the addresses of peers responsible for the neighboring zones for routing Search requests are greedily forwarded to the peers in the closest zones Assignment of peers to zones depends on a random selection made by the peer

32 Network Search and Join Node 7 joins the network by choosing a coordinate in the volume of 1 32

33 CAN Refinements Multiple Realities We can have r different coordinate spaces Nodes hold a zone in each of them Creates r replicas of the (key, value) pairs Increases robustness Reduces path length as search can be continued in the reality where the target is closest Overloading zones Different peers are responsible for the same zone Splits are only performed if a maximum occupancy (e.g. 4) is reached Nodes know all other nodes in the same zone But only one of the neighbors 33

34 When should we use DHT? Does the system need to scale? Does the system have heterogeneous nodes? Does the system need self-organization? Do nodes fail often? Do the economies of scale favor decentralization? Can the system tolerate security risks due to decentralization? Do you need content addressability?

35 DHT Uses corporation wide file-systems sensor networks and queries over them Overnet, DHT based Napster internet wide file-systems, backups Akamai, Scribe Wide-area file-sharing Pier corporate multicast, video-conferencing Farsite, GFS, LOCKSS CFS, Past, Ivy collaborative spam filtering

36 De-centralized file systems CFS [Chord] PAST [Pastry] Block based read-only storage File based read-only storage Ivy [Chord] Block based read-write storage