> Can anyone provide any insight on how to configure gluster networking to
> support multi-tenancy by separating Native/NFS/SMB client connections at
> layer 2? Our thinking was each client will come into our network on a
> dedicated vlan but unsure whether gluster can support say a dedicated
client
> trunk interface with 50 or so vlan interfaces? Is this possible? And if not
> what could be another way?
Some of this is "works by default" and some of it's work in
progress.
When a brick sends a reply to a client request, that reply will simply
follow the default routing for its destination. In a VLAN environment,
this would mean sending it on the pseudo-interface for that VLAN, so in
effect the traffic for groups of clients on separate VLANs will remain
segregated.
What we don't have is a way to do VLAN-based access control across
native, NFS, and SMB. The brick I/O infrastructure does support
address-based access control, but IIRC that doesn't affect who can
connect at the TCP level. We'll still initially accept connections on
any interface, and then close any that don't pass the address filter.
If you want to play with this, then auth.allow is the volume option you
want to look at. I don't know of any similar options for NFS or SMB, so
there might be no way to prevent them from accepting connections on any
VLAN. Maybe someone from one of those teams can correct me.
In 4.0 we're working on ways to give users more control over what
networks get used for what. Primarily this is to let internal traffic
(replication, self-heal, and so on) go over a private back-end network.
However, giving users more explicit control over the relationships
between volumes and front-end networks has also come up. The feature
page is here.
http://www.gluster.org/community/documentation/index.php/Features/SplitNetwork
Does that help?