Pre-requisite:

You have a DNS sub-domain to use for GLB. In this example we will be using "glb.company.com" - a sub domain of "company.com";

You have access to create A records in the glb.company.com (or equivalent) domain; and

You have access to create CNAME records in the company.com (or equivalent) domain.

Design:

Our goal in this exercise will be to configure GLB to send users to their geographically closes DC as pictured in the following diagram:

Design Goal

We will be using an STM setup that looks like this to achieve this goal:

Detailed STM Design

Stingray will present a DNS virtual server in each data center. This DNS virtual server will take DNS requests for resources in the "glb.company.com" domain from external DNS servers, will forward the requests to an internal DNS server, an will intelligently filter the records based on the GLB load balancing logic.

In this design, we will use the zone "glb.company.com". The zone "glb.company.com" will have NS records set to the two Traffic IP addresses presented by vTM for DNS load balancing in each data centre (172.16.10.101 and 172.16.20.101). This set up is done in the "company.com" domain zone setup. You will need to set this up yourself, or get your DNS Administrator to do it.

DNS Zone File Overview

On the DNS server that hosts the "glb.company.com" zone file, we will create two Address (A) records - one for each Web virtual server that the STM's are hosting in their respective data centre.

Step 0: DNS Zone file set up

Before we can set up GLB on Traffic Manager, we need to set up our DNS Zone files so that we can intelligently filter the results.

Create the GLB zone:

In our example, we will be using the zone "glb.company.com". We will configure the "glb.company.com" zone to have two NameServer (NS) records. Each NS record will be pointed at the Traffic IP address of the DNS Virtual Server as it is configured on vTM. See the Design section above for details of the IP addresses used in this sample setup.

You will need an A record for each data centre resource you want Traffic Manager to GLB. In this example, we will have two A records for the dns host "www.glb.company.com". On ISC Bind name servers, the zone file will look something like this:

Pre-Deployment testing:

- Using DNS tools such as DiG or nslookup (do not use ping as a DNS testing tool) make sure that you can query your "glb.company.com" zone and get both the A records returned. This means the DNS zone file is ready to apply your GLB logic. In the following example, we are using the DiG tool on a linux client to *directly* query the name servers that the STM is load balancing to check that we are being served back two A records for "www.glb.company.com". We have added comments to the below section marked with <--(i)--| :

Step 1: GLB Locations

GLB uses locations to help STM understand where things are located. First we need to create a GLB location for every Datacentre you need to provide GLB between. In our example, we will be using two locations, Data Centre 1 and Data Centre 2, named DataCentre-1 and DataCentre-2 respectively:

Step 3 - Testing Round Robin

Now that we have GLB applied to the "glb.company.com" zone, we can test GLB in action. Using DNS tools such as DiG or nslookup (again, do not use ping as a DNS testing tool) make sure that you can query against your STM DNS virtual servers and see what happens to request for "www.glb.company.com". Following is test output from the Linux DiG command. We have added comments to the below section marked with the <--(i)--|:

Step 4: GLB Health Monitors

Now that we have GLB running in round robin mode, the next thing to do is to set up HTTP health monitors so that GLB can know if the application in each DC is available before we send customers to the data centre for access to the website:

In DataCentre-1, in the field labled "Add new monitor to the list" select "GLB_mon_www_AU" and click update.

In DataCentre-2, in the field labled "Add new monitor to the list" select "GLB_mon_www_US" and click update.

Step 5: Activate your preffered GLB load balancing logic

Now that you have GLB set up and you can detect application failures in each data centre, you can turn on the GLB load balancing algorithm that is right for your application. You can chose between:

GLB Load Balancing Methods

Load

Geo

Round Robin

Adaptive

Weighted Random

Active-Passive

The online help has a good description of each of these load balancing methods. You should take care to read it and select the one most appropriate for your business requirements and environment.

Step 6: Test everything

Once you have your GLB up and running, it is important to test it for all the failure scenarios you want it to cover.

Remember: failover that has not been tested is not failover...

Following is a test matrix that you can use to check the essentials:

Test #

Condition

Failure Detected By / Logic implemented by

GLB Responded as designed

1

All pool members in DataCentre-1 not available

GLB Health Monitor

Yes / No

2

All pool members in DataCentre-2 not available

GLB Health Monitor

Yes / No

3

Failure of STM1

GLB Health Monitor on STM2

Yes / No

4

Failure of STM2

GLB Health Monitor on STM1

Yes / No

5

Customers are sent to the geographically correct DataCentre

GLB Load Balancing Mechanism

Yes / No

Notes on testing GLB:

The reason we instruct you to use DiG or nslookup in this guide for testing your DNS rather than using a tool that also does an DNS resolution, like ping, is because Dig and nslookup tools bypass your local host's DNS cache. Obviously cached DNS records will prevent you from seeing changes in status of your GLB while the cache entries are valid.