Este conteúdo não está disponível no idioma selecionado.

Chapter 5. Image service with multiple stores


The Red Hat OpenStack Platform (RHOSP) Image service (glance) supports using multiple stores with distributed edge architecture so that you can have an image pool at every edge site.

5.1. Image copies on multiple stores

When you use multiple stores with distributed edge architecture, you can have an image pool at every edge site. You can copy images between the central site, which is also known as the hub site, and the edge sites.

The image metadata contains the location of each copy. For example, an image present on two edge sites is exposed as a single UUID with three locations: the central site plus the two edge sites. This means you can have copies of image data that share a single UUID on many stores. For more information about locations, see Understanding the location of images.

With a RADOS Block Device (RBD) image pool at every edge site, you can boot Virtual Machines (VMs) quickly by using Ceph RBD copy-on-write (COW) and snapshot layering technology. This means that you can boot VMs from volumes and have live migration. For more information about layering with Ceph RBD, see Ceph block device layering in the Block Device Guide.

When you launch an instance at an edge site, the required image is copied to the local Image service (glance) store automatically. However, you can copy images in advance from the central image store to edge sites to save time during instance launch.

5.2. Requirements of storage edge architecture

Refer to the following requirements to use images with edge sites:

  • A copy of each image must exist in the Image service (glance) at the central location.
  • You must copy images from an edge site to the central location before you can copy them to other edge sites.
  • You must use raw images when deploying a Distributed Compute Node (DCN) architecture with Red Hat Ceph Storage.
  • For each site, you must assign the same value to the NovaComputeAvailabilityZone and CinderStorageAvailabilityZone parameters.

5.3. Multiple Block Storage service stores

You can configure multiple Block Storage service (cinder) back ends for the Image service (glance), and configure volume types for each back end by using the enabled_backends and cinder_volume_type configuration options in the glance-api.conf file.

While you can associate one back end with multiple volume types in the Block Storage service, you can only associate a back end with one volume type in the Image service.

The Image service generates a location URL with a unique ID to identify which back end an image is stored in. When you upgrade from using a single Block Storage service store to using multiple Block Storage service stores, the location URLs for legacy images are updated from cinder://volume-id to cinder://store-name/volume-id.

Example 1: New deployment with two volume types

The following example shows the Image service configuration in the glance-api.conf file for a new deployment when the Block Storage service has two volume types, for example, fast and slow:

[DEFAULT]
# list of enabled stores identified by their property group name
enabled_backends = fast:cinder, slow:cinder

# the default store, if not set glance-api service will not start
[glance_store]
default_backend = fast

# conf props for fast store instance
[fast]
rootwrap_config = /etc/glance/rootwrap.conf
cinder_volume_type = glance-fast
description = LVM based cinder store
cinder_catalog_info = volumev2::publicURL
cinder_store_auth_address = http://localhost/identity/v3
cinder_store_user_name = glance
cinder_store_password = admin
cinder_store_project_name = service
...

# conf props for slow store instance
[slow]
rootwrap_config = /etc/glance/rootwrap.conf
cinder_volume_type = glance-slow
description = NFS based cinder store
cinder_catalog_info = volumev2::publicURL
cinder_store_auth_address = http://localhost/identity/v3
cinder_store_user_name = glance
cinder_store_password = admin
cinder_store_project_name = service
...
Copy to Clipboard Toggle word wrap

Example 2: Upgrade from single store to multiple stores

The following example shows the Image service configuration in the glance-api.conf file for an upgrade from a single Block Storage service store to multiple stores. You must identify the default_volume_type that is used in cinder.conf, and update the cinder_volume_type in glance-api.conf to match:

# new configuration in glance
[DEFAULT]
enabled_backends = old:cinder, new:cinder

[glance_store]
default_backend = new

rootwrap_config = /etc/glance/rootwrap.conf
cinder_volume_type = glance-new
description = LVM based cinder store
cinder_catalog_info = volumev2::publicURL
cinder_store_auth_address = http://localhost/identity/v3
cinder_store_user_name = glance
cinder_store_password = admin
cinder_store_project_name = service
...
Copy to Clipboard Toggle word wrap

