Do you know where crisis hits next? Be prepared with GSLB (Global Server Load Balancing)

Did you know that in 2017 British Airways experienced a massive IT failure during one of the busiest travel weekends in the United Kingdom? This event created a nightmare scenario for the organization and its customers. Altogether, it grounded 672 flights and stranded tens of thousands of customers.
According to the company, the outage occurred when an engineer disconnected the data center’s power supply. A massive power surge came next, bringing the business’s network down in the process (Ref – https://www.theguardian.com/business/2017/may/31/ba-it-shutdown-caused-by-uncontrolled-return-of-power-after-outage).

In 2011 the entire nation of Armenia lost internet connectivity for up to 5 hours when a 75-year-old woman digging for scrap metal and accidently sliced through an underground cable (Ref- https://www.theguardian.com/world/2011/apr/06/georgian-woman-cuts-web-access Correct Infrastructure planning matters. When your network or applications unexpectedly fail or crash, IT downtime can have a direct impact on your bottom line and ongoing business operations. In some extreme cases, data and monetary losses from unplanned outages can even cause a company to go out of business! According to Gartner (Ref – blogs.gartner.com/andrew-lerner/2014/07/16/the-cost-of-downtime/), the average cost of IT downtime is $5,600 per minute. Because there are so many differences in how businesses operate, downtime, at the low end, can be as much as $140,000 per hour, $300,000 per hour on average, and as much as $540,000 per hour at the higher end. We should assume that numbers will go high with the fast adoption of digital transformation.

While you can’t completely eliminate downtime, you can reduce its severity. To be truly prepared, businesses must ensure their IT architecture has flexibility, security and resilience built in. Part of that involves redundant network planning in which Global Server Load Balancing (GSLB) is playing a great role. GSLB is a method of distributing traffic amongst servers potentially dispersed across multiple geographies. The servers can be located either on-premise in a company’s own datacenter or hosted in a cloud (public cloud or private cloud). Distributing content across geographies and services using several criteria’s such as site health, site proximity and content response time which offers several advantages, including:

• Allowing users to be automatically directed to content from servers located in their own geographic region thus reducing response times and decreasing the use of expensive international data connections.
• Directing users away from congested networks and servers, enhancing the users’ experience.
• Increasing fault-tolerance and availability by allowing multi-site content and service deployment, guarding against failures in the event of local or regional network outages, power outages or natural disasters.

How can British Airways or the Nation of Armenia be prepared and prevent the network downtime by deploying GSLB?

GSLB Active-Passive Scheme for Disaster Recovery:
Common practice is to deploy server resources at multiple locations, primarily for enabling disaster recovery. “Active passive” is the most common scheme used. The active location is used to serve the data, which is duplicated on “passive” or “recovery” sites. If the active site fails, the standby locations come into play. In this scenario the role of the GSLB would be to simply detect the failure at the active site and divert requests to the passive sites automatically. In addition, “Active-Active” is another scheme where you can distribute the load between different locations.

How does GSLB work?
When client Z loads their browser and enters the URL: http://www.radware.com (see Figure below), the system sends a DNS getByHostname query to the client’s local DNS server, asking for the IP address that represents www.radware.com. The local DNS server examines its DNS cache to determine if it already knows about this particular domain name and host. If it doesn’t, the local DNS server hands the request off to the appropriate upstream DNS server.
The DNS query is either responded to by an upstream DNS server’s cache or is passed on until the request arrives at a DNS server embedded in one of the Alteon ADC’s at site A, B, or C (in this case site A). Which site ultimately receives the request is determined by a myriad of DNS configuration parameters.
The Alteon ADC at site A, B and C are configured to be “distributed sites” and all can act as Authoritative Name Servers for the domain www.radwarealteon.com. Each can respond directly to DNS queries with IP addresses that represent that domain.
For example, if site A receives the DNS query, the IP address that site A returns represents a Virtual IP (VIP) address for one of the sites hosting the requested content (in this case site B).

In the example above, assume that site A returns the IP address of site B (172.176.110.20). The client receives the DNS query response from its local DNS server indicating that site B (172.176.110.20) is the IP address for www.radwarealteon.com. It then opens a TCP Port 80 connection to site B (172.176.110.20), the VIP address running at site B. Now, the client is communicating with the Alteon ADC exposing content form the Web site at site B.
So, how did site A determine that site B was the right site to handle the client’s request? How is site B “better” than the other two sites, including the one that responded to the DNS query?
As mentioned above with GSLB, three criteria are used to determine to which site DNS will direct the client:

1. Site health
2. Geographic location of the client and sites(s)
3. Measured site load and response time

GLSB provides the list of IPs per the criteria above that DNS uses when responding to client requests. What happens if the site to which the client has been pointed suddenly experiences a failure or is overloaded? Assuming the Alteon ADC running GSLB and its Internet connection are up, it issues an HTTP Redirect back to the client, telling it to go to a different site. This occurs when a VIP no longer has any healthy real IP addresses (RIPs) or when an HTTP request is sent to real servers that have reached their respective maximum connection thresholds.
What to look for in a global load balancing/disaster recovery solution:

1. Local server load balancing, global server load balancing, application redirection, and Layer 2-3 switching within a single platform. This enables additional applications such as Web cache redirection, DNS redirection, firewall load balancing, IPS load balancing and router load balancing.
2. GSLB directs users to the best performing sites within a geographic region. Competitive solutions that rely on metrics such as router hops fail to consider important factors such as networks congestion and server load when making their load balancing decisions.
3. Intelligent load distribution funnels most traffic to the best performing sites without overwhelming them. All resources are effectively used, improving the user’s experience.
4. Users are automatically redirected to the next best site when all servers at a site are down or congested, improving service and content availability.

Summary
Global Server Load Balancing (GSLB) allows Web hosts, portals, and enterprises to enhance users’ Web experiences by reducing response times and increasing service and application availability. At the same time, organizations deploying GSLB benefit through the decreased use of expensive international data connections. GSLB is a software capability on Alteon Application Delivery Controller. GSLB running on these ADC’s directs user requests to the “best site” to service the requests, where the “best site” is intelligently determined by monitoring site health, site proximity and response time.

For more information
If you are wondering how, you can deploy a GSLB with Alteon ADC and get the benefit from the full feature set of Alteon, go here for more information and please feel free to contact one of our ADC professionals here.