<div dir="ltr">In Fuel we deploy haproxy to all of the nodes that are part of the VIP/endpoint service (This is usually part of the controller role) Then the vips (internal or public) can be active on any member of the group. Corosync/Pacemaker is used to move the VIP address (as apposed to keepalived) in our case both haproxy, and the vip live in a namespace and haproxy is always running on all of these nodes bound to 0/0.<div><br></div><div>In the case of murano-rabbit we take the same approach as we do for galera, all of the members are listed in the balancer, but with the others as backup's this makes them inactive until the first node is down. This allow the vip to move to any of the proxies in the cluster, and continue to direct traffic to the same node util that rabbit instance is also un-available</div><div><br></div><div><div>isten mysqld</div><div> bind <a href="http://192.168.0.2:3306">192.168.0.2:3306</a> </div><div> mode tcp</div><div> option httpchk</div><div> option tcplog</div><div> option clitcpka</div><div> option srvtcpka</div><div> stick on dst</div><div> stick-table type ip size 1</div><div> timeout client 28801s</div><div> timeout server 28801s</div><div> server node-1 <a href="http://192.168.0.4:3307">192.168.0.4:3307</a> check port 49000 inter 20s fastinter 2s downinter 2s rise 3 fall 3</div><div> server node-3 <a href="http://192.168.0.6:3307">192.168.0.6:3307</a> backup check port 49000 inter 20s fastinter 2s downinter 2s rise 3 fall 3</div><div> server node-4 <a href="http://192.168.0.5:3307">192.168.0.5:3307</a> backup check port 49000 inter 20s fastinter 2s downinter 2s rise 3 fall 3</div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">listen murano_rabbitmq</span><br></div><div> bind <a href="http://10.110.3.3:55572">10.110.3.3:55572</a> </div><div> balance roundrobin</div><div> mode tcp</div><div> option tcpka</div><div> timeout client 48h</div><div> timeout server 48h</div><div> server node-1 <a href="http://192.168.0.4:55572">192.168.0.4:55572</a> check inter 5000 rise 2 fall 3</div><div> server node-3 <a href="http://192.168.0.6:55572">192.168.0.6:55572</a> backup check inter 5000 rise 2 fall 3</div><div> server node-4 <a href="http://192.168.0.5:55572">192.168.0.5:55572</a> backup check inter 5000 rise 2 fall 3</div></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 23, 2016 at 7:30 AM Mike Lowe <<a href="mailto:jomlowe@iu.edu" target="_blank">jomlowe@iu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Would you mind sharing an example snippet from HA proxy config? I had struggled in the past with getting this part to work.<br>
<br>
<br>
> On Sep 23, 2016, at 12:13 AM, Serg Melikyan <<a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a>> wrote:<br>
><br>
> Hi Joe,<br>
><br>
> I can share some details on how murano is configured as part of the<br>
> default Mirantis OpenStack configuration and try to explain why it's<br>
> done in that way as it's done, I hope it helps you in your case.<br>
><br>
> As part of Mirantis OpenStack second instance of the RabbitMQ is<br>
> getting deployed specially for the murano, but it's configuration is<br>
> different than for the RabbitMQ instance used by the other OpenStack<br>
> components.<br>
><br>
> Why to use separate instance of the RabbitMQ?<br>
> 1. Prevent possibility to get access to the RabbitMQ supporting<br>
> whole cloud infrastructure by limiting access on the networking level<br>
> rather than rely on authentication/authorization<br>
> 2. Prevent possibility of DDoS by limiting access on the<br>
> networking level to the infrastructure RabbitMQ<br>
><br>
> Given that second RabbitMQ instance is used only for the murano-agent<br>
> <-> murano-engine communications and murano-agent is running on the<br>
> VMs we had to make couple of changes in the deployment of the RabbitMQ<br>
> (bellow I am referencing RabbitMQ as RabbitMQ instance used by Murano<br>
> for m-agent <-> m-engine communications):<br>
><br>
> 1. RabbitMQ is not clustered, just separate instance running on each<br>
> controller node<br>
> 2. RabbitMQ is exposed on the Public VIP where all OpenStack APIs are exposed<br>
> 3. It's has different port number than default<br>
> 4. HAProxy is used, RabbitMQ is hidden behind it and HAProxy is always<br>
> pointing to the RabbitMQ on the current primary controller<br>
><br>
> Note: How murano-agent is working? Murano-engine creates queue with<br>
> uniq name and put configuration tasks to that queue which are later<br>
> getting picked up by murano-agent when VM is booted and murano-agent<br>
> is configured to use created queue through cloud-init.<br>
><br>
> #1 Clustering<br>
><br>
> * Given that per 1 app deployment from we create 1-N VMs and send 1-M<br>
> configuration tasks, where in most of the cases N and M are less than<br>
> 3.<br>
> * Even if app deployment will be failed due to cluster failover it's<br>
> can be always re-deployed by the user.<br>
> * Controller-node failover most probably will lead to limited<br>
> accessibility of the Heat, Nova & Neutron API and application<br>
> deployment will fail regardless of the not executing configuration<br>
> task on the VM.<br>
><br>
> #2 Exposure on the Public VIP<br>
><br>
> One of the reasons behind choosing RabbitMQ as transport for<br>
> murano-agent communications was connectivity from the VM - it's much<br>
> easier to implement connectivity *from* the VM than *to* VM.<br>
><br>
> But even in the case when you are connecting to the broker from the VM<br>
> you should have connectivity and public interface where all other<br>
> OpenStack APIs are exposed is most natural way to do that.<br>
><br>
> #3 Different from the default port number<br>
><br>
> Just to avoid confusion from the RabbitMQ used for the infrastructure,<br>
> even given that they are on the different networks.<br>
><br>
> #4 HAProxy<br>
><br>
> In case of the default Mirantis OpenStack configuration is used mostly<br>
> to support non-clustered RabbitMQ setup and exposure on the Public<br>
> VIP, but also helpful in case of more complicated setups.<br>
><br>
> P.S. I hope my answers helped, let me know if I can cover something in<br>
> more details.<br>
> --<br>
> Serg Melikyan, Development Manager at Mirantis, Inc.<br>
> <a href="http://mirantis.com" rel="noreferrer" target="_blank">http://mirantis.com</a> | <a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">Andrew Woodward<div>Mirantis</div></div></div>