Skip to main content

Nondisruptive upgrade of a two-node MetroCluster configuration in ONTAP 9.2 or earlier

Contributors netapp-thomi netapp-ahibbard
PDFs

How you upgrade a two-node MetroCluster configuration varies based on your ONTAP version. If you are running ONTAP 9.2 or earlier, you should use this procedure to perform a manual nondisruptive upgrade which includes initiating a negotiated switchover, updating the cluster at the “failed” site, initiating switchback, and then repeating the process on the cluster at the other site.

If you have a two-node MetroCluster configuration running ONTAP 9.3 or later, perform an automated upgrade using System Manager.

Steps

  1. Set the privilege level to advanced, entering y when prompted to continue:

    set -privilege advanced

    The advanced prompt (*>) appears.

  2. On the cluster to be upgraded, install the new ONTAP software image as the default:

    system node image update -package package_location -setdefault true -replace-package true
    cluster_B::*> system node image update -package http://www.example.com/NewImage.tgz -setdefault true -replace-package true

  3. Verify that the target software image is set as the default image:

    system node image show

    The following example shows that NewImage is set as the default image:

    cluster_B::*> system node image show
                    Is      Is                           Install
Node     Image      Default Current Version              Date
-------- -------    ------- ------- -------------------- -------------------
node_B_1
         OldImage  false   true    X.X.X                MM/DD/YYYY TIME
         NewImage  true    false   Y.Y.Y                MM/DD/YYYY TIME
2 entries were displayed.

  4. If the target software image is not set as the default image, then change it:

    system image modify {-node * -iscurrent false} -isdefault true

  5. Verify that all cluster SVMs are in a health state:

    metrocluster vserver show

  6. On the cluster that is not being updated, initiate a negotiated switchover:

    metrocluster switchover

    The operation can take several minutes. You can use the metrocluster operation show command to verify that the switchover is completed.

    In the following example, a negotiated switchover is performed on the remote cluster (“cluster_A”). This causes the local cluster (“cluster_B”) to halt so that you can update it.

    cluster_A::> metrocluster switchover

Warning: negotiated switchover is about to start. It will stop all the data
         Vservers on cluster "cluster_B" and
         automatically re-start them on cluster
         "cluster_A". It will finally gracefully shutdown
         cluster "cluster_B".
Do you want to continue? {y|n}: y

  7. Verify that all cluster SVMs are in a health state:

    metrocluster vserver show

  8. Resynchronize the data aggregates on the “surviving” cluster:

    metrocluster heal -phase aggregates

    After upgrading MetroCluster IP configurations to ONTAP 9.5 or later, the aggregates will be in a degraded state for a short period before resynchronizing and returning to a mirrored state.

    cluster_A::> metrocluster heal -phase aggregates
[Job 130] Job succeeded: Heal Aggregates is successful.

  9. Verify that the healing operation was completed successfully:

    metrocluster operation show
    cluster_A::> metrocluster operation show
Operation: heal-aggregates
State: successful
Start Time: MM/DD/YYYY TIME
End Time: MM/DD/YYYY TIME
Errors: -

  10. Resynchronize the root aggregates on the “surviving” cluster:

    metrocluster heal -phase root-aggregates
    cluster_A::> metrocluster heal -phase root-aggregates
[Job 131] Job succeeded: Heal Root Aggregates is successful.

  11. Verify that the healing operation was completed successfully:

    metrocluster operation show
    cluster_A::> metrocluster operation show
Operation: heal-root-aggregates
State: successful
Start Time: MM/DD/YYYY TIME
End Time: MM/DD/YYYY TIME
Errors: -

  12. On the halted cluster, boot the node from the LOADER prompt:

    boot_ontap

  13. Wait for the boot process to finish, and then verify that all cluster SVMs are in a health state:

    metrocluster vserver show

  14. Perform a switchback from the “surviving” cluster:

    metrocluster switchback

  15. Verify that the switchback was completed successfully:

    metrocluster operation show
    cluster_A::> metrocluster operation show
Operation: switchback
State: successful
Start Time: MM/DD/YYYY TIME
End Time: MM/DD/YYYY TIME
Errors: -

  16. Verify that all cluster SVMs are in a health state:

    metrocluster vserver show

  17. Repeat all previous steps on the other cluster.

  18. Verify that the MetroCluster configuration is healthy:

    1. Check the configuration:

      metrocluster check run
      cluster_A::> metrocluster check run
Last Checked On: MM/DD/YYYY TIME
Component           Result
------------------- ---------
nodes               ok
lifs                ok
config-replication  ok
aggregates          ok
4 entries were displayed.

Command completed. Use the "metrocluster check show -instance"
command or sub-commands in "metrocluster check" directory for
detailed results.
To check if the nodes are ready to do a switchover or switchback
operation, run "metrocluster switchover -simulate" or "metrocluster
switchback -simulate", respectively.

    2. If you want to view more detailed results, use the metrocluster check run command:

      metrocluster check aggregate show
      metrocluster check config-replication show
      metrocluster check lif show
      metrocluster check node show

    3. Set the privilege level to advanced:

      set -privilege advanced

    4. Simulate the switchover operation:

      metrocluster switchover -simulate

    5. Review the results of the switchover simulation:

      metrocluster operation show
      cluster_A::*> metrocluster operation show
    Operation: switchover
        State: successful
   Start time: MM/DD/YYYY TIME
     End time: MM/DD/YYYY TIME
       Errors: -

    6. Return to the admin privilege level:

      set -privilege admin

    7. Repeat these substeps on the other cluster.

After you finish

Perform any post-upgrade tasks.

Related information

MetroCluster Disaster recovery