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. Another problem that comes to mind is ensuring that the older slower servers don't act as bottlenecks to the whole pool. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131111/397b2a26/attachment.sig>
Bump? Anyone have any thoughts on this? Cheers, James On Mon, Nov 11, 2013 at 7:24 PM, James <purpleidea at gmail.com> 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. > > Another problem that comes to mind is ensuring that the older slower > servers don't act as bottlenecks to the whole pool. 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 >
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 poolI 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>