HAProxy Enterprise Documentation 2.5r1

Enable GSLB failover

While you can use geolocation-based load balancing to route traffic to the datacenter nearest to the client, you can also use HAProxy Enterprise for basic failover and failback between datacenters without the geolocation component. If a critical resource fails and service is disrupted, traffic is automatically redirected to healthy datacenters. This minimizes impact and avoids intervention.

Normal operation

Failover

I

A client asks for the IP address associated with the www.example.com domain name.

A

A client for the IP address associated with the www.example.com domain name.

II

HAProxy Enterprise returns the IP address of the first datacenter on the list since it is up and running.

B

HAProxy Enterprise returns the IP address of the next healthy datacenter on the list.

III

The client is directed to the first datacenter on the list.

C

The client is directed to the next healthy datacenter on the list.

  1. Edit the configuration file at /etc/hapee-extras/hapee-gslb.conf.

    Add a new list record directive to the zone section. This type of record specifies a list of space-separated answer-list names. Essentially, you are specifying datacenters in order of preference, with fallback datacenters following primary datacenters.

    The list record www enumerates two answer-list sections, DC1 and DC2, where DC1 is the primary datacenter and DC2 is the fallback. You could list additional fallback datacenters too.

    zone example.com
  ttl 10

  # ORIGIN records
  record @ SOA ns1.example.com hostmaster.example.com 1 86400 3600 3600 3600 60
  record @ NS  ns1.example.com
  record @ ttl 3600 MX 100  mail1.example.com

  # static records
  record ns1   ttl 10 A 10.0.0.1
  record mail1 ttl 10 A 10.0.0.2

  # dynamic records - DC1 is primary, DC2 is a fallback
  record www ttl 30 list DC1 DC2

  2. Create answer-list sections that match the names you listed on the list record in the zone section.

    We define two answer-list sections named DC1 and DC2. These return DNS records to the client for different datacenters.

    zone example.com
  ttl 10

  # ORIGIN records
  record @ SOA ns1.example.com hostmaster.example.com 1 86400 3600 3600 3600 60
  record @ NS  ns1.example.com
  record @ ttl 3600 MX 100  mail1.example.com

  # static records
  record ns1   ttl 10 A 10.0.0.1
  record mail1 ttl 10 A 10.0.0.2

  # dynamic records
  record www ttl 30 list DC1 DC2

answer-list DC1
  up_threshold 1
  method multi-up
  option httpchk
  http-check connect
  http-check send uri /health.html hdr host www.example.com
  http-check expect status 200,301,302
  answer-record srv1 20.0.0.1

answer-list DC2
  up_threshold 1
  method multi-up
  option httpchk
  http-check connect
  http-check send uri /health.html hdr host www.example.com
  answer-record srv1 30.0.0.1

    The answer-list section directives syntax is as follows.

    Directive

    Description

    up_threshold

    Determines the percentage of servers that must be up. Otherwise, traffic is routed to a different datacenter altogether. A threshold of 1 means that all servers in an answer-list must be healthy for the corresponding datacenter to be regarded as active. If you specify 0.1, then 10% of the total weighted number of servers must be up.

    method

    Determines which IP addresses to return. As with geolocation-based load balancing, you can:

    • return a single IP in a round-robin rotation (single-rr)

    • return multiple addresses in a round-robin rotation (method multi-rr)

    • return all servers that are up (method multi-up)

    • return all servers, even if they are down (method multi-all)

    option

    Specify httpchk to monitor the health of servers. To learn more about health checks, you can visit the define a health check section.

    http-check

    Set any relevant health check parameters.

    answer-record

    Enter any number of answer-record directives, which denote IP addresses assigned to the datacenter.

  3. Save your configuration, close the configuration editor, then restart the GSLB service.

    $ sudo systemctl restart hapee-extras-gslb

Health checks

You can configure which path should be used in your health checks. For example, the URL for health checks in the above example configuration will be /health.html. Ensure that the path used is valid or your health checks will fail, even if the server is healthy.

http-check send uri /health.html hdr host www.example.com

Testing

You can use the dig command to test implementation. For example, if your domain is example.com you can use dig www.example.com @127.0.0.1 -p 153 to test.

; <<>> DiG 9.10.6 <<>> A @127.0.0.1 -p 153 example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4343
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                    IN      A

;; ANSWER SECTION:
example.com.             139   IN      A       20.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#153(127.0.0.1)
;; WHEN: Tue Jul 03 23:27:15 UTC 2023
;; MSG SIZE  rcvd: 74

Next up

Geolocation-based load balancing