GSLB Overview #
Nowadays, the high availability of IT services is a must and that is the reason that companies and organizations develop computing systems distributed around the world and host services in more than one Data Center, as it offers the following benefits:
Fault tolerance: when the hosted service in the data center fails the service goes on in any of the other available sites.
Automatic data center recovery: when one data center fails the service is redirected automatically to any other available data center.
Load Balancing: the traffic could be optimized by distributing the load among all the sites available improving the latency and make the service delivery faster.
Improved Latency: the client application traffic is directly with the real server, no need to pass all the application data through the load balancer.
The adoption and implementation of IT services in the Cloud requires that a method based on WAN is the best option to provide Geo-located high availability solutions. That is what we call Global Service Load balancing or GSLB.
When to use GSLB #
The GSLB service is recommended to be used for the following use cases:
Companies that host their services in more than one data center through WAN.
Companies that requires to create high availability of services or data centers.
Internet Service Providers to create inbound load balancing services to be used by their users.
Definitely, when it’s required to share users and traffic between servers around the world without points of failure GSLB is the right solution.
How does GSLB work #
GSLB is a load balancing mechanism upon DNS protocol, it is fast and reliable because it uses UDP protocol and the client response is almost in real time.
In a common DNS request, for example www.zvnlb.net, a client sends the DNS request resolution to the local configured DNS servers ( for example 8.8.8.8 and 8.8.4.4 ) and then the client system selects randomly one of the servers to make against the request and to send the query.
The selected DNS server receives the request from the client ( for example, what is the IP address of www.zvnlb.net? ) and the local configured DNS servers try to find who is responsible to resolve the DNS zone zvnlb.net.
The DNS used by the client, 8.8.8.8 or 8.8.4.4 in this case, detects that ns1.zvnlb.net and ns2.zvnlb.net are responsible of zone resolutions for zvnlb.net so they send the DNS query received by the client ( for example, what is the IP address of www.zvnlb.net? ) to one of them.
One of the name servers either ns1.zvnlb.net or ns2.zvnlb.net receives the DNS query from 8.8.8.8 or 8.8.4.4 and then, the name server which receives the request, checks the available servers for the host www.zvnlb.net and it will respond to the DNS query with the list of available application servers to serve the real application for the host www.zvnlb.net, hence this information will be finally received by the client.
Now the client will select randomly one of the application servers from the list received in the DNS query and it will send directly the request to the application http://www.zvnlb.net.
The name servers ns1.zvnlb.net (in our example, located in Frankfurt) and ns2.zvnlb.net (in our example, located in Toronto) are steadily checking the health status of the real application of the host www.zvnlb.net (192.235.113.3 and 194.23.52.21 in our case). If ns1.zvnlb.net or ns2.zvnlb.net detects any problem checking the health status of some of the real servers, then the unavailable server will be deactivated for a certain time and its IP address will not be listed in the DNS queries until it becomes available again.
The following diagram shows the described DNS traffic with GSLB capabilities.
Configuring GSLB for Disaster Recovery of data centers #
This configuration is recommended for services that requires high availability of Data Centers for Disaster Recovery, so if all the services of a certain company are in one data center and such data center fails then the system will move all the affected services to another available data center.
Please follow this real example of GSLB configuration to build an active-passive data center for Disaster Recovery.
We have deployed two RELIANOID Load Balancers across two data centers in different sites, Frankfurt 159.89.7.124 and Toronto 159.203.12.35 and we have a web service that responds to the DNS host www.zvnlb.net, configured in Data Center 1 and Data Center 2. The design of this architecture is going to permit to send all the clients traffic to the Data Center 1 but if it fails then redirects the clients to Data Center 2.
In order to achieve this configuration follow the procedure below.
Connect to the RELIANOID web panel in the Data Center 1 (Frankfurt for our case), click in the main menu GSLB module and create a new Farm, in our example will be called DNS1-Frankfurt in the virtual port 53.
Once the farm is created, please edit it, and go to the tab Zones and create the DNS zone that is going to be managed by the GSLB module, in this case zvnlb.net, as follows:
Once this zone had been created please make the first configuration as it’s shown below:
Note that ns1 and ns2 are the Name Servers responsible of the DNS resolutions for the zone zvnlb.net (in our case, one GSLB service in Frankfurt and another in Toronto).
Then, connect to the RELIANOID web panel in the Data Center 2, in the main menu select GSLB and create a new Farm, in our case will be called DNS2-Toronto in the virtual port 53.
Edit the new GSLB farm and go to the tab Zones, create here the DNS zone that is going to be managed by this GSLB service for zvnlb.net as follows:
Once this new zone is created please make the first configuration as follows:
Like the case of the GSLB in the Data Center 1, the Name Servers n1 and n2 will point to the GSLB services in both Data Center 1 and Data Center 2, respectively.
Then click in the tab Services and create a new service, for example webpriority:
Select the Algorithm option Priority: Connections always to the most prio available and configure the service as follows:
Restart the farm to apply the changes. It’s required to apply the same GSLB service configuration in both data centers.
Note that if Farm Guardian is not configured to apply any health check, the GSLB service uses a default check_tcp to the TCP port defined in the health check field in the service configuration.
To enable the new service, go to the zone created (zvnlb.net in our case) and create a new Resource. Then create it by selecting the new Service as it’s shown below.
Finally, save the changes. It’s required to apply this configuration in both Data Centers.
At this point, the host www.zvnlb.net is managed by the GSLB module in Priority mode, so all the traffic will be sent to the Data Center 1 and then, if it fails, the traffic will be redirected to the other available Data Center 2.
The TTL has been configured to 5, it is the sort of expiration date that is put on a DNS record. The TTL serves to tell the recursive server or local resolver how long it should keep said record in its cache. So a lower value configured faster the changes are detected.
Applying this method we could add as many data centers as needed by including new Name Servers with GSLB service.
The following DNS request shows the Nameservers configuration for zvnlb.net and the DNS resolution for the host www.zvnlb.net.
user@client:# host -t ns zvnlb.net zvnlb.net name server ns2.zvnlb.net. zvnlb.net name server ns1.zvnlb.net.
Both nameservers use the virtual IP addresses configured in the GSLB farms.
Now, use your current DNS servers to resolve a host (for example www) in this zone:
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 188.166.230.211
As it is shown, currently the host 188.166.230.211 is the active real application node in the Data Center 1. As soon the host is not reachable (for example, the http service in 188.166.230.211 is down) the DNS resolution will change as it’s shown below.
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 139.59.186.84
As soon as the application server fails, the DNS resolution will change the host to the Data Center 2. Once the host in the Data Center 1 is up the fail-back will be applied automatically.
Configuring GSLB for active-active data centers #
The high availability with the mode priority is a good option for a Disaster Recovery system but the backup Data Center that it’s used for the recovery doesn’t have too much usage, so usually it’s more efficient to load balance all the traffic between the available data centers.
For such cases, please use the sharing method for your GSLB service called Round Robin Load Balancing as it’s shown in the example for the new service called web:
Now, add it in the zone zvnlb.net and change the resource configuration www as follows:
Save the changes and restart the farm if requested.
To test it, try to resolve the host www.zvnlb.net and the output will look like it’s shown:
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 188.166.230.211 Name: www.zvnlb.net Address: 139.59.186.84
Note that the DNS resolver returns both application servers instead of one like the Disaster Recovery case.
Once the host has a failure, the DNS resolution will change automatically. See below what happens.
root@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 139.59.186.84
The unavailable application server is deactivated from the DNS response list.
As soon as the host 188.166.230.211 is available again, it will be included back in the DNS resolution.
Delegating a zone in the RELIANOID GSLB service #
In the case of a public zone (for example zvnlb.net) which delivers a GSLB service as a name server resolver that needs to be recognized by public DNS servers for such domain, then it’s required to register the public IP address used by the GSLB service in your domain’s registrar (like NameCheap, Goddady or others). The following link explains how to register GSLB IPs as NameServers in a Domain Registrar Procedure.
Register a Host as a NameServer
Following the given procedure you have to register ns1.zvnlb.net and ns2.zvnlb.net with the given IPs.
Creating a dedicated subzone for GSLB #
Just in case it’s not possible to delegate the DNS resolution to the GSLB service of RELIANOID, the configuration explained below could be performed. The following example shows how to build a subzone for zvnlb.net that points to the NameServers of this new subzone in the GSLB service.
Node 1 (for example ns1.zvnlb.net with IP 162.243.5.109) and Node 2 (for example ns2.zvnlb.net with IP 178.62.233.104) are Nameservers configured and offering DNS resolution services for the zone zvnlb.net, this zone is under a Bind9 public DNS service and we want to offer GSLB capabilities for some hosts of our infrastructure, so we decided to create the DNS subzone cluster.zvnlb.net and configure 2 GSLB farms like DNS Nameservers for this purpose.
We have created the subzone for our domain cluster.zvnlb.net in our Bind9 DNS Servers as follows:
Now follow the section Delegating a zone in the RELIANOID GSLB service in order to keep 159.89.7.124 and 159.203.12.35 in our example as a recognized nameservers for the zone cluster.zvnlb.net by public DNS Servers.
Then, you can apply the configuration like is explained for the domain zvnlb.net in the section above Configuring GSLB for disaster recovery of data centers.
Pointing a Host in our own DNS referenced to a GSLB service #
In the previous sections we have created a host named www.zvnlb.net load balancing in priority and round robin modes, so we can reuse this configuration in order to offer GSLB capabilities to another DNS Nameserver which doesn’t support this feature by default.
In order to achieve this configuration we only have to create a new Resource in the DNS zone that doesn’t support GSLB options (for example relianoid.io is managed by Bind9) like a Canonical Name or CNAME as it’s show below:
Once the change is applied, www.relianoid.io will be pointing to www.zvnlb.net, but if the host resolution www.zvnlb.net changes then automatically www.relianoid.io will change as well.
Note that this example is done in a Bind9 DNS server but Canonical Names or CNAMES are DNS host configurations supported by any DNS server service implementation.
This simple explanation shows that a GSLB service can be used even if our current DNS Service doesn’t offer GSLB capabilities, just only forwarding the resolution of the given host in a non GSLB zone to the GSLB service in RELIANOID Load Balancer.
