[Gluster-users] NFS availability

[Joe Julian]

On 01/31/2013 08:38 AM, Stephan von Krawczynski wrote:
> On Thu, 31 Jan 2013 12:47:30 +0000
> Brian Candler <B.Candler at pobox.com> wrote:
>
>> On Thu, Jan 31, 2013 at 09:18:26AM +0100, Stephan von Krawczynski wrote:
>>>> The client will still fail (in most cases) since host1 (if I follow you) is
>>>> part of the gluster groupset. Certainly if it's a distributed-only, maybe not
>>>> if it's a dist/repl gluster.  But if host1 goes down, the client will not be
>>>> able to find a gluster vol to mount.
>>> For sure it will not fail if replication is used.
>> Aside: it will *fail* if the client reboots, and /etc/fstab has
>> server1:/volname, and server1 is the one which failed.
> Well, this is exactly the reason we generally deny to fetch the volfile from
> the server. This whole idea is obvious nonsense for exactly the reason you
> described.
>
That doesn't lend me much confidence in your expertise with regard to 
your other recommendations, Stephan.

There are two good ways to make this work even if a server is down:

  * Round robin DNS. A hostname (ie. glusterfs.domain.dom) with multiple
    A records that point to all your servers. Using that hostname in
    fstab will allow the client to roll over to the additional servers
    in the event the first one it gets is not available (ie.
    "glusterfs.domain.dom:myvol /mnt/myvol glusterfs defaults 0 0").
  * The mount option backupvolfile-server. An fstab entry like
    "server1:myvol /mnt/myvol glusterfs backupvolfile-server=server2 0
    0" will allow the mount command to try server2 if server1 does not
    mount successfully.

This whole idea is obvious experience and forethought, not nonsense. By 
having a management service that provides configuration, on-the-fly 
configuration changes are possible. If one "denies to fetch the volfile" 
one cripples their cluster's flexibility.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130131/5013c7ed/attachment.html>