This post is more than 5 years old
67 Posts
0
936
Thick Provisioning yesterday's news?
Hi,
Is it EMC's recommendation not to use FAT devices at all if it can be helped? I know there are a couple of very specific areas where Thin provisioned device is not supported yet e.g SRDF/EDP R21 devices. In a normal scenario is there any peformance benefit in having a Thick/FAT device mapped to a host over a thin. I understand the VMAXe (the baby brother of VMAX) will be fully thin provisioned. I wonder will it be a case that the move will be to only have thin devices mapped to an FA and thick devices are the back end implementation for pool provisioning. Very general query I know but was just wondering is there any performance benefit to thick devices over thin. BTW in our 2 x VMAX (with SRDF/S) we have implemented thin full provisioned devices as recommended by EMC SA.
Thanks,
Victor
GlenH
141 Posts
0
June 20th, 2011 15:00
Exactly right.
I thought my post was reasonably clear on both those counts, but so everyones clear i'll adjust it to:
We do see that for most application workloads, an individual LUN performs significantly better as a thin (VP) compared to thick because a single TDEV can be bound to a pool with many disks compared with a single thick lun that can only address 2/4/8/16 disks depending on the RAID type.
Where multiple thick LUN's perform better than thin LUN's is with sequential write workloads directed at Raid 5 7+1 or Raid 6 configurations.
This is because with thick LUN's, the symm can use Optimised writes (single write for parity and all data for a given raid stripe from cache) whereas with Virtual Provisioning having a 768KB stripe size, a sequential workload directed to the TDEV will most likely not result in optimised writes to the backend and we see a significant increase in backend I/O's to destage data. This is due to the fact that the raid stripe and the VP stripe are not size aligned so we are unlikely to get all the data elements for the raid stripe to calculate parity.
Raid 1 and Raid 5 3+1 do not have this issue as we dont use parity for raid 1, and the VP and raid stripe sizes are the same for Raid 5 3+1 (Being 768KB).
GlenH
141 Posts
0
June 19th, 2011 21:00
Victor,
The EMC Performance engineering tests show that in general, there is very little difference between Thick and thin (VP) provisioned devices in terms of an array envelope test.
We do see that for most application workloads, an individual LUN performs significantly better as a thin (VP) compared to thick because a single TDEV can be bound to a pool with many disks compared with a single thick lun that can only address 2/4/8/16 disks depending on the RAID type.
One area where thick LUN's perform better than thin LUN's is with sequential write workloads directed at Raid 5 7+1 or Raid 6 configurations.
This is because with thick LUN's, the symm can use Optimised writes (single write for parity and all data for a given raid stripe from cache) whereas with Virtual Provisioning having a 768KB stripe size, a sequential workload directed to the TDEV will most likely not permit optimised writes to the backend and we see a significant increase in backend I/O's to destage data. This is due to the fact that the raid stripe and the VP stripe are not aligned. Raid 1 and Raid 5 3+1 do not have this issue as we dont use parity for raid 1, and the VP and raid stripe sizes are the same for Raid 5 3+1.
The benefits of VP generally outway any negatives by a large margin, and I would recommend any customer deploy VP over thick in any situation.
For high write workloads (or clone targets) I would make sure that 3R5 is used to ensure the optimised write capability is maintained.
Glen.
Quincy561
1.3K Posts
0
June 20th, 2011 03:00
It is incorrect to say that 7+1, 6+2 and 14+2 do not support optimized writes. However it is less likely that the whole write stripe will be write pending before we destage.
And even if we don't perform optimized writes, having the wide striping could make the sequential writes to one LUN a lot faster.
vforde
67 Posts
0
June 23rd, 2011 01:00
Glen,
Thanks for that, very informative. Your first post was clear to me but your second was even better ;-)
That's exactly what I was looking for, I was just trying to get a clear understanding from an implementation perspective if there was a scenario where thick would come up trumps and I see where this can be countered by aligning the stripes (R5 3+1). So an extra pool with that config addresses it.
Thanks for your help Glen I may just pick your brain again in the future.
Victor