Search

Chapter 2. Defining the Default Configuration

download PDF

When creating and configuring an Overcloud without an external load balancer, the director configures HAProxy to distribute traffic to multiple OpenStack services. The director provides this configuration in the /etc/haproxy/haproxy.conf file on each Controller node. The default configuration contains three main parts: global, defaults, and multiple service configurations.

The next few sections examine the default parameters from each configuration section. This provides an example of the configuration settings for installing and configuring your external load balancer. Note that these parameters are only a fraction of the total HAProxy parameters. For details about these and other parameters, see the "HAProxy Configuration Manual" located in /usr/share/doc/haproxy-*/configuration.txt on the Controller nodes (or any system where the haproxy package is installed).

2.1. Global Configuration

global
  daemon
  group  haproxy
  log  /dev/log local0
  maxconn  10000
  pidfile  /var/run/haproxy.pid
  user  haproxy

This section defines a set of process-wide parameters. This includes the following:

  • daemon: Run as a background process.
  • user haproxy, group haproxy: Defines the Linux user and group that owns the process.
  • log: Defines syslog server to use.
  • maxconn: Sets the maximum number of concurrent connections to the process.
  • pidfile: Sets file to use for the process IDs.

2.2. Defaults Configuration

defaults
  log  global
  mode  tcp
  retries  3
  timeout  http-request 10s
  timeout  queue 1m
  timeout  connect 10s
  timeout  client 1m
  timeout  server 1m
  timeout  check 10s

This section defines a default set of parameters for each service. This includes the following:

  • log: Enables logging for the service. The global value means that the logging functions use the log parameters in the global section.
  • mode: Sets the protocol to use. In this case, the default is TCP.
  • retries: Sets the number of retries to perform on a server before reporting a connection failure.
  • timeout: Sets the maximum time to wait for a particular function. For example, timeout http-request sets the maximum time to wait for a complete HTTP request.

2.3. Services Configuration

listen ceilometer
  bind 172.16.20.250:8777
  bind 172.16.23.250:8777
  server overcloud-controller-0 172.16.20.150:8777 check fall 5 inter 2000 rise 2
  server overcloud-controller-1 172.16.20.151:8777 check fall 5 inter 2000 rise 2
  server overcloud-controller-2 172.16.20.152:8777 check fall 5 inter 2000 rise 2

There are multiple service configuration sections in the default file. Each service configuration includes the following:

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

The example above shows the HAProxy settings for the ceilometer service. This services identifies the IP addresses and ports on which the ceilometer service is offered (port 8777 on 172.16.20.2500 and 172.16.23.250). HAProxy directs the requests made for those addresses to overcloud-controller-0 (172.16.20.150:8777), overcloud-controller-1 (172.16.20.151:8777), or overcloud-controller-2 (172.16.0.152:8777).

In addition, the example server parameters enable the following:

  • check: Enables health checks
  • fall 5: After five failed health checks, the service is considered dead.
  • inter 2000: The interval between two consecutive health checks set to 2000 milliseconds (or 2 seconds).
  • rise 2: After two successful health checks, a server is considered operational.

Each service binds to different addresses, representing different network traffic types. Also some services contain additional configuration options. The next chapter examines each specific service configuration so that you can replicate these details on your external load balancer.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.