[Gluster-users] Stupid question re multiple networks

Kaushal M kshlmster at gmail.com
Mon Nov 17 02:43:12 UTC 2014

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.


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

More information about the Gluster-users mailing list