We recently purchased a VNX5300 for a small VDI deployment (500 users or less).
We ordered 38 SAS drives and 10 EFDs. The vSpecialist at EMC is recommending:
2 EFD for FAST Cache
7 EFD in FAST Pool 1 (RAID-5)
30 SAS drives in FAST Pool 1 (RAID-5)
The remaining EFD and SAS drives are for the vault and spares and stuff like that.
I'm fine with the recommendation, but I wonder if this might be better:
8 EFD as FAST Cache
6-disk RAID-10 groups on the SAS drives (five of them)
MetaLUN across the RAID-10 groups for replica datastore and all the desktops. Many (if not all) of the desktops are persistent. This will be running on vSphere 5 and View 5.
Assume 3 images and about 200 users initially, scalable to about 500. With this many spindles, capacity is not a concern. This array is dedicated to VDI. What do you think?
Solved! Go to Solution.
I would honestly go with the vSpecialist's recommendation. With the FAST Pool method, you will very effectively stripe across all the disks, as opposed to 5 disk sets in the MetaLUN model. You also get better, more efficient use of the EFDs.
I vote for the vSpecialist config but i'm biased on that one. I think what Matt pointed out is a great point, you get a lot more efficiency in 1 FAST Pool vs having to manage disk sets and MetaLUNS. The EFD's in the FAST Pool will allow the vast majority of your "hot" data to be on the right tier of storage and the 2(ea) EFD for FAST Cache can catch the bursty workload that might be in the SAS tier.
I believe we quoted 8(ea) EFD's for the FAST Pool, 2(ea) EFD's for FAST Cache and 1 or 2 EFD's for Spare - i'm double checking with your TC to be sure.
Just my 2 cents, VNX pooled LUNs have at least 10% performance loss comparing with Flare LUN. Fast Cache is suitable for heavy reads like startup storming and AntiVirus scan. Also good for heavy writes like System patch and application updates. Your configuration of striped Raid10 metaLun will have much less backend overhead and write penalty if you don't mind management complexity and the capacity.
Even though pooled LUNs may cost you some performance, you will stripe the data wider thus using more spindles for a given workload. As the desktop pools are persistent, FAST-VP will work out nicely here. Any "gaps" in the FAST-VP trick will be solved with the FAST-cache floating on top. This looks like a nice setup.
As for the RAID write penalty: This is where cache and FAST-cache comes in. Pending writes in FAST-cache will be held and commited to disk in full stripe writes if possible. This will boost the RAID5's write performance (theoretically even beyond the write performance of RAID10).
I firmly believe either setup will work, but lean towards the FAST-VP approach too. There is one differentiator between the two: Data on the EFDs in the FAST-VP pool will always have snappy access the first time round. FAST-cache will not kick in until the 3rd hit on a block. Only then the block gets promoted to FAST-cache. So FAST-cache will help on anything repetitive, but less so on single block access. Basically I'd go for the "FAST-cache" approach when you have desktops recomposing on a daily basis, and go the "FAST-VP" route for anything more "stable".
Where to put the replicas in these setups is an interesting one: You might consider to put them on the "highest tier" in FAST-VP, effectively putting them directly on EFD in this case. But on the other hand, they'll be sitting there after boot just taking up space (which is expensive on EFDs). After boot the replicas are hardly touched (most reads come from the linked clones).
I think (though never tested) you could easilly put them on the lowest available tier as well. As soon as some VMs start booting (and hit the same blocks), the active part of the replicas will be shooting up into FAST-cache anyway. All the boots after that will be served from FAST-cache and will be speedy. That would be something interesting to test!
Data on the EFDs in the FAST-VP pool will always have snappy access the first time round. FAST-cache will not kick in until the 3rd hit on a block. Only then the block gets promoted to FAST-cache. So FAST-cache will help on anything repetitive, but less so on single block access. Basically I'd go for the "FAST-cache" approach when you have desktops recomposing on a daily basis, and go the "FAST-VP" route for anything more "stable".
if data is already on EFD, why would it get promoted to FAST-cache ?
It will not get promoted to FAST-cache if it is already on EFD. I'll clarify what I mean:
When you look at both setups, the one setup has a FAST-VP pool (with EFDs there) and some FAST-cache. The other solution has RAID10 (non FAST-VP) with more FAST-cache on top.
Blocks that are on the RAID10 set which get touched once will never make it into FAST-cache, thus never in EFD at all. As opposed to the FAST-VP solution, where the hottest data will actually be sitting on EFD already (on the EFDs in the FAST-VP pool). So isolated reads will come from EFD in this setup, but not in the RAID10/FAST-cache setup.
would it still make sense to go with FAST-VP pool if images were getting re-composed everyday, so the blocks that were hot yesterday could be cold today, yet they are sitting on EFD because they got promoted over night ?