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

[Justin Clift]

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