Open Stack

Pacemaker (and the underlying heartbeat mechanism) is a very good tool, 
but to the best of my knowledge it is not very scalable. Therefore, it is 
a great fit to implement HA of things like mysql, between small number of 
'controller' nodes. But when it comes to cloud-scale heartbeat/membership, 
there are better tools -- such as ZooKeeper (which is one of the backend 
implementations of the service heartbeat mechanism within Nova). 

Regards,
Alex




From:   Leen Besselink <ubuntu at consolejunkie.net>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Date:   23/04/2013 10:39 AM
Subject:        Re: [openstack-dev] blueprint proposal nova-compute 
fencing for HA ?



> I was only talking about the fencing off a compute node part, since
> that's what you started the thread with.  :-)

I know I'm going in circles, just trying to get a feel for the best way to 
handle it.

>
> Presumably you would still use nova APIs that already exist to move the
> instances elsewhere.  An 'evacuate' API went in to grizzly for this.
>
> https://blueprints.launchpad.net/nova/+spec/rebuild-for-ha
>

So when any node fails in a Pacemaker cluster, you fence the node, tell 
OpenStack about the
failed node and call evacuate for all the instances. The scheduler will 
just place them anywhere
it pleases.

(there is already a blueprint for evacuate to call the scheduler and even 
an other for handling a whole node)

So, yeah, maybe that is enough.

I guess I was hoping all machines would be the same. Now I'll need to make 
clusters. To OpenStack
they will still all look the same I guess.

But it will work with existing tested code, that is also important.

So no blueprint for fencing.

Thank you for the discussion.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130423/542f851a/attachment.html>