Vmax disk layout

You may find EMC's new product called FAST a perfect fit for your environment, it automatically tiers your storage as you define.

Refer to the following document on Powerlink: "Implementing Fully Automated Storage Tiering (FAST) for Symmetrix V-Max."

There is a Thin Provisioning Best Practice document on PowerLink that will answer your questions for this product.

Create a standard TDAT size that fits best for all 3 types of storage.

You want your TDAT's as large as you can get them to make use of the the most space in the physical disk (usually 2-4 TDAT's fit in the disk well for mirrored pairs).

Then create three separate pools such as (just examples, name then whatever you want)

shared_450_efd

shared_450_fc

shared_1000_sata

Now create your various TDEVS, these can be any size you wish. For the sake of administration you may want to pick a small handfull of "standard sizes" but it is by no means required.

If you want to use these devices just like regular devices then when you bind them to the pool you will want to "preallocate" the entire lun size.  Otherwise they act like thin devices.

We've been really impressed with virtual provisioning so far.  It's nice to see all disks working together with low overhead.  I don't think I will go back to a traditional "hyper" model.

I'm also not much of a GUI guy and the VP stuff lends really well to scripting and capacity planning.

That would be great, my email is kbretzius@phlyins.com.

Virtual provisioning brings in some new terms.  You still have your physical drive configuration of some raid type right; raid-1/5 etc.  On that you then create data devices; data devices are not host presentable and is what you place into the virtual pool.  You then create a thin device which you bind to a pool and that is host presentable.  TDAT I believe they are referring to a thin data device which is the host presentable device.

When you talk about TDATs are you refering to Data Devs?  I am new to EMC and still working out the terminology.

BC

I agree with the preallocation ,which is what I have done, it completely negates the thin "unfriendly" application arguement.  One very nice thng in using the GUI is I created a template for a data warehouse environment and used that in creating the devices.  Once the template is created it you only fill in two fields and are then creating devices; makes a fast process a bit faster.

I agree with that, I don't think this would be beneficial until FAST2 is out.

BooyahI

f he is going to create virtual provisioning FAST isnt going to help him right now; he will need to wait for FAST/VP.  FAST works on the classic lun and not the virutally provisioned (thin luns); please correct me if I have this wrong.

TDATs are the data devices that are not host addressable

TDEVs are the virtual (thin) devices that are created and then assigned to various data devices (TDATs) and then the TDEVs are assigned to your host.

Thanks, that makes sense.  I've only heard them refered to as Data Devs, not TDATs.   So it sounds like for optimal peformance I would only create one thin pool for each flavor of disk that I have.  Then if I have applications or servers we don't want to use thin for we  can still create TDEVs for those and just preallocate the space.  This would set us up to utilize FAST2 or FAST/VP when it's available.

Correct.  Some things to keep in mind, about thin pools, that may get you the first time....

- You can only meta TDEVS not already bound to a pool.

- Concatenate , don't stripe your metas

- Preallocate in cylinders, not MB or GB.  While both work, using units other than cylinders often results in a mis-match between total tracks and pre-allocated tracks

- Once you create a pool you cannot change it's name

- If you add additional TDATs (not TDEVS) to a pool you will need to re-balance it (symcfg -cmd "start balancing on pool XXXX;")

What's the "good" reason to use a striped meta volume in a virtual pool?  This only makes your disk heads "Sad Pandas".

There maybe performance reasons to make striped vs. concatenated meta volumes.

There are characteristics of a Symmetrix logical volume that can limit concurrency when there is locality of reference on a given LUN.  So spreading the workload over more TDEVs can increase performance.  This can be accomplished with host based striping over single TDEVs or striped metas.