Can Fast Cache soften RAID6 write penalty?

Of course the answer is " it depends" and what it will depend upon most is your data skew. FAST cache promotes 64K chunks to flash, but it takes multiple hits of the 64 chunk to get it promoted. So when it's time to flush from write cache (which depending on the write load should help with the latency to the hosts) if the blocks to be flushed are going to chunks that are already promoted, then the flush will definitely be faster and the write penalty delayed until the chunk is destaged to disk. If not, no help. So the rate of re-use of those chunks will determine if FAST Cache will help.

Ok so basically if we are writing the same type of data frequently, this would help?  More like random writes here and there won't really be much of a help?

Maybe its better to just go RAID10 to guarantee better performance.  I just hate to lose so much storage space.  If I try to calculate RAW space, 16 disks of 600GB SAS is only 4.8 TB in RAID10, while its 8.4 TB in RAID6.  That's quite a different story.

I have 2TB NL SAS drives in the same situation but I am more prone to doing RAID10 there to help assist with the performance hit of slower RPM drives, and they are larger so I would still have 16 TB raw capacity in RAID10 which is more than we need now.  In my DAE's there are 22 x 2.5" empty slots and 13 x 3.5" for future growth.

However although we will be migrating all of production off of a Celerra NX4... we will still keep the NX4 but just use it for backup / replication and test machines.  So some space will still be able to be offloaded from the new VNX5200. 

I understand there is no one size fits all, hence the wide range of options in creating storage.

Unless you are seeing a real issue, I wouldn't get scared by the RAID write penalty.  People run RAID-6 (especially with NL-SAS drives) all the time and don't have problems.  It will come down to a couple of issues:

1. Your r/w ratio.  The more writing you do, the more you'll be affected.  Lots of workloads out there have more reads than writes and reads don't hurt you.  Of course there are write-intensive workloads our there.

2. Write Cache. If your write cache is handling the writes coming in, then the hosts shouldn't notice any delays by the write penalty since they get acknowledged as soon as it hits write cache which is usually very quick (DRAM is faster than any disk drive, even flash), then data is de-staged later in the background.  So as long as you don't over-run write cache, you should never notice the penalty.  On the NX4, a performance problem would come from what's called "forced flushes" which is when the write cache goes over its high watermark On your new box, this should be even less of a problem due to the higher amounts of memory, and the OS improvements of the way cache is handled in MCx.  There are no more watermarks or watermark flushing as the system is smart enough to not allow a host to over-run the cache and will automatically pace the writes from that host down based on the drive bandwidth for the writes all in real time.  Also memory is dynamically allocated to read cache or write cache as needed in real-time based on your workload.

3. Big sequential full-stripe writes.  If you are doing big sequential writes to new stripes, you won't notice the RAID write penalty because the parity can be pre-calculated and written out to the stripe.  The penalty comes into play when you have to insert writes into an existing stripe because I have to read in the existing data, re-calculate parity based on the new stripe, then write it back out.  But this will depend on workload as well as how many empty stripes you have.

There is always the option to run RAID-10, but I would only do that if I knew the workload couldn't handle RAID-6 even with write cache.  Your EMC SE should be able to help you see the impact based on your real workload, especially since you have data on an existing NX4 today, and then model that workload onto a 5200 to see what the effect should be.

Hope this helps.