Blog Archives

ESG Lab Spotlight Report: Up to 80% Reduction in Storage Cost for VDI and RDS


You’ve heard the news, you’ve seen the videos, and now the storage savings have been verified! According to an ESG report, the new RAM Cache with Disk Overflow feature, included in the XenApp and XenDesktop 7.6 release, has the potential to reduce storage costs by 80% or more. Now before you stop reading thinking this is too good to be true, think about the storage cost problem for a moment.

Storage costs associated with RDS/VDI solutions is for throughput and not space. We need to have enough throughput or IOPS so the user experience doesn’t suffer. And believe me, it can suffer drastically, as you can easily see in this simple demonstration (pay particular attention from the 3 to 4 minute mark J).

To visualize how this works, take the following diagrams into perspective


IO is destined for the disk. Disks are slow when compared to RAM. So the Cache on RAM with Overflow feature substitutes RAM for disk. And because RAM is not infinite, we will overflow portions of the RAM to disk as needed. But even this overflow is more efficient. The overflow is sequenced and consolidated into large, sequential blocks of data instead of small, random blocks.

Many implementations required massive SANs or expensive SSDs. People were spending large amounts of money on storage, not for space, but instead to achieve the throughput required by RDS/VDI. With the Cache on RAM with Overflow feature, we can drastically reduce the number of disks. We don’t need hundreds of disks to give us our throughput. We don’t need to implement SSDs. We can drastically reduce our disk count and focus more on storage space, which is by far, easier and cheaper to implement.

According to the ESG report on Provisioning Services, when you focus on disk throughput

  • A XenDesktop implementation requiring 26 disks can be reduced to 3
  • A XenApp implementation requiring 74 disks can be reduced to just 4

And because of the way this feature works, it provides value to multiple hypervisors.

From the virtual mind of Virtual Feller

About these ads

PROOF[Video] – New XenDesktop and XenApp Storage Optimizations Does Improve the User Experience


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

Diving deeper into the latest XenDesktop 7.5 IOPS results


As you saw in a previous blog, XenDesktop 7.5 is able to achieve an average IOPS value of less than 1/10th per user. Of course when you put out unbelievable results like this you hear a lot of comments trying to find holes in the results or test procedures. This is as it should be as it is part of any good scientific method.

In order to show a more complete picture of the value of the new Provisioning Services Ram Cache with Disk Overflow, we gathered additional details from the Citrix Solutions Lab’s tests. This set of data includes details for the duration of the entire test that included logons for roughly 100 users (sorry but it didn’t include boot. However, booting is mostly a read operation that PVS can handle with server-side cache).

The results are still just as stunning as the steady state:

For a physical host, we accumulated IOPS numbers for each of the virtual desktop sessions then combined into a single graph. As you can see, during the logon portion of the test we had a peak, and I mean maximum IOPS value, of 12 IOPS.

What if we don’t break it down by user, what would the host’s total IOPS graph look like?

Peak IOPS

 

 

 

 

 

 

 

 

 

 

The absolute peak is 155 IOPS on a host that is running 100 VDI VMs.

Tests details were as follows:

  • LoginVSI 4.0 medium workload
  • Hypervisor: Hyper-V 2012R2 and vSphere 5.5
  • Virtual Machine: Windows 7, 2 vCPU and 2.5 GB of RAM (512 MB as defined for the RAM Cache)

Based on results like this, I’m left to wonder how many users I can support on my mid-1990s college PC (Pentium 486 with a 420MB hard drive) J

From the virtual mind of Virtual Feller

Latest XenDesktop 7.5 IOPS


It is amazing when you’ve been focused on a technology for so long that you start to see major improvements. In 2010, I provided my original guidance on XenDesktop IOPS. Four years later, have we seen any major improvement? See for yourself.

As you might be aware, I’ve been working with the Citrix Solutions Lab on validating standardized designs. These validated designs are published as Citrix Design Guides. Part of this latest round of testing with XenDesktop 7.5 and XenApp 7.5 was focused on the new Provisioning Services write cache option “RAM Cache with Overflow to Disk”. When looking at XenApp 7.5, we observed some astounding results, as detailed in the following blogs:

In addition to these, Dan Allen also released a blog on “Turbo-Charging Your IOPS – Part 2” that showed additional impressive results.

But back to the Solutions Lab testing… I’ve finally started going through the results from the XenDesktop 7.5 portion of the test. And what we see is even more amazing than the XenApp tests (which were impressive).

Using the medium workload from LoginVSI 4.0, we observed the steady state IOPS following:

  • MCS: 10 IOPS
  • PVS with Disk Cache: 9.2 IOPS
  • PVS (RAM Cache with Overflow to Disk): 0.09 IOPS

And before you ask, we saw very similar results with vSphere 5.5

We used Windows 7 virtual machines with 2 vCPU and 2.5 GB of RAM (512MB was defined for the RAM cache)

With this one feature within Provisioning Services, we got steady state IOPS to be less than 1/10th of an IOPS without any special configurations. Impressive

The main challenge I see is how the Provisioning Services team will improve upon this. All I can say is “Good luck!”

From the virtual mind of Virtual Feller

The Latest XenApp 7.5 Read/Write Ratios


As technology changes, so too does a recommendation.

For years when you deployed XenApp servers with Provisioning Services, the storage Read:Write ratio would be 10:90. This is still the case in most scenarios. But in analyzing the latest data from the Citrix Solutions Lab, who were testing the “RAM Cache with Overflow to Disk” option, we encountered some results that will make us revisit some of our old recommendations.

  1. IOPS: For a medium workload on XenApp 7.5 on Hyper-V 2012R2, the average IOPS per user is 1, as explained in the previous blog.
  2. R:W Ratio: When using the new write cache option on Hyper-V 2012R2, the read:write ratio changes to 40:60. (Note: These numbers are taken at the physical host layer and not the VM layer)

Why is this? Why the change?

Think about what the RAM Cache with Disk Overflow does… It uses a section of allocated VM RAM to cache disk activity. As this cache fills up, it will start to move portions to disk. If you allocated enough RAM, you significantly reduce the number of IOPS (especially write IOPS). Look at the differences between PVS Disk and RAM Cache options

We’ve significantly reduced write activity because writes go to RAM. And whatever writes do make it to disk from the RAM Cache are bigger block sizes, thus also helping to reduce IOPS.

And finally, if you look at the disk idle time on the physical host, you can clearly see that the disks have a higher idle percentage when using the new RAM Cache with Disk Overflow option within PVS because we have less data going to the disk.

So far, the RAM Cache with Disk Overflow option is looking very promising. Soon, I’ll show you what it can do for Windows 7 workloads

For this setup, we used

  • LoginVSI 4.0 with a medium workload
  • Hyper-V 2012R2
  • XenApp 7.5 running on Windows Server 2012R2
  • 6 vCPU, 16GB RAM, 2 GB RAM Cache
  • 7 VMs per physical host

From the virtual mind of Virtual Feller

Follow

Get every new post delivered to your Inbox.

Join 470 other followers