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 discuss in this article consists of:
- A single XenMobile active site in the datacenter of one geographical location serving all the enterprises users globally, known as the primary site.
- A second XenMobile site in the datacenter 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 datacenter failure occurs in the primary site. The primary site includes XenMobile, SQL database, NetScaler infrastructure in order 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 NetScaler access tier by means of DNS changes for routing MDM and MAM connections to the disaster recovery site in the event of an outage.
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
- If you are testing your disaster recovery failover process, shut down XenMobile servers in the primary site to simulate site failure.
- Change public DNS records for the XenMobile servers to point to the disaster recovery site’s external IP addresses.
- Change internal DNS record for the SQL Server to point to the disaster recovery site’s SQL Server IP address.
- 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.
- Turn on the XenMobile servers on the disaster recovery site.
XenMobile Server Update Process
Follow these steps any time you update XenMobile with patches and releases, in order to keep the code of the primary and disaster recovery servers uniform.
- Ensure that XenMobile servers in primary site have been patched or upgraded.
- Ensure that DNS record for the SQL Server is resolving to the active SQL Server database in the primary site.
- 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.
- Apply required patches and updates to all disaster recovery site’s XenMobile servers.
- 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.
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 NetScaler for XenMobile wizard configures NetScaler Gateway in a way that does not enable the use of GSLB for disaster recovery. Therefore, you must take additional steps.
How GSLB Works
GSLB is at its core a form of DNS. Participating NetScaler 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 NetScaler 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 NetScaler 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 NetScaler, including sites, services, and monitors, exist in order to provide the correct DNS name resolution.
The actual configuration for publishing servers (in this scenario, the configuration that the NetScaler for XenMobile wizard creates) is not affected by the GSLB. GSLB is a separate service on the NetScaler.
Challenges with Domain Delegation When Using GSLB with XenMobile
The NetScaler for XenMobile wizard configures NetScaler Gateway for XenMobile. This wizard generates three load balancing virtual servers and a NetScaler Gateway virtual server.
Two of the load balancing virtual servers handle MDM traffic, on port 443 and 8443. NetScaler 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 NetScaler 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 NetScaler for XenMobile wizard creates a local DNS record on NetScaler 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 NetScaler 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 NetScaler 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 NetScaler 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.
On the external DNS, create a CNAME for the XenMobile server FQDN that points to the GSLB domain FQDN on NetScaler GSLB. You need two GSLB domains: One for MDM traffic and another for MAM (NetScaler Gateway) traffic.
CNAME = xms.company.com IN CNAME xms.gslb.comany.com
On the NetScaler Gateway instance of each site, create a GSLB virtual server with a FQDN that is what the CNAME record is pointing to.
bind gslb vserver xms-gslb -domainName xms.gslb.company.com
When using the NetScaler for XenMobile wizard to deploy NetScaler 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.
Test with clients enrolling on Secure Hub using the XenMobile server URL (
This example uses the following FQDNs:
xms.company.comis the URL that is used by the MDM traffic and is used by devices enrolling, which is configured in this example by using the NetScaler for XenMobile wizard.
xms.gslb.company.comis the GSLB domain FQDN for the XenMobile server.