On Tue, Oct 21, 2014 at 2:48 PM, Dan Genin <daniel.ge...@jhuapl.edu> wrote:

>  So then it is probably best to leave existing Cinder LVM code in
> lib/cinder_backends/lvm alone and create a similar set of lvm scripts for
> Nova,
> perhaps in lib/nova_backends/lvm?
>
> Dan
>
> On 10/21/2014 03:10 PM, Duncan Thomas wrote:
>
> Sharing the vg with cinder is likely to cause some pain testing proposed
> features cinder reconciling backend with the cinder db. Creating a second
> vg sharing the same backend pv is easy and avoids all such problems.
>
> Duncan Thomas
> On Oct 21, 2014 4:07 PM, "Dan Genin" <daniel.ge...@jhuapl.edu> wrote:
>
>> Hello,
>>
>> I would like to add to DevStack the ability to stand up Nova with LVM
>> ephemeral
>> storage. Below is a draft of the blueprint describing the proposed
>> feature.
>>
>> Suggestions on architecture, implementation and the blueprint in general
>> are very
>> welcome.
>>
>> Best,
>> Dan
>>
>> ========================
>> Enable LVM ephemeral storage for Nova
>> ========================
>>
>> Currently DevStack supports only file based ephemeral storage for Nova,
>> e.g.,
>> raw and qcow2. This is an obstacle to Tempest testing of Nova with LVM
>> ephemeral
>> storage, which in the past has been inadvertantly broken
>> (see for example, https://bugs.launchpad.net/nova/+bug/1373962), and to
>> Tempest
>> testing of new features based on LVM ephemeral storage, such as LVM
>> ephemeral
>> storage encryption.
>>
>> To enable Nova to come up with LVM ephemeral storage it must be provided a
>> volume group. Based on an initial discussion with Dean Troyer, this is
>> best
>> achieved by creating a single volume group for all services that
>> potentially
>> need LVM storage; at the moment these are Nova and Cinder.
>>
>> Implementation of this feature will:
>>
>>  * move code in lib/cinder/cinder_backends/lvm to lib/lvm with appropriate
>>    modifications
>>
>>  * rename the Cinder volume group to something generic, e.g., devstack-vg
>>
>>  * modify the Cinder initialization and cleanup code appropriately to use
>>    the new volume group
>>
>>  * initialize the volume group in stack.sh, shortly before services are
>>    launched
>>
>>  * cleanup the volume group in unstack.sh after the services have been
>>    shutdown
>>
>> The question of how large to make the common Nova-Cinder volume group in
>> order
>> to enable LVM ephemeral Tempest testing will have to be explored.
>> Although,
>> given the tiny instance disks used in Nova Tempest tests, the current
>> Cinder volume group size may already be adequate.
>>
>> No new configuration options will be necessary, assuming the volume group
>> size
>> will not be made configurable.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
One thing to keep in mind when using AWS as an example is that the
equivalent isn't "Use LVM on Compute Node", the model is more use EBS (in
our case Cinder) Volumes for Instances.  We most certainly have this
currently and there is some testing in the gate.  It seems to be coming up
in all sorts of tangential conversations lately.   Personally I'd LOVE to
see it more widely used, which in turn would likely lead to improvements.

As far as the comment made about "poor performance" I'm not sure where that
comes from.  Sure, if you run iSCSI over a 1G network to a Cinder Volume on
a loop back device I wouldn't expect great perf.  If you run over a 10 Gig
Network to a Cinder Volume backed by a descent/real disk I don't think the
performance is as significant as some seem to think (full disclosure it's
been a while since I've actually tested and looked at this closely).  That
being said, there's a good deal of work that should be done here to tweak
it and improve the LVM driver in Cinder for example.  LVM in general tends
to be perceived as providing poor performance, but meh... some of that is
based more in fud than in data (note I said "some of it").

All of that is kinda off topic but it did come up so I thought I'd chime
in.  The real question of LVM on Compute Nodes....  I'd mostly be
interested in more feedback from folks that use that and why?  I don't have
any background or experience with it so I'd love some insight on why one
chooses LVM on the Compute Node versus File System based instances?  At
some point consolidating the LVM code in Cinder and Nova should really
happen as well (i.e. a shared library or having LVM code in oslo).  Yet
another topic and fortunately there are a few folks working on that for
Kilo.

Thanks,
John
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to