VNX2 - Non FAST and all 1 Tier (NL-SAS)
If I have a VNX2, or even a VNX1 for that matter, configured with Storage Pools will my data be striped to all disks in the pool as it would be with FAST enabled?
The way I understand FAST is that data extents (slices) will be moved between tiers in either 1gb (vnx1) or 256mb (vnx2) slices.
I have an application that is heavy sequential write ~70%. Right now I am using RG and multiple Traditional LUNs presented to a Linux host and bound as a single VG.
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.
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 Blog...
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.
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
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.