Global Server Load Balancing (GSLB) – NetScaler 12

Last Modified: Oct 1, 2017 @ 11:10 am

Navigation

ūüí° = Recently Updated

GSLB Planning

GSLB is nothing more than DNS. GSLB is not in the data path. GSLB receives a DNS query, and GSLB sends back an IP address, which is exactly how a DNS server works. The user then connects to the returned IP, which doesn’t even need to be on a NetScaler.

GSLB can do some things that DNS servers can’t do:

  • Don’t give out an IP address unless it is UP (monitoring)
    • If the active IP address is down, then give out the passive IP address (active/passive)
  • Give out the IP address that is closest to the user (proximity load balancing)
  • Give out different IPs for internal users vs external users (DNS View)

GSLB is only useful if you have a single DNS name that could resolve to two or more IP addresses. If there’s only one IP address, then use¬†normal DNS instead.

Citrix Blog Post Global Server Load Balancing: Part 1 explains how DNS queries work and how GSLB fits in.

Citrix has a good DNS and GSLB Primer.

When configuring GSLB, don‚Äôt forget to ask ‚Äúwhere is the data?‚ÄĚ. For XenApp/XenDesktop, DFS multi-master replication of user profiles is not supported, so configure ‚Äúhome‚ÄĚ sites for users. More information at Citrix Blog Post¬†XenDesktop, GSLB & DR ‚Äď Everything you think you know is probably wrong!

GSLB Configuration Overview

GSLB Configuration can be split between one-time steps for GSLB infrastructure, and repeatable steps for each GSLB-enabled DNS name.

One-time GSLB Infrastructure configuration

  1. Create ADNS listener on each NetScaler pair – DNS clients send DNS queries to the ADNS listeners. GSLB resolves a DNS query into an IP address, and returns the IP address in the DNS response.
  2. Create GSLB Sites (aka MEP Listener) – GSLB Sites usually correspond to different datacenters. GSLB Sites are also the IP address endpoints for NetScaler’s proprietary Metric Exchange Protocol (MEP), which is used by GSLB to transmit proximity, persistence, and monitoring information.
  3. Import Static Proximity Database – NetScaler includes a database that can be used to determine the geographical location of an IP address. Or you can subscribe to a geolocation service, and import its database.
  4. Delegate DNS sub-zone to NetScaler ADNS – in the original DNS zone, create a new sub-zone (e.g. gslb.company.com), and delegate the sub-zone to all ADNS listeners.

Repeatable GSLB Configuration for each DNS name:

  1. Create one or more GSLB Services per DNS name, and per IP address response – each GSLB Service corresponds to a single IP address that can be returned in response to a DNS Query.
    • Optionally, bind a Monitor to each GSLB Service. Monitors determine if the GSLB Service is up or not.
  2. Create a GSLB Virtual Server per DNS name
    • Bind a DNS name to the GSLB Virtual Server.
    • For active/active – bind multiple GSLB Services to the GSLB Virtual Server, configure a load balancing method (e.g. proximity), and configure site persistence.
    • For active/passive – bind the active GSLB Service. Create another GSLB Virtual Server with passive GSLB Service, and configure as Backup Virtual Server.
  3. Create CNAME records for each delegated DNS name Рin the main DNS zone, create a CNAME that maps the original DNS name to the delegated sub-zone. For example, CNAME citrix.company.com to citrix.gslb.company.com.

You will create separate GSLB Services, separate GSLB Virtual Servers, and separate CNAMEs for each DNS name. If you have a bunch of DNS names that you want to GSLB-enable, then you’ll repeat these steps for each GSLB-enabled DNS name.

Each datacenter has a separate ADNS listener IP address. DNS is delegated to all GSLB ADNS Listener IPs, and any one of them can respond to the DNS query. Thus, all NetScaler pairs participating in GSLB should have the same Per-DNS name configuration.

One NetScaler appliance for both public DNS/GSLB and internal DNS/GSLB?

GSLB can be enabled both publically and internally. For public GSLB, configure it on DMZ NetScaler appliances, and expose the DNS listener to the Internet. For internal GSLB, configure it on separate internal NetScaler appliances/instances, and create an internal DNS listener.

Each NetScaler appliance only has one DNS table, so if you try to use the same NetScaler for both public DNS and internal DNS, then be aware that external users can query for internal GSLB-enabled DNS names.

  • As described by Phil Bossman¬†in the comments, you can use a Responder policy to prevent external users from reading internal DNS names.
    add policy patset GSLB_INTERNAL
    bind policy patset GSLB_INTERNAL internalHostname.gslb.domain.com -index 1
    add responder action DNS_Empty_Response respondwith DNS.NEW_RESPONSE
    add responder policy GSLB_DNS_Empty_Response "(!(CLIENT.IP.SRC.IN_SUBNET(10.0.0.0/8)||CLIENT.IP.SRC.IN_SUBNET(192.0.0.0/16)||CLIENT.IP.SRC.IN_SUBNET(172.0.0.0/12)) && DNS.REQ.QUESTION.DOMAIN.CONTAINS_ANY(\"GSLB_INTERNAL\"))" DNS_Empty_Response
    bind responder global GSLB_DNS_Empty_Response 100 END -type DNS_REQ_DEFAULT

