[Gluster-users] How Does Gluster Failover

[Joe Julian]

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.

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.

On 8/31/22 8:04 AM, Matthew J Black wrote:
>
> 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
>
> width= 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virus-free.www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20220831/786f2611/attachment.html>