[Gluster-users] Multi-tenancy

Steven Bowker Steven.Bowker at ispnet.com.au
Tue May 5 05:14:54 UTC 2015


Thanks Jeff. As most of clients will be using CIFS we are thinking of running a dedicated samba servers (VM) per client. It doesn’t scale well but could give a little more control with sensitive clients.

Regards,
Steve  

-----Original Message-----
From: Jeff Darcy [mailto:jdarcy at redhat.com] 
Sent: Tuesday, 5 May 2015 4:15 AM
To: Steven Bowker
Cc: gluster-users at gluster.org
Subject: Re: [Gluster-users] Multi-tenancy

> 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?


More information about the Gluster-users mailing list