5.4. Importing an image to multiple stores

Use the interoperable image import workflow to import image data into multiple Red Hat Ceph Storage clusters. You can import images to the Image service (glance) that are available on the local file system or through a web server.

If you import an image from a web server, the image can be imported into multiple stores at once. If the image is not available on a web server, you can import the image from a local file system into the central store and then copy it to additional stores. For more information, see Copy an existing image to multiple stores.

Use the Image service command-line client for image management.

Important

Always store an image copy on the central site, even if there are no instances using the image at the central location. For more information about importing images into the Image service, see the Deploying a Distributed Compute Node architecture guide.

5.4.1. Managing image import failures

You can manage failures of the image import operation by using the --allow-failure parameter:

  • If the value of the --allow-failure parameter to true, the image status becomes active after the first store successfully imports the data. This is the default setting. You can view a list of stores that failed to import the image data by using the os_glance_failed_import image property.
  • If you set the value of the --allow-failure parameter to false, the image status only becomes active after all specified stores successfully import the data. Failure of any store to import the image data results in an image status of failed. The image is not imported into any of the specified stores.

5.4.2. Importing image data to multiple stores

Because the default setting of the --allow-failure parameter is true, you do not need to include the parameter in the command if it is acceptable for some stores to fail to import the image data.

Note

This procedure does not require all stores to successfully import the image data.

Procedure

  • Import image data to multiple, specified stores:

    $ glance image-create-via-import \
    --container-format bare \
    --name <image-name> \
    --import-method web-download \
    --uri <uri> \
    --stores <store-1>,<store-2>,<store-3>
    Copy to Clipboard Toggle word wrap
    • Replace <image-name> with the name of the image you want to import.
    • Replace <uri> with the URI of the image.
    • Replace <store-1>, <store-2>, and <store-3> with the names of the stores to which you want to import the image data.
    • Alternatively, replace --stores with --all-stores true to upload the image to all the stores.
Note

The glance image-create-via-import command, which automatically converts the QCOW2 image to RAW format, works only with the web-download method. The glance-direct method is available, but it works only in deployments with a configured shared file system.

5.4.3. Importing image data to multiple stores without failure

This procedure requires all stores to successfully import the image data.

Procedure

  1. Import image data to multiple, specified stores:

    $ glance image-create-via-import \
    --container-format bare \
    --name <image-name> \
    --import-method web-download \
    --uri <uri> \
    --stores <store-1>,<store-2>,<store-3>
    Copy to Clipboard Toggle word wrap
    • Replace <image-name> with the name of the image you want to import.
    • Replace <uri> with the URI of the image.
    • Replace <store-1>, <store-2>, and <store-3> with the names of stores to which you want to copy the image data.
    • Alternatively, replace --stores with --all-stores true to upload the image to all the stores.

      Note

      With the --allow-failure parameter set to false, the Image service (glance) does not ignore stores that fail to import the image data. You can view the list of failed stores with the image property os_glance_failed_import. For more information, see Section 5.5, “Checking the progress of the image import operation”.

  2. Verify that the image data was added to specific stores:

    $ glance image-show <image-id> | grep stores
    Copy to Clipboard Toggle word wrap

    Replace <image-id> with the ID of the original existing image.

    The output displays a comma-delimited list of stores.

5.4.4. Importing image data to a single store

You can use the Image service (glance) to import image data to a single store.

Procedure

  1. Import image data to a single store:

    $ glance image-create-via-import \
    --container-format bare \
    --name <image-name> \
    --import-method web-download \
    --uri <uri> \
    --store <store>
    Copy to Clipboard Toggle word wrap
    • Replace <image-name> with the name of the image you want to import.
    • Replace <uri> with the URI of the image.
    • Replace <store> with the name of the store to which you want to copy the image data.

      Note

      If you do not include the options of --stores, --all-stores, or --store in the command, the Image service creates the image in the central store.

  2. Verify that the image data was added to specific store:

    $ glance image-show <image-id> | grep stores
    Copy to Clipboard Toggle word wrap
    • Replace <image-id> with the ID of the original existing image.

      The output displays a comma-delimited list of stores.

