Global Server Load Balancing takes the functionality
that network-based local load balancing offers and extends
it across the Internet.
Allan Liska special to HostingTech
Security and disaster recovery have become the new catch phrases
in the hosting industry, and it is not just enterprise customers
who are interested. Customers of all sizes want to know what
will happen if their server fails, or a datacenter experiences
a complete network failure. One of the answers to this problem
is global server load balancing (GSLB). GSLB is a relatively
new service that has been implemented by major load-balancing
vendors, such as Cisco, Nortel, F5, Foundry, Extreme, and Radware.
GSLB allows a website, or websites, to be served from geographically
diverse datacenters. This provides customers with a disaster
recovery solution, and provides an additional revenue stream
for hosting providers.
GSLB is an enhancement to local load balancing; it takes the
functionality that network-based local load balancing offers
and extends it across the Internet. In order to understand how
GSLB works, it is important to comprehend the basics of local
According to the Computer History Museum, Cisco introduced Local Director, the first network-based load balancer, in 1996. A network-based load balancer sits on the network, separate from the server, and performs health checks on each of the servers. The IP (Internet Protocol) address of the website, known as a virtual IP or VIP, is bound to the load balancer, which forwards the packets to one of the available Web servers, which are called the real servers, based on customer-specified algorithms.
Load balancing has become a popular add-on for many hosting companies.
It provides an excellent level of redundancy within the datacenter,
and because most load balancers are network-based devices, they
are capable of providing enhanced security services, such as denial
of service attack prevention and protection against worms like
Nimda or Code Red.
Depending on your vendor, GSLB can be configured in multiple ways.
GSLB can be handled by the same devices that do the local load
balancing, or it can be handed off to a third device. GSLB can
also be configured using DNS (Domain Name Service), BGP (Border
Gateway Protocol), or through a process of packet encapsulation,
but DNS is the most common method.
The GSLB process begins by configuring local load balancing in
each datacenter. When local load balancing has been successfully
configured and tested, there should be a separate VIP for each
datacenter. The VIP creation stage is a phase where the GSLB process
begins to diverge and become more complicated, depending on the
In a basic GSLB configuration, where both local load balancing
and GSLB are performed on the same box, the next step is to add
the VIPs from each datacenter to the remote load balancer as real
addresses. Each load balancer can now distribute traffic between
the local servers and the remote server, which the load balancer
views as a local server.
Traffic between datacenters
The big question is, of course, how do you distribute traffic
between the two datacenters? The answer involves tricks with
DNS. In a local load-balancing situation, the process is simple:
Point the A record for your domain to the IP address of the
VIP. If the domain is www.example.com,
and the VIP is 10.10.0.1, you would make an entry in the zone
file mapping www.example.com
to the VIP:
www IN A 10.10.0.1
In a GSLB situation, a slightly different approach is required.
A VIP for the website exists on the load balancer for each datacenter
in the GSLB configuration; however, loading the VIPs into the
zone file would not work in this situation. If one of the datacenters
were to become unavailable, the DNS server would not know and
would continue to send traffic to the unavailable datacenter.
Instead, traffic should only be directed to available datacenters.
Distributing traffic to available datacenters is accomplished
by delegating the www records to the load balancers in the primary
zone file. Again, using example.com as the domain, the first step
is to create a CNAME record in the example.com zone file:
www IN CNAME www.gslb.example.com
Each load balancer should have an administrative IP address; the
next step is to create A records for those administrative IP addresses.
For example, if the administrative IP address for the load balancer
in Datacenter 1 is 10.10.200.1 and the administrative IP address
for the load balancer in Datacenter 2 is 192.168.200.1, the following
entries would be created in the example.com zone file:
lbdc1 IN A 10.10.200.1
lbdc2 IN A 192.168.200.1
The next step is to direct DNS requests for www.example.com to
the two load balancers, where the DNS server on the load balancer
will process them. To do this, create name server records for
gslb.example.com pointing to the two load balancers:
gslb IN A lbdc1.example.com.
IN A lbdc2.example.com.
Now when someone requests www.example.com, they will go to their
caching name server, which makes the request for information from
the authoritative name servers for example.com. The authoritative
name servers for example.com respond by saying that www.example.com
is really www.gslb.example.com, and to find out information about
www.gslb.example.com caching, the name server needs to query either
lbdc1.example.com or lbdc2.example.com. A name server record would
be added for every datacenter participating in GSLB for example.com.
All backed up
GSLB works because there are multiple levels of redundancy. The first level of redundancy is that the authoritative name servers are set up on different networks, in different locations. The second level is that the load balancers are in multiple datacenters and should be deployed in pairs. The third layer is that there are multiple servers in each datacenter. Even if there are several simultaneous equipment failures within a Web infrastructure, there is a good chance a GSLB-enabled site will remain available.
If one of the authoritative name servers fails, the caching name
server will get information from the second. If a datacenter becomes
unavailable, the caching name server has the second datacenter
from which to pull information. Even if an authoritative name
server fails, and one of the datacenters is unavailable, there
is still a path to the website.
To increase availability, most GSLB devices set the TTL (Time
To Live) for the domain gslb.example.com to one second. This forces
the caching name server to continuously request updated information
from the load balancers (assuming the administrator of the caching
name server honors one-second TTLs). Because the caching name
server is constantly refreshing information about example.com,
if one of the datacenters becomes unavailable, site visitors are
seamlessly transitioned to the other datacenter.
One company that has had a lot of success with this approach
to load balancing is MSNBC (www.msnbc.com).
MSNBC implemented a GSLB solution by F5 Networks (www.F5.com)
prior to the 2002 Winter Olympics. The F5 solution involves
two boxes: the F5 Big IP Controller handles the local load balancing,
while the F5 3-DNS Controller manages the GSLB portion of availability.
When MSNBC received the contract to host the website for the Olympics,
they added a second datacenter and started looking for ways to
distribute traffic between the two. After evaluating several vendors,
MSNBC decided on F5. According to Mike Corrigan, director of technology
for MSNBC, F5 helped integrate more than 50 Windows 2000 DataCenter
and Advanced Servers into a GSLB solution.
During the Olympics, the number of users on the MSNBC website
went from about 3.5 million per day to 8.8 million, with 75 million
page views daily. Traffic to the site grew exponentially as well.
Prior to the Olympics, the traffic averaged 150 Mbps. During the
Olympics, traffic exploded to over 1.3 Gbps. During this time,
the F5 solution helped keep the availability of the MSNBC website
to 99.98 percent at the datacenters and 99.8 percent at the edge.
According to Corrigan, "MSNBC has been happy with the selection
of F5. The combination of local and global load balancing has
strengthened the overall availability and survivability of the
GSLB is not without its problems. Alex Samonte, chief engineer
of Metromedia Fiber Networks (www.mfn.com),
says, "GSLB is an easy concept to understand, but it doesn't
always quite work the way you would imagine it. Caching DNS
servers in odd locations, asymmetric routing, route flapping,
and many other things will cause GSLB not to work as you expect."
This point is one of the most common complaints about GSLB. On
paper, it sounds like it should provide 100 percent availability.
Unfortunately, there are so many unknown factors and uncontrollable
aspects of the network that offering 100 percent availability
is simply not possible.
Samonte adds, "The main problem encountered is mismatched expectations. Most
customers are sold GSLB as the end-all solution to load balancing
and multiple sites."