First, pools are designed for VNX System Administrator 'Ease of Use'.  The Pool provisioning algorithms attempt to solve the complexities of the provisioning problem with the number of drives the Storage System Administrator provides.  'Gaming' the algorithm to tease-out 'special' configurations from the algorithm defeats the purpose of 'Ease of Use'.

VNX System Administrators whose priority is optimal performance, highest possible capacity utilization, or special RAID group drive topologies should consider manually provisioning with traditional RAID groups.  Traditional RAID groups give a Storage Administrator full control of their storage system's provisioning.  

EMC Unified Best Practices for Performance and Availability: Common Platform and Block O.E. 31.5  a.k.a VNX Best Practices in its 'Pool provisioning' section gives a high-level description of the pool's provisioning algorithm. Note this description is not comprehensive.  For example, submitting 17-drives to be provisioned in a RAID-5 pool results in two (5+1)s and a single (4+1).

However, that section does make you aware of the algorithm's general parameters, explains the advantages of 'RAID group symmetry' (the reason why 2x(5+1)'s and a (4+1) may not be ideal), and encourages you to provision with multiples of 'default' RAID group numbers of drives.  That is, multiples of five for RAID-level 5 pools, and multiples of eight for RAID-level 6 and 1/0.

VNX Best Practicesis available on Powerlink.

HTH

Hi,

Thanks for the quick response.

The problem I have with this is that these restrictions have been hidden from us.

One would have expected that you would have flexibility of RAID Group sizes as you did prior to Pools, unless EMC stated otherwise.

I have reviewed the help, read pretty much all the available white papers, been to pretty much every session on Pools/FAST at the last two EMC World conferences, but I am certain this restriction has not been mentioned - rather important I would have thought.

I have just downloaded the latest best practice paper and yes this is now a bit clearer, but:

1. None of this information has been included in previous versions of this or other papers

2. When is the full algorithm going to be published - why keep it so secret?

3. I am all for best practice and warnings saying that what you are doing is not ideal, but sometimes you want extra flexibility - we had it with the old RAID groups so we remove it for Pools?

4. Surely best practice for 9 drives R5 would be an 8+1, not 4+1 and 2+1, so the argument about best practice is just not true

5. I assume there is no work around for this - is there any plans to remove some of these restrictions in the future even if it is from the command line?

6. What are the plans to upgrade the VNX Capacity Configuration tool to include these rules - it should stop you creating configurations that are not valid?

7. The documentation states that best practice when expanding a pool is to add the same number of disks as is already in the pool - surely this is a bit impractical as users will not be doubling capacity every time they expand

8. Using RAID Groups would be fine, but we loose all of the new features (i.e. FAST VP, Compressions, ...) and surely is legacy technology that we should be moving away from

I guess moving forward we need to stick to multiples of 4+1, 6+2 or 4+4 otherwise we could get into trouble.

The issue of hidden restrictions with the VNXe this has been even worse, there are loads of features that existed in an NX4 that have not been ported over and there has been very limited documentation to list them.

I really think for the sake of both partners and customers EMC has to be much more transparent on what restrictions and missing features apply to new products and technologies.

I understand that there is a marketing message to this and some of these restrictions can be perceived negatively, but at least let partners know.

I hope my feedback helps.

Many thanks

Mark

EMC Partner

Mark,

I'll try to address your questions, as best I can.

1. None of this information has been included in previous versions of this or other papers

The section of VNX Best Practices 31.5  does include more information than the 31.0 version.  VNX Best Practices has been updated with each revision of the product.  Check regularly for updates.

2. When is the full algorithm going to be published - why keep it so secret?

For most users the 'general description' of the algorithm has been enough to meet most needs.  It is unlikely the full algorithm will be made public.  The algorithm is complicated, and parts of it are a Trade Secret.  In addition, the algorithm has been evolving with each release of the virtual provisioning product.  It is likely it will continue to evolve as the virtual provisioning product goes forward. 

3. I am all for best practice and warnings saying that what you are doing is not ideal, but sometimes you want extra flexibility - we had it with the old RAID groups so we remove it for Pools?

Many users thought that the provisioning of 'the old RAID group' was complicated and laborious.  Pools and their automated provisioning were designed to make RAID group provisioning easier.  Provsioning can be somewhat 'open-ended'.  To bound the problem, and make provisioning 'do-able' within software, some restrictions were built-in.  That is, 'Ease of Use' came at a loss of some flexibly over traditional RAID groups.  However, the algorithm provisions well for the most common provisioning needs.

4. Surely best practice for 9 drives R5 would be an 8+1, not 4+1 and 2+1, so the argument about best practice is just not true

Sorry.  Nine drives in in a RAID 5 pool would likely be a (4+1) and a (3+1).  Those two RAID groups total nine drives.  Ideally there should be 10 drives to create two (4+1) RAID groups. 

From a performance and availability stand point, the (4+1) is the RAID 5 'sweet spot'.  This is the pool default RAID 5 group.  Although it does not have the higher capacity utilization of a (8+1), it has a stripe size that 'plays well' with most I/O sizes, and rebuilds more quickly.  EMC Unified Storage System Fundamentals for Performance and Availability in its 'RAID groups' section describes the advantages of the (4+1) topology over RAID 5 groups with a larger number of drives.

5. I assume there is no work around for this - is there any plans to remove some of these restrictions in the future even if it is from the command line?

The virtual provisioning product continues to evolve.  It is likely in future revisions that the algorithm will improve its efficiency, offer more flexibility, and support additional functions.

6. What are the plans to upgrade the VNX Capacity Configuration tool to include these rules - it should stop you creating configurations that are not valid?

The VNX Capacity Configuration Tool is supported through (I believe) through USPEED.  You should contact your USPEED representative for that information.

7. The documentation states that best practice when expanding a pool is to add the same number of disks as is already in the pool - surely this is a bit impractical as users will not be doubling capacity every time they expand

The performance implications of pool expansion with the current revision of virtual provisioning are well documented.  The virtual provisioning product continues to evolve.  It is likely in future future revisions that pool expansion will be handled more efficiently and with greater flexibility.

8. Using RAID Groups would be fine, but we loose all of the new features (i.e. FAST VP, Compressions, ...) and surely is legacy technology that we should be moving away from

The virtual provisioning product continues to evolve.  It is likely in future future revisions that pool provisioning will have greater flexibility.

HTH