VNX2 Storage Pools - Non FAST

Your planned usage really does matter here, as does your relative risk tolerance.

If you intended to provision all the storage to the hosts and keep everything the same forever (or whatever the business definition of a really long time was...), then LUNs and MetaLUNs on basic RAID groups would be attractive.

If you want to be able to provision storage in different sizes, and more importantly, take it back and re-provision it in different sizes, the pools would likely make more sense.  You could do this with RAID groups, but there might be extra steps, like defragmenting the groups, to consider.

If your usage includes databases you might want to provide at least two 'lumps' of storage, so that you could allocate database log files from different physical resources than database data files.

Whether you are using pools or groups, the two physical sizes that suggest themselves (to me...) are 4+1R5, and 8+1R5.

In practical terms you could, for example, form a pool using 18 disks formed from 2 x (8+1R5) groups, or form two RAID groups as 8+1R5 and create LUNs and MetaLUNs from them.  That would leave you Three unbound disks for hot spares.

You could also form a pool from 20 disks using 4 x (4+1R5) groups, or again, form those same disks into four separate 4+1R5 groups and create LUNs and MetaLUNs from them.  That would leave you one hot spare.

If you elect to go with pools, those are likely your two best approaches, and I would mention that as far as capacity is concerned, you end up with 16 disks worth of user capacity either way.

If you decided on RAID groups, you could create 2 x (4+1R5) RAID groups *and* a 8+1R5 RAID group and still have two disks available for a hot spare.  While you could construct a pool with those same characteristics, doing so would be a violation of EMC best practice.