I hope somebody can assist in pointing me to a good reading for the above topics. The NetApp docs are pretty much useless.
So what I am trying to do as from the title above is implement the above technologies/capabilities on my filer. My big question is how. I can not figure out how to segment the vlan's small enough that it will suffice for one development group. My scenario is basically, I would like to provision vfilers to multiple development groups without them seeing each others data. It might be as simple as them needing a "fileserver" for both NFS/CIFS traffic. But I might have like 50-70 groups.
How do I implement the vfilers/vlan/ipspace in a combo to achieve this? And how do I tell the network team to configure the switches. I have a general understanding of what I would like to do. But having some difficulty putting it down into execution.
If anybody has any tips or any good articles for reading, will be highly appreciated.
Usually for secure multi-tenancy you create ipspaces and make sure every vfiler is on it's own VLAN interface to provide L2/L3 protection. If you're all one company and you're really just looking to segment data, my question would be Do you have one domain or multiple domains?
If you have a single domain, just assign rights at the share level.
If you have multiple domains then you could create vfilers and join each to a different domain.
Thanks for the reply. We are one company but I really would like to segment the data and we are one domain. That's why i'm really having some problems figuring out how to implement this multi-tenancy. I definitely would like to separate our IT traffic vs customer (development) traffic for both security and bandwidth purposes. For example, all our VMware storage traffic will be on one vlan. IT traffic, e.g. SNMP, monitoring traffic, etc.... on one vlan. development group (customer) on separate vlans, might even be separate vlans per customer
Is this too much security you think granting it's all internal
First of all, MultiStore is a great technology and a fun project to implement.
What it gets you is Network separation and or Authentication Domian separation. It also gets you discrete semi-portable storage systems if you've gone to the trouble to integrate with Protection Manager for vFiler Migrates.
You also get configuration complexity, more complex RC files (HA failover configurations to check) and prior to System Manager 2.0, you had to do it all CLI which is frustrating if you like one GUI or another.
If you're going to use ipspaces then your goal is to have the vfilers non-routable to one-another. Completely, no way for one to talk to the other at all or for clients of one to talk to the other. This would mean that your security posture inside your company is that the Dev Group and the noraml user base are on completey separate networks, not just different subnets.
I use vFilers in situations where different companies will be using the same NetApp system and need to maintan a real level of separation.
You also have to separate the data into separate volumes which means you lose deduplication between departments. My recomendation is to create a vfiler or two for the experience but in my environment, I would place each department into a separate qtree in the same volume and control access with AD Security Groups.
While vfilers can do what you are asking, deploying 50-70 vfilers on a single NetApp cluster is probably a bad idea. In fact, it probably exceeds the number of supported vfilers on the NetApp controller. Vfilers require the NetApp controller to manage system resources for each vfiler separately. Creating 50-70 vfilers would create significant load on the system. I would recommend against it.
At a basic level, here is what the technologies (ipspace, vlan, and vfiler) do.
An ipspace is a logical segregation of your Ethernet network. Filers (both pfilers and vfilers) can only access interfaces within the same ipspace as the filer. Let's assume a filer has interfaces e0a and e0b in ipspaces "engineering" and "marketing," respectively. The pfiler (a.k.a. vfiler0) would reside in one ipspace and a vfiler (let's call it "vfiler1") would reside in the other. The IP traffic from vfiler0 would be entirely separate from the IP traffic from vfiler1. The IP traffic is so segregated that vfiler0 and vfiler1 have their own routing tables, their own vlan domains, etc. Unfortunately (as of DOT 7.3), vfilers are not allowed to have a default route, so you would need to define routes for each network subnet (or supernet) which will access the vfiler. Ipspaces are great for securely segregating IP traffic, but they may well be overkill for what you are trying to accomplish.
A vlan is a "virtual" LAN. A vlan allows network ports on a managed switch to be segregated into separate broadcast domains. As a best practice, each vlan (which supports an IP subnet) will contain one and only one IP subnet. In conversation, vlans are frequently referred to by the IP subnet which they service. However, a vlan is *not* an IP subnet, and an IP subnet is *not* a vlan. Like many enterprise devices and systems, NetApps support vlan tagging. Vlan tagging enables Layer 2 communication from a host to multiple vlans simultaneously. A device that connects to multiple network segments simultaneously is frequently called "multi-homed" or "a bastion host." Multi-homing a device usually a bad idea since it violates many network security models. There are circumstances where bastion hosts are acceptable or even necessary. For example, routers and firewalls generally require multi-homed configuration. However, file servers very rarely require a "multi-homed" configuration. As a general rule, do not multi-home devices unless you absolutely have to do so. For file servers, multi-homing should be a very rare exception, and not a rule.
A vfiler is a "virtual" filer. It requires dedicated volumes and/or qtrees. A vfiler can belong to a separate domain (CIFS or NIS) than the pfiler (i.e. physical filer). Since vfilers require exclusive rights to their assigned volumes and qtrees, the vfilers must maintain their own CIFS shares and NFS exports. If CIFS access is managed via file ACLs (which is recommended), then moving, replicating, or cloning data between vfilers becomes problematic. The file ACLs (access control lists) are specific to the domain (or host) on which the users and groups are created. In CIFS, users and groups each have a GUID (globally unique ID). The GUID contains two parts -- the GIUD of the host/domain to which the user/group belongs and a RID (resource ID). As a result, the GUID of DOMAINA\bsmith and DOMAINB\bsmith are different. If a volume is SnapMirrored from a vfiler in DOMAINA to a vfiler in DOMAINB, the file ACLs on the files will not resolve and access will be denied. "Well-known RIDs" are an exception. Well-known RIDs include the default user objects (Administrator, Guest, etc.) and default group objects ("Administrators, Backup Operators, Guests, etc.).
Vfilers also have a lot of great potential in Disaster Recovery Plans and Business Continuity Plans (DRP/BCP) due to their "vfiler dr" and related commands.
My recommendations would be:
* Use access controls (file permissions, share permissions, export permissions, etc.) to restrict access to the data.
* Use vfilers only where necessary. For example, if "Group A" and "Group B" require different Active Directory domains and the domains do not have a trust relationship.
* Avoid the use of ipspaces unless absolutely required. Ipspaces are really designed for multi-tenancy environments.
* Avoid the use of vlans on the NetApp (and any other NAS appliance or file server).
While the NetApp offers many great features for segregating your users' data, keeping the deployment simple will make administering and maintaining the system much easier in the long run.
Please let me know if I answered your questions sufficiently or if you would like to discuss any of these options further.
Along with the great advice from others, you might consider checking out our Secure Multi-Tenancy solution, which discusses a lot of these topics in detail. It also illustrates the configuration needed on all 3 layers of the stack. Even if you don't use the exact components that we validated, it should get you headed down the right path.
Of interest will be both the Design Guide as well as the Deployment Guide.