Welcome to this week’s VMAXHumpday! Hope you are having an awesome week! Today I would like to talk about TDATs, TDEVs and Thin Pools! Or as some people call them, the Lions, Tigers and Bears of VMAX! OK…I Just made that up, but they can be scary if you don’t understand them. I will do my best to explain.
Before I do the explaining, I like to give a little history. Not so long ago I worked on older Symm’s. In the early days, I was a UNIX admin and provisioned storage to AIX, Solaris, etc type of hosts. I was never able to fully grow out a massive unix beard, so I moved on and started doing storage instead. I took a little break from the EMC line and did a few other types of storage arrays until I moved to North Carolina about 7 years ago. When I first got to NC, I was in charge of migrating off of older DMX-1000 and onto DMX3 and DMX4 arrays. Back then, we didn’t have any stinking thin provisioning or thin devices. We had hypervolumes and small metas and we liked them! EMC usually setup and created all devices in the array and we presented a certain amount of those volumes to hosts and the host would stripe everything using host based striping. Basically they would carve out all the hypervolumes for us and form metadevices to present to the host based on raid protection needed. It was OK, gave predicable performance, but let’s say you had the array carved into 36GB devices and you had to present 3TB to a host… Have you ever seen an AIX admin that was really really angry? I have. It isn’t pleasant.
So enter the DMX4. Enginuity Code 5874. TDATs were introduced and symmetrix was forever changed. TDATs could be formed into a thin pool and thin luns could be carved out of that pool. The way I like to look at it is that the TDATs were created so that you could create luns of multiple sizes out of a thin pool and still have the predictable performance of what we had in the past when we had a bunch of 36GB metas carved out for us. We could then carve out our own metavolumes of varying sizes and we made our sysadmins happy!
So there we have it. History!
Here are the definitions of TDATS, TDEVS and Thin Pools and some considerations:
TDAT: Data devices that provide the actual physical space to be used by the thin pools on your VMAX. Only TDATs with the same protection level (R1,R5,R6) can be used to form a thin pool. Normally thin pools are already defined and carved out during the implementation and design phases of your VMAX.
TDEV: These are the luns that are carved out of the Thin Pool. These can be single luns (up to 240GB) or can be formed into meta-luns for larger capacities. We always recommend when forming metas to create them in groups of 4/8/16 meta members to provide consistency across the Thin Pool, balance and performance. I won’t get into the specifics of why here, but just note this is a good thing.
Thin Pools: These are created by using TDATS. Normally on a VMAX ‘basic’ installation you may have EFD, FC and SATA drives. Your Thin pools may consist of something like:
2TB_SATA_3R5 (a pool made up of 2TB SATA TDATs in Raid 5)
300GB_FC_R10 (a pool made up of 300GB FC TDATs in Raid 10)
EFD_3R5 (a pool made up of 200GB EFD TDATs in Raid 5)
These thin pools are formed normally based off of back end Disk groups that contain the appropriate drives and back end hypervolume structures.
Yes Hypervolumes still exist!
This is the normal disk group Picture in Unisphere:
Click on Disks and you see this:
Then click on hypers and you see this:
Pretty cool huh? So basically, when the TDATs are carved out properly, the stripe across all of the disks in the disk group and form the Hypers…and it is really really cool.
Kinda sorta the same way they did it back in the day with hypers but providing a lot more flexibility in terms of carving out storage.
Hope you enjoy!
-sangeek