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

[Anand Avati]

On Thu, Jun 27, 2013 at 1:16 PM, Justin Clift <jclift at redhat.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130627/7fe47259/attachment-0001.html>