[Openstack-operators] [nova] VM HA support in trunk

Adam Spiers aspiers at suse.com
Mon Jun 13 09:13:25 UTC 2016


Hi all, sorry I am late to this thread but I only just noticed it.

Affan is exactly right.  Architecting new cloud-native apps is
obviously the ideal approach, but unfortunately the demands of the
real-world mean that it is not possible to do this for all legacy
workloads in a timely manner.

I covered this, and much more, in detail in the talk I gave in Austin,
which also enumerates the majority of the solutions for HA of
hypervisors and VMs which currently exist in the OpenStack ecosystem:

  https://www.openstack.org/videos/video/high-availability-for-pets-and-hypervisors-state-of-the-nation

So I would warmly invite you to watch that video and/or read the
slides.

Also please be aware of this user story which we are currently
refining in collaboration with the Product Working Group:

  http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html

Finally, you are warmly invited to join the weekly OpenStack HA IRC
meetings :-)

  https://wiki.openstack.org/wiki/Meetings/HATeamMeeting

Affan Syed <affan.syed.usc at gmail.com> wrote:
> Matt/Joe,
> 
> I think your points are valid. However, when looking at woowing customers
> who are in legacy operation, doing all the changes at once doesnt seem like
> a viable value proposition. This first order transition is important to get
> them to see the benefits of cloud. Then we can have their previous OPS
> people to spend spare time on becoming DEVss and build cloud native apps !
> 
> Affan
> 
> On Tue, 16 Feb 2016 at 19:24 Bajin, Joseph <jbajin at verisign.com> wrote:
> 
> > I would have to agree with Matt.  The ability for any sort of handling of
> > failures either reside within the application or tools around the
> > application to make it work.  Having the infrastructure handle the
> > failures, I believe, is a slippery slope that is starting to appear more
> > and more.
> >
> > I do fear that many people/organizations are starting to look at the cloud
> > as a “low cost” or “free” VMWare solution.  They want the same enterprise
> > based availability and support that they get with a vendor paid solution
> > without the cost of the vendor paid solution.   I have started to see and
> > hear more about how vendors are adding “enterprise” solutions to
> > OpenStack.  This includes High Availability features that rely on the
> > infrastructure to manage instead of the application.  I fear the direction
> > of all the projects will begin migrating this way as more vendors get
> > involve and want to figure out business models that they can use around
> > “enterprise” feature-sets.
> >
> > —Joe
> >
> >
> > From: Matt Fischer <matt at mattfischer.com>
> > Date: Monday, February 15, 2016 at 10:59 AM
> > To: Toshikazu Ichikawa <ichikawa.toshikazu at lab.ntt.co.jp>
> > Cc: "openstack-operators at lists.openstack.org" <
> > openstack-operators at lists.openstack.org>
> > Subject: Re: [Openstack-operators] [nova] VM HA support in trunk
> >
> > I believe that either have your customers design their apps to handle
> > failures or have tools that are reactive to failures.
> >
> > Unfortunately like many other private cloud operators we deal a lot with
> > legacy applications that aren't scaled horizontally or fault tolerant and
> > so we've built tooling to handle customer notifications (reactive). When we
> > lose a compute host we generate a notice to customers and then work on
> > evacuating their instances. For the evac portion nova host-evacuate or
> > host-evacuate-live work fairly well, although we rarely get a functioning
> > floating-IP after host-evacuate without other work.
> >
> > Getting adoption of heat or other automation tooling to educate customers
> > is a long process, especially when they're used to VMware where I think
> > they get the VM HA stuff for "free".
> >
> >
> > On Mon, Feb 15, 2016 at 8:25 AM, Toshikazu Ichikawa <
> > ichikawa.toshikazu at lab.ntt.co.jp> wrote:
> >
> >> Hi Affan,
> >>
> >> I don’t think any components in Liberty provide HA VM support directly.
> >>
> >> However, many works are published and open-sourced, here.
> >>
> >> https://etherpad.openstack.org/p/automatic-evacuation
> >>
> >> You may find ideas and solutions.
> >>
> >> And, the discussion on this topic is on-going at HA meeting.
> >>
> >> https://wiki.openstack.org/wiki/Meetings/HATeamMeeting
> >>
> >> thanks,
> >>
> >> Kazu
> >>
> >>
> >> *From:* Affan Syed [mailto:affan.syed.usc at gmail.com]
> >> *Sent:* Monday, February 15, 2016 12:51 PM
> >> *To:* openstack-operators at lists.openstack.org
> >> *Subject:* [Openstack-operators] [nova] VM HA support in trunk
> >>
> >> reposting with the correct tag, hopefully. Would really appreciate some
> >> pointers.
> >>
> >> ---------- Forwarded message ---------
> >> From: Affan Syed <affan.syed.usc at gmail.com>
> >> Date: Sat, 13 Feb 2016 at 15:13
> >> Subject: [nova] VM HA support in trunk
> >> To: <openstack-operators at lists.openstack.org>
> >>
> >> Hi all,
> >>
> >> I have been trying to understand if we currently have some VM HA support
> >> as part of Liberty?
> >>
> >> To be precise, how are host being down due to power failure handled,
> >> specifically in terms of migrating the VMs but possibly even their
> >> networking configs (tunnels etc).
> >>
> >> The VM migration like XEN-HA or KVM cluster seem to require 1+1 HA, I
> >> have read a few places about celiometer+heat templates to launch VMs for an
> >> N+1 backup scenario, but these all seem like one-off setups.
> >>
> >> This issue seems to be very much important for legacy enterprises to move
> >> their "pets" --- not sure if we can simply wish away that mindset!
> >>
> >> Affan



More information about the OpenStack-operators mailing list