[Gluster-users] How Does Gluster Failover
Joe Julian
joe at julianfamily.org
Wed Aug 31 15:34:27 UTC 2022
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.
On 8/31/22 8:32 AM, Joe Julian wrote:
>
> 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.
>
> On 8/31/22 8:26 AM, Péter Károly JUHÁSZ wrote:
>> You can also add the mount option: backupvolfile-server to let the
>> client know the other nodes.
>>
>> Matthew J Black <duluxoz at gmail.com> 于 2022年8月31日周三 17:21写道：
>>
>> 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.
>>
>> Thank you for taking the time to educate a poor newbie - it is
>> very much appreciated.
>>
>> Cheers
>>
>> Dulux-Oz
>>
>> On 01/09/2022 01:16, Joe Julian wrote:
>>>
>>> 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
>>>>
>>>> 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 <http://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>
>>>>
>>>>
>>>> <#m_-4861399478586633768_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ________
>>
>>
>>
>> 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
>>
>
> ________
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20220831/a171a356/attachment.html>
More information about the Gluster-users
mailing list