i also recommend you read this white paper so you can familiarize yourself with the platform and best practices.

http://www.emc.com/collateral/software/white-papers/h10938-vnx-best-practices-wp.pdf

you need to buy at least 4 drives ..so you need to get at least two more drives.

Thank you very much

if you are willing to backup and restore your data then sure.

As I know, the recomendations for RAID6 are 6 + 2 disks. It is default when I going to create new raid6 pool on my VNX5300.

Is it possible to destroy the current ( 4+2 ) pool and create new ( 6+2 ) pool without byuing new disks?

Hi. As already noted, for RAID 6 you need a minimum of 4 drives.

I just wanted to add the following comments;

Pool LUNs are made up of slices that come from private LUNS within the pool construction. You don't see these private LUNS, but they are created automatically when you create the pool.

In your configuration, you have an existing RAID6 4+2 private RG. That means that each slice (1GB in your system) comes from 6 drives. From a performance perspective that can offer 6 drives worth of random transactional activity.

For thick LUNS, each 1GB slice will map to 1GB of logical block address space. So now if you look at the performance capability of 1GB of LBA space, you have 6 drives.

Now, if you expand the pool by 4 drives, a new private RG will be created and private LUNS. Slices on this new capacity will be made from 4 drives. So now, when you have a hot area of activity within 1GB of LBA space it could be served from 4 drives instead of 6.

In this example, 4 drives versus 6 may not be that big an issue; but if you were using a preferred modulus of 16 drives and had a RAID 6 pool with 16 drives, and then expanded by 4, you could have some 1GB slices across 16 drives and others across 4 drives. That has an obvious performance difference.

For ease of use, you can expand pools by the minimum drive count that any particular RAID type supports, but it isn't always the best thing to do - try to adhere to the preferred modulus as a multiple for each tier (noted as recommended in teh drop down for drive selection).

Also, in your case, if you expand by 4 drives, you effectively lose the capacity of 2 for parity. If you were able to backup, recreate the pool with 8 drives insted of 6, for the same capacity increase you just saved the cost of 2 drives, and maintained consistent performance distribution.

Other examples of where this would be applicable: RAID 1/0 pool with 10 drives -- you'd get a 4+4 and a 1+1 under the covers. A RAID 5 with 8 drives -- youd' get a 4+1 and a 2+1.

I hope those additional comments were useful.

Rgds,

~Keith

@ dynamox: Does it mean that everytime we expand a Raid 6, we would require minimum 4 disks. 2 of these disks we are bound to lose in parity, everytime we expand this Raid?

Basically, yes. Each time you expand, private RG's are created with the new resources and if that tier happens to be RAID 6, it has 2 drives overhead for each private RAID Group so it is best to try expand at any time with the preferred modulus for the current tier option (or a multiple of that preferred modulus).

Since Release 32 operating environment, we have the following tier options;

RAID 5, 4+1 or 8+1

RAID 6 6+2 or 14+2

RAID 1/0 4+1

The minimum RAID Groups that could be created with each RAID Type is;

RAID 5 = 3

RAID 6 = 4

RAID 1/0 = 2

If your tier preference was R5 8+1, then it would be better to expand with at least 6 or 7 drives at a time, with the best being 9. If you expand by 3 drives, you then have slices coming from 3 drives rather than 9, thus a performance difference.

As I try to explain, with slices serving specific LBA ranges of your pool LUNS, specifically for thick LUNS, the size of the private RG may affect the performance that will depend on when you touch individual slices. I will add that it may not be typical that activity is localised to a single 1GB slice but just highlighting that this is the way the technology is working and how it might influence the performance. Skew in the environment affects active data regions and that will influence what is accessed at any point in time.

Incorrect -- expanding a pool tier builds new private RG's within that tier. If it is RAID 6, the minimum we support in a RAID6 configuration is 4 drives.

In older code, before we had storage pools, we did support expanding RAID Groups, but even with RAID 6, it would have been in even number disk increments to go up to the maximum 16 drives per RAID Group.

In that case we would restripe the data across the drives and maintain the same parity overhead for the single RAID Group.

In a pool, we don't expand existing private RAID Groups, we create new one's and then rebalance the exisiting allcoated space across the new resource (based on capacity or performance, depending on data services running on the system).

Not sure if it helps but there is a decent summary mentioned here which makes an effort to describe the pRG structures.

https://community.emc.com/message/696115#696115

If you plan to do so via CLI, the following post may be useful:

https://community.emc.com/message/756310#756310