[openstack-dev] neutron metadata-agent HA

Fox, Kevin M Kevin.Fox at pnnl.gov
Tue Dec 15 00:00:56 UTC 2015


ha and dvr don't play nicely today though, and for our use case, if given the choice, dvr looks more appealing then l3-ha. Thanks for the advice. We may just go with the pacemaker option with dvr taking most of the load off of the network node until l3+ha & dvr all play nice.

Thanks,
Kevin
________________________________________
From: Assaf Muller [amuller at redhat.com]
Sent: Monday, December 14, 2015 2:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] neutron metadata-agent HA

If you're not running HA routers, you have a couple of options that
I'm aware of:

1) Use multiple L3 agents in A/A, and enable
neutron.conf:allow_automatic_l3agent_failover. In which case you'd
enable the metadata agent on each node. There's pros and cons of this
approach vs. HA routers. Significantly slower failover (Hours instead
of seconds, depending on number of routers), reliable on the control
plane for a successful failover, but simpler with less room for bugs.
I recommend HA routers, but I'm biased.
2) Use Pacemaker or similar to manage a cluster (Or clusters) of
network nodes in A/P, in which case all four Neutron agents (L2,
metadata, DHCP, L3) are enabled on only one machine in a cluster at a
time. This is fairly out of date at this point.

On Mon, Dec 14, 2015 at 12:33 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> What about the case where your not running ha routers? Should you still run more then one?
>
> Thanks,
> Kevin
> ________________________________________
> From: Assaf Muller [amuller at redhat.com]
> Sent: Saturday, December 12, 2015 12:44 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] neutron metadata-agent HA
>
> The neutron metadata agent is stateless. It takes requests from the
> metadata proxies running in the router namespaces and moves the
> requests on to the nova server. If you're using HA routers, start the
> neutron-metadata-agent on every machine the L3 agent runs, and just
> make sure that the metadata-agent is restarted in case it crashes and
> you're done. Nothing else you need to do.
>
> On Fri, Dec 11, 2015 at 3:24 PM, Fabrizio Soppelsa
> <fsoppelsa at mirantis.com> wrote:
>>
>> On Dec 10, 2015, at 12:56 AM, Alvise Dorigo <alvise.dorigo at pd.infn.it>
>> wrote:
>>
>> So my question is: is there any progress on this topic ? is there a way
>> (something like a cronjob script) to make the metadata-agent redundant
>> without involving the clustering software Pacemaker/Corosync ?
>>
>>
>> Reason for such a dirty solution instead of rely onto pacemaker?
>>
>> I’m not aware of such initiatives - just checked the blueprints in Neutron
>> and I found no relevant. I can suggest to file a proposal to the
>> correspondent launchpad page, by elaborating your idea.
>>
>> F.
>>
>> __________________________________________________________________________
>> 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
>>
>
> __________________________________________________________________________
> 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
>
> __________________________________________________________________________
> 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

__________________________________________________________________________
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



More information about the OpenStack-dev mailing list