Hi Joe, >Also, is it safe to say that communication between agent/engine only, and will >only, happen during app deployment?
murano-agent & murano-engine keep active connection to the Rabbit MQ broker but message exchange happens only during deployment of the app. >One thing we just ran into, though, was getting the agent/engine rmq config to >work with SSL We had related bug fixed in Newton, can you confirm that you are *not* hitting bug #1578421 [0] References: [0] https://bugs.launchpad.net/murano/+bug/1578421 On Mon, Sep 26, 2016 at 1:43 PM, Andrew Woodward <xar...@gmail.com> wrote: > 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. > > 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 > > isten mysqld > bind 192.168.0.2:3306 > mode tcp > option httpchk > option tcplog > option clitcpka > option srvtcpka > stick on dst > stick-table type ip size 1 > timeout client 28801s > timeout server 28801s > server node-1 192.168.0.4:3307 check port 49000 inter 20s fastinter 2s > downinter 2s rise 3 fall 3 > server node-3 192.168.0.6:3307 backup check port 49000 inter 20s fastinter > 2s downinter 2s rise 3 fall 3 > server node-4 192.168.0.5:3307 backup check port 49000 inter 20s fastinter > 2s downinter 2s rise 3 fall 3 > > listen murano_rabbitmq > bind 10.110.3.3:55572 > balance roundrobin > mode tcp > option tcpka > timeout client 48h > timeout server 48h > server node-1 192.168.0.4:55572 check inter 5000 rise 2 fall 3 > server node-3 192.168.0.6:55572 backup check inter 5000 rise 2 fall 3 > server node-4 192.168.0.5:55572 backup check inter 5000 rise 2 fall 3 > > > On Fri, Sep 23, 2016 at 7:30 AM Mike Lowe <joml...@iu.edu> wrote: >> >> Would you mind sharing an example snippet from HA proxy config? I had >> struggled in the past with getting this part to work. >> >> >> > On Sep 23, 2016, at 12:13 AM, Serg Melikyan <smelik...@mirantis.com> >> > wrote: >> > >> > Hi Joe, >> > >> > I can share some details on how murano is configured as part of the >> > default Mirantis OpenStack configuration and try to explain why it's >> > done in that way as it's done, I hope it helps you in your case. >> > >> > As part of Mirantis OpenStack second instance of the RabbitMQ is >> > getting deployed specially for the murano, but it's configuration is >> > different than for the RabbitMQ instance used by the other OpenStack >> > components. >> > >> > Why to use separate instance of the RabbitMQ? >> > 1. Prevent possibility to get access to the RabbitMQ supporting >> > whole cloud infrastructure by limiting access on the networking level >> > rather than rely on authentication/authorization >> > 2. Prevent possibility of DDoS by limiting access on the >> > networking level to the infrastructure RabbitMQ >> > >> > Given that second RabbitMQ instance is used only for the murano-agent >> > <-> murano-engine communications and murano-agent is running on the >> > VMs we had to make couple of changes in the deployment of the RabbitMQ >> > (bellow I am referencing RabbitMQ as RabbitMQ instance used by Murano >> > for m-agent <-> m-engine communications): >> > >> > 1. RabbitMQ is not clustered, just separate instance running on each >> > controller node >> > 2. RabbitMQ is exposed on the Public VIP where all OpenStack APIs are >> > exposed >> > 3. It's has different port number than default >> > 4. HAProxy is used, RabbitMQ is hidden behind it and HAProxy is always >> > pointing to the RabbitMQ on the current primary controller >> > >> > Note: How murano-agent is working? Murano-engine creates queue with >> > uniq name and put configuration tasks to that queue which are later >> > getting picked up by murano-agent when VM is booted and murano-agent >> > is configured to use created queue through cloud-init. >> > >> > #1 Clustering >> > >> > * Given that per 1 app deployment from we create 1-N VMs and send 1-M >> > configuration tasks, where in most of the cases N and M are less than >> > 3. >> > * Even if app deployment will be failed due to cluster failover it's >> > can be always re-deployed by the user. >> > * Controller-node failover most probably will lead to limited >> > accessibility of the Heat, Nova & Neutron API and application >> > deployment will fail regardless of the not executing configuration >> > task on the VM. >> > >> > #2 Exposure on the Public VIP >> > >> > One of the reasons behind choosing RabbitMQ as transport for >> > murano-agent communications was connectivity from the VM - it's much >> > easier to implement connectivity *from* the VM than *to* VM. >> > >> > But even in the case when you are connecting to the broker from the VM >> > you should have connectivity and public interface where all other >> > OpenStack APIs are exposed is most natural way to do that. >> > >> > #3 Different from the default port number >> > >> > Just to avoid confusion from the RabbitMQ used for the infrastructure, >> > even given that they are on the different networks. >> > >> > #4 HAProxy >> > >> > In case of the default Mirantis OpenStack configuration is used mostly >> > to support non-clustered RabbitMQ setup and exposure on the Public >> > VIP, but also helpful in case of more complicated setups. >> > >> > P.S. I hope my answers helped, let me know if I can cover something in >> > more details. >> > -- >> > Serg Melikyan, Development Manager at Mirantis, Inc. >> > http://mirantis.com | smelik...@mirantis.com >> > >> > _______________________________________________ >> > OpenStack-operators mailing list >> > OpenStack-operators@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- > Andrew Woodward > Mirantis -- Serg Melikyan, Development Manager at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators