On 05/12/2014 10:35 AM, Dmitriy Shulyak wrote:
Adding haproxy (or keepalived with lvs for load balancing) will
require binding haproxy and openstack services on different sockets.
Afaik there is 3 approaches that tripleo could go with.
Consider configuration with 2 controllers:
haproxy: nodes: - name: controller0 ip: 192.0.2.20 - name:
controller1 ip: 192.0.2.21
1. Binding haproxy on virtual ip and standard ports
haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual
ip) port: 80 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22
(virtual ip) proxy_port: 9696 port: 9696
Pros: - No additional modifications in elements is required
Actually openstack services elements have to be updated to bind to local
address only.
HA-Proxy version 1.4.24 2013/06/17 What was the reason this approach
was dropped?
IIRC the major reason was that having 2 services on same port (but
different interface) would be too confusing for anyone who is not aware
of this fact.
2. Haproxy listening on standard ports, services on non-standard
haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual
ip) port: 8080 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22
(virtual ip) proxy_port: 9696 port: 9797
Pros: - No changes will be required to init-keystone part of
workflow - Proxied services will be accessible on accustomed ports
Bear in mind that we already use not-standard SSL ports for public
endpoints. Also extra work will be required for setting up stunnels
(element openstack-ssl).
- No changes to configs where services ports need to be hardcoded,
for example in nova.conf https://review.openstack.org/#/c/92550/
Cons: - Config files should be changed to add possibility of ports
configuration
Another cons is also updating selinux and firewall rules for each node.
3. haproxy on non-standard ports, with services on standard
haproxy: services: - name: horizon proxy_ip: 192.0.2.22 (virtual
ip) port: 8080 proxy_port: 80 - name: neutron proxy_ip: 192.0.2.22
(virtual ip) proxy_port: 9797 port: 9696
Notice that i changed only port for neutron, main endpoint for
horizon should listen on default http or https ports.
Agree that having 2 service ports switched in other way than other is
sub-optimal.
Basicly it is opposite to 2 approach. I would prefer to go with 2,
cause it requires only minor refactoring.
Thoughts?
Options 2 and 3 seem quite equal based on pros vs cons. Maybe we should
reconsider option 1?
Jan
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
