GSLB – Why Global Server Load Balancers don't always suck? (Polaris-GSLB)

GSLB Published on 4 mins Last updated

UPDATE - December 2017: Just for your information - we've finally found a decent reason to use GSLB!

Here at 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:

Okay so we have an FQDN we want to perform GSLB against “”. 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.


There is a lovely open source project on GitHub called Polaris-GSLB, you can find out more about it here :

It allows us to perform health checks to test availability, define topologies to serve up local results for local clients and perform load balancing across multiple sites!

Let’s have a look at the config required for our above scenario :


        monitor: http
        use_ssl: true
        url_path: /MY/SERVICE/URI/
    lb_method: twrr
    fallback: any
    - ip:
    name: dover-office
    weight: 1
    - ip:
    name: kent-office
    weight: 1
    - ip:
    name: dr-site
    weight: 1

        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:



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 

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 @ +norec

; <<>> DiG 9.11.0-P1 <<>> @ +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1680
; IN A


;; Query time: 22 msec
;; 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 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 :

Once done when you perform a lookup for 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