On 01/31/2013 08:38 AM, Stephan von Krawczynski wrote:
On Thu, 31 Jan 2013 12:47:30 +0000
Brian Candler <[email protected]> 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.
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