5.5. Checking the progress of the image import operation

The interoperable image import workflow sequentially imports image data into stores. The size of the image, the number of stores, and the network speed between the central site and the edge sites impact how long it takes for the image import operation to complete.

You can follow the progress of the image import by looking at two image properties, which appear in notifications sent during the image import operation:

  • The os_glance_importing_to_stores property lists the stores that have not imported the image data. At the beginning of the import, all requested stores show up in the list. Each time a store successfully imports the image data, the Image service removes the store from the list.
  • The os_glance_failed_import property lists the stores that fail to import the image data. This list is empty at the beginning of the image import operation.
Note

In the following procedure, the environment has three Red Hat Ceph Storage clusters: the central store and two stores at the edge, dcn0 and dcn1.

Procedure

  1. Verify that the image data was added to specific stores:

    $ glance image-show <image-id>
    Copy to Clipboard Toggle word wrap
    • Replace <image-id> with the ID of the original existing image.

      The output displays a comma-delimited list of stores similar to the following example snippet:

      | os_glance_failed_import       |
      | os_glance_importing_to_stores | central,dcn0,dcn1
      | status                        | importing
      Copy to Clipboard Toggle word wrap
  2. Monitor the status of the image import operation. When you precede a command with watch, the command output refreshes every two seconds.

    $ watch glance image-show <image-id>
    Copy to Clipboard Toggle word wrap
    • Replace <image-id> with the ID of the original existing image.

      The status of the operation changes as the image import operation progresses:

      | os_glance_failed_import       |
      | os_glance_importing_to_stores | dcn0,dcn1
      | status                        | importing
      Copy to Clipboard Toggle word wrap

      Output that shows that an image failed to import resembles the following example:

      | os_glance_failed_import       | dcn0
      | os_glance_importing_to_stores | dcn1
      | status                        | importing
      Copy to Clipboard Toggle word wrap

      After the operation completes, the status changes to active:

      | os_glance_failed_import       | dcn0
      | os_glance_importing_to_stores |
      | status                        | active
      Copy to Clipboard Toggle word wrap

5.6. Copying an existing image to multiple stores

This feature enables you to copy existing images using Red Hat OpenStack Image service (glance) image data into multiple Red Hat Ceph Storage stores at the edge by using the interoperable image import workflow.

Note

The image must be present at the central site before you copy it to any edge sites. Only the image owner or administrator can copy existing images to newly added stores.

You can copy existing image data either by setting --all-stores to true or by specifying specific stores to receive the image data.

  • The default setting for the --all-stores option is false. If --all-stores is false, you must specify which stores receive the image data by using --stores <store-1>,<store-2>. If the image data is already present in any of the specified stores, the request fails.
  • If you set all-stores to true, and the image data already exists in some of the stores, then those stores are excluded from the list.

After you specify which stores receive the image data, the Image service (glance) copies data from the central site to a staging area. Then the Image service imports the image data by using the interoperable image import workflow. For more information, see Importing an image to multiple stores.

Use the Image service command-line client for image management.

Important

Red Hat recommends that administrators carefully avoid closely timed image copy requests. Two closely timed copy-image operations for the same image causes race conditions and unexpected results. Existing image data remains as it is, but copying data to new stores fails.

5.6.1. Copying an image to all stores

Use the following procedure to copy image data to all available stores.

Procedure

  1. Copy image data to all available stores:

    $ glance image-import <image-id> \
    --all-stores true \
    --import-method copy-image
    Copy to Clipboard Toggle word wrap
    • Replace <image-id> with the name of the image you want to copy.
  2. Confirm that the image data successfully replicated to all available stores:

    $ glance image-list --include-stores
    Copy to Clipboard Toggle word wrap

    For information about how to check the status of the image import operation, see Section 5.5, “Checking the progress of the image import operation”.

5.6.2. Copying an image to specific stores

Use the following procedure to copy image data to specific stores.

