[Gluster-users] using a preferred node ?

Ravishankar N ravishankar at redhat.com
Mon Jun 8 06:32:30 UTC 2015



On 06/08/2015 11:51 AM, Mathieu Chateau wrote:
> From this slide (maybe outdated) it says that reads are also balanced 
> (in replication scenario slide 22):
> http://www.gluster.org/community/documentation/images/8/80/GlusterFS_Architecture_%26_Roadmap-Vijay_Bellur-LinuxCon_EU_2013.pdf
>
> Except for write, having an option to do only "failover" for reads & 
> lookup would be possible I guess ?
>

Lookups have to be sent to both bricks because AFR uses the response to 
determine if there is a stale copy etc (and then serve from the good 
copy).  For reads, if a client is also mounted on the same machine as 
the brick, reads will be served from that brick automatically. You can 
also use the cluster.read-subvolume option to explicitly force the 
client to read from a brick:

/`gluster volume set help//`
//
<snip>//
//
Option: cluster.read-subvolume//
//Default Value: (null)//
//Description: inode-read fops happen only on one of the bricks in 
replicate. Afr will prefer the one specified using this option if it is 
not stale. Option value must be one of the xlator names of the children. 
Ex: <volname>-client-0 till <volname>-client-<number-of-bricks - 1>//
//
//</snip>//
//
/
>
> Cordialement,
> Mathieu CHATEAU
> http://www.lotp.fr
>
> 2015-06-08 8:11 GMT+02:00 Ravishankar N <ravishankar at redhat.com 
> <mailto:ravishankar at redhat.com>>:
>
>
>
>     On 06/08/2015 11:34 AM, Mathieu Chateau wrote:
>>     Hello Ravi,
>>
>>     thanks for clearing things up.
>>
>>     Anything on the roadmap that would help my case?
>>
>
>
>     I don't think it would be possible for clients to do I/O only on
>     its local brick and yet expect the bricks' contents to be in sync
>     in real-time..
>
>
>
>>     Cordialement,
>>     Mathieu CHATEAU
>>     http://www.lotp.fr
>>
>>     2015-06-08 6:37 GMT+02:00 Ravishankar N <ravishankar at redhat.com
>>     <mailto:ravishankar at redhat.com>>:
>>
>>
>>
>>         On 06/06/2015 12:49 AM, Mathieu Chateau wrote:
>>>         Hello,
>>>
>>>         sorry to bother again but I am still facing this issue.
>>>
>>>         client still looks on the "other side" and not using the
>>>         node declared in fstab:
>>>         prd-sta-sto01:/gluster-preprod
>>>         /mnt/gluster-preprod glusterfs
>>>         defaults,_netdev,backupvolfile-server=prd-sta-sto02 0 0
>>>
>>>         I expect client to use sto01 and not sto02 as it's available.
>>
>>         Hi Mathieu,
>>         When you do lookups (`ls` etc), they are sent to both bricks
>>         of the replica. If you write to a file, the write is also
>>         sent to both bricks. This is how it works. Only reads are
>>         served from the local brick.
>>         -Ravi
>>
>>
>>>
>>>         If I add a static route to break connectivity to sto02 and
>>>         do a "df", I have around 30s before it works.
>>>         Then it works ok.
>>>
>>>         Questions:
>>>
>>>           * How to force node to stick as possible with one specific
>>>             (local) node ?
>>>           * How to know where a client is currently connected?
>>>
>>>         Thanks for your help :)
>>>
>>>
>>>         Cordialement,
>>>         Mathieu CHATEAU
>>>         http://www.lotp.fr
>>>
>>>         2015-05-11 7:26 GMT+02:00 Mathieu Chateau
>>>         <mathieu.chateau at lotp.fr <mailto:mathieu.chateau at lotp.fr>>:
>>>
>>>             Hello,
>>>
>>>             thanks for helping :)
>>>
>>>             If gluster server is rebooted, any way to make client
>>>             failback on node after reboot ?
>>>
>>>             How to know which node is using a client ? I see TCP
>>>             connection to both node
>>>
>>>             Regards,
>>>
>>>             Cordialement,
>>>             Mathieu CHATEAU
>>>             http://www.lotp.fr
>>>
>>>             2015-05-11 7:13 GMT+02:00 Ravishankar N
>>>             <ravishankar at redhat.com <mailto:ravishankar at redhat.com>>:
>>>
>>>
>>>
>>>                 On 05/10/2015 08:29 PM, Mathieu Chateau wrote:
>>>>                 Hello,
>>>>
>>>>                 Short way: Is there any way to define a preferred
>>>>                 Gluster server ?
>>>>
>>>>                 Long way:
>>>>                 I have the following setup (version 3.6.3) :
>>>>
>>>>                 Gluster A  <==> VPN <==> Gluster B
>>>>
>>>>                 Volume is replicated between A and B.
>>>>
>>>>                 They are in same datacenter, using a 1Gb/s
>>>>                 connection, low latency (0.5ms)
>>>>
>>>>                 I have gluster clients in lan A & B.
>>>>
>>>>                 When doing a "ls" on big folder (~60k files), both
>>>>                 gluster node are used, and so it need 9mn instead
>>>>                 on 1mn if only the local gluster is reachable.
>>>>
>>>
>>>                 Lookups (and writes of course) from clients are sent
>>>                 to both  bricks because AFR uses the result of the
>>>                 lookup to select which brick to read from if there
>>>                 is a pending heal etc.
>>>                 If the file is clean on both A and B, then reads are
>>>                 always served from the local brick. i.e. reads on
>>>                 clients mounted on A will be served from the brick
>>>                 in A (and likewise for B).
>>>
>>>                 Hope that helps,
>>>                 Ravi
>>>
>>>
>>>>                 It's HA setup, application is present on both side.
>>>>                 I would like a master/master setup, but using only
>>>>                 local node as possible.
>>>>
>>>>
>>>>                 Regards,
>>>>                 Mathieu CHATEAU
>>>>                 http://www.lotp.fr
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 Gluster-users mailing list
>>>>                 Gluster-users at gluster.org  <mailto:Gluster-users at gluster.org>
>>>>                 http://www.gluster.org/mailman/listinfo/gluster-users
>>>
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20150608/7d638a67/attachment.html>


More information about the Gluster-users mailing list