[Gluster-users] Lightweight read

[Strahil Nikolov]

On April 30, 2020 1:13:17 AM GMT+03:00, David Cunningham <dcunningham at voisonics.com> wrote:
>Hi Strahil,
>
>Thanks for the tip about choose-local. Am I right in thinking that it
>only
>applies to reads on a GlusterFS server node itself, and not on
>GlusterFS
>clients?
Yes , cluster.choose-local is valid only for workload happening on a gluster node  and not on a separate client.


>If so then perhaps the effect could be expanded to clients by using NFS
>to
>access the GlusterFS server instead of the GlusterFS native client.
Theoretically, with native NFS it should be the same.Why do you try to achieve the client reading from a specific node only ? After all this will be a single point of failiure in case the node goes down and the writes  will be executed only on that node , so the cluster has to do some healing in the background.

NFS ganesha might be a possible solution, as it doesn't use FUSE , but instead libgfapi and has a connection to all replica bricks. With Ganesha, you will need to take care of the clusterization itself, but this can easily be achieved with either pacemaker or ctdb.


>BTW, under normal circumstances when the client checks all bricks, does
>that include checking an arbiter? Or are arbiters not checked?

They have to check the metadata on the arbiter, and thus all clients with FUSE mounts need to have access  to all nodes (including arbiter). You can imagine what will happen if metadata on brick1 is blaming brick2 and the opposite on the brick2 - then only metadata at the Arbiter level can show us which data is good and which has to be fixed.

>
>On Sat, 25 Apr 2020 at 19:41, Strahil Nikolov <hunter86_bg at yahoo.com>
>wrote:
>
>> On April 25, 2020 9:00:30 AM GMT+03:00, David Cunningham <
>> dcunningham at voisonics.com> wrote:
>> >Hi Ravi,
>> >
>> >Thank you for the reply, and yes they are replica volumes. Is it
>> >possible
>> >to improve performance by the client only accessing its configured
>> >server
>> >for reads, or would the difference be negligible?
>> >
>> >
>> >On Fri, 24 Apr 2020 at 18:46, Ravishankar N <ravishankar at redhat.com>
>> >wrote:
>> >
>> >>
>> >> On 24/04/20 11:42 am, David Cunningham wrote:
>> >>
>> >> Hello,
>> >>
>> >> My understanding is that GlusterFS checks with all nodes when
>> >performing a
>> >> read. Is it possible to just get the data from the node directly
>> >being
>> >> accessed (in our case using the GlusterFS client), without
>consulting
>> >with
>> >> the other nodes?
>> >>
>> >> Our application requires the GFS file to be available, but it's
>> >actually
>> >> not critical if we end up with an old version of the file in the
>case
>> >of a
>> >> server down or net-split etc. Significantly improved read
>performance
>> >would
>> >> be desirable instead.
>> >>
>> >> I assume you are talking about replica volumes, in which case the
>> >read
>> >> does happen from only one of the replica bricks. The client only
>> >sends
>> >> lookups to all the bricks to figure out which are the good copies.
>> >Post
>> >> that, the reads themselves are served from only one of the good
>> >copies.
>> >>
>> >> -Ravi
>> >>
>> >>
>> >> Thanks in advance for any help.
>> >>
>> >> --
>> >> David Cunningham, Voisonics Limited
>> >> http://voisonics.com/
>> >> USA: +1 213 221 1092
>> >> New Zealand: +64 (0)28 2558 3782
>> >>
>> >> ________
>> >>
>> >>
>> >>
>> >> Community Meeting Calendar:
>> >>
>> >> Schedule -
>> >> Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
>> >> Bridge: https://bluejeans.com/441850968
>> >>
>> >> Gluster-users mailing
>> >listGluster-users at gluster.orghttps://
>> lists.gluster.org/mailman/listinfo/gluster-users
>> >>
>> >>
>>
>> Hey David,
>> There  is a  cluster.choose-local  (I  think  it was 'cluster , but I
>> could be wrong) option that allows a node  to read  locally - in my
>case
>> I'm using it cause my network is slower than my NVMe so reads over
>the
>> network are slow.
>>
>> Best Regards,
>> Strahil Nikolov
>>