<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>By that same token, you can also use a hostname with multiple A
records and glusterd will use those for failover to retrieve the
vol file.<br>
</p>
<div class="moz-cite-prefix">On 8/31/22 8:32 AM, Joe Julian wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4cd2111c-6a91-8d5a-5d10-310657c05a4e@julianfamily.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Kind-of. That just tells the client what other nodes it can use
to retrieve that volume configuration. It's only used during
that initial fetch.<br>
</p>
<div class="moz-cite-prefix">On 8/31/22 8:26 AM, Péter Károly
JUHÁSZ wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAA01ixPN=Hz2Qdfsf6g=eYu2z+8D=DrM==+D9q6HELsqzBmOg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="auto">You can also add the mount
option: backupvolfile-server to let the client know the other
nodes.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Matthew J Black <<a
href="mailto:duluxoz@gmail.com" moz-do-not-send="true"
class="moz-txt-link-freetext">duluxoz@gmail.com</a>> 于
2022年8月31日周三 17:21写道：<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<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> On 01/09/2022 01:16, Joe Julian wrote:<br>
</div>
<blockquote type="cite">
<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>On 8/31/22 8:04 AM, Matthew J Black wrote:<br>
</div>
<blockquote type="cite">
<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> On 01/09/2022 00:55, Joe Julian wrote:<br>
</div>
<blockquote type="cite">
<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>On 8/30/22 11:55 PM, duluxoz wrote:<br>
</div>
<blockquote type="cite">
<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 <a href="http://192.168.1.1/24"
target="_blank" rel="noreferrer"
moz-do-not-send="true">192.168.1.1/24</a>,
.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></fieldset>
<pre>________
Community Meeting Calendar:
Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: <a href="https://meet.google.com/cpu-eiue-hvk" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">https://meet.google.com/cpu-eiue-hvk</a>
Gluster-users mailing list
<a href="mailto:Gluster-users@gluster.org" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">Gluster-users@gluster.org</a>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.gluster.org/mailman/listinfo/gluster-users</a>
</pre>
</blockquote>
</blockquote>
<div
id="m_-4861399478586633768DAB4FAD8-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" rel="noreferrer"
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="
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"
style="color:#4453ea" target="_blank"
rel="noreferrer" moz-do-not-send="true">www.avast.com</a></td>
</tr>
</tbody>
</table>
<a
href="#m_-4861399478586633768_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"
width="1" height="1" rel="noreferrer"
moz-do-not-send="true"> </a></div>
</blockquote>
</blockquote>
</div>
________<br>
<br>
<br>
<br>
Community Meeting Calendar:<br>
<br>
Schedule -<br>
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
Bridge: <a href="https://meet.google.com/cpu-eiue-hvk"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://meet.google.com/cpu-eiue-hvk</a><br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">Gluster-users@gluster.org</a><br>
<a
href="https://lists.gluster.org/mailman/listinfo/gluster-users"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote>
</div>
</blockquote>
<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">https://meet.google.com/cpu-eiue-hvk</a>
Gluster-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="https://lists.gluster.org/mailman/listinfo/gluster-users">https://lists.gluster.org/mailman/listinfo/gluster-users</a>
</pre>
</blockquote>
</body>
</html>