You need pools for all advanced data features – like thin, compression, FAST VP and soon snapshots – on the block side (FC)

For file (NAS) I don’t see that many advantages of using pools vs. traditional raidgroup – expect maybe a bit of ease-of-use, more granularity for sharing capacity with block storage and FAST VP.

Thanks Rainer. We rarely use Thin nor Compression- due to the requirements from projects, as to FAST VP, if we use one type of disks in one pool, I believe FAST VP would not provide extra performance anyway, that's the thing confusing me, in our environment, I doubt what would be the benifit to use pool over raid.

I heard VNX's latest f/w would introduce re-stripe when new disks adding into the pool, like what vmax does, I guess this might be the only good thing for us to choose pool in terms of benefits.

Also I agree with you on NAS using pool, actually it has a downside that causing waste in our environment. We have one NAS pool that acommodates 20 disks, only around 30% space are used and rest of them just sitting there waiting to be ultised. I know we still can use that pool to build SAN LUNs if we want, but logically we'd happy to seperate them in case of future confusion. I don't see any problem in CX4 over this, I always created just a little more than the needs and will add when project required more.

If you want to take advantage of tiering you'll need to have your data in pools.

I've seen a lot of people here using block pools and assigning lun's to file from that.

So if you aren't planning on tiering your NAS data the recommendation is to use RG's, otherwise you need pools.

You do not need to create a pool with SSD drives, with the ability to use FAST VP and FAST Cache

For example: You can have a pool with 10% SSD, 80% FC (10K+15Krpm), and 10% SATA. With Fast VP, the "hot" data will move into the SSD, the warm data in the FC, and the cold data in the SATA. The SSDs will help with performance, while the SATA will help with capacity. With the FAST Cache, the "active" data with move into the SSD drives configured for fast cache.

I reckon disk pool is more like an easy management solution. If you could identify your IO based on each applications, pool would not provide too much benefit - unless emc's new flare of re-striping disks works well.

There are many things to consider when creating a pool from architecture design level and it might take adverse effect if not planning well, in a RAID5 pool the disks will still be configured as multiple RAID5 groups and made private LUNs after this.

Hi Calvintree

There isnt really a defintely answer to your requirement. But based on experience, I would recommend you to go with pool approach as its a much easier way to manage. Bear in mind of the "penalty" in capacity loss... you looking around 2-4% as pool are sliced into 1GB "chuck"

I would create a pool or RG for the SSD. This will host the IO intensive LUN such as log disks

2nd pool will be a FAST VP pool of SAS and NL-SAS. This will be your second fastest disks. Use it as DATA luns.

If you still have some NL-SAS available... create another pool for all your low IO requirement disks such backup.

thats my 5 cents worth

It may be worth having a look at the relevant integration page. e.g. Everything Oracle at EMC. 

While researching SQL performance with VNX, a document I found at the Everything Microsoft at EMC, showed there is a preformance benefit to using RAID group LUN's for high IO DB's.