I’ve written and seen numerous blogs/tweets about how great the new storage optimization feature is for XenApp and XenDesktop. I’ve read how this feature can reduce IOPS from an average of 15 IOPS per Windows 7 user down to 0.1 IOPS. I’ve read how this feature functions by creating a small RAM buffer within each VM. I’ve seen tweets showing crazy IOPS numbers on using standard, spinning disks.
In fact, I’ve done some of this analysis and was completely blown away by the results.
But who cares? Who cares if my IOPS are reduced by 99%?
Unfortunately, unless you are responsible for storage, you probably don’t care. But what if this drastic reduction in IOPS had a direct impact on the user experience? And from someone who uses VDI remotely 100% of the time, the user experience is what I really care about.
Let’s see what the new RAM Cache with Disk Overflow feature can do for the user experience…
What impresses me the most is that the workload used isn’t some crazy operation that a typical user wouldn’t really do. You can easily see the improvement to the user experience with something as simple as browsing a few web pages.
And all of this is done
- Without complex configurations
- Without expensive SANs
- Without SSDs
- Without additional hardware
- Without additional licenses
- Without a learning curve
From the virtual mind of Virtual Feller
With desktop virtualization, we hear more and more about how important IOPS are to being able to support the virtual desktop. I’ve had a few blogs about it and plan to have a few more. What I wanted to talk about was an interesting discussion I recently had with 3 Senior Architects within Citrix Consulting (Doug Demskis, Dan Allen and Nick Rintalan). There are 3 smart guys who I talk to fairly regularly and the discussions get quite interesting.
This particular discussion was no different. We were talking about the importance of IOPS, RAID configs, spindle speeds with regards to an enterprise’s SAN infrastructure. (Deciding if you are going to use a SAN for your virtual desktops is a completely different discussion that I’ve had before and Brian Madden had more recently). But for the sake of this article, let’s say you’ve decided “Yes, I will use my SAN.” If your organization already has an enterprise SAN solution, chances are that the solution has controllers with plenty of cache. Does this make the IOPS discussion a moot point? Read the rest of this entry
The latest question into the Ask the Architect mailbag comes from Andy. Andy is creating a Provisioning services design for an environment based on Windows Server 2008, with the write cache stored on a NetApp share. Andy’s question is if the write cache estimates are correct. Basically, Andy is estimating 650 MB write cache per virtual desktop. He achieves this by taking the assigned RAM and multiplying it by 25%.
First, using Windows 2008 is great for Provisioning services as this provides the largest system cache for the vDisk, which will speed up delivery as local disk reads are not required as often.
Second, write cache is a tricky thing to determine. You best bet is to set this up and let users go at it for a few days to see what you end up with. However, that might not be possible. In that case ou have to remember that the write cache is based on a few things:
- Application delivery approach: Streamed apps will impact write cache more than installed apps, which impact the write cache more than hosted apps. I can tell you my streamed Office applications are consuming 300MB of space on my disk (which would mean 300MB of write cache if the application is not pre-cached).
- Reboot cycle: If the default behavior is to reboot the virtual desktop upon each logoff, this will keep the write cache small as it is deleted on each reboot.
- Pagefile: The pagefile is included within the write cache file. I’m assuming this is the RAM portion of the formula.
- User work flow: What the user does will have an impact on the size. Many of the apps require writes to the disk. The more apps a user utilizes, the greater the impact on the write cache.
That is just a summary of what is involved. If you want to see the blackboard discussion, check out the Ask the Architect Write Cache Video.
What do you think? Did I miss anything? How are you estimating your write cache size as part of the design process?