cinder ceph #353

Supports: xenial bionic focal groovy hirsute


Cinder is the block storage service for the Openstack project. . This charm provides a Ceph storage backend for Cinder


Cinder is the OpenStack block storage (volume) service. Ceph is a unified, distributed storage system designed for excellent performance, reliability, and scalability. Ceph-backed Cinder therefore allows for scalability and redundancy for storage volumes. This arrangement is intended for large-scale production deployments.

The cinder-ceph charm provides a Ceph (RBD) storage backend for Cinder and is used in conjunction with the cinder charm and an existing Ceph cluster (via the ceph-mon or the ceph-proxy charms).

Specialised use cases:

  • Through the use of multiple application names (e.g. cinder-ceph-1, cinder-ceph-2), multiple Ceph clusters can be associated with a single Cinder deployment.

  • A variety of storage types can be achieved with a single Ceph cluster by mapping pools with multiple cinder-ceph applications. For instance, different pools could be used for HDD or SSD devices. See option rbd-pool-name below.

Note: There is currently no upgrade path to using the cinder-ceph charm for older deployments that have the cinder and ceph-mon applications related directly. This issue is tracked in bug LP #1727184.



This section covers common and/or important configuration options. See file config.yaml for the full list of options, along with their descriptions and default values. See the Juju documentation for details on configuring applications.


The pool-type option dictates the storage pool type. See section 'Ceph pool type' for more information.


The rbd-pool-name option sets an existing rbd pool that Cinder should map to.

Ceph pool type

Ceph storage pools can be configured to ensure data resiliency either through replication or by erasure coding. This charm supports both types via the pool-type configuration option, which can take on the values of 'replicated' and 'erasure-coded'. The default value is 'replicated'.

For this charm, the pool type will be associated with Cinder volumes.

Note: Erasure-coded pools are supported starting with Ceph Luminous.

Replicated pools

Replicated pools use a simple replication strategy in which each written object is copied, in full, to multiple OSDs within the cluster.

The ceph-osd-replication-count option sets the replica count for any object stored within the 'cinder-ceph' rbd pool. Increasing this value increases data resilience at the cost of consuming more real storage in the Ceph cluster. The default value is '3'.

Important: The ceph-osd-replication-count option must be set prior to adding the relation to the ceph-mon (or ceph-proxy) application. Otherwise, the pool's configuration will need to be set by interfacing with the cluster directly.

Erasure coded pools

Erasure coded pools use a technique that allows for the same resiliency as replicated pools, yet reduces the amount of space required. Written data is split into data chunks and error correction chunks, which are both distributed throughout the cluster.

Note: Erasure coded pools require more memory and CPU cycles than replicated pools do.

When using erasure coded pools for Cinder volumes two pools will be created: a replicated pool (for storing RBD metadata) and an erasure coded pool (for storing the data written into the RBD). The ceph-osd-replication-count configuration option only applies to the metadata (replicated) pool.

Erasure coded pools can be configured via options whose names begin with the ec- prefix.

Important: It is strongly recommended to tailor the ec-profile-k and ec-profile-m options to the needs of the given environment. These latter options have default values of '1' and '2' respectively, which result in the same space requirements as those of a replicated pool.

See Ceph Erasure Coding in the OpenStack Charms Deployment Guide for more information.

Ceph BlueStore compression

This charm supports BlueStore inline compression for its associated Ceph storage pool(s). The feature is enabled by assigning a compression mode via the bluestore-compression-mode configuration option. The default behaviour is to disable compression.

The efficiency of compression depends heavily on what type of data is stored in the pool and the charm provides a set of configuration options to fine tune the compression behaviour.

Note: BlueStore compression is supported starting with Ceph Mimic.


These instructions will show how to deploy Cinder and connect it to an existing Juju-managed Ceph cluster.

Let file cinder.yaml contain the following:

  block-device: None

Deploy Cinder and add relations to essential OpenStack components:

juju deploy --config cinder.yaml cinder

juju add-relation cinder:cinder-volume-service nova-cloud-controller:cinder-volume-service
juju add-relation cinder:shared-db mysql:shared-db
juju add-relation cinder:identity-service keystone:identity-service
juju add-relation cinder:amqp rabbitmq-server:amqp

Now deploy cinder-ceph and add a relation to both the cinder and ceph-mon applications:

juju deploy cinder-ceph

juju add-relation cinder-ceph:storage-backend cinder:storage-backend
juju add-relation cinder-ceph:ceph ceph-mon:client

Additionally, when both the nova-compute and cinder-ceph applications are deployed a relation is needed between them:

juju add-relation cinder-ceph:ceph-access nova-compute:ceph-access


The OpenStack Charms project maintains two documentation guides:


Please report bugs on Launchpad.


