[CentOS] Is glusterfs ready?

[Dennis Jacobfeuerborn]

On 08/29/2012 03:17 PM, Johnny Hughes wrote:
> On 08/29/2012 08:06 AM, Les Mikesell wrote:
>> On Wed, Aug 29, 2012 at 7:49 AM, Johnny Hughes <johnny at centos.org> wrote:
>>>> If we were rich, I guess we would have two (or more) "geo-replicated" glusters and
>>>> be able to withstand one failing...
>>>> I would like the same trust level that I have in RAID.
>>> I have routinely used DRBD for things like this ... 2 servers, one a
>>> complete failover of the other one.  Of course, that requires a 50+ TB
>>> file system on each machine.
>> How well do glusterfs or drbd deal with downtime of one of the
>> members?    Do they catch up quickly with incremental updates and what
>> kind of impact does that have on performance as it happens?   And is
>> either suitable for running over distances where there is some network
>> latency?
>>
> 
> Well, DRBD is a tried and true solution, but it requires dedicated boxes
> and crossover network connections, etc.  I would consider it by far the
> best method for providing critical failover.
> 
> I would consider gluserfs almost a different thing entirely ... it
> provides the ability to string several partitions on different machines
> into one shared network volume.
> 
> Glusterfs does also provide redundancy if you set it up that way ... and
> if you have a fast network and enough volumes then the performance is
> not very degraded when a gluster volume comes back, etc.
> 
> However, I don't think I would trust extremely critical things on
> glusterfs at this point.

I think the keyword with solutions like glusterfs, ceph, sheepdog, etc. is
"elasticity". DRBD and RAID work well as long as you have a fixed size of
data to deal with but once you get to a consistent data growth you need
something that offers redundancy yet can be easily extended incrementally.

Glusterfs seems to aim to be a solution that works well right now because
it uses a simple file replication approach whereas ceph and sheepdog seem
to go deeper and provide better architectures but will take longer to mature.

Regards,
  Dennis