Whenever applications are deployed to multiple locations (physical or virtualized data centers and/or public cloud), some mechanism is required to distribute the user requests for content across all application instances to provide optimal experience. The applications may be in the same geographical location or in different geography.
GSLB is the act of redirecting users requesting content to specific application instances that are closest to users based on some distribution logic. While there are several use cases for GSLB in application environments, GSLB is most commonly are implemented to achieve one or more of the following goals for an application:
- Reduced latency to users in geographically distributed locations by optimizing request distribution
- Offer tolerance across application, network or data center failures
- Enable non-disruptive migration to another cloud and other data centers
GSLB, traditionally a DNS-based user redirection, allows service providers to optimize resource use, maximize throughput, minimize response time, and avoid overload of any computing resource. A GSLB device performs global server selection to direct client traffic to the best server for a given domain during the initial client connection.
In this example, a client is using a web browser to view Example Inc. at “www.example.com”. The Example Inc. has two web sites: one in San Jose and one in Denver, each with identical content and available services.
Both Web sites have a load balancer configured for GSLB, with domain name set to www.gslb.example.com.” These devices are also configured as the Authoritative Name Servers for “www.example.com.”
The master DNS server on Example Inc. is configured to delegate “www.example.com” to “www.gslb.example.com”.
The DNS resolution for this GSLB configuration is as follows:
- The client web browser requests the “www.example.com” IP address from the local DNS.
- The client’s DNS asks its upstream DNS, which in turn asks the next, and so on, until the address is resolved. Eventually, the request reaches an upstream DNS server that has the IP address information available or the request reaches one of the Example Inc. DNS servers.
- The Example Inc.’s San Jose DNS tells the local DNS to query the load balancer with GSLB software as the authoritative name server for “www.example.com”.
- The San Jose load balancer responds to the DNS request, listing the IP address with the current best service. Each load balancer with GSLB software is capable of responding to the client’s name resolution request. Since each load balancer regularly checks and communicates health and performance information with its peers, either load balancer can determine which sites are best able to serve the client’s web access needs. It can respond with a list of IP addresses for the Example Inc.’s distributed sites, which are prioritized by proximity, performance, geography, and other criteria. In this case, the San Jose load balancer knows that Example Inc. Denver currently provides better service, and lists Example Inc. Denver’s virtual server IP address first when responding to the DNS request.
- The client connects to Example Inc. Denver for the best service.
If the site serving the client HTTP content suddenly experiences a failure (no healthy real servers) or becomes overloaded with traffic (all real servers reach their maximum connection limit), The load balancer issues an HTTP redirect and transparently causes the client to connect to another peer site. The result is that the client gets quick, reliable service with no latency and no special client-side configuration.
GSLB allows service providers to enhance users’ experiences by reducing response times. At the same time, providers deploying GSLB benefit by increasing service availability while reducing expensive data connections by directing users to the best site by intelligently monitoring site’s health, proximity and response time.
For more details:
Read “Flexibility Is The Name of the Game” to learn more.
Prakash Sinha is a technology executive and evangelist for Radware and brings over 29 years of experience in strategy, product management, product marketing and engineering. Prakash has been a part of executive teams of four software and network infrastructure startups, all of which were acquired. Before Radware, Prakash led product management for Citrix NetScaler and was instrumental in introducing multi-tenant and virtualized NetScaler product lines to market. Prior to Citrix, Prakash held leadership positions in architecture, engineering, and product management at leading technology companies such as Cisco, Informatica, and Tandem Computers. Prakash holds a Bachelor in Electrical Engineering from BIT, Mesra and an MBA from Haas School of Business at UC Berkeley.