Open Stack

There has been some talk in cinder meetings about making cinder<->glance
interactions more efficient. They are already optimised in some
deployments, e.g. ceph glance and ceph cinder, and some backends cache
glance images so that many volumes created from the same image becomes very
efficient. (search the meeting logs or channel logs for 'public snapshot'
to get some entry points into the discussions)

I'd like to see more work done on this, and perhaps re-examine a cinder
backend to glance. This would give some of what you're suggesting
(particularly fast, low traffic un-shelve), and there is more that can be
done to improve that performance, particularly if we can find a better
performing generic CoW technology than QCOW2.

As suggested in the review, in the short term you might be better
experimenting with moving to boot-from-volume instances if you have a
suitable cinder deployed, since that gives you some of the performance
improvements already.

On 16 February 2015 at 12:10, Kekane, Abhishek <Abhishek.Kekane at nttdata.com>
wrote:

>  Hi Devs,
>
>
>
> Problem Statement: Performance and storage efficiency of
> shelving/unshelving instance booted from image is far worse than instance
> booted from volume.
>
>
>
> When you unshelve hundreds of instances at the same time, instance
> spawning time varies and it mainly depends on the size of the instance
> snapshot and
>
> the network speed between glance and nova servers.
>
>
>
> If you have configured file store (shared storage) as a backend in Glance
> for storing images/snapshots, then it's possible to improve the performance
> of
>
> unshelve instance dramatically by configuring
> nova.image.download.FileTransfer in nova. In this case, it simply copies
> the instance snapshot as if it is
>
> stored on the local filesystem of the compute node. But then again in this
> case, it is observed the network traffic between shared storage servers and
>
> nova increases enormously resulting in slow spawning of the instances.
>
>
>
> I would like to gather some thoughts about how we can improve the
> performance of unshelve api (booted from image only) in terms of
> downloading large
>
> size instance snapshots from glance.
>
>
>
> I have proposed a nova-specs [1] to address this performance issue. Please
> take a look at it.
>
>
>
> During the last nova mid-cycle summit, Michael Still
> <https://review.openstack.org/#/q/owner:mikal%2540stillhq.com+status:open,n,z>
> has suggested alternative solutions to tackle this issue.
>
>
>
> Storage solutions like ceph (Software based) and NetApp (Hardare based)
> support exposing images from glance to nova-compute and cinder-volume with
>
> copy in write feature. This way there will be no need to download the
> instance snapshot and unshelve api will be pretty faster than getting it
>
> from glance.
>
>
>
> Do you think the above performance issue should be handled in the
> OpenStack software as described in nova-specs [1] or storage solutions like
>
> ceph/NetApp should be used in production environment? Apart from
> ceph/NetApp solutions, are there any other options available in the market.
>
>
>
> [1] https://review.openstack.org/#/c/135387/
>
>
>
> Thank You,
>
>
>
> Abhishek Kekane
>
> ______________________________________________________________________
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150216/30227ed1/attachment.html>