GSLB service enables users (clients) to connect to the most optimized server among those that serve the same purpose, improving service reliability. In addition, it helps to prevent traffic from being concentrated on a small number of servers, enhancing server availability.  
This post will discuss the benefits that GSLB can bring to an enterprise with distributed servers, and its service logic.

Comparison of GSLB and Conventional DNS

 
Figure 1 below shows a case of an enterprise which has its servers at two sites (datacenters) - in Korea and the US. The left column illustrates Round-Robin DNS process, and the right one shows GSLB-based process.

Figure 1. Comparison of GSLB and conventional DNS

 1. Disaster Recovery

• [DNS] The DNS server cannot check the health status of application servers. So, for 50% (as it is Round-Robin DNS) of users, connection attempts are made to the server in the US even when it was down.
• [GSLB] The GSLB server can check the health status of application servers on a regular basis. So, it prevents users from being connected to the one that is down.

2. Site Load Balancing

• [DNS] The DNS server does not know whether the application servers are over-loaded or not. So, even when the load at the server in Korea exceeds threshold, and becomes over-loaded, connection attempts for 50% of users are still made to the over-loaded server. 
• [GSLB] The GSLB server can check the load status of connected application servers on a regular basis. So it prevents users from being connected to the over-loaded server.  

▶ Note: To be accurate, what the GSLB server checks is the load status of SLB (no. of currently available sessions, network usage, etc.), rather than that of application servers (Detail will be explained in the next post).

  
3. Network Proximity

• [DNS] The DNS server cannot measure Round Trip Time (RTT) over the link between clients and application servers. So, when selecting an application server, the decision cannot be based on the current conditions of the network. 
• [GSLB] The GSLB server can find the application server with the fastest response time (i.e. the best network conditions) through RTT measurement, allowing users to be connected to it.

▶ Note: To be accurate, what the GSLB server measures is the RTT between local DNS server (one that is allocated/configured on clients and SLB, rather than the RTT between clients and application servers (Details will be explained in the next post).   
 

4. Geographic Proximity

• [DNS] The DNS server does not consider the location of a user when selecting an application server for the user. So, a user located in Korea can be connected to the server in the US. 
• [GSLB] The GSLB server can select an application server based on the location of a user, allowing the user to connect to the nearest server.

▶ Note: In general, proximity means smaller RTT. So, the results of No. 3 and No. 4 are the same very often, but can be different in case of network failure or congestion.  
 

As seen so far, using GSLB in an environment where servers are geographically distributed can give you the following benefits:
     (1) High service availability (Disaster recovery)
     (2) More efficient server load distribution (Server/Site load balancing)
     (3) Fast service response (Low latency due to network proximity)
     (4) Connection to the nearest server (due to geographic proximity)

GSLB Service Logic

 
Global Server Load Balancing (GSLB) is an upgraded concept of Server Load Balancing (SLB). While SLB can check the health status of a server (whether it is down or not) and distribute server loads through L4 switching in just a single site, GSLB can do the same in multiple sites over a wider geographic area. 

Figure 2. GSLB service logic

Network Scenario

• There are four web servers for www.example.com - two in Korea and the other two in the US.
• SLBs  (SLB 1 and SLB 2) are located at the front end of the web servers at each site. The user's connection request is sent to the virtual IP addresses (1.1.1.1 and 2.2.2.2) of the SLBs, instead of directly to the IP addresses (10.1.1.10 ~ 13) of the four web servers at www.example.com. Then the SLBs forward it  to the web servers after converting the destination IP addresses of the request.
• At the sites in Korea, GLSB and example.com DNS server are located.

Service logic

1. The user sends a DNS query to the local DNS server to access www.example.com. Then the local DNS server forwards the query to Root DNS server, and then to .com DNS server.
2. The query is sent on to GSLB.
3. As the GSLB works as DNS server proxy, it simply forwards the DNS query to example.com DNS server.
4. At the example.com DNS server, the IP addresses (SLB's virtual IP) of www.example.com (i.e. 1.1.1.1 and 2.2.2.2) are pre-configured. So, the server forwards the values to the GSLB. Time to Live (TTL) during the delivery is assumed to be 300 seconds.
5. Of the two IP addresses, the GSLB selects one that would work best for the user according to its own policy (to be explained later). It also replaces the TTL with a lower value (e.g. 10 seconds). This is to have the local DNS server cache the binding information (IP address of www.example.com) for the minimum period of time.
6. The IP address of the web server 1.1.1.1 that was selected according to the GSLB's policy, and the changed TTL value are forwarded to the local DNS server.
7. The local DNS server then sends the values to the user.
8. Now the user sends HTTP GET message with its destination address set as the IP address of www.example.com, 1.1.1.1, to SLB1 at the site in Korea. And SLB1 forwards the HTTP GET message to the final destination server 10.1.1.10 after applying its policy (considering server health, load, etc.) 

GSLB's policy on server/site selection

GSLB's policy on server/site selection is as follows. We will explain it in detail in the next post.

Figure 3. GSLB's site selection policy