[Rdo-list] Attempt to enable LBaaS on two node Havana 2 Cluster (Controller+Compute) CentOS 6.5

[Boris Derzhavets]

Thank you very much.  I got it.

> Date: Wed, 8 Jan 2014 04:42:04 -0600
> From: rohara at redhat.com
> To: bderzhavets at hotmail.com
> CC: pbrady at redhat.com; rdo-list at redhat.com
> Subject: Re: [Rdo-list] Attempt to enable LBaaS on two node Havana 2 Cluster (Controller+Compute) CentOS 6.5
> 
> On Tue, Jan 07, 2014 at 04:37:09PM -0500, Boris Derzhavets wrote:
> > 
> > 
> > Follow  http://openstack.redhat.com/forum/discussion/comment/2178   
> >   and    http://openstack.redhat.com/Load_Balance_OpenStack_API#HAProxy
> 
> The first link is a discussion about LBaaS and the second is a
> write-up about how to setup HAProxy to load balancer OpenStack API
> services. These are two entirely different things.
> 
> > Edit /etc/neutron/neutron.conf and add the following in the default section:
> > 
> > [DEFAULT]
> > service_plugins = neutron.services.loadbalancer.plugin.LoadBalancerPlugin
> > 
> > Already there
> > 
> > Then edit the /etc/openstack-dashboard/local_settings file and search for enable_lb and set it to true:
> > 
> > OPENSTACK_NEUTRON_NETWORK = { 
> >     'enable_lb': True
> > }
> > 
> > Done
> > 
> > # yum install haproxy - already installed
> > # vi /etc/neutron/lbaas_agent.ini - already done no changes
> > 
> > device_driver=neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver
> > interface_driver=neutron.agent.linux.interface.OVSInterfaceDriver 
> > user_group=haproxy
> > 
> > Comment out the line in the service_providers section: 
> > 
> > service_provider=LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
> > 
> > Nothing to remove
> > 
> > service neutron-lbaas-agent start - already running , restarted
> > chkconfig neutron-lbaas-agent on  - skipped
> > service neutron-server restart  - done
> > service httpd restart  - done 
> 
> So far you've setup LBaaS and everything looks fine.
> 
> > HA enabled via keepalived , Virtual IP 192.168.1.132.
> 
> Keepalived has nothing to do with LBaaS, so we've diverged a bit here.
> 
> > Follow http://openstack.redhat.com/Load_Balance_OpenStack_API#HAProxy  
> > and http://openstack.redhat.com/forum/discussion/798/enabling-lbaas-in-havana-and-why-is-it-not-on-by-default#Item_4  replacing "quantum" by "neutron" and using virirtual IP for one server creating /etc/haproxy/haproxy.cfg. Haproxy fails to start reporting:
> > 
> > 
> > Starting haproxy: 
> > 
> > [ALERT] 006/135903 (12988) : Starting frontend keystone-admin-vip: cannot bind socket
> > 
> > [ALERT] 006/135903 (12988) : Starting frontend keystone-public-vip: cannot bind socket
> > 
> 
> Where are you starting haproxy? I am guessing that you're starting
> this on the controller, which will be a problem since the OpenStack
> services themselves are setup to listen on 0.0.0.0:<PORT> which means
> haproxy cannot also listen on that port on the same node.
> 
> > 
> > Really , for any port mentioned in haproxy.cfg :-
> > 
> > # netstat -lnp | grep 35357 tcp 0 0 0.0.0.0:35357 0.0.0.0:* LISTEN 4189/python
> > # netstat -lnp | grep 5000 tcp 0 0 0.0.0.0:5000 0.0.0.0:*     LISTEN 4189/python 
> > . . . . . .  
> > 
> > Haproxy may be started ahead of openstack services, but in this case
> > openstack services fail to start.  I am missing something here 
> 
> First, what is it you want to do? If you want to setup LBaaS, you were
> on the right track. Once LBaaS is configured and the agent is running,
> use the Neutron API to create a load-balancer. This will load-balancer
> traffic to your virtual machines.
> 
> The write-up you referenced on the RDO page describes how to use
> haproxy and keepalived to achieve a highly-available load-balancer for
> your OpenStack services. For example, you might have many controllers,
> each running neutron, keystone, nova API services, etc. and you can
> put a load-balancer in front of these services for scalability and
> availability.
> 
> Let me know if you have questions.
> 
> Ryan
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20140108/b490047a/attachment.html>