[Gluster-users] Expanding legacy gluster volumes

[Lalatendu Mohanty]

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>