Tracking Objects in Distributed Systems. Distributed Systems

Transcription

1 Tracking Objects in Distributed Systems Arvind Krishnamurthy Fall 2004 Distributed Systems Consider the Shared virtual memory system (SVM) by Kai Li: It tracks pages in a cluster system Simplest version uses a centralized manager to keep track of all objects in the system Refined version uses a distributed manager Distribution is for load-balance and not because the system is a distributed system Trademarks of a distributed system Heterogeneous in nature Loosely coupled systems; interconnection network might be just the Internet Separate entities might control the different components of a system Controlling entities might be receptive to incentives, might be byzantine 1

2 Tracking Objects in Distributed Systems If one were to design the equivalent of the SVM in a distributed system: What issues should we worry about? How will the issues affect the design of the system? Distributed file sharing Motivating Application Large number of users managing an even larger number of objects Users/individual computers might join and leave the system at any point in time Tracking of data objects could be divorced from storing the data objects (orthogonal issues) Minimize the amount of state managed by the system Minimize the amount of communication required to track the current system state Many research systems; popular approach distributed hash tables exemplified by Chord 2

3 Chord Overview Provides lookup service: Lookup(key) IP address Chord does not store the data m bit identifier space for both keys and nodes Key identifier = SHA-1(key) Key= mozilla.rpm SHA-1 ID=60 Node identifier = SHA-1(IP address) IP= SHA-1 ID=123 Hashing Scheme IP= K5 N123 K20 K101 Circular 7-bit ID space N32 N90 K60 Key= mozilla.rpm A key is stored at its successor: node with next higher ID 3

4 Simple Scheme Every node knows of every other node that is, N10 knows N90 is requires global information Routing tables are large O(N) Lookups are fast O(1) 0 N123 N10 Where is mozilla.rpm? Hash( mozilla.rpm ) = K60 N90 has K60 N32 K60 N90 N55 Other Extreme Every node knows its successor in the ring N123 0 N10 Where is mozilla.rpm? Hash( mozilla.rpm ) = K60 N32 N90 has K60 K60 N90 N55 requires O(N) lookups 4

5 Intermediate solution: finger tables Every node knows m other nodes in the ring That is, it knows the node that is maintaining K + 2 i where K is mapped id of current node Increase distance exponentially N96 N N Faster Lookups Lookups take O(Log N) hops Halve the distance to target with each hop N5 N110 N99 N10 N20 K19 N32 Lookup(K19) N60 Question: what topic of parallel computing does this resemble most? 5

6 Joining the ring Three step process: Initialize all fingers of new node Update fingers of existing nodes Transfer keys from successor to new node Less aggressive mechanism (lazy finger update): Initialize only the finger to successor node Periodically verify immediate successor, predecessor Periodically refresh finger table entries Joining the ring: step 1 Initialize the new node s finger table Locate any node p in the ring Ask node p to lookup fingers of new node N36 Return results to new node N5 N36 N99 N20 1. Lookup(37,38,40,,100,164) N40 N60 6

7 Joining the ring (contd.) Step 2: Updating fingers of existing nodes new node calls update function on existing nodes existing nodes can recursively update fingers of other nodes Step 3: transfer keys from successor node to new node only keys in the range are transferred N5 N99 N20 N36 N40 K30 K38 K30 K38 Copy keys from N40 to N36 N60 Handling Failures Failure of nodes might cause incorrect lookup N102 N113 N120 N10 N85 Lookup(90) doesn t know correct successor, so lookup fails Successor fingers are enough for correctness 7

8 Handling Failures Use successor list Each node knows r immediate successors After failure, will know first live successor Correct successors guarantee correct lookups Guarantee is with some probability Can choose r to make probability of lookup failure arbitrarily small Lookup Cost Cost is O(Log N) as predicted by theory constant is 1/2 Average Messages per Lookup Number of Nodes 8