This is the second part of my articles on virtualizing XenApp on vSphere. You can read the first part here.
vSphere design considerations
I recommend to create a dedicated VMware cluster for virtualized XenApp servers. The reason for this is use of vSphere functionality and the resulting licensing costs. Because XenApp VM’s are highly resource intensive there is no need for VMware DRS. VMware DRS is useful when there are a lot of VM’s with different resource demands but with XenApp VM’s this is not the case. All XenApp VM’s are resource intensive. Furthermore I do not recommend to use vmotion on XenApp VM’s because end-users could experience a delay in there XenApp session during a vmotion. Based on these facts a vSphere Standard edition license gives enough functionality for the VMware cluster with XenApp servers, which I will call the VMware XenApp cluster in the rest of this article. By using vSphere standard, the XenApp servers are protected against hardware failures by VMware HA and using the vSphere standard license keeps the cost of a virtualized XenApp server low. There’s one caveat, if you use distributed vSwitches in your environment you are stuck with standard vSwitches with vSphere standard or you should use the vSphere Enterprise Plus license for the VMware XenApp cluster.
Selecting the right server hardware is essential for successful virtualization of XenApp servers. I recommend to use hardware based on the Intel Nehalem processor architecture. At time of writing this article, this is the Intel Xeon 55XX series. The Nehalem processor architecture provides support for hardware-assisted memory management unit (MMU) virtualization. MMU virtualization provides a significant performance increase.
The number of physical CPU cores should be matched with the number of vCPU’s. For virtualized XenApp servers, do not overcommit CPU resources. For example, if you intend to run 4 XenApp servers with 2 vCPU’s, your ESX server should have 8 cores. It is possible to slightly overcommit but you should monitor your CPU ready time for bottlenecks.
I used diskless HP Proliant BL460 G6 servers for building a VMware XenApp cluster, but any modern server will do. These servers are equipped with 2 Quadcore Intel E5540 CPU’s and 24 GB of RAM. With this configuration I managed to run 5 XenApp VM’s with a good performance. With 6 XenApp VM’s the CPU ready time becomes greater than 5% and the performance isn’t acceptable anymore.
Because XenApp VM’s are disk I/O intensive (especially during logon hours) I recommend to make dedicated datastores with the size for holding a maximum of four XenApp VM’s within the VMware XenApp cluster. This way the XenApp’s VM’s make optimal use of the I/O queue’s each lun provide. Also create the datastores on the fastest lun you can provide. I used raid 1 fibrechannel lun’s for the XenApp VM datastores.
Each XenApp VM will contain some standard applications and custom application specific to the business. In this article I focus only on the standard applications. Here’s a quick overview of the standard application set I use on a XenApp VM:
- Microsoft Internet Explorer 7
- Microsoft Office 2003
- Antivirus software
I used Internet Explorer 7 because Internet Explorer 8 had more CPU spikes. I don’t know the reason for this, maybe some web application has not been optimized for IE8 but I didn’t have the time to investigate this problem. By default IE8 also starts two iexplorer processes for each user which requires a little more resources. Office 2003 was used because the customer was still using Office 2003. This is a plus because Office 2007 requires more resources. I recommended to use antivirus software on your XenApp VM.
With this configuration I managed to run 5 XenApp VM’s on a single ESXi host with each XenApp VM supporting 25 users. This makes a total of 150 users on one physical server. The user experience with this configuration is within normal range.
The following chart show’s the CPU usage from a XenApp VM.
Please note that the CPU ready time is below the 5%.