UPDATE - December 2017: Just for your information - we've finally found a decent reason to use GSLB!
Here at Loadbalancer.org we’re not known for being huge fans of GSLB solutions as some of our customers may already know and you can see from a previous blog : GSLB – Why Do Global Server Load Balancers Suck?
Everything said in that Blog is true and said with good intentions, but reading it it’s very much targeted at public facing GSLB solutions serving up websites. For example we reference using CDN’s as a better solution and talk about troubles with routing to the closest location(Geo Location). This sort of stuff is great for my e-commerce site but not so useful when dealing with enterprise applications for corporate users, what use is a CDN for connecting Outlook users to Exchange for example. We also omit to mention another really useful component of a proper GSLB, Health Checks. It’s all well and good configuring multiple A records, but these A records will still be served to clients when an endpoint is down unless you come up with an alternative, possibly home brew solution, to check availability and dynamically update your DNS...
Later we decided to leverage cloud based GSLB solutions so we could assist customers when they have these requirements, we’ve worked with Route 53 which is truly an amazing solution from Amazon as well as other providers successfully.
What we don’t have however, is a solution for when you want to do this internally amongst your own sites and say a DR location or for when you just want to manage it yourself without relying on external providers.
Consider the following requirement (click to enlarge):
Okay so we have an FQDN we want to perform GSLB against “myservice.mydomain.com”. We have 3 sites, the first 2 are offices which have local clients and servers. The 3rd site is our DR location where we have a mirror of the servers from the first 2 sites. What we really want is for users in Dover and Kent to use their local provision unless of course it’s failing health checks in which case we want them to use one of the remaining available sites.
Solution
There is a lovely open source project on GitHub called Polaris-GSLB, you can find out more about it here : https://github.com/polaris-gslb/polaris-gslb/wiki/Overview
It allows us to perform health checks to test availability, define topologies to serve up local results for local clients and perform load balancing of up to 32 endpoints!
Let’s have a look at the config required for our above scenario :
/opt/polaris/etc/polaris-lb.yaml
pools:
myservice-mydomain:
monitor: http
monitor_params:
use_ssl: true
hostname: myservice.mydomain.com
url_path: /MY/SERVICE/URI/
lb_method: twrr
fallback: any
members:
- ip: 10.1.1.10
name: dover-office
weight: 1
- ip: 172.16.1.10
name: kent-office
weight: 1
- ip: 1.2.3.4
name: dr-site
weight: 1
globalnames:
myservice.mydomain.com:
pool: myservice-mydomain
ttl: 1
First we have the polaris-lb.yaml config file where we can define pools and globalnames. Pools consist of endpoints, health checks and load balancing information such as weights and scheduler type. Globalnames is where we declare the FQDN’s we manage.
I wont repeat the information already provided by the Polaris-GSLB guys on this config file, you can find a full description of configuration options here: https://github.com/polaris-gslb/polaris-gslb/wiki/LB-configuration
/opt/polaris/etc/polaris-topology.yaml
Dover:
- 10.0.0.0/8
Kent:
- 172.16.0.0/16
DR:
- 1.2.3.4/32
Next we have the topology feature found in the polaris-topology.yaml which I think is really cool! You can tell Polaris what subnets relate to each location so local client requests can be served up local results unless of course health checks fail, neat huh? One thing to keep in mind is that for every endpoint you need a subnet configured in this file, I found for public IP addresses at the very least I had to provide a /32 subnet in here for the health check daemon to start.
Once your configuration files are setup you’ll want to start the health check daemon with the following command to load the config:
[root@gslb ~]# /opt/polaris/bin/polaris-health start
This is where the magic happens, it loads any configuration and starts the health checks.
Options include [status|start|start-debug|stop|restart].
To apply configuration changes you would issue a restart to the polaris-health service, restarts are seamless to the client so won’t affect frontend DNS resolution.
To monitor the status you can use:
[root@gslb ~]# /opt/polaris/bin/polaris-memcache-control 127.0.0.1
get-ppdns-state = shows the state table used for query distribution
get-generic-state = shows the full health table
Options include [get-generic-state|get-ppdns-state|get-heartbeat|check-heartbeat]
We can also test it’s working by running a command like the following :
[root@gslb ~]# dig myservice.mydomain.com @172.16.200.113 +norec
; <<>> DiG 9.11.0-P1 <<>> myservice.mydomain.com @172.16.200.113 +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;myservice.mydomain.com. IN A
;; ANSWER SECTION:
myservice.mydomain.com. 1 IN A 172.16.1.10
;; Query time: 22 msec
;; SERVER: 172.16.200.113#53(172.16.200.113)
;; WHEN: Tue Nov 15 12:55:09 GMT 2016
;; MSG SIZE rcvd: 60
Okay so you have your Polaris-GSLB configured and tested so what’s next? Well you’ll probably need to configure your existing DNS configuration to delegate myservice.mydomain.com to your GSLB(s).
This basically entails setting the nameservers that handle requests for our FQDN, for a brilliant example of how to do this for both Microsoft DNS and Bind check out this excellent article by Citrix :
https://support.citrix.com/article/CTX121713
Once done when you perform a lookup for myservice.mydomain.com we'll be getting the answers provided by Polaris.
That should be it, to learn how to install Polaris-GSLB on CentOS 7 please check out Part 2 : GSLB – Why Global Server Load Balancers Don’t Always Suck? (Polaris-GSLB) Part 2