Re: Gluster FS Native Client Behaviour (3.7)

[Ravishankar N <ravishankar@xxxxxxxxxx>]

On 02/03/2016 08:03 PM, Peter Spain wrote:

Hello

I am very new to GlusterFS and have been playing around with over the last few weeks, with a view to using it in production. So far I found Gluster to be very interesting and easy to get along with. However, there seems to be a giant hole where the Gluster Native Client documentation should live.

After using it for a few weeks and playing around (inside various VMs) I am still not entirely sure how the client behaves.

From network captures it is clear that the client communicates to all the nodes for a particular volume, and that the client gets this information from a volfile (which it retrieves when mounting a volume). Various blog posts confirm this and go on to mention that the client is responsible for replicating data across nodes, and not the nodes themselves. I assume this is still the case?

That is correct. The client volfile dictates what translators are loaded on the client process. You can look at the various volfiles in /var/lib/glusterd/vols/<volname> on the server to get an idea of what xlators are loaded for different processes and how they are stacked to form a graph. The graph is also printed in the log files of each process as it starts. Each xlator does a specific function. The replication xlator (AFR) is a client xlator that is loaded (among others) on the client graph in case of replicated volumes and has the replication logic.

Beyond that I really have no idea how the client behaves in a replicated volume.

If you specifically want to know how AFR works, you can see https://github.com/gluster/glusterfs-specs/blob/master/done/Features/afr-v1.md. It is a bit dated but the most of it is still valid.

My questions are:

There is a "ping-timeout" option to adjust how long it takes the client to connect to a different node, in case of node failure.

Actually, it is the time duration for which the client waits to check if the server is responsive. (see `gluster volume help`), even after connection is established.

If the client knows about all nodes and actively communicates with all of them, why does it need a time out at all?

You would need some sort of a heartbeat for the clients to know that its connection to servers are still intact or lost because a brick went down or there was a network disconnect etc.

Why does the client "stick" to a particular node?

Not sure what you mean. The client process connects to all the bricks of the volume. Open one of the client volfiles (or the logfile) and study the graph, you'll see many 'protocol/client' xlators, one for each brick that the client needs to talk to.

Does the client go back to the original node once it recovers?

Is it possible to dictate which node a client will initially connect to on mounting a volume?

Like I said, the client connects to all bricks of the volume.

If all this information is contained in some documentation I would love to be pointed to it, as so far I cannot find the answer to these questions.

There are many presentations you can find online on glusterfs architecture. https://gluster.readthedocs.org/en/latest/ is another good start.

Hope that helps,
Ravi

Regards

Peter

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users