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

[Anand Avati]

On Thu, Jun 27, 2013 at 1:16 PM, Justin Clift <address@hidden> wrote:

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? :)

You can already do that by limiting allowing or rejecting access to each volume from a certain subnet (which can map to the subnet of the network you wish you rule in/out). Wouldn't that just work?

Avati