EMC FAST VP for VDI on VNX…
Ok…Storage for VDI is a pain…costs alot…especially if you want to get performance…
EMC introduced a few years ago the concept of FAST (Fully Automated Storage Tiering) on the VMAX and VNX, and then further complimented it on the VNX with FAST Cache. In a nutshell…if you don’t know about FAST and FAST Cache, check out a great post by @vTexan at his blog. (Link HERE)
So…FAST VP sounds great…but can I use it with Linked-clones to drive down my storage costs without affecting performance?
In general, FAST VP is not a good choice for Linked Clone desktops. This applies to View Composer, Citrix MCS, and Citrix PVS. FAST VP is a potential fit for Persistent desktops and User Data, but it does not represent a best practice for linked clones. Here’s why…
Not good for Linked Clones (View and Citrix)
Granularity of the promoted data
The data that is elevated in FAST VP is done so in 1gb chunks (Remember this is for VNX…yes, VMAX is different). The Linked Clones are normally 2-5gb in size. At that rate, there is no good way to determine whether or not the “hot” data is actually able to be brought up as it may not be “centered” on the same 1gb chunk. It would be very easy, then, to have “hot” data that is not getting promoted that needs to get promoted, and impacts the user experience.
Time it takes to settle and balance the data…Linked Clones don’t live that long
Data that is running in a FAST VP pool is analyzed throughout the day, and then is generally moved during a time-window during the off-peak hours. Given the lag between when a desktop is created, analyzed, and then properly balanced, there is a window during which the data will not be hosted on the right tier, resulting in a significant impact to user experience.
In most Linked-Clone environments, the desktops are “refreshed” on logoff, daily, or on a weekly basis through policy or manual operations. In that case, the linked-clone does not live long enough for FAST VP to analyze and balance the workload.
Setting a policy of “Highest Tier” on the LUN will help to mitigate that, but at the same time, will put a lot of data into the “Highest Tier” that doesn’t belong there, which would cause data that NEEDS the performance to be potentially placed into the wrong tier.
While vSphere is excellent at re-using blocks in a thinly provisioned environment, there is no way to ensure that after a “refresh”, “recompose”, or “provisioning” event that the “hot” blocks of data will land on the higher-performing tiers of storage to provide the right user experience.
This is also made worse by the point that due to the lack of granularity in the FAST VP optimization, even once balanced, there is no way to ensure that all of the critical performance is being properly delivered.
Performance hit of using Thin FAST VP pools in VNX
There is a performance hit of up to 50% over a THICK LUN, which still carries a performance penalty over a traditional RAID group. Using Pools can dramatically reduce the performance and once again, significantly impact user and system performance.
Cost of Fast VP on the array
FAST VP is a licensed feature on the VNX array and potentially adds cost to the solution that may not be required. Given that the efficiency of FAST VP for these workloads is in question, the additional cost for EFD and FAST VP licensing has not been shown to provide value in linked-clone configurations. If you are using the VNX as a VDI-Dedicated platform (which is HIGHLY recommended…need a blog post on that alone) then you might not need the persistent tiering of FAST VP.
Good for User Data and Persistent Desktops
Persistent desktops do not share many of the attributes that make Linked-Clone desktops a poor choice for FAST VP environments:
- Persistent desktops live longer than linked–clones, and as such, are able to survive long enough for FAST VP to analyze and optimize the blocks
- Persistent desktops consume much more capacity than linked-clones. More data means more opportunities to optimize the data rather than the 2-5gb found on non-persistent desktops
Performance of Thin Pools is still an issue, and Thick LUNS should be considered at this time due to the performance hit.
User data is generally not as performance-centric as the VDI OS component, and generally can be placed on lower tiers of storage. In the case of user data, depending on the performance requirements and the type of data being accessed, FAST VP may be a good alternative to provide a better mix performance and capacity. Also, consider that extreme cases of user data, you may want to centralize that onto a scale-out NAS solution (Isilon) and keep the boot volumes for your desktops on the VNX.