Este conteúdo não está disponível no idioma selecionado.
Chapter 7. Example configuration: Overcloud with an external HAProxy load balancer
This example configuration shows an overcloud that uses a federated HAProxy server to provide external load balancing. You can choose a different external load balancer based on your environment requirements.
The example configuration includes the following elements:
- An external load balancing server that runs HAProxy.
- One Red Hat OpenStack Platform (RHOSP) director node.
- An overcloud that consists of 3 Controller nodes in a highly available cluster and 1 Compute node.
- Network isolation with VLANs.
The example uses the following IP address assignments for each network:
-
Internal API:
172.16.20.0/24
-
Tenant:
172.16.22.0/24
-
Storage:
172.16.21.0/24
-
Storage management:
172.16.19.0/24
-
External:
172.16.23.0/24
These IP ranges include IP assignments for the Controller nodes and virtual IPs that the load balancer binds to OpenStack services.
7.1. Example HAProxy configuration file Copiar o linkLink copiado para a área de transferência!
The example file shows the internal HAProxy configuration parameters. You can use the sample configuration parameters as a basis for configuring your external load balancer.
The HAProxy configuration file contains the following sections:
- Global configuration
- Defaults configuration
- Services configurations
Director provides this configuration in the /etc/haproxy/haproxy.conf
file on each Controller node for non-containerized environments, and in the /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg
file for containerized environments.
In addition to the global, default, and services parameters, you must also configure other HAProxy parameters. For more information about HAProxy parameters, see the HAProxy Configuration Manual located in /usr/share/doc/haproxy-*/configuration.txt
on the Controller nodes or on any system where the haproxy
package is installed.
Example HAProxy configuration file:
7.1.1. Global configuration parameters: Example HAProxy configuration file Copiar o linkLink copiado para a área de transferência!
The global configuration parameters section defines a set of process-wide parameters for the load balancer. You can use the example parameters from the configuration file to configure your external load balancer. Adjust these parameter values based on your environment:
The example shows the following parameters:
-
daemon
: Run as a background process. -
user haproxy
andgroup haproxy
: Define the Linux user and group that owns the process. -
log
: Defines the syslog server to use. -
maxconn
: Sets the maximum number of concurrent connections to the process. -
pidfile
: Sets the file to use for the process IDs.
7.1.2. Default values configuration parameters: Example HAProxy configuration file Copiar o linkLink copiado para a área de transferência!
The default values configuration parameters section defines a set of default values to use when running the external load balancer services. You can use the example parameters from the configuration file to configure your external load balancer. Adjust these parameter values based on your environment:
The example shows the following parameters:
-
log
: Enables logging for the service. Theglobal
value means that the logging functions use thelog
parameters from theglobal
section. -
mode
: Defines 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.
7.1.3. Service-level configuration parameters: Example HAProxy configuration file Copiar o linkLink copiado para a área de transferência!
The service-level configuration parameters section defines a set of parameters to use when load balancing traffic to a specific Red Hat OpenStack Platform (RHOSP) service. You can use the example parameters from the configuration file to configure your external load balancer. Adjust these parameter values based on your environment, and copy the section for each service that you want to load balance.
This example shows the configuration parameters for the ceilometer
service.
Each service that you want to load balance must correspond to a section in the configuration file. Each service configuration includes the following parameters:
-
listen
: The name of the service that listens for requests. -
bind
: The IP address and TCP port number the on which the service listens. Each service binds a different address that represents a different network traffic type. -
server
: The name of each server that provides the service, the server IP address and listening port, and connection parameters: -
check
: (Optional) Enables health checks. -
fall 5
: (Optional) After five failed health checks, the service is considered offline. -
inter 2000
: (Optional) The interval between two consecutive health checks set to 2000 milliseconds, or 2 seconds. -
rise 2
: (Optional) After two successful health checks, the service is considered operational.
In the ceilometer
example, the service identifies the IP addresses and ports on which the ceilometer service is offered as 172.16.20.2500:8777
and 172.16.23.250:8777
. HAProxy directs the requests 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).
7.2. Configuration parameters for services that use load balancing Copiar o linkLink copiado para a área de transferência!
For each service in the overcloud that uses load balancing, use the following examples as a guide to configure your external load balancer. Adjust the parameter values based on your environment, and copy the section for each service that you want to load balance.
Most services use the default health check configuration:
- The interval between two consecutive health checks set to 2000 milliseconds, or 2 seconds.
- After two successful health checks, a server is considered operational.
- After five failed health checks, the service is considered offline.
Each service indicates the default health check or additional options in the Other information section of that service.
aodh
Port number: 8042
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
ceilometer
Port number: 8777
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
cinder
Port number: 8776
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
glance_api
Port number: 9292
Binds to: storage, external
Target network or server: storage on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
glance_registry
Port number: 9191
Binds to: internal_api
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
listen glance_registry bind 172.16.20.250:9191 server overcloud-controller-0 172.16.20.150:9191 check fall 5 inter 2000 rise 2 server overcloud-controller-1 172.16.20.151:9191 check fall 5 inter 2000 rise 2 server overcloud-controller-2 172.16.20.152:9191 check fall 5 inter 2000 rise 2
listen glance_registry
bind 172.16.20.250:9191
server overcloud-controller-0 172.16.20.150:9191 check fall 5 inter 2000 rise 2
server overcloud-controller-1 172.16.20.151:9191 check fall 5 inter 2000 rise 2
server overcloud-controller-2 172.16.20.152:9191 check fall 5 inter 2000 rise 2
gnocchi
Port number: 8041
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
heat_api
Port number: 8004
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
- This service uses HTTP mode instead of the default TCP mode.
HAProxy example:
heat_cfn
Port number: 8000
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
heat_cloudwatch
Port number: 8003
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
horizon
Port number: 80
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
- This service uses HTTP mode instead of the default TCP mode.
- This service uses cookie-based persistence for interactions with the UI.
HAProxy example:
keystone_admin
Port number: 35357
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
keystone_admin_ssh
Port number: 22
Binds to: internal_api
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
listen keystone_admin_ssh bind 172.16.20.250:22 server overcloud-controller-0 172.16.20.150:22 check fall 5 inter 2000 rise 2 server overcloud-controller-1 172.16.20.151:22 check fall 5 inter 2000 rise 2 server overcloud-controller-2 172.16.20.152:22 check fall 5 inter 2000 rise 2
listen keystone_admin_ssh
bind 172.16.20.250:22
server overcloud-controller-0 172.16.20.150:22 check fall 5 inter 2000 rise 2
server overcloud-controller-1 172.16.20.151:22 check fall 5 inter 2000 rise 2
server overcloud-controller-2 172.16.20.152:22 check fall 5 inter 2000 rise 2
keystone_public
Port number: 5000
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
mysql
Port number: 3306
Binds to: internal_api
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check. However, the health checks use port 9200.
- This service is load balanced to only one server at a time.
- Each server is only used in load balancing only when all other non-backup servers are unavailable.
- If the server is offline, all connections are immediately terminated.
- You must enable the sending of TCP keepalive packets on both sides.
- You must enable HTTP protocol to check on the servers health.
- You can configure a stickiness table to store IP addresses, to help maintain persistence.
The mysql service uses Galera to provide a highly available database cluster. Galera supports an active-active configuration, but to avoid lock contention, you must use an active-passive configuration that is enforced by the load balancer.
HAProxy example:
neutron
Port number: 9696
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
nova_ec2
Port number: 8773
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
nova_metadata
Port number: 8775
Binds to: internal_api
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
listen nova_metadata bind 172.16.20.250:8775 server overcloud-controller-0 172.16.20.150:8775 check fall 5 inter 2000 rise 2 server overcloud-controller-1 172.16.20.151:8775 check fall 5 inter 2000 rise 2 server overcloud-controller-2 172.16.20.152:8775 check fall 5 inter 2000 rise 2
listen nova_metadata
bind 172.16.20.250:8775
server overcloud-controller-0 172.16.20.150:8775 check fall 5 inter 2000 rise 2
server overcloud-controller-1 172.16.20.151:8775 check fall 5 inter 2000 rise 2
server overcloud-controller-2 172.16.20.152:8775 check fall 5 inter 2000 rise 2
nova_novncproxy
Port number: 6080
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
- The default load balancing method is round-robin. However, for this service, use a source method. This method hashes the source IP address and divides it by the total weight of the running servers. This method also designates the server that receives the request and ensures that the same client IP address always reaches the same server unless server goes down or up. If the hash result changes due to a change in the number of running servers, the load balancer redirects the clients to a different server.
HAProxy example:
nova_osapi
Port number: 8774
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
nova_placement
Port number: 8778
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
panko
Port number: 8779
Binds to: internal_api, external
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example:
redis
Port number: 6379
Binds to: internal_api (redis service IP)
Target network or server: internal_api on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
-
Perform health checks using
tcp-check
send/expect sequences. The string to send isinfo\ replication\r\n
and the response isrole:master
. -
The Redis service uses a password for authentication. For example, the HAProxy configuration uses a
tcp-check
with the AUTH method and the Redis administration password. Director normally generates a random password, but you can define a custom Redis password. -
The default balancing method is
round-robin
. However, for this service, use thefirst
method. This ensures that the first server that has available connection slots receives the connection.
HAProxy example:
swift_proxy_server
Port number: 8080
Binds to: storage, external
Target network or server: storage on overcloud-controller-0, overcloud-controller-1, and overcloud-controller-2
Other information:
- Each target server uses a default health check.
HAProxy example: