Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

   
 
Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
 
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
 
banner
banner
Global Server Load Balancing (GSLB) for Enterprise: Part 1. Concept and Service Logic
August 12, 2015 | By Chris Yoo (tech@netmanias.com)
Online viewer:
Comments (3)
3

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

 

 

 

Pankaj sharma 2022-06-07 16:33:23

Perfectly explained the process, step by step thanks dear.

Mahindra Bolero Pik-up 4x4

Pankaj sharma 2022-06-07 16:33:36

Perfectly explained the process, step by step thanks, dear.

Mahindra Bolero Pik-up 4x4

Truckjunction 2023-03-28 20:00:07

Great job on writing such an insightful and informative article! Your attention to detail and thorough research really shines through in your writing.

 

Mahindra Trucks

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
 
 
 
 

[HFR Private 5G: my5G]

 

Details >>

 

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

View All (854)
4.5G (1) 5G (101) AI (7) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) BSS (1) Big Data (2) Billing (1) Blockchain (3) C-RAN/Fronthaul (18) CDN (4) CPRI (4) Carrier Ethernet (3) Charging (1) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (56) KT (43) Korea (20) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (4) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slice (1) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) Private 5G (10) QoS (3) RCS (4) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password