Bug 764850 - (GLUSTER-3118) [FEAT] multi-homed access for fuse mounts on distinct networks is no longer possible
[FEAT] multi-homed access for fuse mounts on distinct networks is no longer p...
Product: GlusterFS
Classification: Community
Component: cli (Show other bugs)
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: bugs@gluster.org
: FutureFeature, Triaged
: 764962 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2011-07-01 09:01 EDT by Need Real Name
Modified: 2015-10-22 11:46 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-22 11:46:38 EDT
Type: ---
Regression: ---
Mount Type: fuse
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2011-07-01 09:01:52 EDT
Previous versions (3.0.x) of Gluster which allowed for using configuration files, enabled us to set up multiple listeners on multiple networks for a single brick.  So when a client on a specific network connected to the volume, it would have no trouble accessing the brick in its entirety.

The current versions (3.1.x, 3.2.x) do not appear to enable this capability, without hand editing the volume files.  This leads to a path where you either have to avoid ever using the management tools after initial configuration, or you have to give up this capability.  As we have customers dependent upon this functionality, this is problematic to say the least.  They are effectively stuck at 3.0.x for the duration of their usage unless this feature makes its way back in via the management tools.

What I would suggest is adding a brick-alias feature to re-enable this capability.  So you could have

   gluster volume VOLNAME add-brick-alias BRICK-NAME ALIAS

where ALIAS is either a DNS name or an IP address.  You could have similar functions of remove-brick-alias, disable-brick-alias, enable-brick-alias, modify-brick-alias, etc.

  Then when a client connects from a particular subnet, the information returned to it is relative to that specific subnet.  So if you have two distinct nets, a 10GbE private net and a 1GbE public net, building the Gluster volume on the 10GbE private net will exploit the 10GbE whenever possible.  But using the 1GbE with fuse clients will still be possible.

  This is needed in a number of cases where the NFS client is not an acceptable alternative.
Comment 1 Amar Tumballi 2011-07-01 11:42:37 EDT

Is an option to preserve user changes to the brick volume file enough to handle this case? or you want some CLI command itself?

Comment 2 Amar Tumballi 2011-07-11 10:14:07 EDT

Can you send me sample volume spec file (server side) for multi-homed access? Let me see how I can incorporate that in 'volume set' frame work. 

Comment 3 Amar Tumballi 2011-09-27 01:50:14 EDT
Planing to keep 3.4.x branch as "internal enhancements" release without any features. So moving these bugs to 3.4.0 target milestone.
Comment 4 Amar Tumballi 2013-02-05 04:24:07 EST
*** Bug 764962 has been marked as a duplicate of this bug. ***
Comment 5 Amar Tumballi 2013-02-05 04:25:52 EST
From bug 764962 (which is marked as duplicate of this one)
Saul Serna 2011-07-22 17:13:48 EDT
As of now GlusterFS probes on single subnet for management. But if use wants to use a different ip which is also local to the system on a different nic results in error since Gluster Management daemon understands only ips which are probed. 

Aforementioned feature is required for users to bisect traffic over multiple subnets and would be a nice to have feature. 

Possible use case:- 

NFS server communicates to other servers over a different subnet on a different switch and clients connecting on a different subnet. 

This would help in isolating server side traffic and clearly free up the client bandwidth, hopefully increasing performance while doing so.
Comment 6 Niels de Vos 2014-11-09 06:23:55 EST
Seems very much that the SplitNetwork feature is all about this:
- http://www.gluster.org/community/documentation/index.php/Features/SplitNetwork
Comment 7 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.

Note You need to log in before you can comment on or make changes to this bug.