Category Archives: XenApp
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.
- 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.
- 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
As you saw in a previous blog, I created a new set of Visio stencils for XenApp 7.5 and XenDesktop 7.5 that included full diagrams within the stencil (I’m still impressed with this idea J)
Over the last few months, I’ve had to create a few more architecture diagrams and realized I needed a few more items. I’ve incorporated them into the latest stencil update. Recent additions include:
- New virtual desktop model: DesktopPlayer
- New user roles: User, Admin and Support
- New hardware: SSD and HDD
Links to the latest stencils are:
From the virtual mind of Virtual Feller
As we all know, IOPS are the bane of any application and virtualization project. If you don’t have enough, users will suffer. If you have too many, you probably spent too much money and your business will suffer. So we are always trying to find ways to more accurately estimate IOPS requirements as well as finding ways to reduce the overall number.
About 5 months ago, I blogged about IOPS for Application Delivery in XenDesktop 7.0. In the blog, I explained that for the XenApp workload, Machine Creation Services, when used in conjunction with Windows Server 2012 Hyper-V, required a significantly fewer number of IOPS than Provisioning Services. With the release of the 7.5 edition of XenApp and XenDesktop, I wanted to see what the latest numbers were on Windows Server 2012R2 Hyper-V while using the same LoginVSI medium workload. In addition, after reading Miguel Contreras’s blog on “Turbo Charging IOPS“, I wanted to see what impact the Provisioning Services “Ram Cache with Overflow to Disk” option would have on the results.
If you aren’t familiar with this caching option, it is fairly new and recently improved and I suggest you read Miguel’s blog “Turbo Charging IOPS“, to learn more. But essentially, we use RAM for the PVS write cache that will move portions to disk as RAM gets consumed, thus overcoming stability issues you would have with just a RAM Cache only option as the cache filled up. For this test, we allocated 2GB per XenApp VM. We only have 7 XenApp 7.5 VMs on the host, requiring 14GB total.
The results are impressive (at least to me they are).
On average, each XenApp 7.5 user requires 1 IOPS. If you want to be safe and go with the 95th Percentile, you have roughly 2 IOPS per user. We were able to achieve this without any complex configurations. We were able to achieve this without adding any new hardware to our servers. We were able to achieve this by literally flipping a switch within Provisioning Services. This is done with a little RAM and spinning disks only, no SSDs.
Some of you might also be wondering why MCS is lower than PVS (Disk Cache). This is one of the intrinsic benefits of MCS when deploying a Windows 2012R2 XenApp server on Windows Server 2012R2 Hyper-V. MCS is able to take advantage of the larger block sizes within the new .VHDX files, thus reducing IOPS requirements.
I keep hearing people say that Citrix needs to show some love to Provisioning Services as it is such a great product. I think the RAM Cache with Overflow to Disk helps.
Coming soon… VDI workloads as well as other hypervisors.
Virtual Feller’s virtual thoughts
When working on desktop transformation designs, many start with the VDI (personal) model. I tend to go for the RDS (Shared) model. There are many reasons why, but mainly it is because
- Scalability: Most agree that a shared desktop environment achieves better scalability than personal desktop environments.
- Storage: Due to the shared operating system, the impact on storage is mostly a non-issue
- Security: Although a desktop can be secured, I typically find that people do a better job securing desktops in the shared model
Like I said, I usually start with the XenApp model, but as we all know, one size does not fit all. There are occasions where the personal desktop model is required. Every time I say this, I get many questions asking what for the user requirements that XenApp cannot provide. Here is a start:
- Reboot control: Can you imagine if you let users reboot a XenApp server. Talk about a great way to tick off your coworkers
- Admin rights: I hate to say it, but some users require admin rights. Doing this on a shared desktop will cause many issues.
- Specialized hardware: Some users need powerful graphics cards or sound cards. It is often easier to do this in a personal (VDI) model
- Backgrounds: Many users want a picture of Homer Simpson on their desktop background. Silly, that can be done with shared or personal. This is NOT a valid requirement to go to a personal desktop.
Of course, I’ll save the most common one for last…
- User Applications: Certain users need to install their own applications. Doing this on a shared model is scary, but on a personal model, makes a lot of sense.
What other areas do you see are viable user requirements that would dictate the need for a Personal (VDI) desktop instead of using the Shared (RDS) model?
One of the first questions when virtualizing XenApp is how many VMs to put on a server. Well, that was discussed in the Virtualize XenApp blog. Once you figure out how you plan to carve up the physical server, one of the next common questions is deciding which features of the hypervisor to enable/disable. For example, if I use XenServer, should I use the “Optimize for XenApp” setting? What about vSphere’s Transparent Page Sharing feature? And the big whopper, how should I allocate memory to my virtualized XenApp servers? Is it safe to use dynamic memory or am I safer to stick with fixed memory?
The following table is what Citrix Consulting has seen and recommends. By the way, if you want the entire discussion on virtualizing XenApp, then go to the XenDesktop Design Handbook and look in the Planning Guide section for XenApp Virtualization Best Practices.
|Overcommit CPU:No||It is advisable not to allocate more vCPU than there are logical cores on within the given hardware. Experience has shown that greater levels of scalability are achieved by not overcommitting CPU.||Hyper-VXenServer
|Utilize Hyper-threading:Yes||Newer processors have the ability to do hyper-threading, where each core is two logical cores. Utilizing hyper-threading in a XenApp environment has been shown to improve user density.||Hyper-VXenServer
|Disable ASLR: No||As many organizations try to protect their XenApp servers from viruses, malware and other OS exploits, it is advisable to keep Address Space Layout Randomization enabled, which is the default setting. The functionality is included with Windows 2008, Windows 2008 R2, Windows Vista and Windows 7.||Hyper-VXenServer
|Enable Transparent Page Sharing:Depends on OS||Enabling or disabling Transparent Page Sharing has not been shown to either help or hurt performance on newer systems (Windows 2008, Windows 2008 R2, Windows Vista and Windows 7). However, older systems (Windows 2003 and Windows XP) have benefited, mostly because the page sizes are smaller (4K), thus making it easier to share pages of memory.||vSphere|
|Optimize for XenApp:N/A||On systems utilizing pre-Nehalem processors, the XenServer setting “Optimize for XenApp” provided increased scalability. Since the release of the Nehalem processors, much of the functionality has been placed on the hardware so this particular XenServer setting can be ignored.||XenServer
|Disk Alignment: Yes||As a host server will be running multiple instances of a server operating system, it is even more important to optimize the disk subsystem to improve performance and scalability as opposed to a system running a single operating system. Windows 2003 is misaligned with default installations. This should be corrected installation to help reduce storage impact.||XenServerHyper-V
|Memory Allocation:Fixed||As users are dynamically load balanced across XenApp servers, memory usage between different virtual machines should be similar, helping negate the need for dynamic memory allocation techniques. Also, if VM migration strategies are used, this could cause memory overcommit resulting in aggressive paging and poor performance across all XenApp virtual machines. It is advisable to set fixed values for memory reservations for XenApp virtual machines.||XenServer
|Host Swapping: No||In most environments, all XenApp servers are actively hosting users at the same time. Swapping out memory from one XenApp host will degrade performance for all virtual machines as the memory keeps getting transferred to/from disk.||vSphere|