[Gluster-devel] DHT idea: rebalance-specific layout

Paul Cuzner pcuzner at redhat.com
Tue Mar 25 22:57:53 UTC 2014


It's an interesting way to avoid data movement, would this be an optional method for rebalance processing or a default? 

You also mention medium bricks and old bricks - which implies meta data associated with the bricks themselves that can be referenced by the rebalance algorithm? 

By avoiding the redistribution of the data, don't we end up placing more of the 'hot' content on fewer servers. I've always liked the notion of the capacity being consumed by data of varying ages within a brick to avoid hot spots within the cluster. 

----- Original Message -----

> From: "Jeff Darcy" <jdarcy at redhat.com>
> To: "Gluster Devel" <gluster-devel at nongnu.org>
> Sent: Tuesday, 25 March, 2014 3:08:49 AM
> Subject: [Gluster-devel] DHT idea: rebalance-specific layout

> I was talking to a user about my size-weighted (or optionally
> free-space-weighted) rebalance script. This led to thinking about ways
> to bring a system back into balance without migrating any old data, as
> some of our users already do. Here's the example I was using.

> * Four existing 1TB bricks, which are 90% full.

> * One new 2TB brick, which is empty.

> Therefore, total free space is 2.4TB, of which the new brick has 2.0TB.
> If we set up the layouts so that the new brick has 5/6 of the hash
> space then as new files are added they should all reach 100% full at
> the same time without ever needing to migrate any old data. Yay.

> Unfortunately, there's still a problem. For these kinds of users (e.g.
> CDNs) the newest data also tends to remain hottest. What happens when
> they want to retire some of their oldest hardware? That *does* involve
> migrating old data, and the load for that will disproportionately fall
> on the newest servers which really should be spending as much of their
> time as possible serving new content. That's not good.

> So (finally) here's the idea. Have a *separate* set of layout values
> that are used specifically for rebalance, so that we can rebalance data
> one way even as new files are placed another way. Let's consider a
> slightly different example.

> * 4 ancient 1TB bricks, 75% full

> * 16 medium-age 1.5TB bricks, also 75% full

> * 4 new 2TB bricks, empty

> Here's one possible way to use dual layouts:

> * currently 8TB free on the medium bricks, goal is 5TB

> * 4TB free on the new bricks

> * set regular layout to 44% new, 55% medium

> * set rebalance layout to 100% medium

> This way 44% of the new files but *none* of the files from the oldest
> bricks will flow toward the newest bricks. 100% of that traffic will
> be from the oldest bricks to the medium ones, and shouldn't affect the
> newest machines at all. This would all be a lot easier if we had
> layout inheritance or default layouts instead of every single directory
> with its own layout, but we can probably find ways to deal with that.

> Any reactions?

> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140325/397176e6/attachment-0001.html>


More information about the Gluster-devel mailing list