Open Stack

I am proposing that Octavia should support deployment models that
enable multiple listeners to be configured inside the HAProxy
instance.

The model I am proposing is:

1. One or more VIP per Octavia VM (propose one VIP in 0.5 release)
2. One or more HAProxy instance per Octavia VM
3. One or more listeners on each HAProxy instance
4. Zero or more pools per listener (shared pools should be supported
as a configuration render optimization, but propose support post 0.5
release)
5. One or more members per pool

This provides flexibility to the operator to support multiple
deployment models,  including active-active and hot standby Octavia
VMs.  Without the flexibility to have multiple listeners per HAProxy
instance we are limiting the operators deployment models.

I am advocating for multiple listeners per HAProxy instance because I
think it provides the following advantages:

1. It reduces memory overhead due to running multiple HAProxy
instances on one Octavia VM.  Since the Octavia constitution states
that Octavia is for large operators where this memory overhead could
have a financial impact we should allow alternate deployment options.
2. It reduces host CPU overhead due to reduced context switching that
would occur between HAProxy instances.  HAProxy is event driven and
will mostly be idle waiting for traffic, where multiple instances of
HAProxy will require context switching between the processes which
increases the VM’s CPU load.  Since the Octavia constitution states
that we are designing for large operators, anything we can do to
reduce the host CPU load reduces the operator’s costs.
3. Hosting multiple HAProxy instances on one Octavia VM will increase
the load balancer build time because multiple configuration files,
start/stop scripts, health monitors, and HAProxy Unix sockets will
have to be created.  This could significantly impact operator
topologies that use hot standby Octavia VMs for failover.
4. It reduces network traffic and health monitoring overhead because
only one HAProxy instance per Octavia VM will need to be monitored.
This again, saves the operator money and increases the scalability for
large operators.
5. Multiple listeners per instance allows the sharing of backend pools
which reduces the amount of health monitoring traffic required to the
backend servers.  It also has the potential to share SSL certificates
and keys.
6. It allows customers to think of load balancers (floating IPs) as an
application service, sharing the fate of multiple listeners and
providing a consolidated log file.  This also provides a natural
grouping of services (around the floating IP) for a defined
performance floor.  With multiple instances per Octavia VM one
instance could negatively impact all of the other instances which may
or may not be related to the other floating IP(s).
7. Multiple listeners per instance reduces the number of TCP ports
used on the Octavia VM, increasing the per-VM scalability.


I don’t want us, by design, to limit the operator flexibility in
deployment an topologies, especially when it potentially impacts the
costs for large operators.  Having multiple listeners per HAProxy
instance is a very common topology in the HAProxy community and I
don’t think we should block that use case with Octavia deployments.

Michael