Speed up volume creation with Image-Volume cache

You can enable Image-Volume cache in the Block Storage service (cinder) to improve the speed of volume creation from frequently-used images.

Before you begin
Copy link

About this task
Copy link

When you enable Image-Volume cache, the first time you create a volume from an image, a copy of the image volume is cached in the internal Block Storage project, cinder-internal. Subsequent requests to create volumes from the image clone the cached copy instead of downloading the original image contents and copying data to the volume.

You can configure Image-Volume cache per back end. If you are using a third-party back end, refer to the storage vendor’s documentation for information about Image-Volume cache support.

You can set the limit of the Image-Volume cache to a size in GB, number of images, or both.

Procedure
Copy link

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the identifiers for your cinder-internal project and project user to the cinder template. In this example, you are using Red Hat Ceph Storage as the back end for the Block Storage service.

    Example:

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  extraMounts:
    ...
  cinder:
    template:
      cinderVolumes:
        ceph:
          customServiceConfig: |
            [DEFAULT]
            cinder_internal_tenant_project_id = <project_id>
            cinder_internal_tenant_user_id = <user_id>
            ...
    • Replace <project_id> with the ID of your cinder-internal project.
    • Replace <user_id> with the ID of your cinder-internal project user.
  2. Add the following parameters to enable Image-Volume cache and to configure the size limit of the cache and the maximum number of images that the cache can store:

    Example:

    ...
          customServiceConfig: |
            [DEFAULT]
            ...
            [ceph]
            image_volume_cache_enabled = True
            image_volume_cache_max_size_gb = <max_size>
            image_volume_cache_max_count = <max_number>
...
    • Replace <max_size> with the size limit of the cache in GB.
    • Replace <max_number> with the maximum number of images to store in the cache.
  3. Update the control plane: 
    $ oc apply -f openstack_control_plane.yaml -n openstack
  4. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 
    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip
    Append the -w option to the end of the get command to track deployment progress.

Volume-from-image optimization
Copy link

When you use the Block Storage service (cinder) as a back end for the Image service (glance), volume creation from images can be optimized with back-end-assisted cloning instead of image downloads.

When you create a bootable volume from an image that is stored as an image-volume in the Block Storage back end, the volume creation process clones the image-volume at the storage back-end level. This back-end-assisted cloning is significantly faster than the traditional method of downloading the image data from the Image service and copying it to the new volume.

In a Red Hat OpenStack Services on OpenShift (RHOSO) environment, the Block Storage service is configured with the allowed_direct_url_schemes parameter set to cinder by default. This configuration enables the service to detect when an image is stored as a Block Storage volume and use back-end-assisted cloning for bootable volume creation.

You can also enable upload-to-image optimization to improve the performance of uploading volumes to the Image service.

Requirements
  • The image must use the raw format and bare container format.
  • You must create the volume in the same project as the image.
  • The image volume and the destination volume must be on the same storage pool. The Block Storage service matches volumes based on the backend#pool identifier. For example, both volumes must be on cinder-volume-host@backend#pool_name.
  • The storage back end must support efficient volume cloning. Most back ends support this optimization, including NetApp ONTAP, Dell PowerFlex, and other back ends with clone capabilities.
  • For environments where the Image service creates multiple volumes simultaneously, use a multiattach-enabled volume type for best results.
Limitations
  • In distributed environments with multiple pools, the system can only clone images efficiently to volumes in the same pool. Volumes created in different pools use the traditional download method for the first volume creation, but can benefit from the image-volume cache feature for subsequent creations.

Optimize volume uploads to the Image service
Copy link

You can enable upload-to-image optimization in the Block Storage service (cinder) to improve the performance of uploading volumes to the Image service (glance).

Before you begin
Copy link

About this task
Copy link

When you enable this optimization, the upload-to-image operation creates a cloned volume and registers its location with the Image service instead of transferring data. This significantly improves performance for upload operations.

Procedure
Copy link

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the image_upload_use_cinder_backend parameter to the Block Storage back-end configuration. In this example, the Image service uses the Block Storage service as a back end, and the Block Storage service uses Red Hat Ceph Storage as a back end: 
    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  cinder:
    template:
      cinderVolumes:
        ceph:
          customServiceConfig: |
            [DEFAULT]
            cinder_internal_tenant_project_id = <project_id>
            cinder_internal_tenant_user_id = <user_id>
            [ceph]
            image_upload_use_cinder_backend = True
            image_upload_use_internal_tenant = True
...
    • Replace <project_id> with the ID of your cinder-internal project.
    • Replace <user_id> with the ID of your cinder-internal project user.
    • Set image_upload_use_cinder_backend to True to enable the optimization.
    • Set image_upload_use_internal_tenant to True to store image-volumes in the cinder-internal project instead of the user’s project.
  2. Update the control plane: 
    $ oc apply -f openstack_control_plane.yaml -n openstack
  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 
    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip
    Append the -w option to the end of the get command to track deployment progress.