ONTAP 9.13

to Japanese version

Prepare SnapMirror relationships for an ONTAP upgrade

Before you upgrade ONTAP on a cluster that is running SnapMirror, SnapMirror operations must be quiesced for each node that contains destination volumes, and each peered SVM must have a unique name across the clusters. It is best practice to use a unique fully qualified domain name (FQDN) for each SVM, for example, “dataVerser.HQ” or “mirrorVserver.Offsite”.

You should also be aware that if you are upgrading clusters with DP SnapMirror relationships, you must upgrade the destination nodes before you upgrade the source nodes.

Quiesce SnapMirror operations before upgrading ONTAP

To prevent SnapMirror transfers from failing, you must quiesce SnapMirror operations. Alternatively, you can quiesce SnapMirror transfers on a particular destination volume and upgrade the owning destination node before upgrading source nodes so the SnapMirror transfers for all other destination volumes can continue. The following table describes the two options for suspending SnapMirror operations.

Option Description Upgrade destination nodes before source nodes?

Suspend SnapMirror operations for the duration of the NDU (nondisruptive upgrade).

The simplest method for upgrading in a SnapMirror environment is to suspend all SnapMirror operations, perform the upgrade, and then resume the SnapMirror operations. However, no SnapMirror transfers will occur during the entire NDU. You must use this method if your cluster contains nodes that are mirroring volumes to each other.

No, the nodes can be upgraded in any order.

Suspend SnapMirror operations one destination volume at a time.

You can suspend SnapMirror transfers for a particular destination volume, upgrade the node (or HA pair) that contains the destination volume, upgrade the node (or HA pair) that contains the source volume, and then resume the SnapMirror transfers for the destination volume. By using this method, SnapMirror transfers for all other destination volumes can continue while the nodes that contain the original destination and source volumes are upgraded.

Yes.

Steps
  1. Determine the destination path for each SnapMirror relationship:

    snapmirror show
  2. For each destination volume, suspend future SnapMirror transfers:

    snapmirror quiesce -destination-path destination

    If there are no active transfers for the SnapMirror relationship, this command sets its status to "Quiesced". If the relationship has active transfers, the status is set to "Quiescing" until the transfer is completed, and then the status becomes "Quiesced".

    This example quiesces transfers involving the destination volume "vol1" from "SVMvs0.example.com":

    cluster1::> snapmirror quiesce -destination-path vs0.example.com:vol1
  3. Verify that all SnapMirror relationships are quiesced:

    snapmirror show -status !Quiesced

    This command displays any SnapMirror relationships that are not quiesced.

    This example shows that all SnapMirror relationships are quiesced:

    cluster1::> snapmirror show -status !Quiesced
    There are no entries matching your query.
  4. If any SnapMirror relationships are currently being transferred, do one of the following options:

    Option Description

    Wait for the transfers to finish before performing the ONTAP upgrade.

    After each transfer finishes, the relationship changes to "Quiesced" status.

    Stop the transfers:

    snapmirror abort -destination-path destination -h

    Note: You must use the -foreground true parameter if you are terminating load-sharing mirror transfers.

    This command stops the SnapMirror transfer and restores the destination volume to the last Snapshot copy that was successfully transferred. The relationship is set to "Quiesced" status.

Top of Page