Thanks for your answer...
For me, this whole discussion is very helpful. For our storage systems I am in kind of a transition of traditional raid groups to storage pools. There are several raid groups with only two disks for logging.
I was planning to create a new storage pool for logging containing all the disks of the old raid groups. The idea was to use RAID10 again, but I will check the IOPS needs of the servers.
maybe it is an option to use RAID5 after all.
Yeah, this is one of the things I keep struggling with myself as well. In the field it is not always possible to calculate it perfectly.
Especially now with the storage pools, FAST VP, FAST Cache etc coming up, we've got most DB servers (logs, db, everything) up in the pool with the rest of the servers. My experience is that the sheer amount of disks in the pool absorbs any write penalties with ease. Furthermore, if you have some SSD in the pool my experience (especially with the CX4 range) is that you'll run into storage processor utilization problems way before the disks become a problem. So there may still lie a problem: RAID5 and RAID6 need to do much more CPU intensive parity calculation than a “simple” mirror to another disk.
Of course if you know beforehand that you need many thousands of IOps that is very write intensive and random, I'd still without a doubt go for a dedicated RAID10 RAID group. But don't forget that LUN Migrate is still working; give it a shot on RAID5 and move to RAID10 if it's not working out. (Or the other way around if you have to play it very safe)
Most of the log disks are now in a dedicated 4RAID5 pool, because FAST Cache has to be disabled on Log luns, as per best practise of EMC. (At least, they told me during implementation.)
To create a RAID1/0 Storage pool, I have to use the RAID5 storage pool anyway for migration purposes... So I am curious what RAID5 will bring for the log disks.
If you don't need the IOps RAID5 isn't that bad at all. I've even seen log disks that were several hundred GBs in size compared to the db disk which was perhaps 200GB bigger than the log disk, so you simply can't say 1 size fits all. If you don't have bottlenecks now, check (perfmon for example) how many read and write operations as well as the R/W ratio you have.
Hmmmmm, I'm not aware that FAST Cache should be disabled on the log LUNs. I would expect FAST Cache to be really helpful there as it absorbs excessive writes from RAM cache to EFD drives instead of the slower rotating drives.
Let's check if anyone can help us here: does FAST Cache need to be disabled on LUNs that are used for database logging?
White papers that I have seen so far tell you to disable Fast Cache for log because of their sequential i/o profile that cannot take advantage of Fast Cache and simply wastes it. It gets prompted but does not get re-used.
That's what they told me...
Without this knowledge, I was thinking that FAST Cache could end the discussion about RAID level for log disks... But unfortunately ;-)
i also heard a little blurb at EMC World that 5.32 should have enhancements where they detect sequential patterns and don't promote them to Fast Cache.