[Openstack-operators] [openstack-dev][openstack-operators][cinder] max_concurrent_builds in Cinder

Ivan Kolodyazhny e0ne at e0ne.info
Mon May 23 14:32:45 UTC 2016


Hi developers and operators,
I would like to get any feedback from you about my idea before I'll start
work on spec.

In Nova, we've got max_concurrent_builds option [1] to set 'Maximum number
of instance builds to run concurrently' per each compute. There is no
equivalent Cinder.

Why do we need it for Cinder? IMO, it could help us to address following
issues:

   - Creation of N volumes at the same time increases a lot of resource
   usage by cinder-volume service. Image caching feature [2] could help us a
   bit in case when we create volume form image. But we still have to upload N
   images to the volumes backend at the same time.
   - Deletion on N volumes at parallel. Usually, it's not very hard task
   for Cinder, but if you have to delete 100+ volumes at once, you can fit
   different issues with DB connections, CPU and memory usages. In case of
   LVM, it also could use 'dd' command to cleanup volumes.
   - It will be some kind of load balancing in HA mode: if cinder-volume
   process is busy with current operations, it will not catch message from
   RabbitMQ and other cinder-volume service will do it.
   - From users perspective, it seems that better way is to create/delete N
   volumes a bit slower than fail after X volumes were created/deleted.


[1]
https://github.com/openstack/nova/blob/283da2bbb74d0a131a66703516d16698a05817c7/nova/conf/compute.py#L161-L163
[2]
https://specs.openstack.org/openstack/cinder-specs/specs/liberty/image-volume-cache.html

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160523/fe216400/attachment.html>


More information about the OpenStack-operators mailing list