2010-06-21 03:49 PM
Any multistore veterans out there,
Is it good practice to create a vfilers primary storage unit on a qtree in the host systems root volume? (My /vol0 on aggr0 is woefully under-utilized) Or shrink vfiler0's /vol0 and make a new vFiler /vol on aggr0? Or should I just create a new vol to host the vfiler out of?
Also, what is the size recommendation for a vfilers primary storage volume is 30G enough? The books really give no guidance on these items.
Thanks in advance,
2010-06-21 03:52 PM
My opinion is to always use volumes unless you've got a really good reason. Using qtrees was a good practice back when all we had were traditional volumes.
But in today's FlexVol world, there's little reason not to use qtrees. The advantage of volumes is that it enabled things like vfiler dr and vfiler migrate.
With respect to size, they can be really small since there is no local messages file or cores that go there. You should be able to get a way with a couple hundred MBs or even 1G is plenty.
Hope this helps.
2010-06-22 12:27 PM
You should take into account 64 bit aggregates. It is just as easy to store your data in a qtree under a flexvol, so why not do it?
"For a vFiler unit that uses qtrees as its primary storage unit and for all other storage units associated with it, vFiler disaster recovery and data migration operations can be performed to any other qtree in any FlexVol volume, regardless of the underlying aggregate type. Therefore, for a vFiler unit that uses a qtree located in a FlexVol volume in a 32-bit aggregate as its primary storage unit and some other qtrees located in FlexVol volumes in 32-bit aggregates as its storage units, you can perform disaster recovery and migration operations to qtrees located in FlexVol volumes in either 32-bit aggregates or 64-bit aggregates."
By continuing to use qtree's you are future proofing your system.
2010-06-22 12:35 PM
I tend to use qtrees often for flexibility with repliction, quotas, security style, oplocks, etc., and even for vFilers. However, I never assign a qtree directly to a vFiler anymore (like Adam said...I did do this back in the tradvol days ontap 6.2-6.5 when multistore was new and we didn't have flexvols). I always assign a volume to a vFiler then create qtrees in those volumes. The vFiler owns the volume and qtrees in it. Even though dr and migrate will work with qtrees assigned to vFilers (by using qsm instead of vsm), the volume fsid will change if the vFiler doesn't own the underlying volume. So, all nfs mounts go stale and it won't work for non-disruptive migrations and won't meet data motion requirements with 7.3.3/ops mgr 4.0. If a host has a qtree mounted, even after migrate/dr/datamotion the mount does not go stale since the entire volume, fsid and file handles all migrated with the volume. Also, when qsm is used, any dedup has to be rerun on the target (although sis start is needed anyway with vsm to a new aggregate, but at least the data is still thin but with qsm it is rehydrated across the wire).
For vFiler root volume size... I often use a very small size, however there are some exceptions. If you are doing cifs auditing, then be careful to size to hold the logs and you might need a larger vfiler root. Most logging (messages, disk, etc.) go to vFiler0, but some specific events like cifs auditing go to the vFiler since it is specific to that vFiler.
2010-06-22 12:55 PM
Exactly. There are pros and cons to both ways of doing it. You do get flexibility of aggregate types (and volume types for those with older systems) by using qtrees and QSM.
But you will be forced to remount everything on migrations or dr activations unless you do VSM.
Bottom line, pick the strategy that works best for you. Personally I'm biased to volumes.