osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[nova] local ssd disk performance


I am using the cinder-lvm backend right now and performance is quite good.
My situation is similar without the migration parts. Prior to this
arrangement I was using iscsi to mount a disk in /var/lib/nova/instances
and that also worked quite well.

If you don't mind me asking, what kind of i/o performance are you looking
for?

On Fri, Aug 2, 2019 at 12:25 PM Budai Laszlo <laszlo.budai at gmail.com> wrote:

> Thank you Daniel,
>
> My colleague found the same solution in the meantime. And that helped us
> as well.
>
> Kind regards,
> Laszlo
>
> On 8/2/19 6:50 PM, Daniel Speichert wrote:
> > For the case of simply using local disk mounted for /var/lib/nova and
> raw disk image type, you could try adding to nova.conf:
> >
> >     preallocate_images = space
> >
> > This implicitly changes the I/O method in libvirt from "threads" to
> "native", which in my case improved performance a lot (10 times) and
> generally is the best performance I could get.
> >
> > Best Regards
> > Daniel
> >
> > On 8/2/2019 10:53, Budai Laszlo wrote:
> >> Hello all,
> >>
> >> we have a problem with the performance of the disk IO in a KVM
> instance.
> >> We are trying to provision VMs with high performance SSDs. we have
> investigated different possibilities with different results ...
> >>
> >> 1. configure Nova to use local LVM storage (images_types = lvm) -
> provided the best performance, but we could not migrate our instances
> (seems to be a bug).
> >> 2. use cinder with lvm backend  and instance locality, we could migrate
> the instances, but the performance is less than half of the previous case
> >> 3. mount the ssd on /var/lib/nova/instances and use the images_type =
> raw in nova. We could migrate, but the write performance dropped to ~20% of
> the images_types = lvm performance and read performance is ~65% of the lvm
> case.
> >>
> >> do you have any idea to improve the performance for any of the cases 2
> or 3 which allows migration.
> >>
> >> Kind regards,
> >> Laszlo
> >>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190803/c5029cb4/attachment.html>