Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

Chapter 5. Using HAProxy

HAProxy provides high-availability features to OpenStack by load-balancing traffic to controllers running OpenStack services. The haproxy package contains the haproxy daemon, which is started from the systemd service of the same name, along with logging features and sample configurations. As noted earlier, Pacemaker manages the HAProxy service itself as a highly available service (haproxy-clone).

Note

Refer to the KCS solution How can I verify my haproxy.cfg is correctly configured to load balance openstack services? for information on validating an HAProxy configuration.

In Red Hat OpenStack Platform, the director configures multiple OpenStack services to take advantage of the haproxy service. The director does this by configuring those services in the /etc/haproxy/haproxy.cfg file. For each service in that file, you can see:

  • listen: The name of the service that is listening for requests
  • bind: The IP address and TCP port number on which the service is listening
  • server: The name of each server providing the service, the server’s IP address and listening port, and other information.

The haproxy.cfg file created when you install Red Hat OpenStack Platform with the director identifies 19 different services for HAProxy to manage. Here’s an example of how the horizon listen service is configured in the haproxy.cfg file: 

 listen horizon
  bind 172.17.0.19:80 transparent 1
  bind 172.20.0.200:80 transparent 2
  mode http 3
  cookie SERVERID insert indirect nocache
  option forwardfor
  server overcloud-controller-0.internalapi.localdomain 172.17.0.21:80 check cookie overcloud-controller-0 fall 5 inter 2000 rise 2 4
  server overcloud-controller-1.internalapi.localdomain 172.17.0.18:80 check cookie overcloud-controller-0 fall 5 inter 2000 rise 2
  server overcloud-controller-2.internalapi.localdomain 172.17.0.13:80 check cookie overcloud-controller-0 fall 5 inter 2000 rise 2
1
Virtual IP address and port on the Internal API network to use inside the overcloud.
2
Virtual IP address and port on the External network that provides access to the API network from outside the overcloud.
3
Type of protocol that the network uses to send and receive information, in this case http
4
Controller node that can accept direct requests from the listed IP addresses. In this case, three controller nodes are available: overcloud-controller-0.internalapi.localdomain, overcloud-controller-1.internalapi.localdomain, and overcloud-controller-2.internalapi.localdomain. The health check is set to run until either two successful attempts (rise 2) or five unsuccessful attempts (fail 5).

Here is the list of services managed by HAProxy on the controller nodes:

Table 5.1. Services managed by HAProxy

ceilometer

cinder

glance_api

glance_registry

haproxy.stats

heat_api

heat_cfn

heat_cloudwatch

horizon

keystone_admin

keystone_public

mysql

neutron

nova_ec2

nova_metadata

nova_novncproxy

5.1. HAProxy Stats

The director also enables HAProxy Stats by default on all HA deployments. This feature allows you to view detailed information about data transfer, connections, server states, and the like on the HAProxy Stats page.

The director also sets the IP:Port address through which you can reach the HAProxy Stats page. To find out what this address is, open the /etc/haproxy/haproxy.cfg file of any node where HAProxy is installed. The listen haproxy.stats section lists this information. For example: 

listen haproxy.stats
  bind 10.200.0.6:1993
  mode http
  stats enable
  stats uri /

In this case, point your web browser to 10.200.0.6:1993 to view the HAProxy Stats page.

5.2. References

For more information about HAProxy, see HAProxy Configuration (from Load Balancer Administration).

For detailed information about settings you can use in the haproxy.cfg file, see the documentation in /usr/share/doc/haproxy-VERSION/configuration.txt on any system where the haproxy package is installed (such as Controller nodes).