This guide will walk you through the setup to deploy Global Server Load Balancing on Traffic Manager using the Global Load Balancing feature. In this guide, we will be using the "company.com" domain.
DNS Primer and Concept of operations:
This document is designed to be used in conjuction with the Traffic Manager User Guide.
Specifically, this guide assumes that the reader:
- is familiar with load balancing concepts;
- has configured local load balancing for the the resources requiring Global Load Balancing on their existing Traffic Managers; and
- has read the section "Global Load Balancing" of the Traffic Manager User Guide in particular the "DNS Primer" and "About Global Server Load Balancing" sections.
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 |
|---|
 |
Traffic Manager 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 vTM'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:
| Sample Zone FIle |
|---|
|
;
; BIND data file for glb.company.com
;
$TTL 604800
@ IN SOA stm1.glb.company.com. info.glb.company.com. (
201303211322 ; Serial
7200 ; Refresh
120 ; Retry
2419200 ; Expire
604800 ; Default TTL
)
@ IN NS stm1.glb.company.com.
@ IN NS stm2.glb.company.com.
;
stm1 IN A 172.16.10.101
stm2 IN A 172.16.20.101
;
www IN A 172.16.10.100
www IN A 172.16.20.100
|
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 vTM 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)--| :
| Test Output from DiG |
|---|
[email protected]$ dig @172.16.10.40 www.glb.company.com A ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.40 www.glb.company.com A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19013 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 604800 IN A 172.16.20.100 <--(i)--| HERE ARE THE A RECORDS WE ARE TESTING www.glb.company.com. 604800 IN A 172.16.10.100 <--(i)--| ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm1.glb.company.com. glb.company.com. 604800 IN NS stm2.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 |
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:
| Creating GLB Locations |
|---|
|
 |
 |
Step 2: Set up GLB service
First we create a GLB service so that vTM knows how to distribute traffic using the GLB system:
| Create GLB Service |
|---|
|
 |
Then we enable the GLB serivce:
| Enable the GLB Service |
|---|
|
 |
Next we tell the GLB service which resources are in which location:
| Locations and Monitoring |
|---|
|
 |
Next we will configure the GLB load balancing mechanism:
| Load Balancing Method |
|---|
|
By default the load balancing "algorithm" will be set to "Adaptive" with a "Geo Effect" of 50%. For this set up we will set the "algorithm" to "Round Robin" while we are testing.
| Set GLB Load Balancing Algorithm |
|---|
|
 |
Last step to do is bind the GLB service "GLB_glb.company.com" to our DNS virtual server.
| Binding GLB Service Profile |
|---|
|
 |
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 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)--|:
| Testing |
|---|
[email protected] $ dig @172.16.10.101 www.glb.company.com ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.101 www.glb.company.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17761 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 60 IN A 172.16.2(i)(i)0.100 <--(i)--| DataCentre-2 response ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm1.glb.company.com. glb.company.com. 604800 IN NS stm2.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 ;; Query time: 1 msec ;; SERVER: 172.16.10.101#53(172.16.10.101) ;; WHEN: Thu Mar 21 13:32:27 2013 ;; MSG SIZE rcvd: 123 [email protected] $ dig @172.16.10.101 www.glb.company.com ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.101 www.glb.company.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9098 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 60 IN A 172.16.1(i)0.100 <--(i)--| DataCentre-1 response ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm2.glb.company.com. glb.company.com. 604800 IN NS stm1.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 ;; Query time: 8 msec ;; SERVER: 172.16.10.101#53(172.16.10.101) ;; WHEN: Thu Mar 21 13:32:27 2013 ;; MSG SIZE rcvd: 123 |
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:
|
Create GLB Health Monitors |
|---|
|
 |
|
|
|
|
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 |
|---|
|
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.
The Final Step - Create your CNAME:
Now that you have a working GLB entry for "www.glb.company.com", all that is left to do is to create or change the record for the real site "www.company.com" to be a CNAME for "www.glb.company.com".
| Sample Zone File |
|---|
;
; BIND data file for company.com
;
$TTL 604800
@ IN SOA ns1.company.com. info.company.com. (
201303211312 ; Serial
7200 ; Refresh
120 ; Retry
2419200 ; Expire
604800 ; Default TTL
)
;
|
