Distributed Cluster Repair for OceanStore

Distributed Cluster Repair for OceanStore

Irena Nadjakova and Arindam Chakrabarti

Acknowledgements:Hakim Weatherspoon

John Kubiatowicz

Dec 9, 2003 Distributed Cluster Repair for OceanStore 2

OceanStore Overview

Data Storage Utility• Robustness• Security• Durability • High availability • Global-scale


Where our project fits in

Durability• Automatic version-management• Highly redundant erasure-coding• Massive dissemination of

fragments on machines with highly uncorrelated availability.


The internet


Choosing locations for storing a fragment






Clustering


Clustering


OceanStore solution

• Availability of each machine tracked over time.

• Machines that have very little availability are not used for fragment storage.

• Distance between each pair of machines computed. (high mutual information ) close)

• Cluster the machines into chunks based on this distance using normalized cuts.

• All the computation is done on one central computer (Cluster Server).


OceanStore solution

• Machines that are highly correlated in availability are in same cluster.

• Machines in separate clusters have low correlation in availability.

• When a node needs to store replica fragments, it requests cluster information from the cluster server and uses it to send each fragment to k nodes: one from each of k different clusters.


Cluster creation

• Needs centralized computation.• Can we do it in a distributed manner ?• NCuts is one stumbling block. It seems to

need the entire graph.• Having to pull the cluster info from one

central cluster server: single point of failure• Can we have a “Distributed NCuts” algo to

look at subgraphs ? How to make subgraphs? Do we need to know the entire graph to decide how to divide it into pieces ?


Distributed clustering










Initial idea

• We run the centralized algorithm once for some time period (chose 73 days) to generate some initial clustering (expensive!)

• We distribute the machines among some f cluster servers– Each has a smaller subset of size num of the

initial machines– Keeping the initial clustering proportions for

each node– Each machine occurs in approximately

equal number of cluster servers


Initial idea (cont)

• Now we can afford to recluster the machines on each server frequently to keep up with the network changes.– Chose to do it once every 30 days for

the simulation purposes, but can easily be done a lot more often


Evaluation

• To see how well this does, we want to compare it with the original global algorithm, run in the same time period.

• Metric – the average mutual informationI(x,y) = P(x,y) log P(x,y)/P(x)P(y)

– Average MI for a single server is just the average of the mutual information between pairs of machines in different clusters on the server

– On multiple servers, we compute the above on every server, then average among servers


Simulating Network Evolution Dynamics

• We have availability data for 1000 machines for a period of 73 days.

• We use it to simulate the behavior of a network with 1000 machines over a period of 730 days = 2 years.

• We simulate networks with varying evolution characteristics to evaluate the robustness of our distributed cluster repair algorithm.


Simulating Network Evolution Dynamics

Qualities of a good network:• Maybe server availability (AV) should

not vary drastically in the future ?• Maybe average server repair time

(MTTR) should not vary drastically ?• Maybe mean time to failure (MTTF)

should not vary drastically ?• Maybe failure correlations (FCOR)

should also not vary drastically ?


NS Algo 1: Sanity Check 1

Global déjà vu• Maintains AV, MTTF, MTTR, FCOR• Simulates a well-behaved network.• Our distributed update algorithm

should do very well on this.


NS Algo 2: Acid Test 1

Local déjà vu• Maintains AV, MTTF, MTTR, but not

FCOR.



Births and Deaths• Maintains AV, MTTF, MTTR, and FCOR,

but only for some nodes, and for some time.

• Nodes are taken off (die) the network or are added to (born) the network at certain times. When they are actually on the network, they maintain their AV, MTTF, MTTR, FCOR.



Noisy Global déjà vu• Maintains AV, MTTF, MTTR, FCOR

to a large extent, but adds some Gaussian noise, representing the variations that may be observed in a real network.



Noisy Local déjà vu• Maintains AV, MTTF, MTTR, but not

FCOR, and also adds some Gaussian noise representing the variations that may be observed in a real network.

• Does our algorithm do well in this situation ? If yes, how robust is it to noise ?






Still problems

• Initial clustering is expensive• What happens if we don’t use it?



How to fix this?

• Randomly distribute machines to the servers

• Perform local clustering• Find the ‘unwanted’ elements (highest

mutual information with the rest on this node)

• Exchange them with ‘unwanted’ elements of another cluster to which the first ones are least correlated

• Communication overhead is low; most computation can proceed without a lot of communication


Under development…

• What we have so far is a scheme that – picks a server at random– finds a few unwanted elements– exchanges those with the same number of

unwanted elements of another server – picked at random, or having the best correlation with the unwanted elements of the first server

• The percentage improvement is small so far – 0.4%-1.5% for the first 5 or so runs. It falls off afterwards.


How to improve

• Exchange more than 1 machines ?• Run for several generations ?• It may be even better to just

randomly exchange machines, as long as the overall average mutual information of the distributed cluster decreases.


Summary of achievements

• Towards getting rid of expensive centralized cluster creation

• Scalable distributed cluster management scheme


Thanks for listening !

Acknowledgements:

Hakim WeatherspoonJohn Kubiatowicz

Documents

Distributed Cluster Repair for OceanStore