When it will up to the point SVM is required?

[netappmagic]

We have a TB volume and will be accessed by around 20 users, 10 desktop, would that worth to create a SVM for this application, or should it be just a volume enough?

My question is, when will it up to the point SVM should be created? any best practice and criteria?

Thanks for you advice!

[JGPSHNTAP]

An SVM is a logical construct.  You and your management need to determine what your failure domain would be.  

IMHO, you have way more to go. 1 TB is nothing.  We have 5000+ users

[netappmagic]

I know 1TB is small,  that is why I raised the question of if a SVM is needed here in this case.

So, are you saying that since this is a small size, and small envirioniment, SVM is not worth doing here?

[JGPSHNTAP]

Ok, so it doesn't appear you have the concept of cDOT.  an SVM is always required.  

There is no other way to provision data

[netappmagic]

I did not make myself clear. I know a SVM is always needed or required in cDOT. We already have an existing SVM, and we have multiple SVMs already.  We use one for NFS volume and in a secured network, so, we can use this one. The question is for this particular application, with < 1TB data, one volume, ~10 users, what would it be the critieria to have a separated SVM? In my opnion, we can just simply export the volume in the same secured network to clients. a SVM is a over-kill.

Understand that the capacity is not the only consideration. 

Multi-tenancy: understand SVM is a logical unit, and can be indepedent on physical environ.

delegation: Can you give me an example,pelase?

 compliance boundaries: this is the only reason that the customer wanted to have a seperate SVM, but the network the existing SVM is based on an already seperated network. In my opinon, we can create a volulme on the same isolated network, which could achive the same security. Isn't

authentication requirements: AD authentication, same as all existing.

 untrusted domains: same AD as other volumes

differing application requirements: can you please give me an example, like what type of applicatoin requirements

DR requirements: we don't set up DR based on SVM

Thank you,   JGPSHNTAP , and SeanHatfield!

[SeanHatfield]

With compliance issues its usually more of a political discussion or policy discussion than a technical discussion.  The requirements are often driven by the mindset of the most recent batch of auditors that have come through.  But if one of those requirements involves delegating vsadmin level credentials, or that the svm be joined to an domain on the other side of a functional compliance boundary, then it makes sense.  The compliance SVM may need different policies, export, snapshot, retention, fpolicy, etc that could likely still be accomplished in a shared SVM but it may be cleaner from an audit trail perspective to break it out. That's a conversation you need to have with the business owner of that dataset and the compliance officer that has to sign off on the control.

Differing application requirements can be fairly obscure.  For example, there are a handful of applications out there that have a hard coded expectation that cifs servers report a 512 block size.  That can be accommodated with an SVM level tunable, so if you encounter that requirement in the wild those workloads can be placed into their own SVM.

[netappmagic]

Diff export, snapshot, retention could be achieved in a shared SVM, as you already indicated.

Like I said, the only reason the customer needs a SVM is to put the volume in an isolcated network which is already the case in an existing SVM. Again, this will be just a <1TB volume, ~10 users.

If none of those you said have anything to do with the need to create a new SVM,  would that be then fair to say that we don't need a separated SVM in our case here? Creating a volume in a shared SVM should be good enough?

[SeanHatfield]

Nothing you've mentioned sounds like a technical requirement for a new SVM.

[SeanHatfield]

There are lots of reasons to make a new SVM, but capacity isn't really a consideration.  Multi-tenancy, delegation, compliance boundaries, differing authentication requirements, untrusted domains, differing application requirements, DR requirements, etc etc, but not really capacity.