Subscribe

disk design

need some advise on disk\aggregate design in order to optimize performance.  My system is a 204a and currently has the following drives

SATA will be used for low performance servers and archive data

SAS will be used for vmware, sql and other high IO

12 1TB SATA shelves (internal)

24 450GB sas drives (4243 shelf)

My thoughts were

san a:

2 spares: 2 parity: total of 8 disk usable.

sata ownership to san A: aggr0: SATA:  raid size 14:

san b:

2 spares: 2 parity: total of 20 usable:

sas ownership  to san B: aggr 0: raid size 20

questions;

- is there any benefit to splitting the disks between the filers vs. having one san own all the disks considreing the number of currnet disks.

- is there any disadvantage to having a raid size of 20?  should it be lower 10, 12, 16 and having drives splut between two raid groups.  logic is more spindles = more performance.

Re: disk design

Your ideas are very good...not a bad idea to split sata on one side and sas on the other...then you only need spares for each on one node and not two.  For the RG of 20...I am ok with that but depends if you plan on adding more disks later.  If you plan on adding shelves later then it makes sense to go with a smaller number that is divisible evenly by the new disks you will add down the road.  For example, it is better to have two 16 drive raid groups than a 20 and a 12 later.

Re: disk design

good point, in my scenario I would need to add 22 disks at a time to the same aggregate in order to get evenly distributed raid groups. if I change my raid group size after the aggregate was created will it affect my aggregate.  there is no data on my fas right now, so worst case scenario is that I destroy and rebuild.

Re: disk design

You can always add disks to an existing raid group, so sometimes starting with smaller even sized raid groups is better...then grow the aggregate by adding to each raid group 'aggr add aggrname -g rg0' for example... the cli allows you to add to existing groups.  Depending on how you grow though (if not complete raid groups) reallocate is sometimes used to even out disk i/o and data, but if dedup is running then reallocate isn't recommended so take that into consideration too..