External Load Balancer¶
Make it possible to use (optionally) an external load balancer as frontend for the Overcloud.
To use an external load balancer the Overcloud templates and manifests will be updated to accomplish the following three:
accept a list of virtual IPs as parameter to be used instead of the virtual IPs which are normally created as Neutron ports and hosted by the controllers
make the deployment and configuration of HAProxy on the controllers optional
allow for the assignment of a predefined list of IPs to the controller nodes so that these can be used for the external load balancer configuration
The VipMap structure, governed by the
resource type, will be switched to
a more specific resource type so that it can pointed to a custom YAML allowing
for the VIPs to be provided by the user at deployment time. Any reference to the
VIPs in the templates will be updated to gather the VIP details from such a
structure. The existing VIP resources will also be switched from the non
OS::TripleO::Controller::Ports::InternalApiPort into a
more specific type
OS::TripleO::Network::Ports::InternalApiVipPort so that
it will be possible to noop the VIPs or add support for more parameters as
required and independently from the controller ports resource.
The deployment and configuration of HAProxy on the controller nodes will become optional and driven by a new template parameter visible only to the controllers.
It will be possible to provide via template parameters a predefined list of IPs
to be assigned to the controller nodes, on each network, so that these can be
configured as target IPs in the external load balancer, before the deployment
of the Overcloud is initiated. A new port YAML will be provided for the purpose;
when using an external load balancer this will be used for resources like
As a requirement for the deployment process to succeed, the external load balancer must be configured in advance with the appropriate balancing rules and target IPs. This is because the deployment process itself uses a number of infrastructure services (database/messaging) as well as core OpenStack services (Keystone) during the configuration steps. A validation script will be provided so that connectivity to the VIPs can be tested in advance and hopefully avoid false negatives during the deployment.
By filtering the incoming connections for the controller nodes, an external load blancer might help the Overcloud survive network flood attacks or issues due to purposely malformed API requests.
Other End User Impact¶
The deployer wishing to deploy with an external load balancer will have to provide at deployment time a few more parameters, amongst which:
the VIPs configured on the balancer to be used by the Overcloud services
the IPs to be configured on the controllers, for each network
Given there won’t be any instance of HAProxy running on the controllers, when using an external load balancer these might benefit from a lower stress on the TCP stack.
Other Deployer Impact¶
None expected unless deploying with an external load balancer. A sample environment file will be provided to provide some guidance over the parameters to be passed when deploying with an external load balancer.
In those scenarios where the deployer was using only a subset of the isolated networks, the customization templates will need to be updated so that the new VIPs resource type is nooped. This can be achieved with something like:
resource_registry: OS::TripleO::Network::Ports::InternalApiVipPort: /path/to/network/ports/noop.yaml
- Primary assignee:
- Other contributors:
accept user provided collection of VIPs as parameter
make the deployment of the managed HAProxy optional
allow for the assignment of a predefined list of IPs to the controller nodes
add a validation script to test connectivity against the external VIPs
The feature seems untestable in CI at the moment but it will be possible to test at least the assignment of a predefined list of IPs to the controller nodes by providing only the predefined list of IPs as parameter.
In addition to documenting the specific template parameters needed when deploying with an external load balancer, it will also be necessary to provide some guidance for the configuration of the load balancer configuration so that it will behave as expected in the event of a failure. Unfortunately the configuration settings are strictly dependent on the balancer in use; we should publish a copy of a managed HAProxy instance config to use as reference so that a deployer could configure his external appliance similarily.