Open Stack

Hi,
You definitely should put your vm-s onto a shared storage, thus decoupling
them from the hardware they run on. Live migration is implemented and
working in nova. When it comes to determining virtual machine's
responsiveness, I would not rely on nova.
The api will only tell you whether the kvm process or domU (xen) is
running. It does not determine whether the system inside the vm is up or
not. In this case a simple ping could do better.

You might also take a look at scalr project:

http://wiki.scalr.net/ - but I don't know whether it supports nova yet.

PS. The "cloud way" to support HA is to spawn different instances of your
vm in different availability zones. But that's the ideal world ;-)

Cheers.

On 18 January 2012 13:21, Gerrit Tamboer <gerrit at gerr1t.nl> wrote:

> Hi!
>
> We are currently working on implementing Nova into our cloud.
> Our current setup consists of 4 compute nodes which are controlled by 2
> dedicated controllers in a MySQL master-master setup.
>
> Everything is working fine, but we are currently investigating how to
> automate instance(s) failover when a host machine goes down due to hardware
> failure.
>
> I think this is scriptable because we have centralized controllers, which
> means we can query the database table 'instances' to get a list of guests
> that are running on a host.
> This means we could script that whenever a host is not responsive that the
> instances that we're running on that compute node are moved to other
> compute nodes.
>
> Before I actually start working on a script that does this I was wondering
> if there is actually a similar solution already around? I don't want to
> waste my time on reinventing the wheel :)
>
> Thanks!
>
> Regards,
>
>
> Gerrit
>
>
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
checkout my blog on linux clusters:
-- linuxdatacenter.blogspot.com --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120119/b7800942/attachment-0002.html>