openstack
/
charm-cinder-ceph
Code Issues Proposed changes
Juju Charm - Cinder Ceph backend
313 Commits 34 Branches 5 Tags 3.3 MiB
Python 99.6%
Shell 0.3%
Go to file
Jadon Naas 4918529125 Add docs key and point at Discourse 
Add the 'docs' key and point it at a Discourse topic
previously populated with the charm's README contents.

When the new charm revision is released to the Charmhub,
this Discourse-based content will be displayed there. In
the absense of the this new key, the Charmhub's default
behaviour is to display the value of the charm's
'description' key.

Change-Id: I2f0e316697aef630a321c6fca1553d337b04ddf6
(cherry picked from commit 0536c8a529)
 		2023-07-25 22:04:46 +00:00
actions Update tox.ini files from release-tools gold copy 2016-09-09 19:22:05 +00:00
charmhelpers Updates to enable jammy and finalise charmcraft builds 2022-04-13 15:14:56 +01:00
files Sync charm/ceph helpers, tox, and requirements 2019-09-30 22:41:38 -05:00
hooks Add support of a common volume_backend_name 2021-03-30 15:10:14 +09:00
lib Update tox.ini files from release-tools gold copy 2016-09-09 19:22:05 +00:00
templates Add marker to avoid empty directory problem for git migration 2015-11-06 12:37:56 +00:00
tests Update the bundles to use the stable track, edge risk for yoga 2022-10-28 15:23:20 -03:00
unit_tests Add support of a common volume_backend_name 2021-03-30 15:10:14 +09:00
.gitignore Update to classic charms to build using charmcraft in CI 2022-02-17 12:30:07 -05:00
.gitreview Updates for stable branch creation 2022-04-15 11:43:48 +01:00
.project Initial version of charm 2014-01-23 16:14:44 +00:00
.pydevproject Fix support for cinder ceph rbd on Ocata 2017-03-13 13:43:07 +00:00
.stestr.conf Replace ostestr with stestr in testing framework. 2019-03-07 17:10:57 -05:00
.zuul.yaml Updates to enable jammy and finalise charmcraft builds 2022-04-13 15:14:56 +01:00
LICENSE Re-license charm as Apache-2.0 2016-07-01 17:22:51 +01:00
Makefile Sync helpers for 20.05 2020-05-20 12:28:22 +02:00
README.md Add note about lack of upgrade path 2021-04-07 19:14:27 -04:00
build-requirements.txt Update to classic charms to build using charmcraft in CI 2022-02-17 12:30:07 -05:00
charm-helpers-hooks.yaml Updates for stable branch creation 2022-04-15 11:43:48 +01:00
charmcraft.yaml Updates to enable jammy and finalise charmcraft builds 2022-04-13 15:14:56 +01:00
config.yaml Add support of a common volume_backend_name 2021-03-30 15:10:14 +09:00
copyright Re-license charm as Apache-2.0 2016-07-01 17:22:51 +01:00
icon.svg Update charm icon 2017-08-02 17:55:03 +01:00
metadata.yaml Add docs key and point at Discourse 2023-07-25 22:04:46 +00:00
osci.yaml Update the bundles to use the stable track, edge risk for yoga 2022-10-28 15:23:20 -03:00
pip.sh Add xena bundles 2021-09-30 13:29:08 +00:00
rename.sh Update to classic charms to build using charmcraft in CI 2022-02-17 12:30:07 -05:00
requirements.txt Updates to enable jammy and finalise charmcraft builds 2022-04-13 15:14:56 +01:00
revision Fixes from testing 2014-01-23 16:38:22 +00:00
setup.cfg Initial version of charm 2014-01-23 16:14:44 +00:00
test-requirements.txt Update the bundles to use the stable track, edge risk for yoga 2022-10-28 15:23:20 -03:00
tox.ini Pin tox to < 4.0.0 2023-01-13 15:02:44 -05:00

README.md

Overview

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.

Usage

Configuration

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.

pool-type

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

rbd-pool-name

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.

Deployment

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:

cinder:
  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

Documentation

The OpenStack Charms project maintains two documentation guides:

Bugs

Please report bugs on Launchpad.