[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gluster-devel] RFC - "Connection Groups" concept
From: |
Justin Clift |
Subject: |
Re: [Gluster-devel] RFC - "Connection Groups" concept |
Date: |
Thu, 27 Jun 2013 20:21:11 +0100 |
On 27/06/2013, at 8:07 PM, Anand Avati wrote:
<snip>
> To figure out which connection a client has to use, we could do auto-discover
> at the time of GETSPEC depending on which network interface the GETSPEC
> request is coming in from. We already have per transport client volfiles (one
> for tcp, one for rdma), and extending it to per network is natural. Today we
> ask the client to specify the transport type in GETSPEC (e.g "volname.rdma")
> - but even that can be retired if we start using getsockname() and discover
> the incoming interface.
>
> This way the client only specifies the appropriate (routable) mount server IP
> and everything else is resolved automatically.
>
> 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?
Interesting idea. Self-heal traffic between servers could use the same
approach (and same code?) too with this couldn't it?
+ Justin
--
Open Source and Standards @ Red Hat
twitter.com/realjustinclift
- Re: [Gluster-devel] RFC - "Connection Groups" concept, (continued)
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Jeff Darcy, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Stephan von Krawczynski, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Joe Landman, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Stephan von Krawczynski, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Joe Landman, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Joe Julian, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Stephan von Krawczynski, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Joe Julian, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Justin Clift, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Anand Avati, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept,
Justin Clift <=
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Justin Clift, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Anand Avati, 2013/06/27
- Re: [Gluster-devel] RFC - "Connection Groups" concept, Amar Tumballi, 2013/06/28
Re: [Gluster-devel] RFC - "Connection Groups" concept, Ian Latter, 2013/06/27
Re: [Gluster-devel] RFC - "Connection Groups" concept, Ian Latter, 2013/06/27