<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Times New Roman, Times, serif">Ah, it all now falls
into place: I was unaware that the client receives that file
upon initial contact with the cluster, and thus has that
information at hand independently of the cluster nodes.</font></p>
<p><font face="Times New Roman, Times, serif">Thank you for taking
the time to educate a poor newbie - it is very much appreciated.</font></p>
<p><font face="Times New Roman, Times, serif">Cheers</font></p>
<p><font face="Times New Roman, Times, serif">Dulux-Oz</font><br>
</p>
<div class="moz-cite-prefix">
<title>PEREGRINE IT Signature</title>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
On 01/09/2022 01:16, Joe Julian wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b8c20b86-fde7-e3ab-dc90-ea75697db74a@julianfamily.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>You know when you do a `gluster volume info` and you get the
whole volume definition, the client graph is built from the same
info. In fact, if you look in
/var/lib/glusterd/vols/$volume_name you'll find some ".vol"
files. `$volume_name.tcp-fuse.vol` is the configuration that the
clients receive from whichever server they initially connect to.
You'll notice that file has multiple "type/client" sections,
each establishing a tcp connection to a server.<br>
<br>
Sidenote: You can also see in that file, how the microkernels
are used to build all the logic that forms the volume, which is
kinda cool. Back when I first started using gluster, there was
no glusterd and you have to build those .vol files by hand.<br>
</p>
<div class="moz-cite-prefix">On 8/31/22 8:04 AM, Matthew J Black
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e8183f56-c910-7403-c607-e9aa5143fa05@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p><font face="Times New Roman, Times, serif">Hi Joe,</font></p>
<p><font face="Times New Roman, Times, serif">Thanks for getting
back to me about this, it was helpful, and I really
appreciate it.</font></p>
<p><font face="Times New Roman, Times, serif">I am, however,
still (slightly) confused - *how* does the client "know" the
addresses of the other servers in the cluster (for read or
write purposes), when all the client has is the line in the
fstab file: "</font><font face="Times New Roman, Times,
serif"><font size="1"><font face="Arial">gfs1:gv1
/data/gv1 glusterfs defaults 0 2</font></font>"? I'm
missing something, somewhere, in all of this, and I can't
work out what that "something" is. :-)</font></p>
<p><font face="Times New Roman, Times, serif">Your help truely
is appreciated</font></p>
<p><font face="Times New Roman, Times, serif">Cheers</font></p>
<p><font face="Times New Roman, Times, serif">Dulux-Oz</font><br>
</p>
<div class="moz-cite-prefix">
<title>PEREGRINE IT Signature</title>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
On 01/09/2022 00:55, Joe Julian wrote:<br>
</div>
<blockquote type="cite"
cite="mid:712baf67-b380-7164-56a4-5f5dc1cb92f6@julianfamily.org">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>With a replica volume the client connects and writes to all
the replicas directly. For reads, when a filename is looked
up the client checks with all the replicas and, if the file
is healthy, opens a read connection to the first replica to
respond (by default).<br>
<br>
If a server is shut down, the client receives the tcp
messages that close the connection. For read operations, it
chooses the next server. Writes will just continue to the
remaining replicas (metadata is stored in extended
attributes to inform future lookups and the self-healer of
file health).<br>
<br>
If a server crashes (no tcp finalization) the volume will
pause for ping-timeout seconds (42 by default). Then
continue as above. BTW, that 42 second timeout shouldn't be
a big deal. The MTBF should be sufficiently far apart that
this should still easily get you five or six nines.<br>
</p>
<div class="moz-cite-prefix">On 8/30/22 11:55 PM, duluxoz
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:143833e4-3a44-c9b3-86ba-dd050c1a5d8f@gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<p><font size="1"><font face="Arial">Hi Guys & Gals,</font></font></p>
<p><font size="1"><font face="Arial">A Gluster newbie
question for sure, but something I just don't "get"
(or I've missed in the doco, mailing lists, etc):</font></font></p>
<p><font size="1"><font face="Arial">What happens to a
Gluster Client when a Gluster Cluster Node goes
off-line / fails-over?</font></font></p>
<p><font size="1"><font face="Arial">How does the Client
"know" to use (connect to) another Gluster Node in the
Gluster Cluster?</font></font></p>
<p><font size="1"><font face="Arial">Let me elaborate.</font></font></p>
<p><font size="1"><font face="Arial">I've got four hosts:
gfs1, gfs2, gfs3, and client4 sitting on
192.168.1.1/24, .2, .3, and .4 respectively.</font></font></p>
<p><font size="1"><font face="Arial"><font size="1"><font
face="Arial">DNS is set up and working correctly.</font></font></font></font></p>
<p><font size="1"><font face="Arial">gfs1, gs2, and gfs3
form a "Gluster Cluster" with a Gluster Volume (gv1)
replicated across all three nodes. This is all working
correctly (ie a file (file1) created/modified on
gfs1:/gv1 is replicated correctly to </font></font><font
size="1"><font face="Arial">gfs2:/gv1 and </font></font><font
size="1"><font face="Arial">gfs3:/gv1).</font></font></p>
<p><font size="1"><font face="Arial">client4 has an entry in
its /etc/fstab file which reads: "gfs1:gv1 /data/gv1
glusterfs defaults 0 2". This is also all working
correctly (ie client4:/data/gv1/file1 is accessible
and replicated).<br>
</font></font></p>
<p><font size="1"><font face="Arial">So, (and I haven't
tested this yet) what happens to </font></font><font
size="1"><font face="Arial">client4:/data/gv1/file1 when
gfs1 fails (ie is turned off, crashes, etc)?</font></font></p>
<p><font size="1"><font face="Arial">Does client4
"automatically" switch to using one of the other two
Gluster Nodes, or do I have something wrong in
clients4's /etc/fstab file, or an
error/mis-configuration somewhere else?</font></font></p>
<p><font size="1"><font face="Arial">I thought about setting
some DNS entries along the lines of:</font></font></p>
<p><font size="1"><font face="Arial">~~~<br>
</font></font></p>
<p><font size="1"><font face="Arial">glustercluster IN A
192.168.0.1<br>
</font></font></p>
<p><font size="1"><font face="Arial"><font size="1"><font
face="Arial">glustercluster IN A 192.168.0.2</font></font></font></font></p>
<p><font size="1"><font face="Arial"><font size="1"><font
face="Arial"><font size="1"><font face="Arial">glustercluster
IN A 192.168.0.3</font></font></font></font></font></font></p>
<p><font size="1"><font face="Arial">~~~<br>
</font></font></p>
<p><font size="1"><font face="Arial">and having </font></font><font
size="1"><font face="Arial">clients4's /etc/fstab file
read: "</font></font><font size="1"><font face="Arial">glustercluster</font></font><font
size="1"><font face="Arial"><font size="1"><font
face="Arial">:gv1 /data/gv1 glusterfs defaults
0 2</font></font>", but this is a Round-Robin DNS
config and I'm not sure how Gluster treats this
situation.</font></font></p>
<p><font size="1"><font face="Arial">So, if people could
comment / point me in the correct direction I would
really appreciate it - thanks.</font></font></p>
<p><font size="1"><font face="Arial">Dulux-Oz<br>
</font></font></p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">________
Community Meeting Calendar:
Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: <a class="moz-txt-link-freetext" href="https://meet.google.com/cpu-eiue-hvk" moz-do-not-send="true">https://meet.google.com/cpu-eiue-hvk</a>
Gluster-users mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:Gluster-users@gluster.org" moz-do-not-send="true">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="https://lists.gluster.org/mailman/listinfo/gluster-users" moz-do-not-send="true">https://lists.gluster.org/mailman/listinfo/gluster-users</a>
</pre>
</blockquote>
</blockquote>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<table style="border-top: 1px solid #D3D4DE;">
<tbody>
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient"
target="_blank" moz-do-not-send="true"><img
src="https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
alt=" width=" 46"="" style="width: 46px; height:
29px;" moz-do-not-send="true" height="29"></a></td>
<td style="width: 470px; padding-top: 12px; color:
#41424e; font-size: 13px; font-family: Arial,
Helvetica, sans-serif; line-height: 18px;">Virus-free.<a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient"
target="_blank" style="color: #4453ea;"
moz-do-not-send="true">www.avast.com</a></td>
</tr>
</tbody>
</table>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1" moz-do-not-send="true"> </a></div>
</blockquote>
</blockquote>
</body>
</html>