Application Delivery (ADX)

Global Server Load Balancing (GSLB) 101 with ServerIron

by pmorrissey on ‎06-01-2009 11:34 AM (174 Views)

Global Server Load Balancing with ServerIron

Feature Brief Intro

Global Server Load Balancing (GSLB) is an extension of the Server Load Balancing (SLB) to enable geographically distributed applications to scale and perform efficiently. Organizations that serve clients spread geographically can distribute the application(s) in multiple geographic locations, even around the globe. GSLB determines and direct clients to the "nearest", "fastest" (i.e lowest latency) , "available" and the "best" location to serve that particular application request. Distributing applications ensures geographic redundancy, localizes traffic and optimizes network usage. At each location, load balancing is normally used with multiple application servers for a complete solution.

How it works:-

Global Server Load Balancing (GSLB) enables a ServerIron ADX to add intelligence to authoritative Domain

Name System (DNS) servers by serving as a proxy to the servers. As a DNS proxy, the GSLB ServerIron ADX

evaluates the server IP addresses in the DNS replies from the DNS for which the ServerIron ADX is a proxy.

Based on the results of the evaluation, the GSLB ServerIron ADX can change the order of the addresses in the

reply so that the “best” host address for the client is on top.

In standard DNS, when a client wants to connect to a host and has the host name but not the IP address, the client can send a lookup request to its local DNS server. The DNS server checks its local database and, if the database contains an Address record for the requested host name, the DNS server sends the IP address for the host name back to the client. The client can then access the host.

If the local DNS server does not have an Address record for the requested server, the local DNS server makes a

recursive query. When a request reaches an authoritative DNS server, that DNS server sends a reply to the DNS

query. The client’s local DNS server then sends the reply to the client. The client now can access the requested


With the introduction of redundant servers, a host name can reside at multiple sites, with different IP addresses.

When this is the case, the authoritative DNS server for the host sends multiple IP addresses in its replies to DNS

queries. To provide rudimentary load sharing for the addresses, many DNS servers use a simple round-robin

algorithm to rotate the list of addresses for each query. Thus, the address that was first in the list in the last reply

sent by the DNS server is the last in the list in the next reply sent by the DNS server.

This mechanism can help ensure that a single site for the host does not receive all the requests for the host.

However, this mechanism does not provide the host address that is “best” for the client. The best address for the

client is the one that has the highest proximity to the client, in terms of being the closest topologically, or

responding the most quickly, and so on. Moreover, if a site is down, the simple round-robin mechanism used by

the DNS server cannot tell that the site is down and still sends that site’s host address on the top of the list.

Thus, the client receives an address for a site that is not available and cannot access the requested host.

The ServerIron ADX GSLB feature solves this problem by intelligently using health checks and other methods to

assess the availability and responsiveness of the host sites in the DNS reply, and if necessary exchanging the

address at the top of the list with another address selected from the list. Thus, the GSLB feature ensures that a

client always receives a DNS reply for a host site that is available and is the best choice among the available



example #1


1. A user/client in Ireland enters into their browser and a request is made to his local DNS for a lookup.

2. If an entry is not found, the clients local DNS sends a recursive query to the authoritative DNS for

3. The GSLB ServerIron, as proxy for the authoritative DNS, forwards the lookup request from the client’s local DNS to the authoritative DNS

4. Other DNSs know the authoritative DNS by the VIP configured on the GSLB ServerIron, instead of its real IP address.

5. The authoritative DNS for answers the DNS query (forwarded by the GSLB ServerIron proxy) by sending a list of IP addresses for the sites that correspond to the requested host.

6. The GSLB ServerIron assesses each IP address in the DNS reply to determine the optimal site for the client and moves the address for that site to the top of the list (London is optimal choice for client in Ireland)

7. The client receives a reordered list of IP addresses

8. The client’s browser uses the best address and retrieves the web pages of from London server

example #2

Assume a client is using some application service (for e.g. accessing Microsoft outlook web access) at from a location in California. Using Global Server Load Balancing, that client is redirected to that application service in Sunnyvale as that is geographical closer (less latency) assuming of course that application service is healthy and available capacity. If Sunnyvale service was down, the client would have received a DNS reply indicating that Atlanta was the best server to service their request


Global Server Load Balancing with RHI

Another option that customers use that does not rely on DNS to achieve the same objective is called route health injection (RHI). VIP Route Health Injection (RHI) allows a ServerIron (SI) to advertise the availability of a VIP address throughout the network. Multiple SIs with identical VIP addresses and services can exist throughout the network. Specifically, you can configure an ServerIron to check the health of a VIP configured on the ServerIron and inject a VIP route into the network to force a preferred route to the VIP. Routers receiving client traffic for the VIP select the best route to the VIP. As a result, clients enjoy fast response time regardless of their location because their gateway routers use the best path to the VIP. RHI also prevents client traffic from being routed to a VIP that is unavailable.

example #1


Both servers are active and available. Because the San Francisco server has a lower metric to Asia, the information requested by Asia will come from San Francisco since that route will be in the client’s gateway routing table. If for some reason the application on San Francisco becomes unavailable or the server becomes unavailable, the San Francisco ServerIron’s health check will recognize the fault and remove the San Francisco server’s IP address from the routing table. By removing the server’s IP address from the routing table, New York now has the lowest metric to Asia and it will appear in the client’s gateway and be used to retrieve information for the client.

More information on this topic, check links below.


Admin Guide: Configuring Global Server Load Balancing (GSLB)

Admin Guide: Route Health Injection (RHI)