XenMobile Server

Disaster Recovery

You can architect and configure XenMobile deployments that include multiple sites for disaster recovery using an active-passive failover strategy.

The recommended disaster recovery strategy discusses in this article consists of:

  • A single XenMobile active site in the data center of one geographical location serving all the enterprise users globally, known as the primary site.
  • A second XenMobile site in the data center of a second geographical location known as the disaster recovery site. This disaster recovery site provides active-passive site failover in if a site-wide data center failure occurs in the primary site. The primary site includes XenMobile, SQL database, and Citrix ADC infrastructure to facilitate failover and provide users with access to XenMobile via the event of connectivity failure to the primary site.

The XenMobile Servers at the disaster recovery site remains offline during normal operations and is brought online during only disaster recovery scenarios, where complete site failover from the primary site to the disaster recovery site is required. The SQL Servers at the disaster recovery site must be active and ready to service connections before you start the XenMobile Servers at the disaster recovery site.

This disaster recovery strategy relies on manual failover of the Citrix ADC access tier by DNS changes for routing MDM and MAM connections to the disaster recovery site in the event of an outage.

Note:

To use this architecture, you must have a process in place for asynchronous backups of the databases and some way of ensuring high availability for the SQL infrastructure.

Disaster Recovery Failover Process

  1. If you are testing your disaster recovery failover process, shut down XenMobile Servers in the primary site to simulate site failure.
  2. Change public DNS records for the XenMobile Servers to point to the disaster recovery site’s external IP addresses.
  3. Change the internal DNS record for the SQL Server to point to the disaster recovery site’s SQL Server IP address.
  4. Bring XenMobile SQL databases online at the disaster recovery site. Ensure that the SQL Server and database is active and ready to service connections from the XenMobile Servers local to the site.
  5. Turn on the XenMobile Servers on the disaster recovery site.

XenMobile Server Update Process

Follow these steps anytime that you update XenMobile with patches and releases to keep the code of the primary and disaster recovery servers uniform.

  1. Make sure that the XenMobile Servers in the primary site have been patched or upgraded.
  2. Make sure that the DNS record for the SQL Server is resolving to the active SQL Server database in the primary site.
  3. Bring the disaster recovery site’s XenMobile Servers online. The servers connect to the primary site’s database across the WAN during the upgrade process only.
  4. Apply required patches and updates to all disaster recovery site’s XenMobile Servers.
  5. Restart the XenMobile Servers and confirm that the patch or upgrade is successful.

Disaster Recovery Reference Architecture Diagram

The following diagram shows the high-level architecture for a disaster recovery deployment of XenMobile.

Diagram of disaster recovery reference architecture

GSLB for Disaster Recovery

A key element of this architecture is the use of Global Server Load Balancing (GSLB) to direct traffic to the correct data center.

By default, the Citrix ADC for XenMobile wizard configures the Citrix Gateway in a way that does not enable the use of GSLB for disaster recovery. Therefore, you must take extra steps.

How GSLB Works

GSLB is at its core a form of DNS. Participating Citrix ADC appliances act as authoritative DNS servers and resolve DNS records to the correct IP address (typically the VIP that is supposed to receive traffic). The Citrix ADC appliance checks the system health before responding to a DNS query directing traffic to that system.

When a record is resolved, GSLB’s role in resolving the traffic is complete. The client communicates directly with the target virtual IP (VIP) address. DNS client behavior plays an important part on controlling how and when a record expires. This is largely outside the boundaries of the Citrix ADC system. As such, GSLB is subject to the same limitations as DNS name resolution. Clients cache responses, thus, load balancing in this way isn’t as real-time as is traditional load balancing.

The GSLB configuration on the Citrix ADC, including sites, services, and monitors, exist to provide the correct DNS name resolution.

The actual configuration for publishing servers (in this scenario, the configuration that the Citrix ADC for XenMobile wizard creates) is not affected by the GSLB. GSLB is a separate service on the Citrix ADC.

Challenges with Domain Delegation When Using GSLB with XenMobile

The Citrix ADC for XenMobile wizard configures the Citrix Gateway for XenMobile. This wizard generates three load-balancing virtual servers and a Citrix Gateway virtual server.

Two of the load-balancing virtual servers handle MDM traffic, on ports 443 and 8443. Citrix Gateway receives MAM traffic and forwards it to the third server, the MAM load balancing virtual server, on port 8443. All traffic to the MAM load-balancing virtual server is passed through Citrix Gateway.

The MAM load balancing virtual server requires the same SSL certificate as the XenMobile Servers and uses the same FQDN as used to enroll devices. The MAM load-balancing server also uses the same port (8443) as one of the MDM load balancing servers. To enable traffic to be resolved, the Citrix ADC for XenMobile wizard creates a local DNS record on Citrix Gateway. The DNS record matches the FQDN used to enroll devices.

This configuration is effective when the XenMobile Server URL is not a GSLB domain URL. If a GSLB domain URL is used as the XenMobile Server URL, as is required for disaster recovery, the local DNS record prevents Citrix Gateway from resolving traffic to the MDM load balancing servers.

Using the CNAME Method for GSLB Disaster Recovery

To address the challenges presented by the default configuration created by the Citrix ADC for XenMobile wizard, you can create a CNAME record for the XenMobile Server FQDN in the parent domain (company.com) and point a record in the delegated subzone (gslb.company.com) for which the Citrix ADC is authoritative. Doing so allows for the creation of the static DNS A record for the MAM load-balancing VIP address required to resolve traffic.

  1. On the external DNS, create a CNAME for the XenMobile Server FQDN that points to the GSLB domain FQDN on Citrix ADC GSLB. You need two GSLB domains: One for MDM traffic and another for MAM (Citrix Gateway) traffic.

    Example:

    CNAME = xms.company.com IN CNAME xms.gslb.comany.com

  2. On the Citrix Gateway instance of each site, create a GSLB virtual server with an FQDN that is what the CNAME record is pointing to.

    Example:

    bind gslb vserver xms-gslb -domainName xms.gslb.company.com

    When using the Citrix ADC for XenMobile wizard to deploy Citrix Gateway, use the XenMobile Server URL when configuring the MAM load balancing server. This creates a static DNS A record for the XenMobile Server URL.

  3. Test with clients enrolling on Secure Hub using the XenMobile Server URL (xms.company.com).

    This example uses the following FQDNs:

    • xms.company.com is the URL that is used by the MDM traffic and is used by devices enrolling, which is configured in this example by using the Citrix ADC for XenMobile wizard.
    • xms.gslb.company.com is the GSLB domain FQDN for the XenMobile Server.
Disaster Recovery