What is GSLB and how does it work ?
Global Server Load Balancing (GSLB) is a method of directing traffic across multiple networks, be it on the same site, or on the other side of the world. GSLB can be used to load balance across two separate networks, where there are no VLANs in place, stretched or otherwise.
This is done using DNS. DNS is the query your PC makes when trying to access a web page such as www.google.com. When this query cannot be answered by normal DNS servers they pass on the query to an authoritative DNS server or servers for the domain in question. This authoritative DNS server is our GSLB, which then provides an answer based on the configured load balancing policy. For example; if a “city match” policy is being used, it will detect the source IP of the client and provide an answer to the client which directs them to the nearest data center.
So what can you do with GSLB?
GSLB for Geo-Location
Acting as a bridge between two or more sites, GSLB can deliver a host of high-availability and routing benefits. A particularly powerful example is using Geo-Location to determine where to send application traffic. If a user were to access a website in London, GSLB can use Geo-Location to send the user to the London data center.
This is achieved by deploying an active-active scenario, where the GSLB can make a routing decision according to the policy set. This results in faster connections and gives much more control in service delivery, allowing for different websites or content to be served depending on the country. (A bit like how Netflix has different shows available depending if you are stateside or not.) This means you can display a website by default in a different language, as GSLB can see where the request has come from and serve the most relevant one to the source IP’s location.
With the edgeNEXUS GSLB you get the flexibility to set the rules on how you want to direct the traffic, we go from continent match all the way down to city match, so we can send the traffic to the nearest location, no matter how far the sites are from one another.
GSLB for Disaster Recovery
Maintaining a solid disaster recovery strategy is a must for every company, especially where multiple data centers are involved. GSLB is an incredibly efficient way to handle disaster recovery, failing over from one data center to the other in the event of a problem or outage. The whole transition is seamless to the end user, as it should be.
edgeNEXUS GSLB does this using an active-passive deployment scenario. In the event your main site fails, the GSLB will detect this and move it to the defined data center(s) of your choosing.
Ultimate flexibility in your service delivery
You can deploy a GSLB anywhere; the cloud, at your data centers or at any other location that suits your environment. We can also add custom locations for private IP address ranges if you have the need to send internal users to specific services based on their location.
Even if you just want to keep the systems balanced across your data centers, we can use a feature to weight where the traffic goes to, if you know you have a lot more grunt in your London data center for instance, we can increase the weighting so more traffic is sent there. If you combine this with local load balancers, downtime should become a thing of the past.
Why doesn’t everyone use GSLB? What are the drawbacks?
GSLB allows you to load balance over multiple networks where stretched VLANS and other methods are not available, but GSLB is not as fluent or efficient as server load balancing. This Achilles heel is down to the way in which DNS works.
A GSLB acts as an authoritative name server for a particular domain. The client’s DNS request is passed to various DNS servers until it reaches one that has the ability to answer the request. This, in theory, is all okay but in practice is hampered by caching the result on the client or DNS server for a certain amount of time. Caching is not a bad thing in general as it prevents lots of usually unnecessary traffic generated by clients.
In our scenario caching results in the failover not being instantaneous as with normal load balancing. The minimum value we can set is 60 seconds, but this may be ignored by other DNS servers or DNS clients who strive to make systems more efficient by caching results for longer. This means the fail over is typically never faster than what is known as the Time To Live (TTL) value of a record. In the event of a disaster recovery situation, it may be 60 seconds before traffic will be re-directed to a different site. However, on balance, it is still preferable for your clients to suffer a 60 second delay than to be locked out of their applications for far longer.
Many companies provide GSLB, so why choose edgeNEXUS?
Quite simply, the jetNEXUS GSLB is easy to use. You don’t need to spend hours trying to configure it using command line and manually adding each site. We use the rest API of the load balancer to retrieve data from a Virtual Service and configure this automatically on the GSLB. This makes it easy to configure and get up and running, without requiring a degree in networking.
It’s true, all major players in load balancing have GSLB either built in or as an extra, so why wouldn’t you choose them? Well, aside from simplicity we offer GSLB for a fixed price, this means you could have 50 users, or 50,000 and the cost per GSLB instance remains the same. You can therefore scale up your business without incurring penalties along the way. Alternative solutions can charge for each additional piece of functionality, be that a health check or a traffic manipulation rule. We don’t have additional charges, enabling you to add as many features as you require and we will not penalize you for it, we want you to expand!
For more information on edgeNEXUS GSLB click here.
To check our free 14 day trial click here.
For more information on the technicalities please see our full guide on our app store.
