[Openstack-operators] Nova (in VLAN mode) and the high availability of a "central" nova-network

Lorin Hochstein lorin at nimbisservices.com
Sun May 20 22:32:45 UTC 2012


Chris:

Have you seen the HA docs? http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html

If you set multi_host=True in your nova.conf, then nova will work properly with multiple nova-network services. But I've only done this with one nova-network service running on each compute host, I don't know how/if it would work if you had only two nova-network services running.

Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com





On May 20, 2012, at 5:57 PM, Christian Parpart wrote:

> Hi all,
> 
> due to the fact, that I cannot provide all compute nodes with public IPs (allowing us
> to run nova-network on each compute node), we're having one (or two in fact) frontend
> node doing the public network traffic work.
> 
> So, how can I make a single nova-network node highly available?
> It would be fine to have some vrrpd/keepalived enabled node, that then
> starts/stops the sensible services (like nova-network) in question.
> 
> However, does this work well with nova-network?
> Will this produce some noticable delay in availability when the active master goes down
> and until the current slave has fully become the master (with nova-network being started up)?
> How does this affect the nova environment.
> Especially, thinking of the `nova-manage service list` output, where only one nova-network instance
> ought to be then, but in HA mode, we are to have at least 2 then. How well does Nova play with that?
> 
> Thanks in advance,
> Christian Parpart.
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120520/6ae02414/attachment-0002.html>


More information about the Openstack-operators mailing list