Chapter 3. Create the Block Storage environment file
The environment file contains the settings that you want to apply to the Block Storage service. In this case, configure the Block Storage service to store volume backups to Google Cloud. For more information about environment files, see the Director Installation and Usage guide.
Define each setting in the environment file in the following format:
Entry format
SECT/PARAM: # 1 value: CONFIG # 2
- 1
- All Block Storage settings are configured in the /etc/cinder/cinder.conf file of the node that hosts the Block Storage service. This file is divided into different sections, making it easier to manage different settings. PARAM is the setting you want to apply, and SECT is the section to which it belongs.
- 2
- CONFIG is the value you want to set to PARAM.
In this document, all parameters are declared in the DEFAULT section. The following table describes each setting required to configure Google Cloud Storage (GCS) as your backup service:
- Google Cloud backup settings
| PARAM | Default | CONFIG Description |
| backup_driver | cinder.backup.drivers.swift |
The backup driver that the Block Storage server uses. For Google Cloud Storage, use |
| backup_gcs_credential_file | The absolute path to the service account key file you created earlier in Chapter 2, Creating and downloading the GCS credentials file. | |
| backup_gcs_bucket | The GCS bucket, or object storage repository that you want to use, which may or may not exist. If you specify a non-existent bucket, the Google Cloud Storage backup driver creates one using the name you specify here. For more information, see Buckets and Bucket name requirements. | |
| backup_gcs_bucket_location | US |
The location of the GCS bucket. This value is only used if you specify a non-existent bucket in For more information, see Bucket Locations. |
| backup_gcs_project_id |
The project ID of the service account you are using, as noted in the | |
| backup_gcs_object_size | 52428800 | The size (in bytes) of GCS backup objects. |
| backup_gcs_block_size | 32768 |
The size (in bytes) that changes are tracked for incremental backups. This value must be a multiple of the |
| backup_gcs_user_agent | gcscinder | The HTTP user-agent string for the GCS API. |
| backup_gcs_reader_chunk_size | 2097152 | GCS objects are downloaded in chunks of this size (in bytes). |
| backup_gcs_writer_chunk_size | 2097152 |
GCS objects are uploaded in chunks of this size (in bytes). To upload files as a single chunk instead, use the value |
| backup_gcs_num_retries | 3 | Number of retries to attempt. |
| backup_gcs_storage_class | NEARLINE |
Storage class of the GCS bucket. This value is used if you specify a non-existent bucket in |
| backup_gcs_retry_error_codes | 429 | List of GCS error codes. |
| backup_gcs_enable_progress_timer | True |
Boolean to enable or disable the timer for sending periodic progress notifications to the Telemetry service ( |
When creating new buckets, Google Cloud Storage charges according to the storage class that you choose (backup_gcs_storage_class). The default NEARLINE class is appropriate for backup services.
You cannot edit the location or class of a bucket after it is created. For more information, see Managing a bucket’s storage class or location.
The following sample shows the typical contents of an environment file to configure GCS as a backup service:
/home/stack/templates/gcs-backup.yaml
parameter_defaults:
ControllerExtraConfig: # 1
cinder::config::cinder_config:
DEFAULT/backup_driver
value: cinder.backup.drivers.gcs.GoogleBackupDriver
DEFAULT/backup_gcs_credential_file
value: /etc/cinder/Cloud-Backup.json
DEFAULT/backup_gcs_bucket
value: mycinderbucket
DEFAULT/backup_gcs_project_id
value: cloud-backup-1370
DEFAULT/backup_gcs_user_agent
value: myuseragent
- 1
ControllerExtraConfigdefines custom settings that you want to apply to all Controller nodes. Include thecinder::config::cinder_configto apply the settings to the Block Storage (cinder) service.
After you create the environment file, re-deploy the overcloud with the new configuration. For more information, see Chapter 4, Re-deploying the overcloud.
