thomas_twyman
1 Nickel

Running Citrix XenApp on VMware...

I have had a lot of questions over the years around running replacing Citrix XenApp with VMware View, and I love this talk track, but unfortunately this far too often become a religious battle as the existing Citrix team struggles to retain their relevance by trying to illustrate how virtual desktops don't meet the efficiencies of server based computing... Interestingly, these are the same folks that are later far too willing to try out XenDesktop, but that's another discussion.

I would far prefer to undertake the discussion that they ought to be virtualizing the existing Citrix farm to get the efficiencies that come along with VMware.  The Citrix team will still push back, and they will try to P2V a couple systems, inevitably they run into problems and declare it untenable.

So, first of all, why would you virtualize a XenApp farm?

  • Deployment
    • One of the things many Citrix shops struggle with is their  deployment process – how do we maintain an up-to-date image for the farm  that incorporates the required applications and accommodates the  hardware in question… rolling out Windows, including updates and  patches, and the Citrix software (though this could be handled by Citrix  Installation Manager).  Either way, you are maintaining server images  somewhere – either through the use of a complicated installation script,  or through imaging software such as Ghost.
    • Deploying a virtual machine through the use of templates is far  quicker and more efficient than any other physical imaging process you  might have used.  VMs can be deployed in a matter of minutes using  templates.  The templates themselves can be created from existing  virtual machines, and can be copied and used with VMware snapshots or  SAN/NAS snapshots, giving you the ability to easily maintain a library  of templates for different types of operating systems, applications,  etc.
  • Disaster recovery
    • Setting up a Citrix farm to failover to another site requires a  large investment in hardware, and man-hours to configure the remote site  to handle all the applications necessary.  Furthermore, the hardware in  the remote site has to be of the same type as the primary, or your  deployment strategy has to take hardware differences into account.
    • Using virtual machines, all you need to do to enable a DR site  is have a copy of the required virtual machines in the remote location –  hence you only need to set up the farm once, and maintain a copy of it  in the remote location.  Spinning up your DR or business continuity site  is a matter of ‘powering up’ the virtual machines.  VMware Site  Recovery Manager may even help automate that process
  • Stability
    • Since the citrix system is accessed by users like a PC on a  regular basis, a Citrix server is more prone to failure than a regular  server (though, with proper maintenance, hopefully less prone than a  desktop).  Server outages mean lost productivity for your users, and a  significant effort in troubleshooting the problem, since Terminal  Services is a good deal more complicated than a regular server.
    • To properly design for the outages we know we will have, you  have to have extra capacity in the farm to handle the overflow users  when one of the servers is down.  This is true for both planned and  unplanned downtime.
    • VMware ESX has been recognized in the industry as one of the  most stable platforms to be introduced… ever.  This means fewer outages  due to host failures.  Also, since we standardize and virtualize the  hardware of the guest operating systems, this holds true across  different hosts, enabling your virtual machines to run across hosts from  different manufacturers and chipsets.
    • See http://redmondmag.com/features/article.asp?EditorialsID=2400
  • Application Deployment
    • Many Citrix shops do a good deal of work maintaining multiple  images – deploying applications in ‘stovepipe’ configurations…  that is  to say, multiple small groups of Citrix servers, each dedicated to a  specific set of applications.  Frequently, this is due to largely due to  application incompatibility.  However, it results in the Citrix admin  being required to maintain several different images for the Citrix farm.
    • Even if the shop has standardized on a single Citrix image, they  will not be using the company’s standard application deployment  methodology…  Terminal Services is too funky with regards to application  deployment, and requires much handholding.  Most Citrix shops has  compeletely separate processes for packaging applications for a PC  versus a Citrix server.
    • VMware ThinApp (http://www.thinstall.com) can be used to image  your applications separately from the Citrix image… In fact, an  application that has been packaged with ThinApp on Windows 2003 will  work on Terminal Services, Citrix, Windows XP, and Vista, eliminating  the need to package that application for the different platforms.   Furthermore, ThinApp includes a ‘sandbox’ to prevent applications from  conflicting with each other.  You simply place the packaged application  on a file share on the network, accessible to the Citrix servers (or  PCs, or both), and you are done.  Your users simply execute the  application from the shared directory, and they are off and running.   This results in a win-win for the customer – the ability to package an  application once, and use it for either a PC environment or a Citrix  environment.

In short, there is a lot more to the story than just  consolidation.  I have customers that have deployed  VMware ESX server for their high-end Oracle databases, and  they have accepted a 1:1 consolidation ratio (that means one virtual  machine per physical host).  The value to the organization is not just  in consolidation, but in the strength of the platform, the disaster  recovery capabilities, and how the infrastructure immediately becomes  more fluid and resilient.

The next question is how would you virtualize a XenApp farm?  To properly size a virtualized Citrix farm, you must start small,  perform your baselining, and scale out untill you figure out where it  breaks.  Most customers miss this point, assuming they can just P2V  their existing farm and get the same or better performance...  These  same customers, however, tackle Tier 1 applications appropriately  (Exchange and SQL), and take the time to size their virtualized solution  appropriately.  The same must be done for XenApp.

Technical Recommendations:

  • Build your template Citrix virtual machine from scratch (don’t convert an existing physical server)
  • Perform some baseline testing, starting with few users, loading the server until it breaks, then add resources. 
    • Use this methodoligy until you land on a size for the vm that satisfies user density and performance requirements, then try scaling out with additional vms.
    • Have an understanding of what an ‘acceptable’ threshold of users  will be… Some customers see an increase in the number of users per  Citrix instance when virtualized, some see fewer.  You should go into it  with the expectation that you may get fewer users, as well as what you  would like to see (ie 80% of physical or better?  70%?).
    • Bear in  mind that even if you get fewer users per vm than in a physical  environment, there are many other benefits to using virtualized Citrix  servers:
    • Start with a single virtual CPU for the template vm
      • This will allow the Windows operating system in the guest to use a uni-processor HAL, as opposed to a SMP HAL, streamlining the guest operating system
    • Configure the template vm for 2-4 GB RAM
    • Configure separate virtual disks (VMDK files) for the operating system and the pagefile
    • Ensure you align the NTFS partition in the VMDK prior to the Windows installation in the guest (http://www.vmware.com/vmtn/resources/608)
    • Use a 64-bit Windows installation.
    • Use the ballooning driver. Some Citrix forums will tell you not to use it but for us the ballooning driver made a complete difference
    • Make sure that the network interfaces are using fixed speed when connecting to the network, do not leave auto negotiated speeds. The best is to use 1000 mbps FULL DUPLEX
    • When installing VMware tools use a custom installation and remove the shared folder feature. This is very important as Citrix seems not to like that and it is a useless feature on ESX as it s meant for Workstation.

    For your reference:

    Links:

    Labels (1)
    0 Kudos