I worked as part of a team that did a very similar configuration for a local company here in North Carolina. I have uploaded that configuration here. We ended up using RAID 10 for datafiles, though. We did segragate the online redo logs onto their own disks, however.

The choice of RAID 5 vs. RAID 10 for datafiles is non-trivial. You really need to think about that. Frequently, RAID 10 is a better choice. RAID 10 is better at write intensive workloads than RAID 5. RAID 10 also does sequential I/O better than RAID 5. You should use RAID 5 for small, random I/O which largely consists of reads. Heavy, large sequential write I/O should be put on RAID 10. I think you get the idea.

Note the use of FAST Cache vs. FAST VP. You also need to think about that carefully. FAST VP is better for deterministic, predictable I/O patterns which do not vary significantly over time. FAST Cache is better for databases (such as this one) where the I/O patterns are variable and unpredictable.

Anyway, take a look at the configuration we put together and see if that sparks some ideas.

Jeff,

why did you decide not to use RAID 10 pool and went with traditional RAID 10 raid groups ? I can't tell from the document you posted if MetaLUNs were in use or simply dedicated raid groups for specific number of data files ?  I would think with pool solution you can later on utilize FAST-VP and hopefully with next version of flare being able to add drives to a pool and being able to "rebalance" the data. Looking at deeppat design, and considering his relatively small resources ..anything stands out as a red flag ?

The customer specified traditional RAID groups. Not sure for the reason, or if there even was one. Obviously, a RAID 10 pool would have worked fine as well. Sometime folks just don't want to come into the new way of doing things!

My thoughts for your consideration.

Selection on FAST_Cache and FAST_VP, general speaking, F_Cache is more friendly to smaller IO and Random IO, FAST_VP would provide more on bigger IO and Sequential IO, therefore F_Cache would be better choice for OLTP, FAST_VP would be one for OLAP, this selection should be careful.

About Raid Selection in F_Cache environment.

R10 and R5 would not have much performance difference after F_Cache warm-up if you have proper F_Cache configuration. The difference on them are on F_Cache warm-up time, performance baseline of access on un-cached data. R10 would perform better on it with cost / # of spindles as tradeoff.

I tends to R5 if customer is able to understand F_Cahce warn-up.

Thanks,

Eddy

at some point data gets distage from fast cache, it destages that much faster (less write penalty) with raid 1/0 than raid-5.

Eddy Yang wrote: I tends to R5 if customer is able to understand F_Cahce warn-up.

what does it mean if customer understands fast cache warm-up ?

I think what Eddy is trying to say is :

1. FAST Cache is created empty.
2. There is an initial warm up period, as more and more hot data is cached and  the FAST Cache hit rate increases gradually.
3. Host reads/writes of hot data will be serviced by the FAST Cache leading to a reduced demand for IOPS on the rotating disk behind the FAST Cache.

Therefore if analysis shows the system suitable for FAST Cache, a different disk or raid onfiguration can be used (R5 instead of R10): this is discussed in the whitepaper: Deploying Oracle Database on EMC VNX Unified Storage

Allan

if you have a brand new application, you don't know it locality of reference, it's re-hit rate so how to make that recommendation (raid 1/0 vs raid-5 ) ?

Thanks Allan, I like to add a bit.

Performance chart of IO w/ F_Cache looks like a log algorithm, therefore the selection of baseline is important under certain SLA.

Eddy

Here is my thoughts for your consideration.

1. Application design does matter with a specific data structure, so speak with application dev to estimate its tendency of OLAP / OLTP.

2. Put OLTP oriented part on R10 and OLAT oriented part on R5.

3. Put 5-10% capacity EFD on system, note it is not for performance baseline, it is only to absorb peak IO.

4. Enable Perf monitor on system to collect NAR/Trace or BTP for future analysis

Eddy

Eddy Yang wrote: Thanks Allan, I like to add a bit. Performance chart of IO w/ F_Cache looks like a log algorithm,

what does it mean, you can please explain ?