Procedure

  1. Copy image data to specific stores:

    $ glance image-import <image-id> \
    --stores <store-1>,<store-2> \
    --import-method copy-image
    Copy to Clipboard Toggle word wrap
    • Replace <image-id> with the name of the image you want to copy.
    • Replace <store-1> and <store-2> with the names of the stores to which you want to copy the image data.
  2. Confirm that the image data successfully replicated to the specified stores:

    $ glance image-list --include-stores
    Copy to Clipboard Toggle word wrap

    For information about how to check the status of the image import operation, see Section 5.5, “Checking the progress of the image import operation”.

5.7. Deleting an image from a specific store

Delete an existing image copy on a specific store by using the Red Hat OpenStack Platform (RHOSP) Image service (glance).

Use the Image service command-line client for image management.

Procedure

  • Delete an image from a specific store:

    $ glance stores-delete --store <store-id> <image-id>
    Copy to Clipboard Toggle word wrap
  • Replace <store-id> with the name of the store on which the image copy should be deleted.
  • Replace <image-id> with the ID of the image you want to delete.
Warning

The glance image-delete command permanently deletes the image across all the sites. All image copies are deleted, as well as the image instance and metadata.

5.8. Listing image locations and location properties

Although an image can be present on multiple sites, there is only a single Universal Unique Identifier (UUID) for a given image. The image metadata contains the locations of each copy. For example, an image present on two edge sites is exposed as a single UUID with three locations: the central site and the two edge sites.

Note

Use the Image service (glance) command-line client instead of the OpenStack command-line client for image management. However, use the openstack image show command to list image location properties. The glance image-show command output does not include locations.

Procedure

  1. Show the sites on which a copy of the image exists:

    $ glance image-show ID | grep "stores"
    
    | stores |  default_backend,dcn1,dcn2
    Copy to Clipboard Toggle word wrap

    In the example, the image is present on the central site, the default_backend, and on the two edge sites dcn1 and dcn2.

  2. Alternatively, you can run the glance image-list command with the --include-stores option to see the sites where the images exist:

    $ glance image-list --include-stores
    
    | ID                                   | Name    | Stores
    
    | 2bd882e7-1da0-4078-97fe-f1bb81f61b00 | cirros | default_backend,dcn1,dcn2
    Copy to Clipboard Toggle word wrap
  3. List the image location properties to show the details of each location:

    $ openstack image show ID -c properties
    
    | properties |
    
    (--- cut ---)
    locations='[{'url': 'rbd://79b70c32-df46-4741-93c0-8118ae2ae284/images/2bd882e7-1da0-4078-97fe-f1bb81f61b00/snap', 'metadata': {'store': 'default_backend'}}, {'url': 'rbd://63df2767-8ddb-4e06-8186-8c155334f487/images/2bd882e7-1da0-4078-97fe-f1bb81f61b00/snap', 'metadata': {'store': 'dcn1'}}, {'url': 'rbd://1b324138-2ef9-4ef9-bd9e-aa7e6d6ead78/images/2bd882e7-1da0-4078-97fe-f1bb81f61b00/snap', 'metadata': {'store': 'dcn2'}}]',
    (--- cut --)
    Copy to Clipboard Toggle word wrap

    The image properties show the different Ceph RBD URIs for the location of each image.

    In the example, the central image location URI is:

    rbd://79b70c32-df46-4741-93c0-8118ae2ae284/images/2bd882e7-1da0-4078-97fe-f1bb81f61b00/snap', 'metadata': {'store': 'default_backend'}}
    Copy to Clipboard Toggle word wrap

    The URI is composed of the following data:

    • 79b70c32-df46-4741-93c0-8118ae2ae284 corresponds to the central Ceph FSID. Each Ceph cluster has a unique FSID.
    • The default value for all sites is images, which corresponds to the Ceph pool on which the images are stored.
    • 2bd882e7-1da0-4078-97fe-f1bb81f61b00 corresponds to the image UUID. The UUID is the same for a given image regardless of its location.
    • The metadata shows the glance store to which this location maps. In this example, it maps to the default_backend, which is the central hub site.
Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat