MetaLUN vs. FAST Pool

for RAID-5 config you will want to use 4+1 RAID-5, so you will need to reconsider what you do with your 7 EFD drives.

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. 

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. 

Thanks,

Tommyt

www.vtexan.com

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!

ErikZandboer wrote: 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 ?

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 ?

dynamox wrote: 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 ?

It's likely to not work as great for environments that are very much "in motion".Had no change to measure this yet, but the theories vary from "no it would not work because of the ever changing workload" to "it might still work because VMFS will reuse old blocks first".

Until things are validated to work, I'd go the FAST-cache route in very dynamic environments (where FAST-VP might niever catch up), so build either non-FAST-VP RAID sets with FASt-cache on top, or build a FAST-VP pool with NL-SAS and SAS only and add EFDs as FAST-cache.

Correct me if I am wrong, but promotions of data to the higher tier in a FAST Pool will only happen once a day, at most.  This activity can be scheduled to occur every day, but only once a day.

Promotion of hot data to FAST Cache happens dynamically all the time, and at a much more granular level - 64KB vs 1GB.  When using pools, if a chunk of data gets hot, we've got to wait until tomorrow before we see the benefits of the EFDs in that pool.

Our vSpecialist has also recommended that we provision everything thick, so the VP part of the FAST-VP pool doesn't even come into play.

We don't have a cheap SATA or NL-SAS tier that would really drive the efficiency argument of Pools, and we won't have terabytes and terabytes and terabytes of data at rest, either.  This is 100% VDI.

To me, there are a lot of little drawbacks like these that make Pools less attractive for this solution.  I guess what I am really trying to ask is this:

Lacking a tier-3 of disks to tier down to, and having to wait until "tomorrow" to see the benefits of my hot data tiering up to EFD in the pool, why even use a pool?

With all of my EFD configured as FAST Cache, it is always ready to serve.  I don't have to wait until tomorrow, I can realize the benefits right now.  With 732GB of FAST Cache, practically my whole environment will live there.  Only the unused and untouched portions of the Windows OS on the virtual desktops will "tier-down" to "slow" RAID-10 SAS drives.  And did I mention that the stripe of "slow" RAID-10 SAS drives is 32 spindles wide?  That seems to me like the best solution.

If my understanding of pools is a little off, or if my understanding of the VDI workload is not 100% accurate, please tell me, and help me understand a bit better.

Physical inspection of the equipment shows that we have the following spindles:

38 x 300GB 15k SAS  (4 of them are vault, so don't count)

11 x 200GB EFD

My ammended proposed solution is as follows:

8 EFD as FAST Cache

2 EFD as a mirror for replica disks

Four RAID-10 groups of 8 members - MetaLUNs striped across them (put all the users' desktops here)

1 EFD spare

2 SAS spares

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. 

We have had a lot of discussions around exactly this dillema: Where to put the EFDs. Go for FAST-cache or FAST-VP with EFD and some FAST-cache. For environments that are changing on a daily basis or for sub-500 designs I think the FAST-cache option is a valid one. For larger environments you start to bump into an unpleasant bottleneck: CPU on the controllers. The amount of backend I/Os gets bigger as you add FAST-cache, at least if you assume that at some point you will destage. Data going to FAST-cache that is destaged later on will hit the backend three times, on FAST-VP the backend overhead would be less.

A 5300 should be able to handle 10 EFDs in FAST-cache, so you should be fine there.

When working in a pool, you loose some raw performance when going thin. So yes, I'd definitely go thick, also because VMware View will thin everything anyway. What I see as a possible problem in the four RAID10 groups setup is that you need to make sure that they get hit equally. In a pool it would be more efficient since you stripe wide across its members. Hard to say how much you gain using a pool, and loose using the same pool

Have you considered to create a big RAID10 pool and putting FAST-cache on top?

Also, I know the reference architecture uses two EFDs in mirror for the replicas. But I think things would work better if you put the replicas on the underlying disks, and rely on FAST-cache to cache all active data from the replicas; I would move the two EFD drives from the dedicated tier up to join the FAST-cache drives. As soon as you have some boots, all active data will shoot into FAST-cache anyway, and the two EFDs can now join in handling your workload during steady state.

i like 8 EFD's in the FAST Pool - vs 4(ea) EFD's in the FAST Cache but at this point - i'll give in   I think the new design you describe looks solid.

I think we desgned for RAID 5 - you can certainly do RAID 10 but RAID 5 would be more then enough and give you more useable capacity but if capacity is not a problem - go for RAID 10

Thank you VERY much for posting this question.  This was a great discussion !! 

Tommyt

Well, that settles it.

FAST Cache

   = 4 EFDs ~365GB

FAST Pool

   = 6 EFDs (RAID-10) ~550GB

   = 32 SAS (RAID-10) (4 groups of 8) ~4200GB (Not that capacity matters here, it's all about spindle count)

1 EFD spare

2 SAS spares

4 SAS vault

How about that?