One appliance resolving a single DNS name differently for internal and public

Let’s say you have a single DNS name¬†citrix.company.com. When somebody external resolves the name, it should resolve to a public IP. When somebody internal resolves the name, it should resolve to an internal IP.

For internal GSLB and external GSLB of the same DNS name on the same NetScaler appliance, you can use DNS Policies and DNS Views to return different IP addresses depending on where users are connecting from. See Citrix CTX130163 How to Configure a GSLB Setup for Internal and External Users Using the Same Host Name.

If the Internet circuit in the remote datacenter goes down, then this should affect public DNS, since you don’t want to give out a public IP that isn’t reachable. But do you also want an Internet outage to affect internal DNS? Probably not. In that case, you would need different GSLB monitoring configurations for internal DNS and external DNS. However, if you have only a single GSLB Virtual Server with DNS Views, then you can’t configure different monitoring configurations for each DNS View.

To work around this limitation, create two separate GSLB Virtual Servers with different monitoring configurations. Internal DNS uses a CNAME record to reach the GSLB Virtual Server configured for internal monitoring:

  • External citrix.company.com:
    • Configure NetScaler GSLB for citrix.company.com.
    • On public DNS, delegate citrix.company.com to the NetScaler DMZ ADNS services.
  • Internal citrix.company.com:
    • Configure NetScaler GSLB for citrixinternal.company.com or something like that.
    • On internal DNS, create CNAME for citrix.company.com to citrixinternal.company.com
    • On internal DNS, delegate citrixinternal.company.com to NetScaler internal ADNS services.

Remote Internet Monitoring

For public DNS/GSLB, you don’t want to give out a remote public IP address if that remote public IP address is not reachable. That means the local NetScaler will need to somehow determine if the remote datacenter has Internet connectivity or not. Here are some methods of verifying the remote Internet connection:

  • Route GSLB Metric Exchange Protocol (MEP) across the Internet. If MEP goes down, then all IP addresses associated with the remote GSLB Site are assumed to be down, and thus the local NetScaler will stop giving out those remote IP addresses.
  • Bind explicit monitors to each GSLB Service, and ensure the monitoring is routed across the Internet.

GSLB IP Addresses

GSLB is separate from data traffic. The GSLB IP addresses are separate from the IP addresses needed for data.

Some GSLB-specific IP Addresses are needed on each NetScaler pair:

  • ADNS Listener IP: A NetScaler IP¬†that listens for DNS queries.
    • The ADNS listener IP is typically an existing SNIP on the appliance.
    • For external DNS, create a public IP for the ADNS Listener IP, and open UDP 53, so Internet-based DNS servers can access it.
    • A single NetScaler appliance can have multiple ADNS listeners – typically one ADNS listener for public, and another ADNS listener for internal.
  • GSLB Site IP / MEP listener IP: A NetScaler IP¬†that will be used for NetScaler-to-NetScaler GSLB communication. This communication is called MEP or Metric Exchange Protocol. MEP transmits the following between GSLB-enabled NetScaler pairs: load balancing metrics, proximity, persistence, and monitoring.
    • GSLB Sites – On NetScaler, you create GSLB Sites. GSLB Sites are the endpoints for the MEP communication. Each NetScaler pair is configured with the MEP endpoints for the local appliance pair, and all remote appliance pairs.
    • TCP Ports – MEP uses port¬†TCP 3009 or TCP 3011 between the NetScaler pairs. TCP 3009 is encrypted.
    • The ADNS IP address can be used as the MEP endpoint IP.
    • MEP endpoint can be any IP – The MEP endpoint IP address can be any IP address and does not need to be a SNIP or ADNS.
    • One MEP IP per appliance – there can only be one MEP endpoint IP address on each NetScaler pair.
    • Route MEP across Internet? – If you route MEP across the Internet, and if the MEP connection is interrupted, then Internet at one of the locations is probably not working. This is an easy way to determine if remote Internet is up or not. If you don’t route MEP across the Internet, then you’ll need to configure every remote-site GSLB Service with a monitor to ensure that the remote Internet is up.
      • Public IPs for MEP Enpoints – if you route MEP across the Internet, then you’ll need public IPs for each publically-accessible MEP endpoint IP address.
      • Public Port for MEP: Open port TCP 3009 between the MEP Public IPs. Make sure only the MEP IPs can access this¬†port on the other NetScaler. Do not allow any other device on the Internet to access this port. Port 3009 is encrypted.
    • GSLB Sync Ports: To use GSLB Configuration Sync, open ports TCP 22 and TCP 3008 (secure) from the NSIP (management IP) to the remote public MEP IP. The GSLB Sync command runs a script in BSD shell and thus NSIP is always the Source IP.
  • Public IP Summary: In summary, for public GSLB, if MEP and ADNS are listening on the same IP, then you need one new public IP that is NAT‚Äôd to the DMZ IP that is used for ADNS and MEP (GSLB Site IP).
    • Each datacenter has a separate public IP.
    • DNS is delegated to all public ADNS IP listeners.

