Customers have many requirements. As I usually deal with large customers, a disaster recovery solution is always one of them.

With XenMobile 10.x, things have gotten a lot easier: clustering is a piece of cake, and to direct traffic to the right data center we have NetScalers and GSLB (Global Server Load Balancing) at our disposal. This post is about configuring GSLB on NetScalers for XenMobile.

Now, before I continue, I do want to clarify that I’ll be discussing a configuration for disaster recovery (DR), NOT High Availability (HA). Those are two different solutions for two different problems. It’s one of my pet peeves (I have a large collection of peeves) how this gets confused all the time and often the same solution is used to cover both (hint: you shouldn’t). That’s a topic for a whole other blog article. This solution isn’t the only solution, nor is it necessarily the best one. However, it’s fairly simple and I know it works as it has been deployed in production environments.

Some assumptions before I start:

  • I am using two data centers: PROD (where my production servers are), and DR (where DR servers are located).
  • Both data centers are connected using a reliable link (just to simplify the design. If the link is not reliable then you have a some additional GSLB configuration to do). However, latency between both data centers exceeds 10ms and thus I really need to put in an active/passive solution.
  • We are using XenMobile version 10.3.6, although this will work with any XenMobile 10.x released at the time of writing.
  • There is a NetScaler in each data center, and each data center has it’s own internet connection with public IP addresses.
  • I am using MDM.CCSLABS.BIZ as my enrollment and MDM server address and MAM.CCSLABS.BIZ as the MAM or NetScaler Gateway address.
  • I configured both NetScalers using the XenMobile wizard.

Note regarding the database: For obvious reasons, the database needs to be available in both data centers (although not at the same time). A very common solution for this is using Always-On Availability Groups. Ultimately, in most large companies, the database server will be managed by a separate team. It’s their responsibility to ensure that database is activated in the DR site when required. (And no, you can’t have two writable copies in both data centers at the same time.). So, I don’t really discuss what options can be used for the database as it really doesn’t have any bearing on this article.

What is GSLB?

If you’ve never used GSLB before, here’s what you need to know: GSLB is DNS. In order to send traffic to the correct data center, our NetScalers will be configured as authoritative DNS servers and will resolve DNS queries based on the rules we specify. If all traffic is to go to one data center, then GSLB will respond to DNS queries sending traffic that way. Remember that GSLB is DNS and the whole configuration will make a lot more sense. Once GSLB has resolved a DNS record, it’s role is finished. So, under normal circumstances, both NetScalers will act as a DNS server and will resolve MDM.CCSLABS.BIZ and MAM.CCSLABS.BIZ to the IP addresses of the PROD data center. In case of DR, they will resolve the records to the IP address of the DR data center.

The challenge when using XenMobile

If you’ve configured your NetScaler using the XenMobile wizard, you will have noticed that a local DNS record is created for the MDM server. This is important for the proper functioning of XenMobile through the NetScaler.  In our example, there’ll be a local DNS record created for MDM.CCSLABS.BIZ. Only the NetScaler will ever actually use that record, but without it things will break.

This creates an immediate challenge. Each NetScaler will have one of those records and it will point to an IP address local to that NetScaler and local to that data center.  However, I want to use GSLB to resolve this MDM.CCSLABS.BIZ address to the correct data center and thus direct our traffic. We can’t have it both ways. I need the local record (and it will be different in each of the sites), so I’ll need a different solution to resolve the MDM.CCSLABS.BIZ record to the right IP for all other devices (that is: everything that’s not the NetScaler itself).

The solution

The solution is simple and will be familiar to those experienced with GSLB.

I will not have GSLB resolve the MDM.CCSLABS.BIZ and MAM.CCSLABS.BIZ records. Instead, they will resolve MDM.GSLB.CCSLABS.BIZ and MAM.GSLB.CCSLABS.BIZ. In our public DNS servers (which very often are managed by a different team), I create two CNAME records:

mdm.ccslabs.biz IN CNAME mdm.gslb.ccslabs.biz
mam.ccslabs.biz IN CNAME mam.gslb.ccslabs.biz

Obviously, the gslb.ccslabs.biz domain will need to be delegated to the NetScalers. As each NetScaler will act as an authoritative DNS server for the gslb.ccslabs.biz domain, you will need to create DNS records for them and a proper domain delegation in your public DNS servers. How that is done is server-specific (Windows, BIND, etc) and I won’t detail it here.

Some basic configuration required for the NetScalers

As the NetScalers will be authoritative DNS servers for the gslb.ccslabs.biz domains, I require the following:

  • A public IP address ( can be NAT-ed to a private IP, as used in my example) for each NetScaler. This IP address is assigned to the ADNS (authoritative DNS) listener and is where DNS requests will be received.
  • A firewall rule that permits traffic on UDP port 53 on those public IP addresses
  • A domain delegation for the gslb.ccslabs.biz domain using those two IP addresses as the authoritative DNS servers. You typically need to assign a name to each IP address. Make sure this resolves correctly. I used prod.gslb.ccslabls.biz and dr.gslb.ccslabs.biz as names for each of the NetScalers (resolving to the public IP addresses assigned to the ADNS listener). This delegation is setup on the ccslabs.biz domain.
  • A site IP address for each NetScaler. I use the same IP addresses as for the ADNS listener, but this is not a requirement. This is used for the NetScalers to exchange information.
  • An SOA (Start of authority) record for the gslb.ccslabs.biz domain. This is required to be properly standards compliant. You create this record on each of the NetScalers.

Configuration walkthrough

What I’ll configure is almost identical on both NetScalers, so I’ll point out the differences where needed.

Step 1: create sites

  1. Login to the NetScaler
  2. Select System – Settings – Advanced Features
  3. Select Global Server Load Balancing.
  4. Click OK
  5. Go to Traffic Management – GSLB – Sites
  6. Click Add
  7. Specify the details of the site:
    1. Name
    2. Type
    3. Site IP address
    4. Metric exchange: enabled.
  8. Create the following two sites on each NetScaler:
PROD NetScaler DR NetScaler
Name: PROD
Type: Local
Site IP address: PROD site IP address
Metric Exchange: Enabled
Name: DR
Type: Local
Site IP address: DR site IP address
Metric Exchange: Enabled
Name: DR
Type: Remote
Site IP address: DR site IP address
Metric Exchange: Enable
Name: PROD
Type: Remote
Site IP address: PROD site IP address
Metric Exchange: Enabled

Both NetScalers should now be aware of each other and be able to exchange information. It is important that each NetScaler can reach the site IP address of the other NetScaler in order to receive status updates. I am using private IP addresses and obviously need to ensure that network connectivity is correct (routing, firewalls, etc.).

Step 2: Create ADNS listeners

Next, we specify on which IP address the NetScalers will listen for DNS requests.

  1. Go to Traffic Management – Load balancing – Services
  2. Click Add
  3. Create a new service with following settings:
    1. Name: GSLB_ADNS
    2. IP address: I am using the same address as what was used for the GSLB site
    3. Protocol: ADNS
  4. Click OK
Note: If using a private IP address for this, make sure you NAT this to a public IP address and allow traffic on port UDP 53. The NetScaler is acting as a public DNS server.

Step 3: Setup services

Services tie my GSLB configuration to the existing VIPs (the MDM VIP and NetScaler Gateway VIP) that were setup by the XenMobile wizard.

I’ll create a service to monitor the status of the MDM load balancers (created by the wizard). I also need to create a service for the MAM address, which is the NetScaler Gateway.

  1. The following services should be created (you can use whatever name you want): Go to Traffic Management – GSLB – Services
  2. Click Add
  3. Create a GSLB service
    1. Service Name: specify the name
    2. Site name: select the correct site
    3. Select type: IP based
    4. Select service type: SSL
    5. Select port: 443
    6. Select the IP address (for local services, you can select an existing virtual server, for remote services, enter the virtual IP address)
    7. Public IP address: This is the address that will be provided in the DNS response. It is specific to each site
    8. Public port: 443
PROD NetScaler DR NetScaler
Name: GSLB_PROD_MDM_443
Site: PROD
Type: Local
IP address: MDM VIP on PROD NS
Public IP: public IP  in PROD
Name: GSLB_PROD_MDM_443
Site: PROD
Type: Remote
IP address: MDM VIP on PROD NS
Public IP: public IP  in PROD
Name: GSLB_PROD_MAM_443
Site: PROD
Type: Local
IP address: NG VIP on PROD NS
Public IP: public IP  in PROD
Name: GSLB_PROD_MAM_443
Site: PROD
Type: Remote
IP address: NG VIP on PROD NS
Public IP: public IP  in PROD
Name: GSLB_DR_MDM_443
Site: DR
Type: Remote
IP address: MDM VIP on DR NS
Public IP: public IP in DR
 NameL GSLB_DR_MDM_443
Site: DR
Type: Local
IP address: MDM VIP on DR NS
Public IP: public IP in DR
Name: GSKB_DR_MAM_443
Site: DR
Type: Remote
Ip address: NG VIP on DR NS
Public IP: public IP in DR
 Name: GSKB_DR_MAM_443
Site: DR
Type: Local
Ip address: NG VIP on DR NS
Public IP: public IP in DR

As is obvious, the services I created are the same in each NetScaler (you don’t need to specify whether they are local or remote.). Each NetScaler will have 4 services: 2 local and 2 remote. The IP addresses are those IP addresses assigned to the MDM load balancing VIPs and to the NetScaler gateway. The public IP address specify the IP address that will be supplied as a response to the DNS request. (Remember, GSLB is DNS. Here is where you specified the IP address that is returned. Later you will specify the FQDN that matches that IP address). These are not the public IP addresses of the ADNS listener but the IP addresses used by a device when it actually needs to connect to your XenMobile deployment.

Step 4: Create monitors

