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 _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev