Re: Protection Manager provisioning 8.1TB volume for 6 volumes @ ~200gb

yangus · ‎2010-01-28

I'm currently working with a client who is running Protection Manager 3.8 /w SMO, the integration of SMO works perfectly fine and SMO is able to create it's dataset after attaching a policy to a SMO profile, what I need some clarification on is why does PM try to provision a 8.1TB (the exact same size of the secondary destination Aggregate) volume for the SMO dataset when we apply a protection policy in PM.

The protection policy is a copy of the default Backup and Mirror with the exception of the retention policy which is set to keep dailies for 1 week, the resource pool has an 8.1TB aggregate from the secondary system in it.

Both systems, a 3050c and a 2050, are running DOT 7.3.1.1.

See the conformant output below, each volume it tries to create is ~1TB for a source volume that is under 100gb.

Lastly, if we switch the protection policy to "Backup" (local backups and snapvault to secondary) we get the expected behaviour of 1:1 volume relationship.

Preview Details

=== SEVERITY ===

Information: Provision a new flexible volume of 8.10 TB from aggregate 'st-ydc02-01:aggr0'(258).

=== ACTION ===

Provision flexible volume (volume mirror destination) of size 8.10 TB

=== SEVERITY ===

Information: Create volume mirror relationship(s) between 'vf_ttc1:/hibctst1_undo_temp' and new volume to be provisioned from resource pool(s) 'database_backup_resource' (1132).

=== ACTION ===

Create volume mirror relationship(s) for dataset 'smo_tdb001_hibctst1' (1136) on connection 1 with backup version 'Thu Jan 28 21:44:03 2010'.

=== SEVERITY ===

Information: Provision a new flexible volume of 8.10 TB from aggregate 'st-ydc02-01:aggr0'(258).

=== ACTION ===

Provision flexible volume (volume mirror destination) of size 8.10 TB

=== SEVERITY ===

Information: Create volume mirror relationship(s) between 'vf_ttc1:/hibctst1_db' and new volume to be provisioned from resource pool(s) 'database_backup_resource' (1132).

=== ACTION ===

Create volume mirror relationship(s) for dataset 'smo_tdb001_hibctst1' (1136) on connection 1 with backup version 'Thu Jan 28 21:44:03 2010'.

=== SEVERITY ===

Information: Provision a new flexible volume of 8.10 TB from aggregate 'st-ydc02-01:aggr0'(258).

=== ACTION ===

Provision flexible volume (volume mirror destination) of size 8.10 TB

=== SEVERITY ===

Information: Create volume mirror relationship(s) between 'vf_ttc1:/hibctst1_redo_a' and new volume to be provisioned from resource pool(s) 'database_backup_resource' (1132).

=== ACTION ===

Create volume mirror relationship(s) for dataset 'smo_tdb001_hibctst1' (1136) on connection 1 with backup version 'Thu Jan 28 21:44:03 2010'.

=== SEVERITY ===

Information: Provision a new flexible volume of 8.10 TB from aggregate 'st-ydc02-01:aggr0'(258).

=== ACTION ===

Provision flexible volume (volume mirror destination) of size 8.10 TB

=== SEVERITY ===

Information: Create volume mirror relationship(s) between 'vf_ttc1:/hibctst1_arch_1' and new volume to be provisioned from resource pool(s) 'database_backup_resource' (1132).

=== ACTION ===

Create volume mirror relationship(s) for dataset 'smo_tdb001_hibctst1' (1136) on connection 1 with backup version 'Thu Jan 28 21:44:03 2010'.

=== SEVERITY ===

Information: Provision a new flexible volume of 8.10 TB from aggregate 'st-ydc02-01:aggr0'(258).

=== ACTION ===

Provision flexible volume (volume mirror destination) of size 8.10 TB

=== SEVERITY ===

Iformation: Create volume mirror relationship(s) between 'vf_ttc2:/hibctst1_redo_b' and new volume to be provisioned from resource pool(s) 'database_backup_resource' (1132).

=== ACTION ===

Create volume mirror relationship(s) for dataset 'smo_tdb001_hibctst1' (1136) on connection 1 with backup version 'Thu Jan 28 21:44:03 2010'.

=== SEVERITY ===

Information: Provision a new flexible volume of 8.10 TB from aggregate 'st-ydc02-01:aggr0'(258).

=== ACTION ===

Provision flexible volume (volume mirror destination) of size 8.10 TB

=== SEVERITY ===

