Multistore/multitenancy

[ccolht]

Forgive me if these questions have been answered before but I haven't been able to find specific answers.

I'm building out a new infrastructure involving multiple filers in multiple locations for multiple customers

Here are my (initial) questions:

1) Is it good practice to create a volume for all the vfiler root vols and use qtrees for each one? This would seem to simplify disk space management for them and allow me to back them all up with one snapshot. Is there adequate separation this way? What is the impact on vfiler migration? This would only be for their vol0, each vfiler would have its own volume set for data.

2) When snapmirroring the vfiler data volumes, should this be done at the base filer level or in each vfiler? It seems the former is recommended and I can see advantages especially in our case where we don't want to have to provision a separate replication conduit for each vfiler pair and it simplifies the network configuration of the vfilers. The main downside I can envision is where we are replicating from a customer's filer and they are not using vfilers. I don't see a mechanism that would prevent them from snapmirroring any volume from our filer since the access is controlled by hostname and we would have to allow access for their filer. The access controls don't specify direction.

[scottgelb · Accepted solution]

In the old days with Traditional Volumes, I often used qtrees for vfiler root.  However, with flexible volumes added in 7.0 several years ago, we stopped using qtrees.  The best practice is to use flexvols. There is no disk sizing issue since some customers create their vfiler root flexvols at 20MB (min vol size).  I prefer to use 10GB though since things like Data Motion need 10GB min (but will resize root if needed).  Also, if you enable cifs auditing or mirror/vault from the vfiler (instead of vfiler0), then those logs will be in vfiler_root/etc.   The impact of assigning qtrees instead of volumes with data motion and vfiler migrate is that qtree mirror (QSM) is used instead of volume snapmirror (VSM).  When QSM is used, the volume fsid is not migrated to the target and nfs mounts to the qtree will go stale.  I see no reason to use qtrees instead of flexvols unless you are on ONTAP 6.2-6.5 which shouldn't be the case.

You can snapmirror from the base system (vfiler0), or the vfiler itself.  Either works well.  Even if the target is not a vfiler or vice-versa.  vfiler migrate and data motion use vfiler0 (physical system) for the snapmirror replication and not the vfiler unit.  I could see use cases for mirroring from the vFiler instead of vFiler0, but most replicate from vfiler0... one use case for going from the vfiler is if you migrate the vfiler the snapmirror relationship migrates with it... if set to vfiler0, then you have to update the relationship to the new vFiler0 after migration.

[ccolht]

Is the following possible?

A customer snapmirrors their filer (any vfiler or none) to one of our filers(vfiler0) which has a vfiler for their access to their replicated volumes. So each vfiler0 has the other in it's snapmirror.access list. The customer filer admin decides to snapmirror some other volumes that don't belong to him from our filer to his. All he has to do is know or guess the path. I haven't found a mechanism to prevent this other than doing those mirrors to a vfiler on our side so the customer couldn't see any other volumes. Hopefully I am mistaken...

[scottgelb]

Good point.. With vfiler0 access, you can replicate any volume.. You could monitor mirrors to catch it, but that would catching it after a security breach. Creating a vfiler for them may be better then set vfiler to vfiler snapmirror.access to prevent access to an entire physical system.

Typos Sent on Blackberry Wireless

[ccolht]

Thank you. Flexvols for vfilers it is. That is what I've been doing but as the number of vfilers grows qtrees looked attractive because they use 'just enough' space.

I would do all the snapmirroring from the vfilers for security reasons but management and networking are a problem. Some of the vfilers are on customer address space and the host network cannot reach them. So I would not be able to admin the relationships without entering their 'space'. Our contracts allow this but it is still a sensitive issue and we want to avoid it. Plus the mirroring is to a remote (undisclosed ) location so we would have to provide a network path for that while maintaining their isolation. I like the ability to migrate vfilers and all their associated relationships together but we probably won't do a lot of that.