Chapter 2. Deploying the Block Storage backup service

The Block Storage (cinder) backup service is optional. You must include it in your Red Hat OpenStack Platform (RHOSP) overcloud deployment to deploy it on your Controller nodes.

2.1. Deploying your active-active Block Storage backup service

Before Red Hat OpenStack Platform (RHOSP) 17.1, the Block Storage backup service was deployed in active-passive mode and was managed by Pacemaker.

In RHOSP 17.1, the Block Storage backup service is deployed in active-active mode and therefore runs on each Controller node and is not managed by Pacemaker.

Note

When you upgrade to RHOSP 17.1, the Block Storage backup service remains in active-passive mode.

If you choose to use the Block Storage backup service, then you must include it in your RHOSP 17.1 overcloud deployment.

Prerequisites

  • An available storage source for your backup repository that uses one of the following back ends: Object Storage (swift), Red Hat Ceph Storage, NFS, or S3.

Procedure

  1. Log in to the undercloud host as the stack user.
  2. Source the stackrc undercloud credentials file:

    $ source ~/stackrc
  3. Add this environment file to the stack with your other environment files: /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml

    This file deploys the Block Storage backup service in active-active mode and sets all the heat template parameters of this service to their default settings. The default settings configure your backup repository to use the Object Storage (swift) back end and the zlib data compression algorithm.

    If the default configuration meets your deployment requirements, then you do not need to do anything further and you can deploy the overcloud.

  4. If you need to use another back end for your backup repository or to change other default values:

    1. Add these parameters and their new values to the parameter_defaults section of either a new or existing environment file. For more information about the parameters that you can change, see Changing the default Block Storage backup service parameter values.

      For example, a new environment file /home/stack/templates/custom_backup_environment_file.yaml specifies an NFS back end and changes the data compression algorithm to zstd:

      parameter_defaults:
        CinderBackupBackend: nfs
        CinderBackupNfsShare: 192.168.1.1:/var/export/cinder-backup
        CinderBackupCompressionAlgorithm: zstd
    2. Add the environment file that contains your specific parameter values to the stack with your other environment files, after the /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml file and deploy the overcloud. In this example:

      $ openstack overcloud deploy --templates
      -e [your other environment files]
      -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml
      -e /home/stack/templates/custom_backup_environment_file.yaml

Verification:

2.2. Changing the default Block Storage backup service parameter values

When you deploy the Block Storage backup service, it implements default settings for its heat template parameters. For more information, see Deploying your active-active Block Storage backup service.

You can provide your deployment specific values for these parameters.

Procedure

  1. Select and configure the back end for your backup repository. For more information, see Backup repository back-end configuration.
  2. Implement the Block Storage backup service configuration supported by your selected back end. For more information, see Block Storage backup service configuration.

2.2.1. Backup repository back-end configuration

Select and configure one of the following back ends for your backup repository.

2.2.1.1. OpenStack Object Storage service (swift) back end

Parameter

Description

Value

CinderBackupBackend

The back end of your backup repository.

Note

There are no additional parameters for this default back end.

swift

The default value.

2.2.1.2. NFS back end

Parameter

Description

Value

CinderBackupBackend

The back end of your backup repository.

nfs

CinderBackupNfsShare

The remote NFS share that you want to mount to store your backups.

Ensure that you specify the server name or IP followed by the export.

 

CinderBackupNfsMountOptions

Optional: A comma-delimited list of options for mounting your NFS share.

 

2.2.1.3. Red Hat Ceph Storage back end

Parameter

Description

Value

CinderBackupBackend

The back end of your backup repository.

ceph

CinderBackupRbdPoolName

The RBD pool name of your Ceph cluster that stores your backups.

backups

2.2.1.4. S3 back end

Parameter

Description

Value

CinderBackupBackend

The back end of your backup repository.

s3

CinderBackupS3Bucket

The S3 bucket that stores your backups.

Note

Ensure that you create this bucket on the S3 back end and that you have configured the necessary permissions to write to this bucket, before you deploy the Block Storage backup service.

volumebackups

CinderBackupS3AccessKey

The S3 Access key to connect to your S3 bucket.

 

CinderBackupS3SecretKey

The S3 Secret key to connect to your S3 bucket.

 

CinderBackupS3EndpointUrl

The URL of your S3 endpoint.

 

2.2.2. Block Storage backup service configuration

You can implement any Block Storage backup service parameter that is supported by your selected back end.

Parameter

Description

Value

CinderBackupCompressionAlgorithm

If your back end supports it, you can enable the data compression of your backup repository.

Data compression requires additional CPU power but uses less network bandwidth and storage space.

Note

You cannot specify the data compression algorithm for the Red Hat Ceph Storage back end driver. This parameter is ignored for this back end.

zlib

Alternatives:

none, bzip2, or zstd