Short answer:  Yes, the pool is composed of one or more RAID groups of disks, and LUNs in the pool will use all of those groups.

If you aren't using thin LUNs though, there would be a couple of advantages to using MetaLUNs across multiple traditional RAID groups:

1)  On VNX2, LUNs in RAID groups are served with Symmetric Active/Active access to both SPs, so you can round-robin across all paths to the LUN, not just to one SP.

2)  There is a modest performance hit of a couple of percentage points to using pools over traditional RAID groups.  This amounts to a bit of software overheard in the execution path for pools.

Why use pool, if you have only NL-SAS disks? RAID group have more performance, isnt't it?

Maybe flexiblity, thin LUNs, snapshots, deduplication, ....

A good and valid question.  I manage 14 VNX/VNX2 arrays, and fully ten of those are configured with only one drive type, and all of those are organized into RAID groups, not pools.  You seemed particularly interested in VNX2 units, but for VNX arrays, and in particular the 'smaller' ones there there is a good argument to be made for going a bit further than just not using pools; you can significantly improve the robustness of the units by eliminating the enablers for them altogether.

Here are the Software and SP Memory tabs from the properties of a 5300 I have with pools:

And here are those same tabs from one that I have 'cleaned up':

I would draw your attention to the SP Usage, and the Write Cache Memory differences between the two.  By eliminating enablers, the SP Usage footprint drops significantly, resulting in more than doubling the available write cache.  The stripped down systems can only create RAID groups, not pools, but they can still support MetaLUNs, as well as analyzer for monitoring and troubleshooting.

Without MCx, and probably more importantly the larger SP RAM in the 5200/5400, that difference in write cache makes a profound difference in the robustness of those 5300s.  They experience far fewer forced flushes of their write cache at any workload, along with an improved ability to defer and coalesce writes, and that provides a more consistent write latency.  Read latency is also improved since the backend buses aren't as often clogged up with write activities.

I have a 5200 with a similar uniform disk configuration, that unit has double the SP memory, and all the advantages of MCx Flare code.  It is licensed for just the core components, but it is still enabled for making and using pools.  But it too is configured into just RAID groups due to the limitations of Symmetric Active/Active, and it is a 'happy and productive' unit.

Can you compare performance of your application with RAID group LUN vs Pool LUN?

I think pool and thin LUN have poor performance vs. RAID group LUN.

I don't see why snapshots are on this list...but otherwise; absolutely.

The newer pointer-based snapshots require pools – sure you could use SnapView with raid groups

Yes if you know what functionality you need and know how to create an optimal diks/LUN config there is nothing wrong with using raidgroups

If you don’t then pools are simpler to use

Was your question answered correctly? If so, please remember to mark your question Answered when you get the correct answer and award points to the person providing the answer. This helps others searching for a similar issue.

Also, you can use the internal EMC Forums and mailing lists if you need additional information.

glen

In my experience the performance difference isn't much at all. There was a study not long ago which pretty much concluded the same: Virtualized Storage Performance: RAID Groups versus Storage pools - VMware VROOM! Blog - VMware Blogs 

The  differences that stand out for me is the fact that with RAID Groups you can get granular with FAST Cache to a LUN level, with Pools it has to be on or off for the entire pool. Also it's far easier to extend LUNS in a pool, and for that matter to increase a pool size. No need to bother with meta's.

Well, how about active-active vs ALUA LUN performance in VNX5200?