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
Well, that settles it.
= 4 EFDs ~365GB
= 6 EFDs (RAID-10) ~550GB
= 32 SAS (RAID-10) (4 groups of 😎 ~4200GB (Not that capacity matters here, it's all about spindle count)
1 EFD spare
2 SAS spares
4 SAS vault
How about that?
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 !!
I would recommend you to read these two articles before you make your final decision:
1- The biggest Linked Clone “IO” Split Study http://myvirtualcloud.net/?p=2084
2- Use Flash Drives (SSD) for Linked Clones, not Replicas http://myvirtualcloud.net/?p=2513
Also IO wise it turns out that a 3+1 RAID5 is more efficient that a RAID10 set, thx to write optimization techniques on the VNX.
I've read valid points from every one here. The most important is now to collect data to identify your VDI IO trend and behavior. Then you can design the storage accordingly to your real needs and requirements.
The three backend iops required is a theoretical one. For starters, your FAST-cache should have reached the high watermark. So any io that was promoted to FAST-cache had to be written to those disks. Next, because we need to flush data from FAST-cache, we need to read that data. Finally, we need to write it out again.
However, this is not taking account several things:
1) Raid overhead (when I say 3 backend iops it is really 3 actions taken);
2) The write out to disk is probably a full-stripe write, which helps a lot in raid5 or 6 setups;
3) The fact that is FAST-cache is sized properly, many iops will never leave FAST-cache. As long as the io is hot and FAST-cache is not overly filled, nine of this overhead applies (which is where you want to be).
PS: Sent from my Blackberry - Please excuse typos