[Gluster-devel] High Available Transparent File System

[Meisam Mohammadkhani]

Dear Gordan,

Actually our little tests showed that replicated files, could be accessible
in more than one minute with GlusterFS. It's a big delay for us, but maybe
our tests was not configured nicely. Our application is a .net application
and we used CIFS to accessing the GlusterFS files. Also machines hardware
are not so powerful. I wanna to know what should be the accessibility delay
range in different cases? Can GlusterFS support "High Availability" in a
fastest way as it's possible?

Regards

On Sun, Apr 10, 2011 at 8:03 PM, Gordan Bobic <gordan at bobich.net> wrote:

> On 10/04/2011 15:27, Meisam Mohammadkhani wrote:
>
>> Hi All,
>>
>> I'm new to GlusterFS. I'm searching around a solution for our enterprise
>> application that is responsible to save(and manipulate) historical data
>> of industrial devices. Now, we have two stations that works like hot
>> redundant of each other. Our challenge is in case of failure. For now,
>> our application is responsible to handling fault by synchronizing the
>> files that changed during the fault, by itself. Our application is
>> running on two totally independent machines (one as redundant) and so
>> each one has its own disk.
>> We are searching around a solution like a "high available transparent
>> file system" that makes the fault transparent to the application, so in
>> case of fault, redundant machine still can access the files even the
>> master machine is down (replica issue or such a thing).
>> Is there fail-over feature in GlusterFS that satisfy our requirement?
>> Actually, my question is that can GlusterFS help us in our case?
>>
>
> It sounds like you need the AFR/replicate functionality. So yes, GlusterFS
> may fit your requirements, depending on what degree of split-brain
> prevention guarantees you require.
>
> Gordan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20110410/e0b4bb3b/attachment-0003.html>