Configuration options

About

VolumeCare configuration is stored in the StorPool cluster’s key-value store in the form of a section based configuration file. It can be viewed and edited with storpool_vcctl tool (see VolumeCare control tool). storpool_vcctl config show will print the current configuration, and storpool_vcctl config edit will open an editor to alter the configuration.

Note

Initially, the VolumeCare configuration can be created in a text file in /etc/storpool/volumecare.conf and the VolumeCare daemon will transfer it automatically to the key-value store. Once the configuration is transferred, the text file will become obsolete.

The configuration file consists of four types of sections: format, volumecare, policy, and template. This document provides details about the format and volumecare sections. For the policy and template sections, see Retention policies.

[format] section

The [format] section is mandatory and describes the version of the format for the configuration through the version=X.Y option. Currently, only version 1.0 is available.

[volumecare] section

The [volumecare] section describes working parameters for the service.

Mode

A mode option should be specified which defines the working routine of the service and can be one of the following:

  • normal - for a single cluster with snapshots kept in it

  • primary - for a primary (multi) cluster which will send snapshots to a backup cluster

  • backup - for a backup cluster which only stores snapshots from other clusters

  • multi_backup - for a multiclustered backup cluster which only stores snapshots from other clusters

  • primary_backup - for a situation of two clusters sending backups to each other

Note

VolumeCare working in backup and multi_backup modes can have multiple primary clusters sending backups. This is natively supported provided that policies defined in all the primary clusters do not contradict each other and all of them are defined in the backup cluster as well.

When the primary or primary_backup mode is selected, a remote location also needs to be specified in the configuration. It will tell the VolumeCare which is the backup cluster that should receive snapshots from it. This is achieved by setting the remote=<location-name> option. Its value should be the same as a remote location name seen in storpool location list.

Note

  • As of version 1.21 the remote can be overriden per policy by setting the remote=<location-name> directly in the policy definition.

  • As of version 1.23 you can use two subclusters of the same StorPool multicluster as a primary and backup location. To do this, the use_cluster_id=1 setting must be applied in both clusters.

Tags

By default, no tag except vc-policy is inherited by VolumeCare’s snapshots from the source volumes. To enable selective tag inheritance, use the inherit_tags option. It accepts a list of tags that will be inherited from each volume to all of its snapshots. If a tag from inherit_tags is missing on a volume, its snapshots will not have this tag defined at all.

For example, consider the following volumes and VolumeCare configuration fragment:

# VolumeCare configuration fragment
[volumecare]
inherit_tags=my_tag,my-other-tag

# Volumes
| vc-inherit-tags-example-vol-1 | ... | my_tag=one                                                                    |
| vc-inherit-tags-example-vol-2 | ... | my_tag=two skip_the_tag=three                                                 |
| vc-inherit-tags-example-vol-3 | ... | my-other-tag=six my_tag=four skip_the_tag=five                                |
| vc-inherit-tags-example-vol-4 | ... | my-other-tag=nine my_tag=seven skip_the_tag=eight                             |
| vc-inherit-tags-example-vol-5 | ... | skip_this_other_other_tag=eleven skip_this_other_tag=twelve skip_this_tag=ten |
| vc-inherit-tags-example-vol-6 | ... |                                                                               |

The resulting snapshots from this policy will be:

| <VC_PREFIX>--vc-inherit-tags-example-vol-1 | my_tag=one vc-policy=<CONFIGURED_VC_POLICY>                     |
| <VC_PREFIX>--vc-inherit-tags-example-vol-2 | my_tag=two vc-policy=<CONFIGURED_VC_POLICY>                     |
| <VC_PREFIX>--vc-inherit-tags-example-vol-3 | my-other-tag=six my_tag=four vc-policy=<CONFIGURED_VC_POLICY>   |
| <VC_PREFIX>--vc-inherit-tags-example-vol-4 | my-other-tag=nine my_tag=seven vc-policy=<CONFIGURED_VC_POLICY> |
| <VC_PREFIX>--vc-inherit-tags-example-vol-5 | vc-policy=<CONFIGURED_VC_POLICY>                                |
| <VC_PREFIX>--vc-inherit-tags-example-vol-6 | vc-policy=<CONFIGURED_VC_POLICY>                                |

Driver

Last thing that needs to specified is the driver option. Currently only driver=storpool is supported.

Tuning

Some additional options for the [volumecare] section are available to fine-tune the VolumeCare behavior:

  • scan_interval_s - default: 60 (seconds). Configures how often the VolumeCare daemon will re-scan the cluster for changes. Higher values could be beneficial in big backup clusters. Lowering this to less than 30 seconds requires extreme caution as re-scanning is a time heavy operation.

  • care_obsolete_check_tout_s - default: 600 (10 minutes). The VolumeCare will periodically check if snapshots have expired. This sets the maximum amount of time between these checks.

Task control

Internally the VolumeCare daemon has a queue of scheduled tasks to perform. Below are a few options that can delay task execution times in different manners.

The two options care_max_ops and care_obsolete_check_tout_s should be used together. You can instruct the VolumeCare to not execute too many tasks together. It will wait the set number of seconds after it executes the set amount of tasks immediately one after the other.

  • care_max_ops - default: 10. The number of tasks that can be executed without a pause.

  • care_obsolete_check_tout_s - default: 1 (second). Time in seconds to wait (pause) between a batch of task executions.

A finer method of task control allows to spread/pace the snapshot deletion and creation tasks. This is achieved through three parameters:

  • create_delay - default: 0 (seconds, floating point). Time in seconds to wait between executing two snapshot creation tasks.

  • delete_delay - default: 0 (seconds, floating point). Time in seconds to wait between executing two snapshot deletion tasks.

  • create_delete_delay - default: 0 (seconds, floating point). Time in seconds to wait between executing a creation and a deletion task.

Warning

Delaying snapshot tasks too much can lead to VolumeCare not being able to execute all the needed operations thus failing to do its job. Use these options with care and after discussing them with the StorPool support team.

More information

Example configurations