Skip to content

Persistent Desktop Failover

by on January 23, 2014

In this blog I review how to set up Citrix XenDesktop with persistent virtual desktops in a DR scenario. I have written in the past regarding why some companies are forced to go with persistent virtual desktops as opposed to non-persistent desktops.

With Citrix XenDesktop, sites are used and a single site can’t span geographic datacenters. For a production/DR setup you would require two XenDesktop sites, both managed independently. Unfortunately Citrix doesn’t offer any type of site failover and/or hooks into the backend hypervisor to facilitate a failover. Many of Gotham’s customers utilize VMware as the hypervisor and XenDesktop as the desktop presentation layer. To failover to a DR site requires technologies from both Citrix and VMware, and of course the storage array.

The Setup

  • Two Datacenters
  • VMware vSphere 5.X hosting all virtual machines
  • Citrix XenDesktop 7.1 configured with two sites (one site per datacenter)
  • Citrix NetScalers configured with Global Server Load Balancing (GSLB) between sites
  • EMC storage replicating the LUNs that contain the VMs to the DR site
  • VMware Site Recovery Manager (SRM) to automate recovery

Failover Procedure

  • In the event of a DR failover, the SRM recovery run book is run, which stops the replication between sites, if it is still operational
  • SRM instructs vCenter to mount the replicated storage to the VMware vSphere infrastructure
  • SRM instructs vCenter to power on the virtual desktops
  • The virtual machines register with the Delivery Controller for the DR site
  • The DR NetScalers are flipped to production, retaining the same URL for access
  • Users can now access the assigned persistent virtual desktop

Note that this is not an automated failover, and that is on purpose, as any action like this should involve manual intervention. However, the only manual intervention that is required is to run the recovery run book and flip GSLB to the passive NetScalers. It would be great to see the integration of both products, but I doubt that will ever happen, given the two companies are direct competitors. The use of SRM simplifies the overall configuration; scripting can be used for the same functionality.

The two key pieces SRM provides are the creation of the shadow VM and the ability to automate the recovery run book. The shadow VM creation is critical as it is imperative to prepopulate the DR XenDesktop site with the assigned virtual machines. The last thing you want to do is fail over the site and not have the virtual desktops pre-assigned, as assigning them could be a lengthy process depending on the number of virtual desktops. The shadow VM contains all relevant files for the VM minus the .VMDK(s). The VMDK(s) are mounted once the run book is run to take the latest replica.

Overall, this configuration is straightforward, but there are many moving pieces. Please contact your Gotham account manager for more information regarding VDI and related technologies.

Comments are closed.

%d bloggers like this: