Open Stack

Yes. Really three(?) different beasts, here.

Ephemeral storage is exactly that. It must contain nothing that needs to be
preserved. So you can factor this out into three main cases:

1.  Instance boots from ephemeral storage. All persistent state is not
owned by the instance.
2.  Instance boots from ephemeral storage. Some/all persistent state is in
an additional attached Cinder volume.
3.  Instance boots from a persistent Cinder volume, which contains
persistent state.

In (1) you are closest to a built-for-cloud application. The persistent
state might be in cloud-object storage, or in some other net-accessible
service. If the instance fails, simply boot another. No preservation of
instance-state needed.

In (2) you have a more traditional sort of application, deployed
efficiently in the cloud. Failover consists of  spinning up a new instance,
attached to the volume with state.

In (3) you have a traditional sort of application, simply deployed in the
cloud. Less efficient, but less work needed. Failover consists of spinning
up a new instance, booted off the Cinder volume.

NOTE:  In *no* case are you looking to preserve the state of the ephemeral
volume!!

If you need to preserve the volume, it must be in Cinder. It must *not* be
ephemeral. Ephemeral means exactly that.



> Excerpts from Adam Lawson's message of 2014-09-26 14:43:40 -0700:
> \> I'm looking for discussions/plans re VM continuity.
> >
> > I.e. Protection for instances using ephemeral storage against host
> failures
> > or auto-failover capability for instances on hosts where the host suffers
> > from an attitude problem?
> >
> > I know fail-overs are supported and I'm quite certain auto-fail-overs are
> > possible in the event of a host failure (hosting instances not using
> shared
> > storage). I just can't find where this has been addressed/discussed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140926/17cc9bc4/attachment.html>