Thursday, 26 May 2011

Virtual Desktop Write Cache - To SAN or not to SAN?

Education is currently buzzing with virtualization. Where can we use it? How much is it going to saves us? How do we implement it? One of the key issues that keeps coming up is where do we put our write cache? write cache on PVS HD (SAN) or write cache on devices HD, they are both possible options, I won't go into target devices RAM today as I don't think it as viable as the other options.

We are specifically dicussing a configuration of Citrix Xendesktop 5 in conjunction with Citrix PVS 5.6 fp1 as a delivery method for the image.



Slipping it into the SAN (write cache on PVS HD)

At a glance SAN write cache looks like a great option, why not move the write cache onto the PVS and consolidate the write cache in with the rest of our enterprise data? The is a definitate positive, but on the negative we can potentially kill the IOPS of our SAN, the same storage medium our business critical services are using.

Imagine this scenario, our servers are under heavy load, perhaps we have a very SQL transaction load and this is already straining your IOPS. Then you have a class of students log into their virtual desktops and use some write intensive application on the desktop. All of a sudden these students have the ability to negatively impact your server performance, or alternatively your server environment can negatively impact your end user experience.

Another negative on the SAN side is the potential price, if you dont already have a SAN, purchasing one specifically for VDI would be rediculous cost, making your VDI ROI way out of proportion with a standard desktop.

You don't HAVE to run your write cache on a SAN storage if you use the write cache PVS HD option, but this is where things get messy. If you have 100 clients accessing an image from the same PVS then you will need adequate IOPS on your PVS local HDD for 100 clients. This is roughly estimated at 15 IOPS per virtual desktop instance, but I like to go over the top and estimate based on 20 IOPS.

IOPS arn't your only problem with this method, not only do you need to supply enough disk speed, you need to remember that all that traffic will be loading your network. You can potentially have 100 IOPS per user, but that won't mater if you have a saturated network, your virtual desktop experience will be awful.



Directing the writes to the device

This option naming is slightly misleading, the write cache is not sitting on the thin client itself, but sitting on the device providing the virtual desktop, your Xenserver, Hyper-V or alternate hypervisor that is hosting your VDI.

The immediate benefit that you realize with this option is that you are seperating your write cache from your servers, so you don't negatively impact your server environment. Not only that, because the write cache is staying on the same physical system as your virtual desktop host, none of that write traffic is ever hitting the network.

Another not so obvious benefit is that if you are providing 100 virtual desktops over 2 physical servers, you can split the IOPS across the two servers, this could provide a better experience for the end user, but it also could cost you more money. Two servers, more disks required, potentially more maintenance.

There is no reason you wouldn't put the PVS image itself on the SAN, but the write cache on the device HD. This way you can consolidate all your images and the PVS itself onto your SAN for redundancy, but avoid all those nasty write IOPS by redirecting them to the virtual desktop host write cache array.


What is the best option for me?

That is an answer that only you can decide, there are definate negatives and positives of both options. For our organization we decided to put the write cache on the device hd and host the PVS vdisk and the PVS itself on the SAN, this cost us less money and gave us piece of mind that our server loads would never be negatively impacted by normal usage or an unlikely denial of service attack.

There are so many other considerations that are outside the scope of this article. Does your thin client provide some write cache capability? Will that save you money? Will it positively or negatively impact your end user experience?

The best advice is explore every option, and don't take anyones word for it, test out the possible options yourself and design a solution that meets your business requirements.

No comments:

Post a Comment