On 11/12/2013 05:54 AM, James wrote: > Hi there, > > This is a hypothetical problem, not one that describes specific hardware > at the moment. > > As we all know, gluster currently usually works best when each brick is > the same size, and each host has the same number of bricks. Let's call > this a "homogeneous" configuration. > > Suppose you buy the hardware to build such a pool. Two years go by, and > you want to grow the pool. Changes in drive size, hardware, cpu, etc > will be such that it won't be possible (or sensible) to buy the same > exact hardware, sized drives, etc... A heterogeneous pool is > unavoidable. > > Is there a general case solution for this problem? Is something planned > to deal with this problem? I can only think of a few specific corner > case solutions. I am not sure about of issues you are expecting when a heterogeneous configuration is used. As gluster is intelligent enough for handling sub-volumes/bricks with different sizes. So I think heterogeneous configuration should not be a issue for gluster. Let us know what are the corner cases you have in mind (may be this will give me some pointers to think :)). > Another problem that comes to mind is ensuring that the older slower > servers don't act as bottlenecks to the whole pool I think this is unavoidable but the time-line for these kind of change will be around 10 to 15 years. However we can replace bricks if the old servers really slows the whole thing down. > . jdarcy had mentioned > that gluster might gain some notion of tiering, to support things like > ssd's in one part of the volume, and slow drives at the other end. Maybe > this sort of architecture can be used to solve the same problems. > > Thoughts and discussion welcome. > > Cheers, > James > > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131120/8be79454/attachment.html>