(string) Availability zone name of this volume backend. If set, it will override the default availability zone. Supported for Pike or newer releases.
(string) Compressor to use (if any) for pools requested by this charm. . NOTE: The ceph-osd charm sets a global default for this value (defaults to 'lz4' unless configured by the end user) which will be used unless specified for individual pools.
(int) Chunks larger than this are broken into smaller blobs sizing bluestore compression max blob size before being compressed on pools requested by this charm.
(int) Value of bluestore compression max blob size for rotational media on pools requested by this charm.
(int) Value of bluestore compression max blob size for solid state media on pools requested by this charm.
(int) Chunks smaller than this are never compressed on pools requested by this charm.
(int) Value of bluestore compression min blob size for rotational media on pools requested by this charm.
(int) Value of bluestore compression min blob size for solid state media on pools requested by this charm.
(string) Policy for using compression on pools requested by this charm. . 'none' means never use compression. 'passive' means use compression when clients hint that data is compressible. 'aggressive' means use compression unless clients hint that data is not compressible. 'force' means use compression under all circumstances even if the clients hint that the data is not compressible.
(float) The ratio of the size of the data chunk after compression relative to the original size must be at least this small in order to store the compressed version on pools requested by this charm.
(int) This value dictates the number of replicas ceph must make of any object it stores within the cinder rbd pool. Of course, this only applies if using Ceph as a backend store. Note that once the cinder rbd pool has been created, changing this value will not have any effect (although it can be changed in ceph by manually configuring your ceph cluster).
(int) Defines a relative weighting of the pool as a percentage of the total amount of data in the Ceph cluster. This effectively weights the number of placement groups for the pool created to be appropriately portioned to the amount of data expected. For example, if the ephemeral volumes for the OpenStack compute instances are expected to take up 20% of the overall configuration then this value would be specified as 20. Note - it is important to choose an appropriate value for the pool weight as this directly affects the number of placement groups which will be created for the pool. The number of placement groups for a pool can only be increased, never decreased - so it is important to identify the percent of data that will likely reside in the pool.
(string) (lrc plugin) The type of the crush bucket in which each set of chunks defined by l will be stored. For instance, if it is set to rack, each group of l chunks will be placed in a different rack. It is used to create a CRUSH rule step such as step choose rack. If it is not set, no such grouping is done.
(string) Device class from CRUSH map to use for placement groups for erasure profile - valid values: ssd, hdd or nvme (or leave unset to not use a device class).
(int) (shec plugin - c) The number of parity chunks each of which includes each data chunk in its calculation range. The number is used as a durability estimator. For instance, if c=2, 2 OSDs can be down without losing data.
(int) (clay plugin - d) Number of OSDs requested to send data during recovery of a single chunk. d needs to be chosen such that k+1 <= d <= k+m-1. Larger the d, the better the savings.
(int) Number of data chunks that will be used for EC data pool. K+M factors should never be greater than the number of available zones (or hosts) for balancing.
(int) (lrc plugin - l) Group the coding and data chunks into sets of size l. For instance, for k=4 and m=2, when l=3 two groups of three are created. Each set can be recovered without reading chunks from another set. Note that using the lrc plugin does incur more raw storage usage than isa or jerasure in order to reduce the cost of recovery operations.
(int) Number of coding chunks that will be used for EC data pool. K+M factors should never be greater than the number of available zones (or hosts) for balancing.
(string) Name for the EC profile to be created for the EC pools. If not defined a profile name will be generated based on the name of the pool used by the application.
(string) EC plugin to use for this applications pool. The following list of plugins acceptable - jerasure, lrc, isa, shec, clay.
(string) (clay plugin) specifies the plugin that is used as a building block in the layered construction. It can be one of jerasure, isa, shec (defaults to jerasure).
(string) EC profile technique used for this applications pool - will be validated based on the plugin configured via ec-profile-plugin. Supported techniques are ‘reed_sol_van’, ‘reed_sol_r6_op’, ‘cauchy_orig’, ‘cauchy_good’, ‘liber8tion’ for jerasure, ‘reed_sol_van’, ‘cauchy’ for isa and ‘single’, ‘multiple’ for shec.
(string) Name of the metadata pool to be created (for RBD use-cases). If not defined a metadata pool name will be generated based on the name of the data pool used by the application. The metadata pool is always replicated, not erasure coded.
(string) Ceph pool type to use for storage - valid values include ‘replicated’ and ‘erasure-coded’.
(boolean) Flatten volumes created from snapshots to remove dependency from volume to snapshot. Supported on Queens+
(string) The RBD mirroring mode used for the Ceph pool. This option is only used with 'replicated' pool type, as it's not supported for 'erasure-coded' pool type - valid values: 'pool' and 'image'
(string) Optionally specify an existing rbd pool that cinder should map to.
(boolean) Optionally restrict Ceph key permissions to access pools as required.
(boolean) Setting this to True will configure services to log to syslog.