Create Schedules and Policies

Goal

This workflow automates the initial creation of schedules, Snapshot policies and SnapMirror policies on a clustered ONTAP system. This workflow performs the following:

· This workflow will enable administrators to apply Master Definitions of schedules and policies across all new clusters, which can then be repeatedly used to configure SnapMirror/SnapVault relationship.

· “Initial” creation of schedule and policies for SnapVault and Snapmirror relationship. Any modifications to this workflow with new definitions can only be applied to a new cluster. For any changes to already created schedule/policy and SnapVault/Snapmirror relationship, a new custom workflow will have to be created.

· Creates schedule and policies on a clustered ONTAP system which does not have one already available. However, if a schedule or policy already exists, it is not changed.

User Input parameters:

The only input to this workflow is the “name of the cluster” on which the schedules and policies need to be created. This allows administrators to easily push the master definitions of the schedules and policies on to the new clusters.

Cluster *: This user input refers to the cluster name on which schedules and policies are to be created. This is a tabular resource selection showing Cluster Name, Primary Address and ONTAP version.

Note: This workflow creates schedules/policies as needed. If the schedule/policy already exists on a given cluster system then, it is left alone even if it may have different settings than those in the workflow.

· This workflow creates the following canned schedules –

· Hourly on the hour

· Daily at 8:00 pm

· 11:00 pm on Sunday

· Monthly on 1st at 00:05 am

· Yearly on December 31st at 11:55 pm

· Every 15 minutes

· Every 30 minutes

· Hour on half hour

· Every 2 hours

· Every 4 hours

· Every 8 hours

1. Every 12 hours

· Every 30 minutes weekdays during work hours

· This workflow creates the following canned Snapshot policy –

1. wfaDefault

a. Schedules: Hourly on the hour, Daily at 8:00 pm, 11:00 pm on Sunday, Monthly on 1st at 00:05 am, Yearly on December 31st at 11:55 pm

b. Snapshot prefixes: hourly, daily, weekly, monthly, yearly

c. Retention counts: 48 hourly (2 days), 14 daily (2 weeks), 4 weekly (1 month), 2 monthly, 1 yearly

d. SnapMirror labels: hourly, daily, weekly, monthly, yearly

· This workflow has the following canned SnapVault policy :

2. Name: wfaSnapVaultDefault

a. SnapMirror labels: hourly,daily,weekly,monthly,yearly

b. Retention counts: 24,60,52,24,5

3. Name: wfaSnapVaultAfterSnapMirror

c. SnapMirror labels: sm_created

d. Retention counts: 90

e. Note: This is a special policy to be used for the SnapVault relationship in “SnapMirror then SnapVault” cascade. Due to an ONTAP limitation, the labeled snapshots on the primary do not appear on the SnapVault destination in SnapMirror-SnapVault cascade Instead, only the SnapMirror-created snapshots end up on the SnapVault destination. By default, 251 of such snapshots get accumulated. This policy allows user to control this count.

Result

This workflow will return the names of the schedules and policies it created.

Potential Workflow Extensions

This workflow is provided just as a sample. If the default options provided in this workflow do not meet your environment needs then, you may want to customize this workflow by cloning and customizing the schedules and policies to suit your specific environment. Once changes are done and validated, this customized workflow can be executed and the new schedules and policies will show up in the drop-down inputs in the SnapMirror/SnapVault workflows

It’s important to note that creations of a new schedule/policy or modification of an existing schedule/policy with new settings for “Create Schedule and Policies” workflow will only be applied on new clusters. However, to change the policies on existing clusters, it’s recommended to create a custom workflow consisting of the certified commands to create/modify schedules and policies. This custom workflow will have to be executed on existing cluster to reflect the changes.