ONTAP Discussions
ONTAP Discussions
Hi All
Im hoping someone can help me understand the implications and consequences around mixing data volumes within the root volume aggr.
We have recently purchased a FAS3210 with dual processors and 2 trays of SAS 600GB (560GB useable) = 48disks
Right now, straight out of the box we are taking a 6 disk hit from the root volume being managed by the 2 processors in RAID-DP. When we also include our 2 spares per shelf that's 8 x 560GB disks just for management and redundancy gone without even starting to setup other aggr's.
I have been reading documentation that states we can migrate to RAID4 and it's preferred to separate the root volume from the data volumes on the filer for optimal management but coming from a newbie to Netapp i'd like to consider my options around the following consolidation scenario:
Root Aggr0 Vol0 - RAID-DP 22 disks
560GB x 20 x 90% = 10080 GB
LUN1=2TB
LUN2=2TB
LUN3=4TB
Is adding a further 19disks to the root vol0 aggr0 and putting production data volumes for files an option i can consider or am i going down the wrong path here.
Thank you
Using a non dedicated root aggregate (i.e. what you are suggesting) is what I see very often in small deployments for the very reason you state: maximizing diskspace.
Before doing so, make sure the raidsize parameter of the aggregate is set to 22 (defaults to 16), or else Ontap will create 2 raidgroups (each with 2 parity disks).
Regards,
Niek
LIke Niek suggests, expanding the root aggregate is a VERY common practice and one that I normally take in most of my deployments (I've helped to architect/deploy over 100 filers in the last 2.5 years).
The layout that you're suggesting appears to only have one volume?? That is definately not a good practice. You shouldn't place ANY user data in vol0. You should create new volumes for each of your LUNs - NetApp best practice is one LUN per volume. Remember, most Data ONTAP operations occur at a volume level (i.e. snapshots, dedupe, etc.). In most cases, your different LUNs are going to have different snapshot schedules, dedupe policies, etc. So, separating them out into separate volumes allows for greater, granular managability.
So, in summary... One large aggregate (per controller), many volumes within that aggregate, and one LUN per volume.
Also... when expanding an aggregate (adding disks) you need to take into account one last item: reallocation. The volumes within an aggregate will need to be reallolcated across the new disks that you add. See the following link for more info:
Both replies on this thread are very good. But why not consider using 23 disks in aggr0 and leave one spare disk per shelf?
Regards,
Wei
Hey Wei,
I believe typical NetApp 'best practice' is to have two spares per disk type/size per controller (at a minimum - more depending on the number of spindles in the entire system). I believe you also have to have two spares in order for Maintenance Center to run properly.
That being said... if you don't need the features of MC and need that little bit of extra capacity / performance, there's nothing stopping someone from going with just one spare per controller.
You are probably right about the 2 spare disks per controller. However, for small configurations, 1 spare is OK. Please see the Appendix A.2 (on page 12) of TR-3760: http://media.netapp.com/documents/tr-3760.pdf.
Thanks,
Wei
Thank you all for you're replies, you have been very helpful on my 1st ever Netapp forum post.
In our case we are looking for maximum capacity aswell as performance, so i am going to trial the following config through our test lab where i add all disks to Agrr0.
We are looking to dedup heavy expecting disk savings as it is all file data. Snaps, Dedup, SnapMirror is all part of our plan.
Processor 1
Aggr0
22 – 2 = 20 x 547GB x 90% = 9847GB
Vol0 - Root
Vol1 - LUN1 - 2TB
Vol2 - LUN2 - 2TB
Vol3 - LUN3 - 4TB
Processor 2
Aggr0
22 – 2 = 20 x 547GB x 90% = 9847GB
Vol0 - Root
Vol1 - LUN1 - 2TB
Vol2 - LUN2 - 2TB
Vol3 - LUN3 - 4TB
Thank you