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:
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.
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.
The following diagram shows the high-level architecture for a disaster recovery deployment of XenMobile.
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.
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.
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.
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.
1. 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.
Example: CNAME = xms.company.com IN CNAME xms.gslb.comany.com
2. 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.
Example: 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.
3. Test with clients enrolling on Secure Hub using the XenMobile server URL (xms.company.com).
This example uses the following FQDNs: