MD3000 RAID 5 vs RAID 6 performances and benchmark

When using parity based raid, for every write, you take a performance hit. Each single write isn't noticable, but if you add up all the writes it could make a big difference.

The turning point where the performance hit outgrows the performance gain (from using multiple drives) is around the point where 30% or more of your IOs are writes.

If your write-to-read ratio shows more than 30% to be writes, I'd suggest going with raid 10 for the write performance.

Keep in mind: Raid is NOT a backup solution; it prevents downtime and dataloss in case of a drive failure, but data corruption can still occur and can only be 'restored' from an offline backup (e.g. tape).

Is the magic 30% writing I/O the same for raid 5 and raid 6?

I'm pretty sure that we are under 30%, but to avoid benchmarking all and every of the 7-8 server, I was thinking to use raid 10 because  that shouldn't give space cocerns, because I'd get a raid 10 array with more than 1.5 TB for a maximum extimated utilization of 1 TB in the next years. But a raid 6 would be more fault tolerant (to loose data you  have to get 3 broken disks together instead of two) and I don't think that we can fully use (as performance) a raid 10 array on a MD3000i by means of iSCSI ethernet 1 Gbit connections and 6-8 virtual server utilized by 100 users at maximum.

I know that raid isn't a backup solution. We'll have a disk backup solution of VMs images with Acronis for virtual on a Qnap, snnapshot on MD3000i, and LTO backups that we bring to the bank every week (as already we do right now with the physical servers).

Regards,

Andrea

Gotta get it right the first time?   We actually tested quite a few configs on our MD3000i's before putting them in production.

So many factors here.  Hard to really guage unless you find numbers with the same number and speed of drives.  And even then in it so application dependent once you get to see what the real world performance will be.

At 14 disks in the group, the write hits from RAID 5 to 6 was not that notice-able for us.  I resisted the switching of the RAID level, but it's been fine.

The RAID 10 thing is interesting.   But you lose 1/2 the spindles as far as overall IOPS are concerned.  8 spindles did not provide us with very good performance in pre-implementation testing.

I was thinking about what you're saying about LUNs numerosity. I should reply in that thread, but now we are here and are speaking about performances. 

I don't know about iSCSI reservation (I'm ignorant), but I know that when you define a LUN the MD3000 reserve some memory cache of its grand total - 512 MB I think - for such LUN, so the performance gain in defining many LUNs could be that each one has its own cache reserved (until you have yet free cache), while if you make bigger LUNs with many VMs on it you have the same cache (of such LUN) divided by the VMs that require them.

Because the default in assigning cache to a LUN is 128 KB, to get better performances in default allocation (you can require also 256) is to define at least 4 LUNs for controller (having such controller as primary).

I don't know well about what I'm writing, so if I make mistakes, please, correct me.

Regards

I'm not sure.  We did physical to virtual conversions and did our testing, then re-did the conversions once we were satisfied with the performance / configurations    I did not see to mcuh difference when the VM's were not demanding on the disk.  But Exchange and our Imaging server were way best on dedicated luns.   Maybe on the cache,  I actually just assumed it was iSCSI reservations,  but the cache makes more sense.  When looking at san disk performance, I usually only look at latency.   If it's low good performance, if it's high bad performance.

Thx. I found also another good answer for me:

RTFM!  :-)

http://i.dell.com/sites/content/business/solutions/whitepapers/en/Documents/PowerVault_MD3000_and_MD3000i_Array_Tuning_Best_Practices.pdf