thin pool - Best practices

Actually, there is no maximum size for a Thin Pool as far as bytes are concerned.  In FLARE28 and 29, there were limits to the number if physical disks in each pool, as well as the number of pools, and number of disks total in all pools.  In FLARE30 those limits are gone.  I don't recommend doing this, but you can create a single pool with all of the drives that an array can support (a single pool with 955 drives in a CX4-960) minus the vault drives.

You will want to leave hot spares available and most likely want 2 or more pools to give some flexibility with redistributing LUNs later.

The 14TB limit is for the maximum size of a single LUN that is in a thin pool.

Depending on RAID configuration there is a recommended multiplier for drive count though..  RAID5 Pools use 4+1 striping and RAID6 Pools use 6+2 striping.  Because of that you will want to have pools with multiples of 5 or 8 drives, respectively.

In FLARE30, there is the concept of a Thick LUN inside a Thin Pool, as well as a traditional thick LUN in a Raid Group.  The use of a Thick LUN in a pool is targetted at giving better performance for the LUN because the chunks are preallocated across the pool before data is written/read.  So a Thick LUN's performance is slightly more predictable and there is less overhead for writes.  A Thick LUN also guarantees the space is allocated for that LUN if you over provision the pool.  Thin LUNs can experience an outage if the pool runs out of free space.

If you are reaching capacity of a LUN, you can expand the LUN to add more space up to the 14TB limit per LUN.  If you are reaching the capacity of a Pool, you can add drives to the pool, preferably in increments of 5 disks (RAID5) or 8 disks (RAID6) and ideally in large groups like 30 drives, or possibly adding the same number of drives you already had in the pool.

14TB is the largest capacity for a Thin Lun pool

https://powerlink.emc.com/nsepn/webapps/btg548664833igtcuup4826/km/live1/en_US/Offering_Technical/White_Paper/H5512-emc-clariion-virtual-provisioning-wp.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tDb250ZW50RXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwNTI4NGY4LGRvY3VtZW50VHlwZT1wZGYsbmF2ZU5vZGU9MGIwMTQwNjY4MDM1MDUwZV9Hcmlk

here is a good place to start

EMC CLARiiON Performance and Availability Release 30 Firmware Update Applied Best Practices

For a CX4-960 running FLARE29, the following limits apply..

Max 60 pools, 180 disks per pool, 360 disks in all pools, 2048 thin luns

The % full, % oversubscribed, and disk quantity by themselves wouldn't cause a performance problem.  Actually, adding disks in small increments could cause uneven distribution of data on the disks in the pool, ie: newer LUNs and data on the recently added drives vs across all drives in the CX's attempt to even out the amount of raw data on each spindle in the pool.  Clariion doesn't have a way to rebalance the pool after drives are added so the data stays where it was first written.  This can result in hotspots.

The other limitation in FLARE29 (no longer a problem in FLARE30) is that LUNs in a ThinPool cannot be expanded.  The way to get around it is to use LUN Migration to migrate out to a standard RAID Group, then migrate the LUN back into a larger LUN in the pool. In FLARE30 you can expand a ThinLUN in place.  Migrating LUNs out and back into the pool could help redistribute blocks for better performance as well.

All this is guesswork though, the best thing is to engage your local EMC guys to help do some performance analysis on the array, or dig in to Navisphere Analyzer if you are adventurous.

>>RAID6 Pools use 6+2 striping

I understand the performance reasoning for making R6 a 6+2, but couldn't the CX engineers have made it a 5+2 as that would allow us field admins to take a full dae and carve out 5+2, 5+2, HS? Or am I being too logical here.

That would definitely be nice, but I think they are working with what they've got. 

CX is notoriously better with even numbers of disks in a Raid Group when it comes to performance.  Let's say you have 6+2 (384KB stripe size) and issue 128KB IOs, you fill the stripe after 3 IOs and CX can do a full stripe write without the penalty of reading data to generate parity.  If you have a 5+2 (320KB stripe size and issue the same 128KB IOs, you get 256KB of data in the stripe, then you have to issue a read to get the last 64KB for parity calc.   

>Sorry, I forgot to mention, we are on FLARE29 code. But in our senario some of the luns are fixed in size and the increase is not the >requirement. So when such luns are reach max capacity, is it a good practice to migrate them to traditional luns/thick luns (Flare 30 onwards).

From FLARE 29 through 30.5, 14 TB is the maximum capacity pool-based LUN.

If you need a larger capacity LUN, you will need to either: re-partition your application to use additional LUNs (if possible to remain pool-based), migrate to a larger capacity FLARE LUN (this may require a large RAID group or high-capacity drives), or migrate to a MetaLUN.

A pool-based Thick LUN shares the same 14 TB maximum capacity as a pool-based Think LUN.

Richard,

that makes perfect sense. oh well, us admins have to live with what we've got, too.

It was mentioned that in regards to a thick LUN, "the chunks are preallocated across the pool before data is written/read".  Just wanted to rephrase that a bit as it may lead to some incorrections implications.  The 1GB slices are still allocated on demand from the private lun pool.  I simply wanted to clarify that since the original phrase might have mistakenly suggested that:

1) The extents are (physically) sequential across the disk

2) If the pool was extended, then the thick lun would not have extents residing on the new drives

Basically, for both a thick and a thin lun, the chunks are allocated (mapped from the private lun pool) as needed.  So it is highly unlikely the slices would be physically in close proximity of each other (if shared with other luns thin or thick) and they could very well be written to new drives if the pool was extended.  I know that the statements in the list above were never explicitly mentioned anywhere in the post, but it could be implied.

I'm thinking I am restating what you already know, and I'm misunderstanding what was meant.