Updating the first DR pair in a MetroCluster DR group

You must perform a takeover and giveback of the nodes in the correct order to make the new version of ONTAP the current version of the node.

Before you begin

All nodes must be running the old version of ONTAP.

About this task

In this task, node_A_1 and node_B_1 are updated.

If you have updated the ONTAP software on the first DR group, and are now updating the second DR group in an eight-node MetroCluster configuration, in this task you would be updating node_A_3 and node_B_3.

If MetroCluster Tiebreaker software is enabled, disabled it.
For each node in the HA pair, disable automatic giveback: storage failover modify -node target-node -auto-giveback false
This command must be repeated for each node in the HA pair.
Verify that automatic giveback is disabled: storage failover show -fields auto-giveback
Example
This example shows that automatic giveback has been disabled on both nodes:
cluster_x::> storage failover show -fields auto-giveback node auto-giveback -------- ------------- node_x_1 false node_x_2 false 2 entries were displayed.
Ensure that I/O is not exceeding ~50% for each controller. Ensure that CPU utilization is not exceeding ~50% per controller.
Initiate a takeover of the target node on cluster_A:
Do not specify the -option immediate parameter, because a normal takeover is required for the nodes that are being taken over to boot onto the new software image.
1. Take over the DR partner on cluster_A (node_A_1):storage failover takeover -ofnode node_A_1
  The node boots up to the Waiting for giveback state.
  Note
  If AutoSupport is enabled, then an AutoSupport message is sent indicating that the nodes are out of cluster quorum. You can ignore this notification and proceed with the upgrade.
2. Verify that the takeover is successful: storage failover show
  Example
  The following example shows that the takeover is successful. Node_A_1 is in the Waiting for giveback state and node_A_2 is in the In takeover state.
  TDC-DM7K::> storage failover show Takeover Node Partner Possible State Description -------------- -------------- -------- ------------------------------------- node_A_1 node_A_2 - Waiting for giveback (HA mailboxes) node_A_2 node_A_1 false In takeover 2 entries were displayed.
Take over the DR partner on cluster_B (node_B_1):
Do not specify the -option immediate parameter, because a normal takeover is required for the nodes that are being taken over to boot onto the new software image.
1. Take over node_B_1: storage failover takeover -ofnode node_B_1
  The node boots up to the Waiting for giveback state.
  Note
  If AutoSupport is enabled, then an AutoSupport message is sent indicating that the nodes are out of cluster quorum. You can ignore this notification and proceed with the upgrade.
2. Verify that the takeover is successful: storage failover show
  Example
  The following example shows that the takeover is successful. Node_B_1 is in the Waiting for giveback state and node_B_2 is in the In takeover state.
  TDC-DM7K::> storage failover show Takeover Node Partner Possible State Description -------------- -------------- -------- ------------------------------------- node_B_1 node_B_2 - Waiting for giveback (HA mailboxes) node_B_2 node_B_1 false In takeover 2 entries were displayed.
Wait at least eight minutes to ensure the following conditions:
- Client multipathing (if deployed) is stabilized.
- Clients are recovered from the pause in I/O that occurs during takeover.
  The recovery time is client-specific and might take longer than eight minutes depending on the characteristics of the client applications.
Return the aggregates to the target nodes:
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.
1. Give back the aggregates to the DR partner on cluster_A: storage failover giveback –ofnode node_A_1
2. Give back the aggregates to the DR partner on cluster_B: storage failover giveback –ofnode node_B_1
The giveback operation first returns the root aggregate to the node and then, after the node has finished booting, returns the non-root aggregates.
Verify that all aggregates have been returned by issuing the following command on both clusters: storage failover show-giveback
If the Giveback Status field indicates that there are no aggregates to give back, then all aggregates have been returned. If the giveback is vetoed, the command displays the giveback progress and which subsystem vetoed the giveback.
If any aggregates have not been returned, do the following:
1. Review the veto workaround to determine whether you want to address the veto condition or override the veto.
  High-availability Configuration Guide
2. If necessary, address the veto condition described in the error message, ensuring that any identified operations are terminated gracefully.
3. Reenter the storage failover giveback command.
  If you decided to override the veto condition, set the -override-vetoes parameter to true .
Wait at least eight minutes to ensure the following conditions:
- Client multipathing (if deployed) is stabilized.
- Clients are recovered from the pause in I/O that occurs during giveback.
  The recovery time is client-specific and might take longer than eight minutes depending on the characteristics of the client applications.
Set the privilege level from admin to advanced, entering y when prompted to continue: set -privilege advanced
The advanced prompt (*>) appears.

Confirm the version on cluster_A: system image show

Example

The following example shows that System image2 should is the default and current version on node_A_1:

cluster_A::*> system image show 
                 Is      Is               Install
Node     Image   Default Current Version  Date
-------- ------- ------- ------- -------- -------------------
node_A_1
         image1  false   false    X.X.X   MM/DD/YYYY TIME
         image2  true    true     Y.Y.Y   MM/DD/YYYY TIME
node_A_2
         image1  false   true     X.X.X   MM/DD/YYYY TIME
         image2  true    false    Y.Y.Y   MM/DD/YYYY TIME
4 entries were displayed.

cluster_A::> 

Confirm the version on cluster_B: system image show

Example

The following example shows that System image2 (ONTAP 9.5) is the default and current version on node_A_1:

cluster_A::*> system image show 
                 Is      Is               Install
Node     Image   Default Current Version  Date
-------- ------- ------- ------- -------- -------------------
node_B_1
         image1  false   false    X.X.X   MM/DD/YYYY TIME
         image2  true    true     Y.Y.Y   MM/DD/YYYY TIME
node_B_2
         image1  false   true     X.X.X   MM/DD/YYYY TIME
         image2  true    false    Y.Y.Y   MM/DD/YYYY TIME
4 entries were displayed.

cluster_A::> 

Give documentation feedback