[Gluster-devel] RFC - "Connection Groups" concept

Justin Clift jclift at redhat.com
Thu Jun 27 20:16:45 UTC 2013


On 27/06/2013, at 8:07 PM, Anand Avati wrote:
<snip>
> Another approach might be to just store the UUID of the host in the client volfile, as remote-uuid (instead of remote-host option). The client can query the mount server to resolve the UUID to a host at that point in time with a HOSTMAPPER service (like our PORTMAPPER server which maps bricks to ports). This hostmapper can maintain the relationship of all the host UUIDs in the trusted pool to all their respective interface IPs, and use the interface of the incoming mapping request to perform appropriate mapping. When in doubt, it can always return the entire set of IPs of a host (with transport types) and let the client figure out which of those IPs are routable and maybe even autodetect which is the fastest. E.g your server might have both 1g/e and 10g/e, and only some of your clients have 10g/e. In such cases this kind of auto discovery at mount time might be desirable.
> 
> Thoughts?

Potentially very dynamic, and less controllable.  Could be a good way to go
for cloud scale. :)

The hostmapper idea is also interesting, because over time people could
develop some very interesting algorithms for optimising that.  Plugin
model? :)

It doesn't sound that optimal for some non-cloud-scale environments (I'm
thinking some corporate/enterprise/government).  The places I've personally
worked have dedicated networks for things, and dynamic stuff like this
could be a pita.  (note "could" not "would be in every case")

It would be nice if we could specify which network to use on a per volume
basis for at least some volumes (eg "use the  trusted network for volume X
for PCI compliance").  But that doesn't necessarily preclude having other
volumes select their networks automatically.

Any ideas on how to work that into your concept too? :)

Regards and best wishes,

Justin Clift

--
Open Source and Standards @ Red Hat

twitter.com/realjustinclift





More information about the Gluster-devel mailing list