openstack
/
charm-ceph-fs
Code Issues Proposed changes
charm-ceph-fs/src
History
Peter Matulis a44894a249 Update README for Ceph EC pools 
This updates the README for erasure coded
Ceph pools for the case of CephFS.

The new text should be as similar as possible
for all the charms that support configuration
options for EC pools. See the below review for
the first of these charms whose README has been
updated.

https://review.opendev.org/#/c/749824/

Other minor improvements.

Change-Id: Ic6543e3241048591818358c972eadecd6ceab50c
 		2020-10-08 20:11:45 +00:00
..
actions Add .gitreview and clean up repo 2017-01-06 08:29:43 -08:00
files Sync charm/ceph helpers, tox, and requirements 2019-09-30 22:41:33 -05:00
lib Fix Ceph upgrade issue by porting charm to common framework 2020-06-12 08:24:57 +02:00
reactive Add BlueStore Compression support 2020-10-06 16:51:52 +02:00
templates Fix Ceph upgrade issue by porting charm to common framework 2020-06-12 08:24:57 +02:00
tests Add BlueStore Compression support 2020-10-06 16:51:52 +02:00
README.md Update README for Ceph EC pools 2020-10-08 20:11:45 +00:00
actions.yaml Add .gitreview and clean up repo 2017-01-06 08:29:43 -08:00
config.yaml Add BlueStore Compression support 2020-10-06 16:51:52 +02:00
copyright Add .gitreview and clean up repo 2017-01-06 08:29:43 -08:00
icon.svg Update charm icon 2017-07-31 13:48:41 -05:00
layer.yaml Fix Ceph upgrade issue by porting charm to common framework 2020-06-12 08:24:57 +02:00
metadata.yaml Updates for 20.08 cycle start for groovy and libs 2020-07-09 08:48:49 +00:00
test-requirements.txt Release sync for 20.08 2020-07-27 20:49:28 +01:00
tox.ini Release sync for 20.08 2020-07-27 20:49:28 +01:00
wheelhouse.txt Remove duplicate requirement 2020-07-02 11:50:04 +00:00

README.md

Overview

Ceph is a unified, distributed storage system designed for excellent performance, reliability, and scalability.

The ceph-fs charm deploys the metadata server daemon (MDS) for the Ceph distributed file system (CephFS). The deployment is done within the context of an existing Ceph cluster.

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. A YAML file (e.g. ceph-osd.yaml) is often used to store configuration options. 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.

source

The source option states the software sources. A common value is an OpenStack UCA release (e.g. 'cloud:xenial-queens' or 'cloud:bionic-ussuri'). See Ceph and the UCA. The underlying host's existing apt sources will be used if this option is not specified (this behaviour can be explicitly chosen by using the value of 'distro').

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 CephFS 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 'ceph-fs-data' cephfs 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 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 CephFS file systems two pools will be created: a replicated pool (for storing MDS metadata) and an erasure coded pool (for storing the data written into a CephFS volume). 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.

Deployment

To deploy a single MDS node within an existing Ceph cluster:

juju deploy ceph-fs
juju add-relation ceph-fs:ceph-mds ceph-mon:mds

High availability

Highly available CephFS is achieved by deploying multiple MDS servers (i.e. multiple ceph-fs units).

Actions

This section lists Juju actions supported by the charm. Actions allow specific operations to be performed on a per-unit basis. To display action descriptions run juju actions ceph-fs. If the charm is not deployed then see file actions.yaml.

  • get-quota
  • remove-quota
  • set-quota

Bugs

Please report bugs on Launchpad.

For general charm questions refer to the OpenStack Charm Guide.