[Gluster-users] How Does Gluster Failover

Matthew J Black duluxoz at gmail.com
Wed Aug 31 15:04:09 UTC 2022


Hi Joe,

Thanks for getting back to me about this, it was helpful, and I really 
appreciate it.

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: 
"gfs1:gv1  /data/gv1  glusterfs defaults  0 2"? I'm missing something, 
somewhere, in all of this, and I can't work out what that "something" 
is.  :-)

Your help truely is appreciated

Cheers

Dulux-Oz

PEREGRINE IT Signature On 01/09/2022 00:55, Joe Julian wrote:
>
> 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).
>
> 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).
>
> 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.
>
> On 8/30/22 11:55 PM, duluxoz wrote:
>>
>> Hi Guys & Gals,
>>
>> A Gluster newbie question for sure, but something I just don't "get" 
>> (or I've missed in the doco, mailing lists, etc):
>>
>> What happens to a Gluster Client when a Gluster Cluster Node goes 
>> off-line / fails-over?
>>
>> How does the Client "know" to use (connect to) another Gluster Node 
>> in the Gluster Cluster?
>>
>> Let me elaborate.
>>
>> I've got four hosts: gfs1, gfs2, gfs3, and client4 sitting on 
>> 192.168.1.1/24, .2, .3, and .4 respectively.
>>
>> DNS is set up and working correctly.
>>
>> 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 gfs2:/gv1 and gfs3:/gv1).
>>
>> 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).
>>
>> So, (and I haven't tested this yet) what happens to 
>> client4:/data/gv1/file1 when gfs1 fails (ie is turned off, crashes, etc)?
>>
>> 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?
>>
>> I thought about setting some DNS entries along the lines of:
>>
>> ~~~
>>
>> glustercluster  IN  A 192.168.0.1
>>
>> glustercluster  IN  A  192.168.0.2
>>
>> glustercluster IN  A  192.168.0.3
>>
>> ~~~
>>
>> and having clients4's /etc/fstab file read: "glustercluster:gv1  
>> /data/gv1  glusterfs  defaults  0 2", but this is a Round-Robin DNS 
>> config and I'm not sure how Gluster treats this situation.
>>
>> So, if people could comment / point me in the correct direction I 
>> would really appreciate it - thanks.
>>
>> Dulux-Oz
>>
>>
>> ________
>>
>>
>>
>> Community Meeting Calendar:
>>
>> Schedule -
>> Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
>> Bridge:https://meet.google.com/cpu-eiue-hvk
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-users

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20220901/c637a2a9/attachment.html>


More information about the Gluster-users mailing list