On 02/24/2011 11:23 AM, Ian Main wrote:
We had a meeting this morning and we managed to hash some things out
on
this subject. Here is the result. I am posting this to both
aeolus-devel and deltacloud-devel as it impacts both.
Stateful vs Stateless instances and the cloud
---------------------------------------------
In an effort to support private cloud, we had to sort out what to do about
'stateful' instances. We're defining a stateful instance as one where
the image for the instance does not get destroyed when the instance is
stopped and it is possible to restart it with the same state.
Also, the model that Aeolus Conductor is using regarding images is the
same as ec2, where a given image can be used to launch as many instances
as needed. This is not the same as the model used by many private cloud
providers where an image is used directly by a instance/VM and it is
not possible for it to be used by multiple running instances.
We want to tackle these questions in two different phases. Stateless
cloud on supported providers is presently the most important requirement,
but we will need both soon.
STATELESS CLOUD
---------------
The way that some providers (such as rhevm and vmware) launch instances
now are not what we need. Cloud launch must start an instance in
such a way that it can perform multiple launches from the same image.
To support that what really needs to happen is that prior to launch the
image needs to be either cloned or snapshotted.
Below are a couple of ways we thought of to do this:
- Deltacloud API provider driver start call must clone disk on startup
if the provider does not already do that.
- On destroy, API must clean up cloned disk image if the provider does
not already do it.
- On shutdown, the API leaves the disk alone.
OR
- Deltacloud API provides instrospection into the driver and specifies
whether or not an instance start will clone the disk for us.
- It also needs to specify if the storage needs to be destroyed on
instance shutdown (some clouds do, some don't).
- Deltacloud API provides APIs for performing the clone and then cleanup
of cloned images.
- It is then up to the client to perform the right sequence of actions
to get the desired behavior.
Either of these will work and allow us to make the Conductor model
consistent with existing public cloud providers.
STATEFUL CLOUD INSTANCES
------------------------
Stateful instances have the ability to be stopped without destroying the
disk image and then resumed from the same state. In order to support
this we need:
Condor:
- Condor must have "suspend"/stop/restart support.
- Image must be built to target stateful - we need a toggle at image
build time and at launch time.
Deltacloud API:
- Deltacloud API must support stop that does not cleanup disk image but
only if available.
- Introspection as to whether or not a stop is valid. Currently
stop/destroy is the same op on ec2, but 'stop' should be invalid. Stop is
only valid for stateful instances. Destroy cleans up disk image. This is
to act as introspection as to whether the instance is stateful or not.
This may not be needed depending on how we support disk clone/cleanup as
defined above.
Conductor:
- If an instance on a stateful-only cloud is designated stateless, we must
track that extra condition in the conductor (because stateful/stateless
will act the same). This lets us know if we need to clean up disk
images etc.
- We could provide a 'stateful/stateless' toggle at launch time that
warned the user there is no match and they must build a stateful instance
for it to work.
Thanks!
Ian
Just a comment to confirm that we are on the same page.
For the stateless images the bootsrapping of the security and identity
will happen every time the image is launched. There is no guarantee that
the key materials or any identity information will be preserved between
the launches. This means that the controlling/tracking identity storage
for the VMs needs to be cleaned after the image is destroyed and
initialized each time before the image is launched.
The statefull image would contain all the keys except the ones that
would allow it to make a home call to the enterprise. Those have to be
provisioned on every launch if the machine is actually supposed to
connect back. This also means that for the statefull images the full
disk encryption might be a requirement. Do we have a way to pass the key
to decrypt the disk at the launch time? This would at least protect from
the brute force offline attacks if the image at rest is stolen from the
storage in the public cloud.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/