GSLB Wizard

NetScaler 12 has a GSLB Wizard at Traffic Management > GSLB.

However, the wizard is quite finicky (buggy?), and doesn’t really save any time or steps, so it won’t be documented here.

ADNS Listener

  1. At System > Network > IPs, identify a NetScaler-owned IP that you will use as the ADNS listener. This is typically a SNIP.
  2. Create a public IP for the ADNS Service IP, and configure firewall rules.
  3. On the left, expand Traffic Management > Load Balancing, and click Services.
  4. On the right, click Add.
  5. In the Basic Settings section, do the following:
    1. Name the service ADNS or similar.
    2. In the IP Address field, enter an appliance SNIP.
    3. In the Protocol drop-down, select ADNS.
  6. Click OK.
  7. Scroll down, and click Done to close the Load Balancing Service properties.
  8. On the left of the console, expand System, expand Network, and then click IPs.
  9. On the right, you’ll see the SNIP is now marked as the ADNS svc IP.
  10. Repeat the ADNS configuration on the other appliance pair in the other datacenter.
  11. Your NetScaler appliances are now DNS servers.

DNS Security

  1. NetScaler includes DNS Security Options, at Security > DNS Security, which can protect your ADNS service.
  2. To protect ADNS, set the Profile to All DNS Endpoints.

Metric Exchange Protocol

This section details MEP configuration between two GSLB Sites. See Citrix Docs for larger Parent-Child Topology Deployment Using the MEP Protocol.

GSLB Sites

  1. The local GSLB Site IP can be any IP. Or you can use the same SNIP, and same public IP, used for ADNS.
  2. Open the firewall rules for Metric Exchange Protocol.
  3. On the left, expand Traffic Management, right-click GSLB, and enable the feature.
  4. Expand GSLB, and click Sites.
  5. On the right, click Add.
  6. In the Create GSLB Site page, do the following:
    1. We’re adding the local site first. Enter a descriptive name for the local site.
    2. In the Site Type drop-down, select LOCAL.
    3. In the Site IP Address field, enter an IP that this appliance will listen for MEP traffic. This is typically a DMZ SNIP.
    4. For Internet-routed GSLB MEP, in the Public IP Address field, enter the public IP that is NAT’d to the GSLB Site IP.
    5. For internal GSLB MEP, there is no need to enter anything in the Public IP field.
  7. Scroll down, and click Create, to close the Create GSLB Site page.
  8. Go back to System > Network > IPs, and verify that the IP is now marked as a GSLB site IP.
  9. If you want to use the GSLB¬†Sync Config feature, then you’ll need to edit the GSLB site IP, and enable Management Access.

    1. Scroll down, and enable Management Access. SSH is all you need.
  10. Go to the other appliance pair, and also create the Local GSLB site using its GSLB site IP, and its public IP that is NAT’d to the GSLB site IP.

    1. In System > Network > IPs on the remote appliance, there should now be a GSLB site IP. If GSLB Sync is desired, enable management access on that IP and ensure SSH is enabled.
  11. Now on each appliance, add another GSLB Site, which will be the Remote GSLB site.
  12. In the Create GSLB Site page, do the following:
    1. Enter a descriptive name for the remote site.
    2. Select REMOTE as the Type.
    3. Enter the other appliance’s actual GSLB Site IP as configured on the appliance. This IP does not need to be reachable.
    4. In the Public IP Address field, enter the public IP that is NAT’d to the GSLB Site IP on the other appliance. For MEP, TCP 3009 must be open from the local GSLB Site IP, to the remote public Site IP. For GSLB sync, TCP 22, and TCP 3008, must be open from the local NSIP, to the remote public Site IP.
  13. Click Create.
  14. Repeat on the other appliance.

RPC

MEP defaults to unencrypted on TCP 3011. To fix that:

  1. On the left, expand System, expand Network, and click RPC.
  2. On the right, right-click the new RPC address (the other site’s GSLB Site IP), and click Edit.
  3. On the bottom, check the box next to Secure.

    • If your local GSLB Site IP is not a SNIP, then you’ll need to change the RPC Node to use the local GSLB Site IP as the source IP. In the¬†Source IP Address¬†field,¬†enter the local GSLB Site IP.
  4. Click OK when done.
  5. Do the same thing on the other appliance.
  6. If you go back to GSLB > Sites, you should see it as active.

If your MEP connection between GSLB Sites flaps, it might be useful to introduce a delay before remote GSLB Services are marked as Down.

  1. You can do this at Traffic Management > GSLB > Dashboard.
  2. On the right, click Change GSLB settings.
  3. In the GSLB Service State Delay Time (secs) field, enter a delay before the GSLB Services are marked as down when MEP goes down.

    set gslb parameter -GSLBSvcStateDelayTime 15

Static Proximity Geo Location Database

If you want to use DNS Policies, or Static Proximity GSLB Load Balancing, or Responders based on user’s location, import a geo location database.

NetScaler has a built-in database at /var/netscaler/inbuilt_db/ that you can use. Or you can download a database. Common free databases are:

For IP2Location, see the blog post Add IP2Location Database as NetScaler’s Location File for instructions on how to import.

Import the Built-in Geo database:

  1. In the NetScaler GUI, on the left, expand Traffic Management, expand GSLB, expand Database and Entries, and click Static Databases.
  2. On the right, click Add.
  3. Change the Import From selection to File.
  4. Click Choose File.
  5. Browse to /var/netscaler/inbuilt_db/, and open Citrix_NetScaler_InBuilt_GeoIP_DB.csv. To browse to the directory, select var, and then click Open. Repeat for each directory until you reach /var/netscaler/inbuilt_db.
  6. In the Location Format field, if using the built-in database, select netscaler, and click Create.
  7. When you open a GSLB Service, the public IP will be translated to a location.

Private IP Blocks

Geo Location databases only contain entries for Public IPs. For Private IPs, do the following:

  1. On the left, expand Traffic Management, expand GSLB, expand Database and Entries, and click Custom Entries.
  2. On the right, click Add.
  3. Enter a range of IP addresses for a particular location.
  4. Enter a Location Name in Geo Location format, which is typically six location words separated by periods. You can look in the static proximity database for examples.
  5. Click Create.
  6. Continue creating Custom Entries for other private IP blocks.

Use Geo Locations

You can use the Geo locations in a DNS Policy, static proximity GSLB Load Balancing, or Responders:

GSLB Services

GSLB Services represent the IP addresses that are returned in DNS Responses. The IP addresses represented by GSLB Services do not need to be on a NetScaler, but NetScaler-owned IP addresses (e.g. load balancing VIPs) have additional GSLB Site Persistence options (e.g. cookie-based persistence).

  • Each potential IP address in a DNS response is a separate GSLB Service.
  • GSLB Services are associated with GSLB Sites.
  • GSLB Service configuration is identical for active/active and active/passive. GSLB Virtual Server define active/active or active/passive, not GSLB Services.

GSLB should be configured identically on all NetScaler pairs that are responding to DNS queries. Since you have no control over which NetScaler will receive the DNS query, you must ensure that both NetScaler pairs are giving out the same DNS responses.

To create a GSLB Service:

  1. On the left, expand Traffic Management > GSLB, and click Services.
  2. On the right, click Add.
  3. The service name should be similar to the DNS name that you are trying to GSLB. Include the site name in the service name.
  4. Select one of the GSLB Sites. The IP address you’re configuring in this GSLB Service should be geographically located in the selected GSLB Site.
  5. On the bottom part, if the IP address is owned by this NetScaler, then select Virtual Servers, and select a Virtual Server that is already defined on this appliance. It should automatically fill in the other fields. This option is only available when creating a GSLB Service in the Local GSLB Site.

    1. If the IP address is not owned by this NetScaler, then change the selection to New Server, and enter the remote IP address in the Server IP field.
    2. The Server IP field is the IP address that NetScaler will monitor for reachability.
    3. If the remote IP is owned by a different NetScaler that is reachable by MEP, then enter the actual VIP configured on that remote NetScaler. The Server IP does not need to match what is returned to the DNS Query.
  6. In the Public IP field, enter the IP address that will be returned to the DNS Query. If you leave Public IP blank, then NetScaler will copy the Server IP to the Public IP field. For Public GSLB, the Public IP field is usually a Public IP address. For internal GSLB, the Public IP field is usually an internal IP, and probably matches the Server IP.
  7. Scroll up, and make sure the Service Type is SSL. It’s annoying that NetScaler doesn’t set this drop-down¬†correctly.
  8. Scroll down, and click OK, to close the Basic Settings section.
  9. GSLB Service Monitoring Рon the right, in the Advanced Settings column, you can click Monitors to bind a monitor to this GSLB Service. Review the following notes before you bind a monitor.

    • Local NetScaler VIP – If the GSLB Service IP is a VIP on the local appliance, then GSLB will simply use the state of the local traffic Virtual Server (Load Balancing, Content Switching, or Gateway). There’s no need to bind a monitor to the GSLB Service.
    • Remote NetScaler VIP – If the GSLB Service IP is a VIP on a remote appliance, then GSLB will use MEP to ask the other appliance for the state of the remote traffic Virtual Server. In both cases. There’s no need to bind a monitor to the GSLB Service.
    • GSLB Monitor overrides other Monitoring methods – If you bind a monitor to the GSLB Service, then MEP and local Virtual Server state are ignored (overridden).
    • Here are some reasons for binding a monitor to the GSLB Service:
      • IP is not on a NetScaler – If the GSLB Service IP is not hosted on a NetScaler, then only GSLB Service monitors can determine if the Service IP¬†is up or not.
      • Monitor remote Internet – For Public DNS, if MEP is not routed through the Internet, then you need some method of determining if the remote Internet circuit is up or not. In that case, you’ll need to bind monitors directly to the GSLB Service. The route of the Monitor should go across the Internet. Or you can ping the Internet router in the remote datacenter to make sure it’s reachable.
      • Traffic Domains – If the GSLB Service IP is in a non-default Traffic Domain, then you will need to attach a monitor, since GSLB cannot determine the state of Virtual Servers in non-default Traffic Domains.
  10. Active/Active Site Persistence – If you intend to do GSLB active/active, and if you need site persistence, then you can configure your GSLB Services to use Connection Proxy or HTTP Redirect. See Citrix Blog Post Troubleshooting GSLB Persistence with Fiddler for more details. This only works with GSLB Service IPs that match Virtual Server VIPs on NetScaler appliances reachable through MEP.
  11. Scroll down, and click Done, to finish creating the GSLB Service.
  12. Create additional GSLB Services for each IP address that will be returned to a DNS query.

Manually Synchronize GSLB Configuration

Copy the GSLB Service Configuration to the remote NetScaler pair. You can either repeat the GUI steps listed above. Or you can do the following:

  1. On the left, expand Traffic Management, expand GSLB, and click Dashboard.
  2. On the right, click View GSLB Configuration.
  3. This shows you all of the CLI commands for GSLB. Look for add gslb service commands. You can copy them, and run them (SSH) on other NetScaler pairs that are participating in GSLB.

GSLB Virtual Server

The GSLB Virtual Server is the entity that the DNS name is bound to. GSLB Virtual Server then gives out the IP address of one of the GSLB Services that is bound to it.

For Active/Passive GSLB:

  1. Create a GSLB Virtual Server for the Passive IP address.
    1. Bind the Passive GSLB Service to the Passive GSLB Virtual Server.
  2. Create another GSLB Virtual Server for the Active IP address.
    1. Bind the Active GSLB Service to the Active GSLB Virtual Server.
    2. Configure Backup Virtual Server pointing to the Passive GSLB Virtual Server.
    3. Bind a DNS name to the Active GSLB Virtual Server.
  3. Repeat the GSLB Virtual Server configuration on other NetScaler pairs participating in GSLB.
  4. Delegate the DNS name to NetScaler ADNS.

For Active/Active GSLB:

  1. Create one GSLB Virtual Server.
    1. Bind two or more GSLB Services to the Virtual Server.
    2. Configure the GSLB Virtual Server Load Balancing Method – e.g. Proximity
    3. Configure Site Persistence:
      1. Source IP persistence is configured on the GSLB Virtual Server.
      2. Cookie Persistence is configured on the GSLB Services.
    4. Bind a DNS name to the GSLB Virtual Server.
  2. Repeat the GSLB Virtual Server configuration on other NetScaler pairs participating in GSLB.
  3. Delegate the DNS name to NetScaler ADNS.

Configure Active/Passive GSLB

Passive Virtual Server

  1. On the left, expand Traffic Management, expand GLSB, and click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section, do the following:
    1. Give the Passive GSLB Virtual Server a descriptive name.
    2. Set the Service Type to SSL to match the GSLB Services that you will bind to this Virtual Server.
  4. Click OK to close the Basic Settings section.
  5. On the left, click where it says No GSLB Virtual Server to GSLBService Binding.

    1. Click where it says Click to select.
    2. Check the box next to an existing Passive GSLB Service, and click Select.
    3. Click Bind.
  6. Click OK to close the GSLB Virtual Server GSLB Service Binding section.
  7. Click OK to close the GSLB Virtual Server Domain Binding section. The DNS name is bound to the Active Virtual Server, not the Passive Virtual Sever.
  8. Click OK to close the ADNS Service section.
  9. Click Done to finish creating the Passive GLSB Virtual Server.

Active Virtual Server

  1. On the left, expand Traffic Management, expand GLSB, and click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section, do the following:
    1. Give the Active GSLB Virtual Server a descriptive name.
    2. Set the Service Type to SSL to match the GSLB Services that you will bind to this Virtual Server.
  4. Click OK to close the Basic Settings section.
  5. On the left, click where it says No GSLB Virtual Server to GSLBService Binding.

    1. Click where it says Click to select.
    2. Check the box next to an existing Active GSLB Service, and click Select.
    3. Click Bind.
  6. Click OK to close the GSLB Virtual Server GSLB Service Binding section.
  7. On the left, click where it says No GSLB Virtual Server Domain Binding.
  8. In the Domain Binding page, do the following:
    1. Enter the FQDN that GSLB will resolve.
    2. Click Bind.
  9. Click OK to close the GSLB Virtual Server Domain Binding section.
  10. Click OK to close the ADNS Service section.
  11. On the right, in the Advanced Settings section, click Backup Virtual Server to add it to the left.
  12. On the left, in the Backup Virtual Server section, select the Passive GSLB Virtual Server, and click OK.
  13. Click Done when done creating the Active GSLB Virtual Server.
  14. On the left, if you expand Traffic Management > DNS, expand Records, and click Address Records
  15. You’ll see a new DNS record for the GSLB domain you just configured. Notice it is marked as GSLB DOMAIN, and has a default TTL of 5 seconds. You can also see which GSLB Virtual Server it is bound to.
  16. Configure identical GSLB Virtual Servers on the other NetScaler appliance pair. Both NetScaler pairs must be configured identically. You can use Traffic Management > GSLB > Dashboard > View GSLB Configuration to copy the add/set/bind gslb vserver commands from this appliance to other NetScaler appliances.

Configure Active/Active GSLB

  1. On the left, expand Traffic Management, expand GLSB, and click Virtual Servers.
  2. On the right, click Add.
  3. In the Basic Settings section, do the following:
    1. Give the GSLB Virtual Server a descriptive name.
    2. Set the Service Type to SSL to match the GSLB Sevices you intend to bind.
    3. You can optionally check the box for¬†Send all “active” service IPs in response (MIR). By default, GSLB only gives out one IP address per DNS query. This checkbox always returns all IPs, but the IPs are ordered based on the GSLB Load Balancing Method and/or GSLB Persistence.
    4. A new DNS feature called ECS will contain the actual DNS client IP. This dramatically improves the accuracy of determining a user’s location. Without this setting, GSLB can only see the IP address of the user’s configured DNS server instead of the real client IP. Check the box next to¬†Respond with ECS option to enable ECS for site persistence.

      set gslb vserver <gslb_vserver> -ECS ENABLED
  4. Click OK to close the Basic Settings section.
  5. On the left, click where it says No GSLB Virtual Server to GSLBService Binding.

    1. Click where it says Click to select.
    2. Check the boxes next to multiple existing GSLB Services, and click Select.
    3. Click Bind.
  6. Click OK to close the GSLB Virtual Server GSLB Service Binding section.
  7. On the left, click where it says No GSLB Virtual Server Domain Binding.

    1. Enter the FQDN that this GSLB Virtual Server will resolve.
    2. Click Bind.
  8. Click OK to close the GSLB Virtual Server Domain Binding section.
  9. Click OK to close the ADNS Service section.
  10. On the left, in the Method section, click the pencil icon.

    1. Change the Choose Method drop-down to Static Proximity or similar. This assumes the Geo Location database has already been installed on the appliance.
    2. Click OK to close the Method section.
  11. On the right, in the Advanced Settings column, click Persistence to add it to the left.

    1. Change the Persistence drop-down to Source IP.
    2. Enter a Persistence Id.
      1. This ID must match on every NetScaler pair participating in GSLB.
      2. Each active/active GSLB Virtual Server should have a different Persistence ID.
    3. In the Time-out field, enter the Persistence Time-out. This is typically the same or longer than the webpage timeout.
    4. Click OK to close the Persistence section.
  12. Click Done to finish creating the GSLB Virtual Server.
  13. On the left, if you expand Traffic Management > DNS, expand Records, and click Address Records
  14. You’ll see a new DNS record for the GSLB domain you just configured. Notice it is marked as GSLB DOMAIN, and has a default TTL of 5 seconds. You can also see which GSLB Virtual Server it is bound to.
  15. Configure an identical GSLB Virtual Server on the other NetScaler appliance pair. Both NetScaler pairs must be configured identically. You can use Traffic Management > GSLB > Dashboard > View GSLB Configuration to copy the add/set/bind gslb vserver commands from this appliance to other NetScaler appliances.


GSLB Configuration Synchronization Script

Manual GSLB Synchronization

  1. The script requires SSH to be enabled on your GSLB Site IPs.

  2. Ports TCP 3008, TCP 3010, and TCP 22 must be opened from the local NSIP to the remote GSLB Site IP.
  3. To manually run the script that syncs GSLB configuration from one GSLB Site to another, on the left, expand Traffic Management, expand GSLB, and click Dashboard.
  4. On the right, click Auto Synchronization GSLB.
  5. Use the check boxes on the top, if desired. It’s usually a good idea to Preview the changes before applying them.
  6. Then click Run to begin synchronization.
  7. Click Close.
  8. You can Run it again without previewing it. It seems to take several seconds to complete.

Automatic GSLB Synchronization

  1. There is an automatic GSLB Configuration Sync feature, which automatically syncs the GSLB config every 15 seconds. To enable it on the master appliance, go to Traffic Management > GSLB > Dashboard. On the right, click Change GSLB settings.
  2. Check the box next to Automatic Config Sync. Only enable this on the one appliance where you are configuring GSLB, and want that GSLB config synced to other appliance.
  3. The automatic sync log can be found at /var/netscaler/gslb/periodic_sync.log.

Some notes regarding GSLB Sync:

  • When syncing GSLB Services, it tries to create Load Balancing Server objects on the remote appliance. If the GSLB Service IP matches an existing Load Balancing Server object, then the GSLB sync will fail. Check the Sync logs for details. You’ll have to delete the conflicting Load Balancing Server object before GSLB Sync works correctly.
  • GSLB Sync runs as a script on the BSD shell and thus always uses the NSIP as the source IP.
  • GSLB Sync connects to the remote GSLB Site IP on TCP 3008 (if RPC is Secure) and TCP 22.

Test GSLB

  1. You can test GSLB DNS name resolution from the GUI by going to Traffic Management > GSLB > Dashboard, and on the right, click Test GSLB.

  2. Select a GSLB Domain Name.
  3. Select an ADNS Service IP to test it from, and click Test.
  4. The test performs a dig against the ADNS IP. Verify that the response contains the IP address you expected.
  5. Another method of testing GSLB is to simply point¬†nslookup to the ADNS services, and submit a DNS query for one of the DNS names bound to a¬†GSLB vServer. Run the query multiple times to make sure you’re getting the response you expect.
  6. The NetScaler ADNS services at both GSLB sites should be giving the same response.
  7. To simulate a failure, if the GSLB Service IP is a NetScaler Traffic Management or Gateway IP, you can disable the Traffic Management or Gateway Virtual Server.
  8. Then the responses should change. Verify on both ADNS services.
  9. Re-enable the traffic Virtual Server, and the responses should return to normal.

DNS Delegation

If you are enabling GSLB for the domain gateway.corp.com, you’ll need to create a delegation at the server that is hosting the corp.com DNS zone. For public GSLB, you need to edit the public DNS zone for corp.com.

DNS Delegation instructions will vary depending on what product host’s the public DNS zone. This section details Microsoft DNS, but it should be similar in BIND or web-based DNS products.

There are two ways to delegate GSLB-enabled DNS names to NetScaler ADNS:

  • Delegate the individual record. For example, delegate gateway.corp.com to the two NetScaler ADNS services (gslb1.corp.com and gslb2.corp.com).
  • Delegate an entire subzone. For example, delegate the subzone¬†gslb.corp.com to the two NetScaler ADNS services. Then create a CNAME record in the parent DNS zone for gateway.corp.com that is aliased to gateway.gslb.corp.com. When DNS queries make it to NetScaler, they will be for gateway.gslb.corp.com¬†and thus¬†gateway.gslb.corp.com¬†needs to be bound to the GSLB Virtual Server instead of¬†gateway.corp.com. For additional delegations, simply create more CNAME records.

Delegate an individual DNS record

  1. Run DNS Manager.
  2. First, create Host Records pointing to the ADNS services running on the NetScaler pairs in each data center. These host records for ADNS are used for all GSLB delegations no matter how many GSLB delegations you need to create. These are sometimes called glue records.
  3. The first Host record is gslb1, (or similar) and should point to the ADNS service (Public IP) on one of the NetScaler appliances.
  4. The second Host record is gslb2, and should point to the ADNS Service (public IP) on the other NetScaler appliance.
  5. If you currently have a host record for the service that you are delegating to GSLB (gateway.corp.com), delete it.
  6. Right-click the parent DNS zone, and click New Delegation.
  7. In the Welcome to the New Delegation Wizard page, click Next.
  8. In the Delegated Domain Name page, enter the left part of the DNS record that you are delegating (e.g. gateway for gateway.corp.com). Click Next.
  9. In the Name Servers page, click Add.
  10. This is where you specify gslb1.corp.com and gslb2.corp.com as delegated name servers. Enter gslb1.corp.com, and click Resolve. Then click OK. If you see a message about the server not being authoritative for the zone, ignore the message. Note: you only add one name server at a time.
  11. Then click Add to add the other GSLB ADNS server.
  12. Once both ADNS servers are added to the list, click Next.
  13. In the Completing the New Delegation Wizard page, click Finish.
  14. The delegation is shown in the DNS Manager console.
  15. For proper delegation, the Name Server records should also be added to NetScaler.¬† ūüí°
    1. On the GSLB NetScaler appliances, expand Traffic Management, expand DNS, expand Records, and click Name Server Records.
    2. On the right, click Add.
    3. In the Domain Name field, enter the name of the delegated DNS name (e.g. gateway.corp.com).
    4. In the¬†Name Server field, leave it set to¬†–<< New >>–, and enter one of the FQDNs for your GSLB ADNS services. This is one of the glue records you created earlier.
    5. Click Create.
    6. Add another Name Server Record for the same domain name. But this time, enter the second GSLB ADNS FQDN. Repeat this process until all GSLB ADNS FQDNs are specified.

  16. If you run nslookup against your Microsoft DNS server, it will respond with Non-authoritative answer. That’s because it got the response from NetScaler, and not from itself.

Delegate a Sub-zone

  1. Run DNS Manager.
  2. First, create Host Records pointing to the ADNS services running on the NetScaler pairs in each data center. These are sometimes called glue records.

    1. The first Host record is gslb1 (or similar), and should point to the ADNS service (Public IP) on one of the NetScaler appliances.
    2. The second Host record is gslb2, and should point to the ADNS Service (public IP) on the other NetScaler appliance.
  3. Right-click the parent DNS zone, and click New Delegation.
  4. In the Welcome to the New Delegation Wizard page, click Next.
  5. In the Delegated Domain Name page, enter the left part of the DNS sub-zone that you are delegating (e.g. gslb for gslb.corp.com). Click Next.
  6. In the Name Servers page, click Add.
  7. This is where you specify gslb1.corp.com and gslb2.corp.com. Enter gslb1.corp.com, and click Resolve. Then click OK. If you see a message about the server not being authoritative for the zone, ignore the message. Note: you only add one name server at a time.
  8. Then click Add to add the other GSLB ADNS server.
  9. Once both ADNS servers are added to the list, click Next.
  10. In the Completing the New Delegation Wizard page, click Finish.
  11. The sub-zone delegation is shown in the DNS Manager console.
  12. For proper delegation, the Name Server records should also be added to NetScaler.¬† ūüí°
    1. On the GSLB NetScaler appliances, expand Traffic Management, expand DNS, expand Records, and click Name Server Records.
    2. On the right, click Add.
    3. In the Domain Name field, enter the name of the delegated sub-domain (e.g. gslb.corp.com).
    4. In the¬†Name Server field, leave it set to¬†–<< New >>–, and enter one of the FQDNs for your GSLB ADNS services. This is one of the glue records you created earlier.
    5. Click Create.
    6. Add another Name Server Record for the same domain name. But this time, enter the second GSLB ADNS FQDN. Repeat this process until all GSLB ADNS FQDNs are specified.

Each GSLB-enabled DNS name must be CNAMED to GSLB:

  1. In NetScaler, go to Traffic Management > GSLB > Virtual Servers, and edit your GSLB Virtual Server.
  2. On the left, click in the GSLB Virtual Server Domain Binding section.
  3. Click Add Binding.
  4. Add a domain binding for the CNAMED DNS name. For example, if the original DNS name is gateway.corp.com, then enter gateway.gslb.corp.com. gslb.corp.com matches the sub-zone that you delegated to NetScaler. Click OK.
  5. Repeat the Domain Binding on the other NetScaler appliances.
  6. In DNS Manager, if you currently have a host record for the service that you are delegating to GSLB (gateway.corp.com), delete it.
  7. Right-click the DNS zone, and click New Alias (CNAME).
  8. In the Alias name field, enter the left part of the original DNS name. For gateway.corp.com, enter gateway.
  9. In the Fully qualified domain name (FQDN) for target host field, enter the CNAMED DNS name that is delegated to NetScaler. For example, if you delegated gslb.corp.com to NetScaler, then enter gateway.gslb.corp.com. The GSLB Virtual Server must be configured to match this longer DNS name.
  10. Click OK.
  11. If you run nslookup for the delegated DNS name, it will first CNAME to the longer name, and then respond with the IP address returned by NetScaler GSLB.
  12. You can repeat these steps to delegate (CNAME) additional DNS names to NetScaler GSLB.

4 thoughts on “Global Server Load Balancing (GSLB) – NetScaler 12”

  1. Carl,
    If we have a netscaler pair for internal and external configured for GSLB, is it best to configure them as individual GSLB setups. Both internal and external clients are connecting to same back end infrastructure via content switching VIPs, Goal is for both internal and external clients to be failed over and avoid a situtaiton wher internal hasn’t failed over, but external has.

    1. I try to do separate, but there’s no requirement to do so.

      With separate, external DNS Resolvers can’t resolve internal DNS names.

      With separate, you can have different failover policies for external vs internal. If Internet goes down, you want external to fail over, but not necessarily internal.

Leave a Reply