<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/31/2013 08:38 AM, Stephan von
Krawczynski wrote:<br>
</div>
<blockquote cite="mid:20130131173818.f69ff8cd.skraw@ithnet.com"
type="cite">
<pre wrap="">On Thu, 31 Jan 2013 12:47:30 +0000
Brian Candler <a class="moz-txt-link-rfc2396E" href="mailto:B.Candler@pobox.com"><B.Candler@pobox.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Jan 31, 2013 at 09:18:26AM +0100, Stephan von Krawczynski wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
For sure it will not fail if replication is used.
</pre>
</blockquote>
<pre wrap="">
Aside: it will *fail* if the client reboots, and /etc/fstab has
server1:/volname, and server1 is the one which failed.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
That doesn't lend me much confidence in your expertise with regard
to your other recommendations, Stephan.<br>
<br>
There are two good ways to make this work even if a server is down:<br>
<ul>
<li>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").</li>
<li>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.</li>
</ul>
<p>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.<br>
</p>
</body>
</html>