[Gluster-users] New user questions - behavior of HA setup with network failure

[Raghavendra G]

Hi Robert,

On Tue, Jan 27, 2009 at 11:29 PM, Robert Gormley <rgormley at mgcare.com>wrote:

> Hi all,
>
> Forgive the new-ish-ness of this question - I am reading through the docs,
> just trying to digest as much as possible as quickly as possible.
>
> We're looking at a project - two sites, two servers, with the intent that
> they be "highly available" - not 'completely transparent to user', but 'back
> within 15 minutes or less'.
>
> There -may- be load balancing, but that would be down the road, though see
> my question below.
>
> My belief from reading is that setting up similar to the Tutorial Simple HA
> would be sufficient. What is the behavior in the event of a network outage.
> I would believe that both file systems start in sync, everything written to
> their ext3 filesystem. If Gluster detects the remote node is unavailable,
> how will it respond / re-sync? I read of 'split braining' which is probably
> sufficient for our needs (management is prepared to accept that if someone
> is working on a case in our application at the time of "disaster" or other
> outage, there may be some data / transaction loss).


I think you are mixing up both AFR (replicate) and HA. 'split brain'
situation does not occur if you're using only HA, since there is only one
copy of data. But the path accessing to that single copy is made 'highly
available' using HA. Generally HA has different physical links connecting
the same server, which has data as its children.

'split brain' can happen in AFR. You might need AFR if you want  mirroring
capability (which also offers high availability here).


>
> But does anything else occur? Or can anything else be done, in the sense
> of: Detection of outage, locking of files (although this could be done by
> another mechanism), until an admin manually designates (or changes) the
> "favorite child" option so we can have some semblance of 'control', i.e. a
> replicating high availability set, but with a designated 'master'.


Afr can handle the replication automatically. It requires manual
intervention only in case of 'split brain' situations in the form of copying
the file manually from the node which is perceived to be latest by the
admin. Even this is handled by option "favorite child" as you mentioned.


>
> Forgive the at times vague language, feel free to ask for clarification,
> and my apologies if I'm misusing any Gluster terms, etc.
>
> Re load balancing - how does Gluster handle concurrent writes to a file
> from two different servers? Is, for example, the appropriate lock only
> returned from the filesystem call when it has been communicated to the other
> node?


The writes are atomic. But If you need ordering b/w the write s, you've to
use locks the same way they would be used on a local filesystem.


>
> Thank you so much,
>
> Robert Gormley
> Senior Web Developer
> Managed Care Systems, Inc. | 32531 N. Scottsdale Rd Suite 105, Scottsdale
> AZ 85266
> Phone: 623.434.3881 x109 | Email: rgormley at mgcare.com
> Web: www.mgcare.com | www.impactservicecenter.com
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>


regards,
-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090128/cff6cec5/attachment.html>