Citrix: Virtualization Best Practices for XenApp
Daniel Feller posted another great blogpost on the Citrix Blogs
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.
| Decision | Justification | Hypervisor |
|
Overcommit CPU:
No
|
It is advisable not to allocate more vCPU than there are physical cores within the given hardware. Experience has shown that greater levels of scalability are achieved by not overcommitting CPU. |
Hyper-V
XenServer
vSphere
|
|
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-V
XenServer
vSphere
|
| 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-V
XenServer
vSphere
|
|
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. |
XenServer
Hyper-V
vSphere
|
|
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 Hyper-V vSphere
|
| 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 |
Leave a Reply