[openstack-dev] deliver the vm-level HA to improve the business continuity with openstack

Clint Byrum clint at fewbar.com
Mon Apr 14 14:45:49 UTC 2014


Excerpts from Russell Bryant's message of 2014-04-14 07:18:49 -0700:
> On 04/14/2014 09:45 AM, Jiangying (Jenny) wrote:
> > Pacemaker provides the high availability for openstack infrastructure.
> > 
> > We'd like to deliver the vm-level HA to improve the business continuity
> > with openstack.
> > 
> > Besides host failure, Our HA mechanism can detect and report host
> > isolation, network partition as well as ha agent down.
> > 
> > Ha agent is placed on every node of the system. The master agent is
> > elected automatically on system startup and others will be regarded as
> > the slave.
> > 
> > For the host states detection, the ha agents communicates through the
> > storage subsystem as well as over the management network. Multiple
> > communication paths enable better assessment of the health of the host.
> > On host failure, the master agent selects the candidate hosts and calls
> > the slave ha agents. The slave ha agents talk to the nova compute to
> > restart the virtual machine. The master agent reacts to ha agent down by
> > reporting to the administrator. During the network partition or host
> > isolation event, the HA mechanism will not interrupt the virtual
> > machines and just keep them running.
> > 
> > For the virtual machine detection, the ha agents relies on nova compute
> > for the information about virtual machines.
> > 
> > Please let me know your comments on this.
> 
> In the past we've pushed back on this pretty heavily because it isn't
> really relevant for new cloud-style architectures.  The push on this
> functionality from a lot of users is pretty insistent so I expect it to
> be added at some point in some way, it's just a question of the most
> appropriate way.
> 
> What I would like to see is to *not* have this be in Nova.  I'd like to
> make sure Nova exposes all necessary information and actions through the
> API to make implementing this possible.  However, I think the
> functionality generally belongs as something outside of Nova.
> 
> If it's something that lives outside of Nova, then we should discuss it
> in terms of public APIs (whether that's Nova's API, or a combination of
> Nova and Ceilometer, perhaps).
> 

For the most part we've been trying to encourage projects that want to
control VMs to add such functionality to the Orchestration program, aka
"Heat".



More information about the OpenStack-dev mailing list