You can also add the mount option: backupvolfile-server to let the client know the other nodes.
Matthew J Black <dulu...@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, .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 > listGlusteremail@example.com://lists.gluster.org/mailman/listinfo/gluster-users > > > [image: 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 > Glusterfirstname.lastname@example.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 Glusteremail@example.com https://lists.gluster.org/mailman/listinfo/gluster-users