Netscaler Knowledgebase

Configuring Global Server Load Balancing for one site with two internet providers.

Author: Daniel Castro
Evil.dani@gmail.com


Summary

This document discusses Global Server Load Balancing (GSLB) and describes the steps involved to configure GSLB with two internet providers.
The configuration on this documented was tested on a NS 8.1 56.7
The Internet providers are: ETB and Telmex for Colombia, South America
ETB 200.75.61.81 255.255.255.252
Telmex 190.144.55.185 255.255.255.248
This was done as part of lab that was needed for an implementation of a client of ours, it was tested but not very intensively, here we use a single danta center to load balance connections using the DNS infrastructure, it can be used for multiple data centers just by adding more sites instead of only one.

Requirements

An understanding of the Domain Name Service (DNS) process is assumed.

Before configuring GSLB, you must have a properly working load balancing virtual server/service configuration.

Global Server Load Balancing (GSLB) components:

GSLB Domain: The GSLB domain is a publicly resolvable domain or zone that GSLB is responsible for. The NetScaler can be set up to be the Authoritative Server for this domain or it can be set up to proxy the information to an internal DNS server. You will need two public IPs configured as MIP, so DNS resolution can be made from the internet. Each IP will be configured on each provider. In this example only one MIP was used for DNS, because we did not had sufficient Ips on the second provider.

GSLB Site: The GSLB site is the top-level entity for GSLB communications. The information used when configuring the site is used for linking LOCAL sites to REMOTE sites and sharing monitoring data using the Metric Exchange Protocol (MEP). The IP address used must be owned by the NetScaler system (such as a mapped IP (MIP) or subnet IP (SNIP)) and must use TCP port 3011. For this example we will use one of the virtual servers.

GSLB virtual server (vserver): The GSLB vserver is used as the decision intermediary for directing clients’ requests to one of the GSLB site’s load-balanced vservers. The GSLB vserver is bound to a GSLB service. Here you determine via the services what Ips will be resolved in the DNS query.

GSLB service: The GSLB service is basically a monitoring link to the load-balanced vserver. The GSLB service monitors the link to the load-balanced vserver that is created on the NetScaler. The state of the local GSLB service depends on the corresponding local virtual server state. Determine the public Ips that will be resolved in the DNS query, yet the service points to the LB vserver.

GSLB Scenario:

We have only one netscaler connected to two internet providers. On the back-end we hace a single service that published a web server,

We will implement a single LOCAL site, with a single GSLB vserver, two GSLB services pointing to two lb vserver, onw for each provider.

Procedure

GSLB requires the underlying load balancing functionality to be configured and working properly. The following steps must be done on each NetScaler that will participate in GSLB.

Create a ADNS in the lb services, just select the type as ADNS, and the server type the IP address of the public MIP address, do this with all internet providers.

The site type of Local will always be that local NetScaler's assigned IP address.

1. Enable Global Server Load Balancing:

> enable ns feature gslb

2. Add the GSLB site for the local NetScaler system:

> add gslb site "site-1" 190.75.61.82 -publicIP 190.75.61.82

3. Add the GSLB site for all the remote NetScaler systems NOT USED in this example

4. Add the GSLB virtual server that references a service being used in GSLB:

> add gslb vserver "vserver-GSLB-1" HTTP -tolerance 0
This just creates the virtual server of a certain type, the imporant part are the services.

5. Add the GSLB services for each site that is participating in GSLB:

> add gslb service "service-GSLB-1" 200.75.61.82 HTTP 80 -publicIP 200.75.61.82 -publicPort 80 -maxClient 0 -siteName "site-1" -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED
> add gslb service "service-GSLB-2" 190.144.55.188 HTTP 80 -publicIP 190.144.55.188 -publicPort 80 -maxClient 0 -siteName "site-1" -cltTimeout 180 -svrTimeout 360 -downStateFlush DISABLED
Most of this stuff is by default.
When done via the GUI, you will be asked to create some servers, just click yes. The important part here is when doing it via the GUI to type the public address that will be published, this is done on the service window, basic tab on the lower part, just type the ip that will be given via the DNS query.

6. Bind the GSLB service to the GSLB virtual server:

> bind gslb vserver "vserver-GSLB-1" -serviceName "service-GSLB-2"
> bind gslb vserver "vserver-GSLB-1" -serviceName "service-GSLB-1"
No magic here.

This is done last, and it creates the dns records needed for GSLB
> bind gslb vserver "vserver-GSLB-1" -domainName vmomanager.com -TTL 5

As I understand it, the DNS query looks for the service on the GSLB vserver, and return one the IP that are published on the service.

To test it, just configure your pc with the netscaler as DNS, and resolve the domian you binded last.

Monitor the upstream router is the hardest part. ISPs usualy configure the router to answer to ping on your public interface event when their gateway is down. On version 8.1 if you ping an internet router then the netscaler will use the routing table, in doing so usualy it picks the same route. And you can get into many asymetric routing scenarios.
So if I remember correctly the only way to efectivly monitor the link is to ask your ISP to change the router configuration so that it will not answer ping if the outter link is down. The you simply ping the gateway and you will know the status of that ISP's link.

Hope this helps,

Daniel

It all depends on your configuration, but the general answer I would give would be, no. For example if you use routes, then the default reute takes precedence; Mac Based Forwarding could affect; Link load balancing is a big No No. The real problem is consistency between a destination and the route it will use.

Maybe someone else can think of a way to do it, when I did the deployment the only way was to ping the inside interface of the router, that way the route was not important. It was version 8.1 maybe things have changed.

Why can't the device send an HTTP GET to google via a specific link to verify upstream connectivity?

The problem is how to FORCE the probe via a SPECIFIC interface.