[Gluster-devel] Multi-network support proposal
Anders Blomdell
anders.blomdell at control.lth.se
Fri Feb 13 19:43:08 UTC 2015
On 13 February 2015 18:27:54 CET, Jeff Darcy <jdarcy at redhat.com> wrote:
>This is a proposal for a "lightweight" version of multi-network
>support,
>somewhat limited in functionality but implementable quickly because it
>seems unlikely that anyone will be able to spend much time on a full
>version. Here's the corresponding feature page:
>
>http://www.gluster.org/community/documentation/index.php/Features/SplitNetwork
>
>There are three things a user must be able to do:
>
> * Create new named networks (a "default" network always exists)
>
> * Associate specific host interface names/addresses with networks
>
> * Associate volume roles (e.g. I/O, rebalance) with networks
>
>The crux of this proposal is to do what we can by rewriting volfiles
>between when they're fetched and when they're used to construct a
>translator graph. Each protocol/client translator within a volfile
>originally uses a server's *canonical* name - on the default network,
>used for "peer probe" and other glusterd-to-glusterd operations. For
>each such translator, the volfile consumer must do the following:
>
> (1) Determine its own role (e.g. client, self-heal daemon)
>
> (2) Use the {volume,role} tuple to find the right *network* to use
>
> (3) Use the {network,canonical_name} tuple to find the right
> *interface* to use
>
>(4) Replace the server's canonical name ("remote-host" option) with the
> interface name
>
>For example, consider the following (don't worry about the syntax yet).
>
> gluster volume create fubar server1:/brick server2:/brick
>
> gluster network create client-net
>
> gluster network associate client-net server1 server1-public
>
> gluster network associate client-net server2 server2-public
>
> gluster volume set-role fubar mounts client-net
>
>According to step (2) above, any native mount of fubar will know to use
>client-net. Therefore, according to step (3) it should make the
>following substitutions:
>
> server1 => server1-public
>
> server2 => server2-public
>
>By contrast, glusterd would still use the plain old "server1" and
>"server2" on the "default" network.
>
>Three kinds of enhancements are being left to the future:
>
> (a) Determine the network to use based on *client* identity as well as
> {volume,role}
>
> (b) Allow a volume to be used only through certain networks
>
> (c) Modify other parameters (e.g. SSL usage/credentials) based on
> network or interface
>
>Any other thoughts?
Perhaps bandwidth allocation?
/Anders
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the Gluster-devel
mailing list