Protection Manager won't thin provision when space is available

[reide]

I have a secondary resource pool configured for SnapVault backups and OSSV client backups.  It has 4.5 GB of free space in it. I can manually thin-provision a 10 GB volume, and manually assign it to a Dataset for OSSV backups and it works just fine. However, if I attempt to let Protection Manager automatically thin-provision a 10 GB volume from this exact same resource pool, it fails.  It tells me I must have 10 GB of free space in my resource pool. If it's thin-provisioning, why does it require this?

Conformance Results

=== SEVERITY ===
Error: Attention: Provisioning a new flexible volume (backup secondary) failed.
=== ACTION ===
No physical resources exist, so thin provision a new flexible volume (backup secondary) of size 10.0 GB for directory opsmgr:C:/Demo/OSSV_Data into node 'Backup' and then attempt to create a backup relationship using SnapVault.
=== REASON ===

Storage system : 'secondary'(76):

     Aggregate : 'secondary:aggr0'(82):

         - Aggregate 'secondary:aggr0'(82) does not have 10.0 GB of free space.

=== SUGGESTION ===

Suggestions related to storage system 'secondary'(76):

     Suggestions related to aggregate 'secondary:aggr0'(82):

         - Add more disks to aggregate 'secondary:aggr0'(82)to increase the capacity of the aggregate.

I have set all of my aggregate thresholds to very high values to allow for over-provisioning:

aggregate=secondary:aggr0
aggrFullThreshold=1000
aggrNearlyFullThreshold=900
aggrFullThresholdInterval=00:00:00
aggrOvercommittedThreshold=1000
aggrNearlyOvercommittedThreshold=900
aggrSnapshotNearlyFullThreshold=80
aggrSnapshotFullThreshold=90
aggrNearlyOverDeduplicatedThreshold=500
aggrOverDeduplicatedThreshold=1000

Any ideas?

[dmilani]

When ProtMgr checks the aggr space for a provisioning operation, it ignores a nearlyFullThreshold setting above 100%.  So in this case, the threshold is at 100% which still means ProtMgr counts only 4.5 GB free.  That free space has to be larger than the amount ProtMgr uses for the size of this volume to be – in this case 10 GB.

When selecting from existing volumes, ProtMgr only looks at volume characteristics such as volume free space.  However, a subsequent conformance run where it does check the aggregate fullness may flag the dataset for migration.

By default, ProtMgr assumes an OSSV secondary volume will need 10GB.  You can change this if you want by setting a hidden option pmOSSVDirSecondaryVolSizeMb to something less than 4500.  If the option is 0 or non-existent, a default of 10240 MB.  However, this option is global and will affect all OSSV secondary volumes.  Example:  dfm options set pmOSSVDirSecondaryVolSizeMb=4000

--Dave

[reide]

First, the pmOSSVDirSecondaryVolSizeMb option worked great. I set it to 2000 and my OSSV dataset backup immediately worked. Most environments won't have an aggregate size this small (simulator) so I understand this option wouldn't be changed in a production environment.

So, I've learned that even though it's thin-provisioning the OSSV destination volumes, it checks to make sure the physical space exists first. This makes sense as you don't want to accidentally fill-up the aggregate with a new protection job.

Second, it didn't behave as I expected. When it thin-provisioned the OSSV secondary volume, it made it the same size as the containing aggregate (5,850 MB in this case).  I was expecting it to thin-provision a 2,000 MB volume.  So, is the pmOSSVDirSecondaryVolSizeMb option just a way to verify that xxxx MB of physical space exists before it thin provisions the volume?

Thanks!

Reid

[adaikkap · Accepted solution]

Hi Reid,

     The  option pmOSSVDirSecondaryVolSizeMb is for PM just to estimate how much space would be required for the OSSV to be backed up, so PM needs to check if the RP contains that much free space.

The dpDynamicSecondarySizing options is not applicable to dataset containing OSSV.But if you apply a secondary provisioning policy to the dataset, it is provisioned to the dedup limits of the platform and Ontap version and not to the containing aggr.

Unless otherwise the dedupe limit is more than the containing aggr size.

Below is the conformance message for a dedupe case.

Conformance Results

=== SEVERITY ===
Information: Provision a new flexible volume of 20.0 GB from aggregate 'f2020:aggr0'(6868).
=== ACTION ===
Provision flexible volume (backup secondary) of size 20.0 GB

=== SEVERITY ===
Information: Enable deduplication on flexible volume 'VolToBeProvision:test_lnx' (11)
=== ACTION ===
Enable deduplication on flexible volume.

=== SEVERITY ===
Information: Create backup relationship(s) between 'lnx:/apitest' and new volume to be provisioned from resource pool(s) 'pri_103' (7098).

=== ACTION ===
Create backup relationship(s) for dataset 'test_lnx' (19135) on connection 1.

Below is my aggr size.

Aggregate                total       used      avail capacity
aggr0                    454GB       20GB      433GB       5%
aggr0/.snapshot           23GB        0GB       23GB       0%

Regards

adai