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.
Joe, Is an option to preserve user changes to the brick volume file enough to handle this case? or you want some CLI command itself? -Amar
Joe, 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. Regards, Amar
Planing to keep 3.4.x branch as "internal enhancements" release without any features. So moving these bugs to 3.4.0 target milestone.
*** Bug 764962 has been marked as a duplicate of this bug. ***
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. ----
Seems very much that the SplitNetwork feature is all about this: - http://www.gluster.org/community/documentation/index.php/Features/SplitNetwork
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.