[openstack-dev] [fuel] RabbitMQ in dedicated network

Bogdan Dobrelya bdobrelia at mirantis.com
Thu Jan 14 13:27:44 UTC 2016


On 28.12.2015 10:12, Bogdan Dobrelya wrote:
> On 23.12.2015 18:50, Matthew Mosesohn wrote:
>> I agree. As far as I remember, rabbit needs fqdns to work and map
>> correctly. I think it means we should disable the ability to move the
>> internal messaging network role in order to fix this bug until we can
>> add extra dns entries per network role (or at least addr)
> 
> For DNS resolve, we could use SRV [0] records perhaps.
> Although, nodes rely on /etc/hosts instead, AFAIK.
> 
> So we could as well do net-template-based FQDNs instead, like
> messaging-node*-domain.local 1.2.3.4
> corosync-node*-domain.local 5.6.7.8
> database-node*-domain.local 9.10.11.12
> 
> and rely on *these* FQDNS instead.
> 
> [0] https://en.wikipedia.org/wiki/SRV_record


The original idea with the "fqdn_prefix" OCF RA parameter [0] appeared
the way more simple. It would as well allow to instantiate multiple
rabbit clusters constructed from prefix-based instances of rabbit nodes.

The complexity with DNS alias is what we have 1) a node name in CIB
(corosync cluster's crm_node -n), 2) a node name as we want it in rabbit
cluster (with some prefix), 3) the actual clustered rabbit node name in
the mnesia DB constructed from the name (2) with the rabbit@<...> prefix
added.

So, as we often compare those in the RA logic and assume (1) == (2), the
prefix-based solution would be more simple. Otherwise we shall introduce
some translate_name() function, which translates the name (1) into the
name (2), for example using DNS resolving, and fix all of the type (1),
(2), (3) names comparsions in the OCF RA. Which would end up in much
more changes to test and maintain.

[0] https://review.openstack.org/#/c/262535/8

> 
>>
>> On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <amaksimov at mirantis.com
>> <mailto:amaksimov at mirantis.com>> wrote:
>>
>>     Hi Kirill,
>>
>>     I don't think we can give up on using fqdn node names for RabbitMQ
>>     because we need to support TLS in the future. 
>>
>>     Thanks,
>>     Andrey Maximov
>>     Fuel Project Manager
>>
>>     On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov
>>     <kgalanov at mirantis.com <mailto:kgalanov at mirantis.com>> wrote:
>>
>>         Hello,
>>
>>         I would like to start discussion regarding the issue we have
>>         discovered recently [1].
>>
>>         In a nutshell, if RabbitMQ is configured to run in separate
>>         mgmt/messaging network it fails on building cluster.
>>         While RabbitMQ is managed by Pacemaker and OCF script, the
>>         cluster is built using FQDN. Apparently, FQDN resolves to admin
>>         network which is different in this particular case.
>>         As a result, RabbitMQ on secondary controller node fails to join
>>         to primary controller node.
>>
>>         I can suggest two ways to tackle the issue: one is pretty
>>         simple, while other is not.
>>
>>         The first way is to accept by design using admin network for
>>         RabbitMQ internal communication between controller nodes.
>>
>>         The second way is to dig into pacemaker
>>         and RabbitMQ reconfiguration. Since it requires to refuse from
>>         using common fqdn/node names, this approach can be argued.
>>
>>
>>         --
>>         [1] https://bugs.launchpad.net/fuel/+bug/1528707
>>
>>         Best regards,
>>         Kyrylo
>>
>>         __________________________________________________________________________
>>         OpenStack Development Mailing List (not for usage questions)
>>         Unsubscribe:
>>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>     __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



More information about the OpenStack-dev mailing list