[Gluster-users] Stupid question re multiple networks

[Kaushal M]

The 'Better peer identification' part is completed. GlusterD can now
correctly identify the mentioned peer, regardless of the type of name
used (IP, FQDN, short name). It also laid down a framework on which we
can build a nice multi-interface support in the future, as we can now
associate multiple names with a peer.

~kaushal

On Sat, Nov 15, 2014 at 1:42 AM, Justin Clift <justin at gluster.org> wrote:
> On Thu, 13 Nov 2014 14:15:24 -0500 (EST)
> Jeff Darcy <jdarcy at redhat.com> wrote:
>
>> > AFAIK multiple network scenario only works if you are not using
>> > Gluster via FUSE mounts or gfapi from remote hosts. It will work
>> > for NFS access or when you set up something like Samba with CTDB.
>> > Just not with native Gluster as the server always tells the clients
>> > which addresses to connect to: ie your storage hosts will always
>> > supply the connection details of the hosts that are configured in
>> > gluster to your storage clients.
>> >
>> > I wonder if this could be gaffer-taped with some bridging/vlan/arp
>> > spoofing trickery but I'm not sure I'd trust such a hack.
>> >
>> > It would be *really* nice if there was a way to set up gluster so
>> > you could specify different IPs for backend and frontend operations.
>>
>> As you suggest, there are various kinds of "trickery" that can be used
>> to fake multi-network support even for native mounts.  I've seen it
>> done via split-horizon DNS, explicit host routes, and iptables.
>> *Proper* support for multiple networks is part of the proposed 4.0
>> feature set.
>>
>> http://www.gluster.org/community/documentation/index.php/Planning40
>>
>> In fact, I would greatly appreciate your help defining what "proper"
>> means in this context.
>
> As an extra data point, this is a gluster-devel thread from a while ago
> about one potential approach:
>
>   https://lists.gnu.org/archive/html/gluster-devel/2013-06/msg00069.html
>
> It turned out the code (at the time) in GlusterFS for identifying
> peers wasn't great, and needed to be updated first before really
> addressing the problem at all. ;)
>
>   https://lists.gnu.org/archive/html/gluster-devel/2013-06/msg00067.html
>
> Those two threads should be read together, as the concept in the first
> one evolved during discussion with Kaushal M (CC'd) and via the mailing
> list and IRC over a few days.
>
> This pre-requisite required code became the "Better Peer Identification"
> feature for 3.6.x series:
>
>   http://www.gluster.org/community/documentation/index.php/Features/Better_peer_identification
>
> I haven't kept an eye on that though, so unsure if it's completed yet
> or not (just now emailed Kaushal to find out).
>
> + Justin
>
> --
> GlusterFS - http://www.gluster.org
>
> An open source, distributed file system scaling to several
> petabytes, and handling thousands of clients.
>
> My personal twitter: twitter.com/realjustinclift