[Gluster-users] How gluster parallelize reads
Jeff Darcy
jdarcy at redhat.com
Mon Oct 3 19:42:09 UTC 2016
> Anyway, in gerrit you are talking about "local" reads. How could you
> have a "local" read? This would be possible only mounting the volume
> locally on a server. is this a supported configuration?
Whether or not it's supported for native protocol, it's a common case
when using NFS or SMB with the servers for those protocols appearing
as native-protocol clients on the server machines.
> Probably, a "priority" could be added in mount option, so that when
> mounting the gluster volume i can set the preferred host for reads.
>
> Something like this:
>
> mount -t glusterfs -o preferred-read-host=1.2.3.4 server1:/test-volume
> /mnt/glusterfs
It's a great idea that would work well for a volume containing a single
replica set, but what about when that volume contains multiple? Specify
a preferred read source for each? Even that will get tricky when we
start to work around the limitation of adding bricks in multiples of the
replica count. Then we'll be building new replica sets "automatically"
so the user would have to keep re-examining the volume structure to
decide on a new priority list. Also, what should we do if that priority
list is "pathological" in the sense of creating unnecessary hot spots?
Should we accept it as an expression of the user's will anyway, or
override it to ensure continued smooth operation?
IMO we should try harder to find the right answers *autonomously*,
perhaps based on user-specified relationships between client networks
and servers. (Ceph does some of this in their CRUSH maps, but I think
that conflates separate problems of managing placement and traffic.) To
look at it another way, we'd be doing the same calculations the user
might do to create that explicit priority list, except we'd be in a
better position to *re*calculate that list when appropriate. We're
thinking about some of this in the context of handling multiple networks
better in general, but it's still a bit of a research effort because
AFAICT nobody else has come up with much empirically-backed research to
guide solutions.
More information about the Gluster-users
mailing list