Hey Darish,
On 3/17/07, Darish Rajanayagam darishr@softcom.biz wrote:
The current configuration is one large RAID DP Group with 1 HotSpare (27 Disk DP RAID Group), which belong to one aggregate (aggr0).
My question:
The new enclosures, should I create 2 x 28 Disk DP RAID groups and add it to the existing aggregate? The application we run is IO intensive and more spindles the better. Does anyone see any disadvantages of doing the above?
The performance of a raidgroup depends on the number of spindles in the raidgroup, and in my experience not on the amount of rg's in an aggr. In my experience, the most applications perform best with about 22 - 25 disks / rg, after that the performance doesn't seem to increase that much anymore.
If you need to serve the data out of one volume (mountpoint/share/lun), you have no option but to expand your aggr, and in general that is something that works best. You can create more aggregates however, this gives you more future flexibility since you cannot destroy raidgroups, but only whole aggregates.
Does anyone have a formula to calculate mean time to Repair on the 10K 144GB disks on a busy filer? I only have one hot spare disk, should I add more, is there a rule of thumb?
I generally use one hotspare per set of 40-60 disks, depending on the need for redundancy. With DP on FC you are reasonably safe, so I'd opt of 1 spare per 60 disks and round that number up.
I have seen reconstruct times of roughly 3-4h for a 10K 144GB disk, this offcourse depends a lot on the load of your box. You can always tune the reconstruct priorities. Also, don't forget you have RAID-DP so you are protected against double-disk failure within a raidgroup.
We currently have multiple volumes on the filer, after adding the new shelves/spindles, if I run a reallocate on the existing volumes, would it take advantage of the additional spindles.
Only if you expanded the aggregate where the volume resides in. And yes, if remotely possibly, try to reallocate if you grow a busy aggregate. You can also schedule regular reallocate jobs using the "reallocate schedule" command, which IIRC appeared in 7.0.5.
A scheduled reallocation job will first scan if the reallocation is needed and only then fire off a wafl reallocate.
Gr,
Nils