Re: Server-side AFR + Failover and mixed server/client-side AFR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 6, 2008 at 9:45 PM, Derek Price <derek@xxxxxxxxxxx> wrote:
> Krishna Srinivas wrote:
>
> >
> > >  >  Is this an issue in server-side-only AFR? I have two servers which
> are also
> > >  > clients of themselves, and they both list their local subvolume first
> and
> > >  > remote subvolume second. Is this a problem? What are the possible
> > >  > consequences of this?
> > >
> > >  It will be a problem. The "first" subvol is always the "lock" server.
> > >  Consider a case where you are creating a file simultaneously
> > >  on two clients, only one of them should succeed. If AFR's
> > >  subvols order are not same, chances are that both client
> > >  returns success for file creation with same name.
> > >
> >
> > Hence you have "option read-subvlume" to speeden the
> > read() calls so that it can be done from local subvol.
> >
>
>  So, what happens if the "lock" server is the one that goes down?  Will that
> render the whole AFR cluster inoperable, at least for writes?
>

If first server is down, the second one is tried and so on. The cluster remains
operable.

Krishna

>  Why not arrange some sort of voting system for AFR locks, where no specific
> server, but rather half of the listed servers (maybe the first server listed
> gets an extra vote in the case of an even number of servers) have to agree
> to assign the lock (and increment the version # without receiving the data).
> Then writes could also be done locally and synchronized at leisure.
>
>  Derek
>  --
>  Derek R. Price
>  Solutions Architect
>  Ximbiot, LLC <http://ximbiot.com>
>  Get CVS and Subversion Support from Ximbiot!
>
>  v: +1 248.835.1260
>  f: +1 248.246.1176
>




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux