Global Server Load Balancing (GSLB) – NetScaler 11

Last Modified: Jul 12, 2016 @ 6:19 pm


šŸ’” = 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. However, GSLB can do some things that DNS servers can’t do:

  • Don’t give out an IP address unless it is UP (monitoring)
    • If active IP address is down, 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 vs external (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 can be enabled both externally and internally. For external GSLB, configure it on the DMZ NetScaler appliances and expose it to the Internet. For internal GSLB, configure it on internal NetScaler appliances. Note: Each NetScaler appliance only has one DNS table so if you try to use one NetScaler for both public and internal then be aware that external users can query for internal GSLB-enabled DNS names.

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

However, GSLB monitoring applies to the entire GSLB Service so it would take down both internal and external GSLB. If you need different GSLB monitoring for internal and external of the same DNS name, try CNAME:

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


Some IP Addresses are needed on each NetScaler pair:

  • ADNS IP: AnĀ IPĀ that will listen for ADNS queries. For external, create a public IP for the ADNS IPĀ and open UDP 53 so Internet-based DNS servers can access it. This can be an existing SNIP on the appliance.
  • GSLB Site IP / MEP IP: A GSLB Site IPĀ that will be used for NetScaler-to-NetScaler communication, which is called MEP or Metric Exchange Protocol. The IPĀ for ADNS can also be used for MEP / GSLB Site.
    • RPC Source IP: If running NetScaler 11.0 build 64 or newer then the GSLB Site IP can be anything and RPC traffic (MEP) can be sourced from the GSLB IP. For older NetScaler builds, RPC traffic is sourced from a SNIP, even if this is different than the GSLB Site IP. In older builds, it’s less confusing if you use a SNIP as the GSLB Site IP.
    • Public IP: For external GSLB, create public IPs that are NATā€™d to the GSLB Site IPs. The same public IP used for ADNS can also be used for MEP. MEP should be routed across the Internet so NetScaler can determine if the remote datacenter has Internet connectivity or not.
    • MEP Port: Open port TCP 3009 between the two NetScaler GSLB Site IPs. Make sure only the NetScalers can access thisĀ port on the other NetScaler. Do not allow any other device on the Internet to access this port. This port is encrypted.
    • GSLB Sync Ports: To use GSLB Configuration Sync, open ports TCP 22 and TCP 3008 from the NSIP (management IP) to the remote public IP that is NATā€™d to the GSLB Site IP. The GSLB Sync command runs a script in BSD shell and thus NSIP is always the Source IP.
  • DNS Queries: The purpose of GSLB is to resolve a DNS name to one of several potential IP addresses. These IP addresses are usually public IPs that are NATā€™d to existing Load Balancing, SSL Offload, Content Switching, or NetScaler Gateway VIPs in each datacenter.
  • IP Summary: In summary, for external GSLB, you will need a minimum of two public IPs in each datacenter:
    • One public IP that is NATā€™d to the IP that is used for ADNS and MEP (GSLB Site IP). You only need one IP for ADNS / MEP no matter how many GSLB names are configured. MEP (GSLB Site IP) can be a different IP, if desired.
    • One public IP that is NATā€™d to a Load Balancing, SSL Offload, Content Switching, or NetScaler Gateway VIP.
    • If you GSLB-enable multiple DNS names, each DNS name usually resolves to different IPs. This usually means that you will need additional public IPs NATā€™d to additional VIPs.


  1. Identify an NetScaler-owned IP that you will use for ADNS. This is typically a SNIP.
  2. Configure a public IP for the ANDS Service IP and configure firewall rules.
  3. On the left, expand Load Balancing and click Services.
  4. On the right, click Add.
  5. Name the service ADNS or similar.
  6. In the IP Address field, enter an appliance SNIP.
  7. In the Protocol field, select ADNS. Then click OK.
  8. Scroll down and click Done.
  9. On the left of the console, expand System, expand Network and then click IPs.
  10. On the right, youā€™ll see the SNIP as now being marked as the ADNS svc IP. If you donā€™t see this yet, click the Refresh icon.
  11. Repeat on the other appliance in the other datacenter.

Metric Exchange Protocol

  1. Select an IP to be the GSLB Site IP. In NetScaler 11.0 build 64 and newer, this can be any IP. In older builds, 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. Add the local site first. Enter a descriptive name and in the Site Type select LOCAL.
  7. In the Site IP Address field, enter an IP that this appliance will listen for MEP traffic. This IP must be in the default Traffic Domain. (Note: NetScaler 11.0 build 64 supports GSLB in Admin Partitions).
  8. For external GSLB, in the Public IP Address field, enter the public IP that is NATā€™d to the GSLB Site IP. For internal GSLB, thereā€™s no need to enter anything in the Public IP field. Click Create.
  9. Go back to System > Network > IPs and verify that the IPĀ is now marked as a GSLB site IP. If you donā€™t see it yet, click the Refresh button.
  10. If you want to use the GLSB Sync Config feature, then you’ll need to edit the GSLB site IP and enable Management Access.
  11. When you enable Management Access on a dedicated GSLB site IP, SSH is already selected by default. That’s all you need.
  12. Go to the other appliance 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.
  13. In System > Network > IPs on the remote appliance, there should now be aĀ GSLB site IP. This could be a SNIP. If GSLB Sync is desired, enable management access on that IP and ensure SSH is enabled.
  14. Now on each appliance add another GSLB Site, which will be the remote GSLB site.
  15. Enter a descriptive name and select REMOTE as the Site Type.
  16. Enter the other applianceā€™s actual GSLB Site IPĀ as configured on the appliance. This IP does not need to be reachable.
  17. In the Public IP 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 to this IP from the local GSLB Site IP. For GSLB sync, TCP 22, and TCP 3008 must be open to this IP from the local NSIP. Click Create.
  18. Repeat on the other appliance.
  19. MEP will not function yet since the NetScalers are currently configured to communicate unencrypted on TCP 3011. To fix that, on the left, expand System, expand Network and click RPC.
  20. On the right, edit the new RPC address (the other siteā€™s GSLB Site IP) and click Open.
  21. On the bottom, check the box next to Secure.
  22. In NetScaler 11.0 build 64 or newer, if your 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. UncheckĀ IPv6 first. Then enter the local GSLB Site IP. Click OK when done.
  23. Do the same thing on the other appliance.
  24. If you go back to GSLB > Sites, you should see it as active.

GSLB Services

GSLB Services represent the IP addresses that are returned in DNS Responses. DNS Query = DNS name. DNS Response = IP address.

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

Create the same GSLB Services on both NetScalers:

  1. Start on the appliance in the primary data center. This appliance should already have a traffic Virtual Server (NetScaler Gateway, Load Balancing, or Content Switching) for the DNS name that you are trying to GSLB enable.
  2. On the left, expand Traffic Management > GSLB and click Services.
  3. On the right, click Add.
  4. The service name should be similar to the DNS name that you are trying to GSLB. Include the site name in the service name.
  5. Select the LOCAL Site.
  6. On the bottom part, select Virtual Servers and then select a Virtual Server that is already defined on this appliance. It should automatically fill in the other fields. If you see a message asking if you wish to create a service object, click Yes.
  7. Scroll up and make sure the Service Type is SSL. It’s annoying that NetScaler doesn’t set this drop-downĀ correctly.
  8. The Public IP field contains the actual IP Address that the GSLB ADNS service will hand out. Make sure this Public IP is user accessible. It doesnā€™t even need to be a NetScaler owned IP.
  9. Scroll down and click OK.
  10. 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). 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.
  11. However, you can also bind monitors directly to the GSLB Service. Here are some reasons for doing so:
    • If the GSLB Service IP is a NetScaler-owned traffic VIP, but the monitors bound the traffic Virtual Server are not the same ones you want to use for GSLB. When you bind monitors to the GSLB Services, the monitors bound to the traffic Virtual Server are ignored.
    • 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.
    • 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.
  12. 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.
  13. Click Done.
  14. On the otherĀ datacenter NetScaler, create a GSLB Service.
  15. Select the REMOTE site that is hosting the service.
  16. Since the service is on a different appliance and not this one, you wonā€™t be able to select it using the Virtual Servers option.Ā Instead, selectĀ New Server.
  17. For the Server IP, enter the actual VIP configured on the other appliance. This localĀ NetScaler will use GSLB MEP to communicate with the remoteĀ NetScaler to find a traffic Virtual Server with this VIP. The remoteĀ NetScaler respondĀ if the remote traffic Virtual Server is up or not. The remote Server IP configured here does not need to be directly reachable by this local appliance. If the Server IP is not owned by either NetScaler, then you will need to bind monitors to your GSLB Service.
  18. In the Public IP field, enter the IP address that will be handed out to clients. This is the IP address that users will use to connect to the service. For Public DNS, you enter a Public IP that is usually NAT’d to the traffic VIP. For internal DNS, the Public IP and the Server IP are usually the same.
  19. Scroll up and change the Service Type to match the Virtual Server defined on the other appliance..
  20. Click OK.
  21. Just like the other appliance, you can also configure Site Persistence and GSLB Service Monitors. ClickĀ Done when done.
  22. Create more GSLB Services, one for each traffic VIP. GSLB is useless if there’s only one IP address to return. You should have multiple IP addresses (VIPs) through which a web service (e.g. NetScaler Gateway) can be accessed. Each of these VIPs is typically in different datacenters, or on different Internet circuits. The mapping between DNS name and IP addresses is configured in the GSLB vServer, as detailed in the next section.

GSLB Virtual Server

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

Configure the GSLB vServer identically on both appliances:

  1. On the left, expand Traffic Management > GLSB, and click Virtual Servers.
  2. On the right, click Add.
  3. Give the GSLB vServer a descriptive name. For active/active, you can name it the same as your DNS name. For active/passive, you will create two GSLB Virtual Servers, one for each datacenter, so include Active or Passive in the Virtual Server name.
  4. Click OK.
  5. If you intend to bind multiple GSLB Services to this GSLB vServer, then you can optionally check the box forĀ Send all “active” service IPs. By default, GSLB only gives out one IP 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.
  6. On the right, in the Advanced SettingsĀ column, click Service.
  7. On the left, click where it says No GSLB Virtual Server to GSLBService Binding.
  8. Click the arrow next to Click to select.
  9. Check the box next to an existing GSLB Service and click Select. If your GSLB is active/passive then only bind one service.
  10. If your GSLB is active/active then bind multiple GSLB Services. Also, youā€™d probably need to configure GSLB persistence (Source IP or cookies).
  11. Click Bind.
  12. On the right, in the Advanced SettingsĀ column, click Domains.
  13. On the left, click where it says No GSLB Virtual Server Domain Binding.
  14. Enter the FQDN that GSLB will resolve.
  15. If this GSLB is active/passive, there are two options:
    • Use the Backup IP field to specify the IP address that will be handed out if the primary NetScaler is inaccessible or if the VIP on the primary appliance is marked down for any reason.
    • Or, create a second GSLB Virtual Server that has the passive GSLB service bound to it. Donā€™t bind a Domain to the second GSLB Virtual Server. Then edit the Active GSLB Virtual Server and use the Backup Virtual Server section to select the second GSLB Virtual Server.
  16. Click Bind.
  17. If this is active/active GSLB, you can edit theĀ Method section to enableĀ Static Proximity. This assumes the Geo Location database has already been installed on the appliance.
  18. Also for active/active, if you don’t want to use Cookie-based persistence, then you can use theĀ Persistence section to configureĀ Source IPĀ persistence.
  19. Click Done.
  20. If you are configuring active/passive using the backupĀ GSLB Virtual Server method, create a second GSLB Virtual Server that has the passive GSLB service bound to it. Donā€™t bind a Domain to the second GSLB Virtual Server.Ā Then edit the Active GSLB Virtual Server and use the Backup Virtual Server section to select the second GSLB Virtual Server.

  21. On the left, if you expand Traffic Management >Ā DNS, expand Records and click Address Records, youā€™ll see a new DNS record for the GSLB domain you just configured. Notice it is marked as GSLB DOMAIN.

  22. ConfigureĀ identical GSLB Virtual Servers on the other NetScaler appliance. Both NetScalers must be configured identically.
  23. You can also synchronize the GSLB configuration with the remote appliance by going to Traffic Management > GSLB.
  24. On the right, click Synchronize configuration on remote sites.
  25. Use the check boxes on the top, if desired. Itā€™s usually a good idea to Preview the changes before applying them. Then click OK to begin synchronization.

Some notes regarding GSLB Sync:

  • It’s probably more reliable to do it from the CLI by runningĀ sync gslb config and one of the config options (e.g.Ā -preview).
  • 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.


  1. To test GSLB, 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.
  2. Both NetScaler ADNS services should be giving the same response.
  3. To simulate a failure, disable the traffic Virtual Server.
  4. Then the responses should change. Verify on both ADNS services.

  5. Re-enable the traffic Virtual Server, and the responses should return to normal.

DNS Delegation

If you are enabling GSLB for the domain, youā€™ll need to create a delegation at the server that is hosting theĀ DNS zone. For public GSLB, you need to edit the public DNS zone for

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 to the two NetScaler ADNS services ( and
  • Delegate an entire subzone. For example, delegate the subzoneĀ to the two NetScaler ADNS services. Then create a CNAME record in the parent DNS zone for that is aliased to 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Ā For additional delegations, simply create more CNAME records.

This section covers the first method – delegating an individual DNS record:

  1. Run DNS Manager.
  2. First, create Host Records pointing to the ADNS services running on the NetScalers 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.
  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Ā (, 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). Click Next.
  9. In the Name Servers page, click Add.
  10. This is where you specify and Enter and click Resolve. Then click OK. If you see a message about the server not being authoritative for the zone, ignore the message.
  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. 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.

Thatā€™s all there is to it. Your NetScalers are now DNS servers. For active/passive, the NetScalers will hand out the public IP address of the primary data center. When the primary data center is not accessible, GSLB will hand out the GSLB Service IP bound to the Backup GSLB vServer.

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 11 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.

To DownloadĀ GeoLite Legacy:

  1. Download the GeoLite Country database CSV from
  2. Note: GeoLite City is actually two files that must be merged as detailed at Citrix Blog PostĀ GeoLite City as NetScaler location database. GeoLite Country doesn’t need any preparation.
  3. Upload the extracted database (.csv file) to the NetScaler appliance atĀ /var/netscaler/locdb.

To importĀ the Geo databaseĀ (including the built-in database):

  1. In the NetScaler GUI, on the left, expand AppExpert, expand Location and click Static Database (IPv4).
  2. On the right, click Add.
  3. Change theĀ Import From selection toĀ File.
  4. ClickĀ Browse.
  5. For the built-in database, browse toĀ /var/netscaler/inbuilt_db/ and openĀ Citrix_NetScaler_InBuild_GeoIP_DB.csv.
  6. Or browse to the Geo Location database file you uploaded and open it.
  7. In the Location Format field, if using the built-in database, selectĀ netscaler.
  8. If using GeoLite Country, select geoip-country.
  9. Click Create.
  10. When you open a GSLB Service, the public IP will be translated to a location.

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

Email this to someonePrint this pageTweet about this on TwitterShare on LinkedInShare on FacebookPin on PinterestShare on RedditShare on StumbleUpon

30 thoughts on “Global Server Load Balancing (GSLB) – NetScaler 11”

  1. Carl-

    Question: I set up GSLB for Active/Passive sites. I realized after the fact, I entered the subnet as a /24 on my passive site and should have entered a /23. Is there a way to change this direct route to reflect a /23 without rebuilding GSLB? THe route is a Direct route so I am unable to remove it from the GUI and unable to run a “remove route” from CLI.

    Thank you for any help you can provide-


  2. Hi Carl, I have never configured GSLB before and just did it using your article. It is perfect!

    Can you give me a hint please with this minor issue:

    I am trying to GSLB 2 NetScaler Gateways and when I disable Virtual Server on my first NetScaler and trying to access my URL ( it just redirects me to (which is my second NetScaler Virtual Server IP) Do you know why this could happen?

    I haven’t configured DNS delegation yet, but that shouldn’t cause the issue.
    Thank you.

    1. Can you use your Browser’s developer tools to trace the HTTP traffic to see where the redirect is coming from?

      Do you have a Responder on your Gateway?

      Otherwise, I’ve never seen it redirect to an IP before.

  3. Hi Carl ā€“ This is really awesome and great documents in your website. Thanks for the help with such detailed information which is not available straight elsewhere.

    I have a question on GSLB, Is this possible to use the same public IP used for NetScaler Gateway VIP to enable the GSLB configuration. We are having 2 public IPs (one per DC site) and NATed to NetScaler GW VIP of respective DCs. I just wanted to know if it is possible to use the same Public IP again (NATed to SNIP configured for ADNS service) as the ports are different. I am yet to discuss with my networking team if they can enable 1 Pubic IP NATed to few Internal IPs with different ports. I wanted to take your great views as it will help to circumvent multiple public IP requirements.

    1. On a firewall you can configure Port Address Translation instead of Network Address Translation. But the IPs on the NetScaler are still separate.

  4. Thanks Carl,
    That’s where the problem is. I already have a Storefront monitor bound to Storefront Vserver. I can’t have multiple monitors bound to a Vserver?

    1. You can definitely bind multiple monitors to a vServer. Try it. By default, if any one of the monitors is down then the vSever goes down.

  5. Thanks Carl, for the reply. I really need to set up Storefront LB Vserver to monitor the delivery controllers (which are set up as a service and LB vip on the same netscaler) so that if either of the delivery controller service or vip goes down then storefront LB vserver should show down as well. in this case the GSLB will point to Passive DC.

    1. Create a new monitor that contains the VIP of your Delivery Controller VIP. Bind this monitor to your StoreFront LB vServer. Monitors can have IP addresses in them.

  6. Hi Carl,
    My GSLB is pointing to 2 storefront vips in 2 different DCs in active passive mode. The storefront servers then point to a VIP on the Netscaler for delivery controllers. Is it possible that if the delivery controller at one site is down the GSLB points to other DC.

    1. Are you asking if the delivery controller is down then “StoreFront” points to the other DC?

      You can easily setup an active/passive LB vServer. You already have the active LB vServer. Create a new LB vServer that is non-addressable and points to the other datacenter. Then open the Active LB vServer, add the Protection section, and select your passive LB vServer.

  7. Hi Carl, Do you have a config example for active/passive GSLB load balancing for NS v11. Appreciate if you could point to the right direction Please.

  8. Thanks Carl for very useful information. I have a question on GSLB. What will hapopen if the MEP on tcp 3009 goes down between 2 netscalers in 2 different DCs. Will the GSLB stop working or only GSLB services for remote site will not be accessible. Also in your above example how the dns resolution will work. Will the dns server always send the first IP address back to client DNS request or will it round robin.

    1. If MEP goes down, and if you don’t have monitors attached to GSLB services, then the remote GSLB services will go down and the local ADNS will stop giving out those IPs.

      The delegating DNS servers will delegate to all NetScaler ADNS services. One of them is chosen at random.

      GSLB can be configured to return multiple IPs for a GSLB vServer. The order of the list depends on the load balancing algorithm.

    1. I’m not sure what that means. Are you referring to the GSLB Service monitors? Or do you mean MEP? You can bind monitors to the GSLB Services to monitor almost anything.

        1. Are you asking if the 1st Gateway can use GSLB to resolve a DNS name for the 2nd Gateway’s IP? For double-hop, I usually direct ICA traffic to the 2nd Gateway in the same datacenter. Are you wanting that if the 2nd Gateway is down in the local datacenter then GSLB fails over to the 2nd Gateway in a different datacenter? I don’t see why that wouldn’t work.

          Or are you simply asking if GSLB service can run on the 2nd Gateway? It can run on every appliance if you want. It’s just DNS.

  9. Hi, Carl! Looooove your stuff! Budding NS architect here with two questions:

    1. What is the functional difference between defining a Backup IP in the GSLB Vsrv, and creating and defining a Backup Virtual Server for it? Is there an advantage to one strategy over the other, or is one simply a hold-over from earlier versions of the software? Most docs and help guides I’ve seen simply offer the two options as equals without going into any detail. The only thing I’ve come up with so far is defining separate virtual servers allows you to create and bind separate services that could use slightly different parameters, but I’m not entirely sure why you’d do that.

    2. When doing GSLB for a CSW configuration, how do you cleanly ensure the health of the CSW VIP (which is always UP unless you get into RHI state settings) actually reflects the health of the content it front-ends? And, related, is there a way to only fail over part of a CSW structure, or can you only GSLB fail over the entire name space?

    Thanks so much for all your work! I rely on it ~a lot~! šŸ™‚

    1. 1. Frankly, I don’t know the difference. I used to do Backup IP but all documentation refers to two vServers so I switched to that method instead.

      2. HTTP data is not included in DNS (GSLB) requests. So you’ll have the situation of the user connecting to the “wrong” site. In that case, the “wrong” site needs to either do a proxy or do a redirect. Both have their pros and cons. For proxy, you setup the LB VIP in active/passive. For redirect, you configure a Redirect URL if the LB services are down.

      1. Yea, the Primary/Secondary virtual server structure made the most sense to my brain, but I just wasn’t sure whether I was shooting myself in the foot down the road by going one route or the other.

        And that raises an interesting point to me on #2. I’ve been looking at GSLB as a black/white kind of setup, where I’ve either truly enabled our services to fail across sites using *just* GSLB, or I’ve not. But really, there’s an in-between of sorts: GSLB to fail over the entire name space in the event of a real calamity, but also the use of backup virtual servers and the like at different levels of the structure as needed. I guess I worried that mixing the two strategies was overly confusing, but I’m not sure how you’d get around some scenarios without doing it. šŸ˜®

  10. Hello Carl, you said “NetScaler 11.0 build 64 supports GSLB in Admin Partitions so this might a workaround for single-appliance deployments.” but GSLB settings is not present in the admin partition after adding a partition. Did I miss anything? Thanks.

  11. Thank you very much for this Carl. I was hung up with DNS Delegation until I came across your post. I was wondering though, which methods you use for a true active/passive GSLB. I do not want my DR site’s IP to resolve unless the main one is completely down.

    1. The GSLB vServer config is straightforward. However, the hard part is configuring the monitors so it fails over when you want it to and doesn’t when you don’t want it to. A common scenario is to failover when main site Internet is down and routing MEP through the Internet should handle that scenario.

Leave a Reply