Baijulal,
Thanks for your reply. See my responses below.
I would suggest reading TR-3838 available on now site.
Also you can search for best practice documenations at http://www.netapp.com/us/library/ (use key word search)
Someone else pointed out that TR-3838 is an internal document only -- I don't find it when I search for it. Also, I could just be missing it, but I don't find a Best Practice document that describes creating separate Aggregates based on how the data will be accessed or used.
Number of spindles in Aggregate (say for example 2 different aggrs with say RAID-DP and 3 disks each is not a good idea;smaller number of disks on Aggr can lead to bottlenecks from disk i/o performace)
This is definitely a concern. I think this is the main reason we would want to use either a single or small number of large aggregates, regardless of the usage.
VMWARE VOLs are typical candidate for dedupe savings so having them on a seperate aggregate is benificial.
Yes, we dedupe the VMware volumes and not the others. Deduplication runs on a volume basis, correct? Is it more compute intensive or I/O? If compute, that will effect us regardless of whether the volumes are on separate aggregates. If I/O, that could be a valid reason to use a separate aggregate for the VMDK usage so as not to effect the others.
So depending on onumber of disks I might consider 2 -3 Aggrs in this case.
I'm not sure what the 2-3 number is based on. If separate aggregates for different usage is not beneficial (or worse if it is harmful), we will follow best practices for number of aggregates based on the number of disks/raid groups.
Adding disk to aggregate is easy and quick but keep in mind there is no option to remove a disk from Aggr.
I would also prefer to have all disks added in Aggrs initially before volumes are created, rather than expanding them later.
The removal issue is valid but I don't think we're too concerned about it. I'm more worried about performance issues of recalculating parity and new data being directed to the empty disk(s). Is that why you'd rather not expand an aggregate later?