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....@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 [amul...@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 > <fsoppe...@mirantis.com> wrote: >> >> On Dec 10, 2015, at 12:56 AM, Alvise Dorigo <alvise.dor...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
