summaryrefslogtreecommitdiffstats
path: root/under_review/Split Network.md
blob: 95cf94476a888e80b642f565818316193cbbd2fa (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
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 <jdarcy@redhat.com>

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)