> 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? _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