Information: Create volume mirror relationship(s) between 'vf_ttc2:/hibctst1_arch_2' and new volume to be provisioned from resource pool(s) 'database_backup_resource' (1132).

=== ACTION ===

Create volume mirror relationship(s) for dataset 'smo_tdb001_hibctst1' (1136) on connection 1 with backup version 'Thu Jan 28 21:44:03 2010'.

Thanks!

lovik_netapp · ‎2010-01-28

This is a short fall of PM and well documented somewhere in KB (will update KB number once I get it) actually PM creates a thin (guarantee=none) volume of maximum size available in aggregate for SM mirror destination, so it doesn't have to resize the volume if source grows however as a downside of this, you end up over provisioning your aggregate and soon you get error as aggregate over provisioned in your OM. I would suggest that you create secondary volume manually and then use that as destination volume while creating relationship.

adaikkap · ‎2010-01-28

PM creates aggr sized volumes with guarantee set to none in case of VSM relationship, but for Backup relationships (ie SV/QSM) if Dynamic Sizing is enabled we dynamically resize the secondary volumes instead of creating it to the size of the containing aggr.

DFM 3.8.1 is released and its a GA release, i strongly suggest you to upgrade to the same.

Regards

adai

astafford · ‎2010-01-31

I had a similar experience with SnapManager for Exchange and snapvault integration into PM (3.6). I found the PM operations to be unpredictable as it would re-baseline and create new qtree relationships without warning. In the end I elected to manually create destination volumes with understandable names, manually initiate the snapvault relationships and import them into the PM dataset created by SME. I would expect this approach to work for SMO as well.

yangus · ‎2010-02-10

Is there any work around for this behaviour, I've upgraded my lab to 3.8.1 and still don't see any changes. Can you also elaborate on the dynamic sizing being enabled or disabled. The real challange here is that the customer does not want to do any work manually if using PM.

Thanks.

adaikkap · ‎2010-02-10

Can you get the output for the following command ?

dfm options list | grep -i dynamic

dfm options list | grep -i fan

Regards

adai

yangus · ‎2010-02-10

Here are the current settings (this is on a windows server btw).

dpDynamicSecondarySizing Disabled
dpMaxFanInRatio 1

adaikkap · ‎2010-02-10

Enabled the option for dynamic sizing which is currently disabled in your case.

Also set the maxfan-in value to a value larger than 1 if you wish to backup more than one primary volume to a secondary volume.

Regards

adai

dmilani · ‎2010-02-10

The dry-run results you attach are only for the provisioning of the mirror volumes and relationships.

The Dynamic Secondary Sizing (DSS) feature introduced in DFM 3.8 only applies to Backup relationships.

Mirrors are still provisioned as they were in the 3.7 release of DFM. That is, secondary volumes are "thin"

provisioned to the size of the aggregate. The aggr size default could be overridden by seting the option

pmSecondaryMaxVolSizeMb to a non-zero value. This is a hidden option, so will not appear in the DB unless

it has already been set.

lovik_netapp · ‎2010-02-10

Now I have two questions:

1) does that mean value set in pmSecondaryMaxVolSizeMb will be the size of secondary volume which it will create or it will create secondary mirror volume on the basis of primary volume?

2) If it will create secondary volume as per primary volume size then will it grow secondary also when you grow primary or that has to be done manually?

adaikkap · ‎2010-02-10

1) does that mean value set in pmSecondaryMaxVolSizeMb will be the size of secondary volume which it will create or it will create secondary mirror volume on the basis of primary volume?

Yes.The value set in the option would be the size of the secondary volume and not on the basis of the primary volume.

The secondary question is not valid as its not applicable.

This options basically sets the max value for the secondary volumes instead of PM using the size of the aggr where it is trying to provisioning a secondary volume.

Regards

adai

yangus · ‎2010-02-19

Are there any new options in 4.0 that might help with this?

adaikkap · ‎2010-02-20

No changes to provisioning of destination volumes for VSM relationships in 4.0.

It will always create aggr sized volume and of the Resource Pool used for provisioning the VSM destination.

Also note even though it creates aggr sized volumes after snapmirror (VSM) the destination volumes takes the size of the source volume.

Though vol size command show the actual size of the volume in your case 8.1 TB.

But df on the destination volume will show the size of source volume.

Also aggr over commitment calculation for the destination aggr is done on the df size and and not the vol size.

Another options is as suggested by dmilani to use the hidden options to restrict the size.

Regards

adai

yangus · ‎2010-02-24

Turns out the option was pmAutomaticSecondaryVolMaxSizeMb.

Thanks!