Ce contenu n'est pas disponible dans la langue sélectionnée.
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.
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
-
Log in to the undercloud host as the
stack
user. Source the
stackrc
undercloud credentials file:$ source ~/stackrc
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.
If you need to use another back end for your backup repository or to change other default values:
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 tozstd
:parameter_defaults: CinderBackupBackend: nfs CinderBackupNfsShare: 192.168.1.1:/var/export/cinder-backup CinderBackupCompressionAlgorithm: zstd
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:
- Ensure that the Block Storage services are running correctly on their hosts and then verify that the Block Storage backup service is deployed successfully. For more information, see Verifying the Block Storage backup service deployment.
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
- Select and configure the back end for your backup repository. For more information, see Backup repository back-end configuration.
- 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. |
The default value. |
2.2.1.2. NFS back end
Parameter | Description | Value |
CinderBackupBackend | The back end of your backup repository. |
|
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. |
|
CinderBackupRbdPoolName | The RBD pool name of your Ceph cluster that stores your backups. |
|
2.2.1.4. S3 back end
Parameter | Description | Value |
CinderBackupBackend | The back end of your backup repository. |
|
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. |
|
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. |
Alternatives:
|