From d7d3274c6f6cea46ad296fc6d1259ee9a4e9964f Mon Sep 17 00:00:00 2001 From: hchiramm Date: Tue, 4 Aug 2015 11:07:42 +0530 Subject: Adding Features and planning features to glusterfs-specs repo As per the discussion (http://www.gluster.org/pipermail/gluster-users/2015-July/022918.html) the specs are part of this repo. Signed-off-by: hchiramm --- Feature Planning/GlusterFS 4.0/Split Network.md | 138 ++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 Feature Planning/GlusterFS 4.0/Split Network.md (limited to 'Feature Planning/GlusterFS 4.0/Split Network.md') diff --git a/Feature Planning/GlusterFS 4.0/Split Network.md b/Feature Planning/GlusterFS 4.0/Split Network.md new file mode 100644 index 0000000..95cf944 --- /dev/null +++ b/Feature Planning/GlusterFS 4.0/Split Network.md @@ -0,0 +1,138 @@ +Goal +---- + +Better support for multiple networks, especially front-end vs. back-end. + +Summary +------- + +GlusterFS generally expects that all clients and servers use a common +set of network names and/or addresses. For many users, having a separate +network exclusively for servers is highly desirable for both performance +reasons (segregating administrative traffic and/or second-hop NFS +traffic from ongoing user I/O) and security reasons (limiting +administrative access to the private network). While such configurations +can already be created with routing/iptables trickery, full and explicit +support would be a great improvement. + +Owners +------ + +Jeff Darcy + +Current status +-------------- + +Proposed, awaiting summit for approval. + +Related Feature Requests and Bugs +--------------------------------- + +One proposal for the high-level syntax and semantics was made [on the +mailing +list](http://www.gluster.org/pipermail/gluster-users/2014-November/019463.html). + +Detailed Description +-------------------- + +At the very least, we need to be able to define and keep track of +multiple names/addresses for the same node, one used on the back-end +network e.g. for "peer probe" and and NFS and the other used on the +front-end network by native-protocol clients. The association can be +done via the node UUID, but we still need a way for the user to specify +which name/address is to be used for which purpose. + +Future enhancements could include multiple front-end (client) networks, +and network-specific access control. + +Benefit to GlusterFS +-------------------- + +More flexible network network topologies, potentially enhancing +performance and/or security for some deployments. + +Scope +----- + +### Nature of proposed change + +The information in /var/lib/glusterd/peers/\* must be enhanced to +include multiple names/addresses per peer, plus tags for roles +associated with each address/name. + +The volfile-generation code must be enhanced to generate volfiles for +each purpose - server, native client, NFS proxy, self-heal/rebalance - +using the names/addresses appropriate to that purpose. + +### Implications on manageability + +CLI and GUI support must be added for viewing/changing the addresses +associated with each server and the roles associated with each address. + +### Implications on presentation layer + +None. The changes should be transparent to users. + +### Implications on persistence layer + +None. + +### Implications on 'GlusterFS' backend + +None. + +### Modification to GlusterFS metadata + +See [nature of proposed change](#Nature_of_proposed_change "wikilink"). + +### Implications on 'glusterd' + +See [nature of proposed change](#Nature_of_proposed_change "wikilink"). + +How To Test +----------- + +Set up a physical configuration with separate front-end and back-end +networks. + +Use the new CLI/GUI features to define addresses and roles split across +the two networks. + +Mount a volume using each of the several volfiles that result, and +generate some traffic. + +Verify that the traffic is actually on the network appropriate to that +mount type. + +User Experience +--------------- + +By default, nothing changes. If and only if a user wants to set up a +more "advanced" split-network configuration, they'll have new tools +allowing them to do that without having to "step outside" to mess with +routing tables etc. + +Dependencies +------------ + +None. + +Documentation +------------- + +New documentation will be needed at both the conceptual and detail +levels, describing how (and why?) to set up a split-network +configuration. + +Status +------ + +In design. + +Comments and Discussion +----------------------- + +Some use-cases in [Bug 764850](https://bugzilla.redhat.com/764850). +Feedback requested. Please jump in. + +[Discussion on gluster-devel](https://mail.corp.redhat.com/zimbra/#16) -- cgit