EMC CLARiiON and Virtual Provisioning

6 06 2010

Beginning with Flare code revision 28.5, the block-based storage side has been able to take advantage of the thin provisioning functionality that the filesystem-based camp has been enjoying for quite some time.  Virtual Provisioning is a admin-configurable option on CLARiiON arrays which allows the full size of a given traditional LUN or metaLUN to be presented to hosts while only occupying the actual utilized space on the back-end disks.

Thin LUN technology therefore gives a storage administrator a lot more freedom with how storage is allocated and managed on an ongoing basis.  It can also work to allow for more efficient use of storage in an environment due to a “use on demand” model…basically physical storage is only allocated when new data blocks are written.  Once the administrator determines some high level parameters, such as defining user capacity, subscribed capacity, over-subscribed capacity, and %Full Threshold, a mapping service that operates at the array level can automatically manage the provisioning of storage moving forward.

Thin LUNs are very similar to traditional LUNs except for the fact that they consume less physical space on the array, and that they are allocated from Thin Pools instead of RAID groups.  An administrator adds disks to the Thin Pool so as to increase the physical capacity for all underlying LUNs to consume as they automatically expand to meet host requirements.

While this technology can bring a lot of benefit to most storage environments, it is always important to test out the potential impact, both positive and negative, before implementing into production.  Listed below are some of the considerations and best practices for using Virtual Provisioning in your environment:

-Thin LUNs should not be used to support workloads which cannot tolerate variable performance

-Thin Pools can be comprised of both FC and SATA disks, as well as Enterprise Flash as of Flare 28.7

-Vault drives cannot be used in a Thin Pool

-While FC and SATA drives can be mixed in a single pool it is not a recommended best practice to do so

-FC and SATA drives cannot be mixed into the same pool with EFDs present

-All drives within a Thin Pool should be of the same speed, they should also be of the same size

-If using drives of varying size, first create the pool using all drives of the same speed, then expand the pool using all the remaining drives differing in speed

-Thin Pools should be created in increments of 5 drives for RAID 5 pools, and 8 drives in RAID 6 pools

-There is an overhead for creating Thin LUNs which can be calculated using the following equation:

Metadata overhead (in GB) = LUN size (in GB units) * .02 + 3GB

-Thick LUNs can be migrated to a Thin format and vice versa

-Flare 29 is required to use MirrorView to replicate Thin LUNs

-Thin LUNs cannot be private LUNS and therefore cannot be used for Reserved LUN Pools, Clone Private LUNs, or Write Intent Log LUNs

-In VMware environments, the “eagerzeroedthick” virtual disk format is not recommended for use with Thin LUNs




2 responses

7 06 2010
Matt Taylor

Great post Matt, good info.

23 08 2010
Virtual Provisioning, Storage Pools and FLARE 30 « Matt Hensley’s Blog

[…] Storage Pools and FLARE 30 23 08 2010 A while back I wrote about best practices for CLARiiON and Virtual Provisioning, and while it was an excellent feature when introduced with FLARE 28.5,..it’s gotten even […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: