<div dir="ltr">Yes, I meant EBS not ECS. Too many similar acronyms...<div><br></div><div>The thing about the Amazon folk is that they collect a lot of metrics, and pretty much do everything on a fairly empirical basis. This is a huge advantage. Starting thinking about what I could with good metrics and building on the performance characteristics of flash. Turns out ... I can see how this could work (and very, very well). But that requires a much longer write-up than I have time for at the moment.</div><div><br></div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 12:11 PM, Dan Genin <span dir="ltr"><<a href="mailto:daniel.genin@jhuapl.edu" target="_blank">daniel.genin@jhuapl.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Did you mean EBS? I thought it was
generally hard to get the same kind of performance from block
storage that local ephemeral storage provides but perhaps Amazon
has found a way. Life would certainly be much simpler with a
single ephemeral backend. Storage pools
(<a href="https://blueprints.launchpad.net/nova/+spec/use-libvirt-storage-pools" target="_blank">https://blueprints.launchpad.net/nova/+spec/use-libvirt-storage-pools</a>)
should provide some of the same benefits.<div><div class="h5"><br>
<br>
On 10/21/2014 02:54 PM, Preston L. Bannister wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">As a side-note, the new AWS flavors seem to
indicate that the Amazon infrastructure is moving to all ECS
volumes (and all flash, possibly), both ephemeral and not. This
makes sense, as fewer code paths and less interoperability
complexity is a good thing.
<div><br>
</div>
<div>That the same balance of concerns should apply in
OpenStack, seems likely.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Oct 21, 2014 at 7:59 AM, Dan
Genin <span dir="ltr"><<a href="mailto:daniel.genin@jhuapl.edu" target="_blank">daniel.genin@jhuapl.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I would like to add to DevStack the ability to stand up Nova
with LVM ephemeral<br>
storage. Below is a draft of the blueprint describing the
proposed feature.<br>
<br>
Suggestions on architecture, implementation and the
blueprint in general are very<br>
welcome.<br>
<br>
Best,<br>
Dan<br>
<br>
========================<br>
Enable LVM ephemeral storage for Nova<br>
========================<br>
<br>
Currently DevStack supports only file based ephemeral
storage for Nova, e.g.,<br>
raw and qcow2. This is an obstacle to Tempest testing of
Nova with LVM ephemeral<br>
storage, which in the past has been inadvertantly broken<br>
(see for example, <a href="https://bugs.launchpad.net/nova/+bug/1373962" target="_blank">https://bugs.launchpad.net/nova/+bug/1373962</a>),
and to Tempest<br>
testing of new features based on LVM ephemeral storage, such
as LVM ephemeral<br>
storage encryption.<br>
<br>
To enable Nova to come up with LVM ephemeral storage it must
be provided a<br>
volume group. Based on an initial discussion with Dean
Troyer, this is best<br>
achieved by creating a single volume group for all services
that potentially<br>
need LVM storage; at the moment these are Nova and Cinder.<br>
<br>
Implementation of this feature will:<br>
<br>
* move code in lib/cinder/cinder_backends/lvm to lib/lvm
with appropriate<br>
modifications<br>
<br>
* rename the Cinder volume group to something generic,
e.g., devstack-vg<br>
<br>
* modify the Cinder initialization and cleanup code
appropriately to use<br>
the new volume group<br>
<br>
* initialize the volume group in stack.sh, shortly before
services are<br>
launched<br>
<br>
* cleanup the volume group in unstack.sh after the services
have been<br>
shutdown<br>
<br>
The question of how large to make the common Nova-Cinder
volume group in order<br>
to enable LVM ephemeral Tempest testing will have to be
explored. Although,<br>
given the tiny instance disks used in Nova Tempest tests,
the current<br>
Cinder volume group size may already be adequate.<br>
<br>
No new configuration options will be necessary, assuming the
volume group size<br>
will not be made configurable.<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>