Modifying the destination SnapMirror Volume when using XDP

References: 
How to modify Destination SnapMirror volume size and other attributes

SnapMirror Configuration Best Practice ONTAP 9.1-9.2

NetApp has been using a replication technology called SnapMirror for a very long time. I have been around so long, I remember when when we called it BMM or Bare Metal Migrate. It was used to help customers replicate (or migrate) data from an old Network Appliance, Inc filer to a new model. It was barbaric! You actually had to create some floppies. The source and the destination had to boot from the special media. A special connection was made over IP (usually a point-to-point Gigabit link, but sometimes 100BaseT). The transfer started and finished. This was the beginning of SnapMirror. Over the next years it molded into a product that was available in the operating system (again, before ONTAP, before 7-mode!) and was dubbed SnapMirror.

The Types

Ever since that time, the underlying replication engine was known as DP or Data Protection. This intelligently moved blocks of data from the source to the destination. When SnapVault was introduced, a new engine was used to move data around. This engine was called XDP or eXtended Data Protection. This engine is more of a logical block transfer that was updated to be used in regular SnapMirror transfers as well. In ONTAP 9.1, it became the default for SnapMirror and in 9.3 it became the default for SVM-DR. In the next couple of releases, I Suspect DP will be removed completely from ONTAP.

Forwards and Backwards

One the fantastic benefits of an XDP mirror is the ability to replicate to releases on ONTAP forwards or backwards! Historically, a DP mirror can only mirror to the current version or newer and never backwards. As ONTAP rapidly advances, this affords the customer the ability to no longer have to keep source and destination ONTAP releases tight. They can let them change and still maintain the ability to migrate forwards and backwards.

Changes Stick…

When a DP SnapMirror was configured, the destination needed to be the same size or larger than the source. After the relationship was established, nearly any change on the source was made automatically on the destination. Resizing the source volume, adding more inodes, changing the Snapshot schedule or SnapShot reserve space…all of things and more triggered the same change to happen on the destination.

…But not with XDP

This is no longer the case with an XDP SnapMirror, especially in a SVM-DR relationship. In this setup, the relationship will mirror all volumes from one SVM to another and all volumes in the SVM are replicated using XDP. If a change is made on the source and want that change to be applied to the destination, the storage administrator needs to make that happen. This process cannot be done normally on the destination. Why? When an XDP mirror has been established, the destination becomes read-only and the storage admin is no longer able to run commands on the destination volume.

The Long Way

From experience, I can tell you there are two way to make changes to the destination. The first way is the long way. There are a few steps here:

1. Update your mirror
2. Quiesce your mirror
3. Break your mirror (which now creates a RW destination)
4. Make any changes to the volume
   1. vol size or vol modify commands to manipulate inodes, snapshot reserve space, etc.
5. Re-sync the mirror
6. Resume the mirror

This is a lot of work. Resyncing can take time. There is an alternative as I recently found out!

The Short Way

The short was is actually very simple and it uses a command I recently became aware of.

Note: This is a warning! Use of “diag” mode on the ONTAP CLI can be dangerous and result in loss of data.

The short way is also very quick. First access the CLI. Use SSH or the console or the Service-Processor(SP) or the Baseboard Management Controller (BMC) and access the ONTAP command line. Then, enter “diag” mode:

::> set -privilege diag
::*>

Your normal prompt will change and display the asterisk as indicated above. All thats left is to modify the destination volume(s):

::*> vserver config override -command "volume size -vserver <dest_SVM> -volume <dest_vol> -new-size <new_size>"
::*> vserver config override -command "volume modify -vserver <dest_SVM> -volume <dest_vol> -autosize-mode {off|grow|grow_shrink}"

Make the changes that are required (volume size, autogrow mode, autogrow thresholds, etc) and then just set the mode back to admin:

::*> set -privilege admin
::>