[Gluster-users] Per-client prefered server?

[Yannick Perret]

Le 03/03/2016 15:07, Krutika Dhananjay a écrit :
> Ok, and what version of glusterfs are you using?
At this time I'm using glusterfs 3.6.7 on Debian 8 (64bit), same OS on 
servers and clients.

--
Y.
>
> -Krutika
> ------------------------------------------------------------------------
>
>     *From: *"Yannick Perret" <yannick.perret at liris.cnrs.fr>
>     *To: *"Krutika Dhananjay" <kdhananj at redhat.com>
>     *Cc: *gluster-users at gluster.org
>     *Sent: *Thursday, March 3, 2016 7:23:09 PM
>     *Subject: *Re: [Gluster-users] Per-client prefered server?
>
>     Le 03/03/2016 13:18, Krutika Dhananjay a écrit :
>
>         What does "nearest" storage server mean? Are the clients
>         residing in the storage pool too? Or are they external to the
>         cluster?
>
>     They are external.
>     Nearest means that they are in the same building, linked by the
>     same switch. Machines in the other building are rooted via some
>     more equipments.
>
>     --
>     Y.
>
>         -Krutika
>         ------------------------------------------------------------------------
>
>             *From: *"Yannick Perret" <yannick.perret at liris.cnrs.fr>
>             *To: *gluster-users at gluster.org
>             *Sent: *Thursday, March 3, 2016 5:38:33 PM
>             *Subject: *[Gluster-users] Per-client prefered server?
>
>             Hello,
>
>             I can't find if it is possible to set a prefered server on
>             a per-client
>             basis for replica volumes, so I ask the question here.
>
>             The context: we have 2 storage servers, each in one
>             building. We also
>             have several virtual machines on each building, and they
>             can migrate
>             from one building to an other (depending on load,
>             maintenance…).
>
>             So (for testing at this time) I setup a x2 replica volume,
>             one replica
>             on each storage server of course. As most of our volumes
>             are "many reads
>             - few writes" it would be better for bandwidth that each
>             client uses the
>             "nearest" storage server (local building switch) - for
>             reading, of
>             course. The 2 buildings have a good netlink but we prefer
>             to minimize -
>             when not needed - data transferts beetween them (this link
>             is shared).
>
>             Can you see a solution for this kind of tuning? As far as
>             I understand
>             geo-replica is not really what I need, no?
>
>             It exists "cluster.read-subvolume" option of course but we
>             can have
>             clients on both building so a per-volume option is not
>             what we need. An
>             per-client equivalent of this option should be nice.
>
>             I tested by myself a small patch to perform this - and it
>             seems to work
>             fine as far as I can see - but 1. before continuing in
>             this way I would
>             first check if it exists an other way and 2. I'm not
>             familiar with the
>             whole code so I'm not sure that my tests are in the
>             "state-of-the-art"
>             for glusterfs.
>
>             Thanks in advance for any help.
>
>             Regards,
>             --
>             Y.
>
>
>
>             _______________________________________________
>             Gluster-users mailing list
>             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/20160303/b31632fe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3369 bytes
Desc: Signature cryptographique S/MIME
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160303/b31632fe/attachment.p7s>