With the default configuration, I am not monitoring the services correctly. I need to monitor the XMS servers behind the NetScaler Gateway, rather than the gateway itself (as the gateway will be active all the time). Also, I want to monitor whether the XMS service is operational rather than whether or not the tomcat service on the server has started.

Note: In this example, my NetScalers are exchanging information using MEP (metric exchange protocol). That includes the status of services. Thus, I only need to attach a monitor to the local services.
Note 2: I will point my monitor to port 8443. This allows me to use the same monitor for both the MDM service and the NetScaler (MAM) Gateway service.
  1. Go to Traffic Management – Load balancing – Monitors
  2. Click Add
  3. Create a monitor:
    1. Specify HTTP-ECV as the monitor type
    2. Name: GSLB_MDM_MON
    3. Under standard parameters, specify the following:
      1. Destination IP: <IP of the MDM load balanced VIP on this NetScaler>
      2. Destination port: 8443
      3. Secure: selected
    4. Under special parameters, specify the following:
      1. Send string: GET /zdm/cxf/public/getserverinfo
      2. Receive string: https://mam.ccslabs.biz (replace with the MAM address. This is case sensitive, do not include quotes).
    5. Click create
    6. Go to Traffic Management – GSLB – Services
    7. Select the first LOCAL service in the list and click edit
    8. Select monitors on the right, click on > to bind a monitor
    9. Bind the monitor you have just created.
    10. Repeat this process for the other LOCAL service. There’s no need to do this for remote services.

Step 5: Create the virtual servers

The virtual servers tie everything together. The concept is similar to virtual servers used for normal load balancing, except that these virtual servers don’t have an IP address and don’t receive traffic. GSLB is DNS, remember? Thus the virtual servers will control for each FQDN which IP address it will resolve to.

In a normal GSLB configuration, I’d create a virtual service on each NetScaler with essentially the same configuration. As I have 2 services (MDM, and NetScaler Gateway) you’d expect 2 virtual servers on each NetScaler. However, this is an Active/Passive setup (this is pretty much required as in a DR scenario latency to the database server in the other site is often too high to run active/active) which will require the setup of 2 production virtual server and to backup virtual servers (for the services in DR) on each NetScaler. That way, traffic only flows to DR servers in case the production servers are down.

To make my life easy, I start with the backup virtual servers.

  1. Go to Traffic Management – GSLB – Virtual Servers
  2. Click Add
  3. Create a virtual server
    1. Set the name
    2. DNS record type: A
  4. Click OK
  5. Click on Services (on the right)
  6. Select the correct service to bind.
  7. On the ‘active’ virtual servers (essentially the ones representing the PROD site), click on Domains
  8. Click on > to create a domain binding
    1. Enter the FQDN.
    2. Click Bind
  9. On the ‘active’ virtual servers, click on Backup Virtual Servers
  10. Select the correct backup virtual server and bind it.

Create the following virtual servers. The configuration is the same in both sites.

Virtual Servers Configuration
GSLB_MDM_Active_vs Bound Service: GSLB_PROD_MDM_443
Bound Domain: mdm.gslb.ccslabs.biz
Backup Virtual Server: GSLB_MDM_Backup_vs
GSLB_MAM_Active_vs Bound Service: GSLB_PROD_MAM_443
Bound Domain: mam.gslb.ccslabs.biz
Backup Virtual Server: GSLB_MAM_Backup_vs
GSLB_MDM_Backup_vs Bound Service: GSLB_PROD_MDM_443
GSLB_MAM_Backup_vs Bound Service: GSLB_PROD_MDM_443

Testing the setup

  1. To test this, disable the XMS servers in the DR site. Ensure the servers in the PROD site are active. Use NSLookup to test name resolution for MDM address as well as the MAM address. The addresses should resolve to the public IP addresses of the PROD site.
  2. Disable the servers in the PROD site, enable the database in the DR site, turn on the XMS servers in the DR site. Use NSLookup to test name resolution again. The IP addresses should now resolve to the public IP address of the DR site.

To test on Windows (from command line):

&gt; nslookup
 &gt; server &lt;ADNS listener IP address on the NetScaler&gt;
 &gt; mdm.gslb.ccslabs.biz
 &gt; mam.gslb.ccslabs.biz

Test this for both NetScalers

Final note on the  DR configuration

This example shows how to configure GSLB for XenMobile. It will switch based on whether servers are active in the PROD or DR site. If the servers in PROD are active, traffic will always go to that site.

It is important to create appropriate DR processes to ensure that before servers are activated in the DR site, the database is transferred first, and any PROD servers have been disabled.

It is possible to create a monitor that checks the status of the database in the site. That way you could potentially switch to DR by just switching the database. I have tested that in my lab, but this has not been tested in any production environment. Hence, I do not recommend this.

GSLB detailed document

I’ve previously put this content in a guide which is a bit more detailed that what I included in on this blog. You can download that document here:

https://citrix.sharefile.com/d-s35e7d1da8c14e32b

SYNC AND SHARE BANNER