Skip to main content
ONTAP MetroCluster

Prepare the MetroCluster IP system for upgrade

Contributors netapp-aoife
PDFs

To prepare for the controller upgrade, you might need to upgrade the switch reference configuration files (RCFs) depending on the old and new platform models. You then perform system prechecks, collect the configuration information, and remove existing monitoring software.

Update the MetroCluster switch RCFs before upgrading controllers

Depending on the old and new platform models, you might need to update the MetroCluster switch reference configuration files (RCFs) before you upgrade controllers.

About this task

Perform this task in the following circumstances:

  • The switch RCF configuration isn't on the minimum version.

  • You need to change VLAN IDs used by the back-end MetroCluster connections.

Before you begin

Determine whether you need to update the RCFs before you upgrade your controllers:

  • If the switch configuration wasn't configured with the minimum supported RCF version, you need to update the RCFs before you upgrade your controllers:

    Switch model

    Required RCF version

    Cisco 3132Q-V

    1.7 or later

    Cisco 3232C

    1.7 or later

    Broadcom BES-53248

    1.3 or later

    NVIDIA SN2100

    2.0 or later

  • If both of your old and new platform models are in the following list, you do not need to update the VLAN ID before you upgrade controllers:

    • FAS8200 or AFF A300

    • AFF A320

    • FAS9000 or AFF A700

    • AFF A800, AFF C800, ASA A800, or ASA C800

      If either of your old or new platform models are not listed above, you must confirm that the MetroCluster interfaces are using a supported VLAN ID. Supported VLAN IDs for the MetroCluster interfaces are: 10, 20, or in the range of 101 to 4096.

      Caution

      • If the VLAN ID is not 10, 20, or in the range of 101 to 4096, you must upgrade the switch RCF before you upgrade controllers.

      • The local cluster connections can use any VLAN, they don't need to be in the given range.

      • The new RCF that you are upgrading to must use the VLANs 10, 20, or be in the range 101 to 4096. Don't change the VLAN for the local cluster unless it is required.
Steps

  1. Prepare the IP switches for the application of the new RCFs.

    Follow the steps in the section for your switch vendor:

    Note You should update the switches in the following order: switch_A_1, switch_B_1, switch_A_2, switch_B_2.

  2. Download and install the RCFs.

    Follow the steps in the section for your switch vendor:

Perform system prechecks

Before the prechecks start, if ONTAP Mediator is installed, it is automatically detected and removed. To confirm the removal, you are prompted to enter a username and password. When you complete the upgrade, or if prechecks fail or you choose not to proceed with the upgrade, you must manually re-configure the ONTAP Mediator service.

At any stage during the upgrade, you can run the system controller replace show or system controller replace show-details command from site A to check the status. If the commands return a blank output, wait for a few minutes and rerun the command.

Steps

  1. Start the automated controller replacement procedure from site A to replace the controllers at site B:

    system controller replace start -nso true

    The automated operation executes the prechecks. If no issues are found, the operation pauses so you can manually collect the configuration related information.

    Note

    • If you do not run the system controller replace start -nso true command, the controller upgrade procedure chooses NSO based automated switchover and switchback as the default procedure on MetroCluster IP systems.

    • The current source system and all compatible target systems are displayed. If you have replaced the source controller with a controller that has a different ONTAP version or a non-compatible platform, the automation operation halts and reports an error after the new nodes are booted up. To bring the cluster back to a healthy state, you need to follow the manual recovery procedure.

      The system controller replace start command might report the following precheck error:

      Cluster-A::*>system controller replace show
Node        Status         Error-Action
----------- -------------- ------------------------------------
Node-A-1    Failed         MetroCluster check failed. Reason : MCC check showed errors in component aggregates

      Check if this error occurred because you have unmirrored aggregates or due to another aggregate issue. Verify that all mirrored aggregates are healthy and not degraded or mirror-degraded. If this error is due to unmirrored aggregates only, you can override this error by selecting the -skip-metrocluster-check true option on the system controller replace start command. If remote storage is accessible, the unmirrored aggregates come online after switchover. If the remote storage link fails, the unmirrored aggregates fail to come online.

  2. Manually collect the configuration information by logging in at site B and following the commands listed in the console message under the system controller replace show or system controller replace show-details command.

Gather information before the upgrade

Before upgrading, if the root volume is encrypted, you must gather the backup key and other information to boot the new controllers with the old encrypted root volumes.

About this task

This task is performed on the existing MetroCluster IP configuration.

Steps

  1. Label the cables for the existing controllers, so you can easily identify the cables when setting up the new controllers.

  2. Display the commands to capture the backup key and other information:

    system controller replace show

    Run the commands listed under the show command from the partner cluster.

    The show command output displays three tables containing the MetroCluster interface IPs, system IDs, and system UUIDs. This information is required later in the procedure to set the bootargs when you boot the new node.

  3. Gather the system IDs of the nodes in the MetroCluster configuration:

    metrocluster node show -fields node-systemid,dr-partner-systemid

    During the upgrade procedure, you will replace these old system IDs with the system IDs of the new controller modules.

    In this example for a four-node MetroCluster IP configuration, the following old system IDs are retrieved:

    • node_A_1-old: 4068741258

    • node_A_2-old: 4068741260

    • node_B_1-old: 4068741254

    • node_B_2-old: 4068741256

    metrocluster-siteA::> metrocluster node show -fields node-systemid,ha-partner-systemid,dr-partner-systemid,dr-auxiliary-systemid
dr-group-id        cluster           node            node-systemid     ha-partner-systemid     dr-partner-systemid    dr-auxiliary-systemid
-----------        ---------------   ----------      -------------     -------------------     -------------------    ---------------------
1                    Cluster_A       Node_A_1-old    4068741258        4068741260              4068741256             4068741256
1                    Cluster_A       Node_A_2-old    4068741260        4068741258              4068741254             4068741254
1                    Cluster_B       Node_B_1-old    4068741254        4068741256              4068741258             4068741260
1                    Cluster_B       Node_B_2-old    4068741256        4068741254              4068741260             4068741258
4 entries were displayed.

    In this example for a two-node MetroCluster IP configuration, the following old system IDs are retrieved:

    • node_A_1: 4068741258

    • node_B_1: 4068741254

    metrocluster node show -fields node-systemid,dr-partner-systemid

dr-group-id cluster    node          node-systemid dr-partner-systemid
----------- ---------- --------      ------------- ------------
1           Cluster_A  Node_A_1-old  4068741258    4068741254
1           Cluster_B  node_B_1-old  -             -
2 entries were displayed.

  4. Gather port and LIF information for each old node.

    You should gather the output of the following commands for each node:

    • network interface show -role cluster,node-mgmt

    • network port show -node <node-name> -type physical

    • network port vlan show -node <node-name>

    • network port ifgrp show -node <node-name> -instance

    • network port broadcast-domain show

    • network port reachability show -detail

    • network ipspace show

    • volume show

    • storage aggregate show

    • system node run -node <node-name> sysconfig -a

    • aggr show -r

    • disk show

    • system node run <node-name> disk show

    • vol show -fields type

    • vol show -fields type , space-guarantee

    • vserver fcp initiator show

    • storage disk show

    • metrocluster configuration-settings interface show

  5. If the MetroCluster nodes are in a SAN configuration, collect the relevant information.

    You should gather the output of the following commands:

    • fcp adapter show -instance

    • fcp interface show -instance

    • iscsi interface show

    • ucadmin show

  6. If the root volume is encrypted, collect and save the passphrase used for key-manager:

    security key-manager backup show

  7. If the MetroCluster nodes are using encryption for volumes or aggregates, copy information about the keys and passphrases.

    For additional information, see Back up onboard key management information manually.

    1. If Onboard Key Manager is configured:

      security key-manager onboard show-backup

      You will need the passphrase later in the upgrade procedure.

    2. If enterprise key management (KMIP) is configured, issue the following commands:

      security key-manager external show -instance

      security key-manager key query

  8. After you finish collecting the configuration information, resume the operation:

    system controller replace resume

Remove the existing configuration from Tiebreaker or other monitoring software

Before you start the upgrade, remove the existing configuration from the Tiebreaker or other monitoring software.

If the existing configuration is monitored with the MetroCluster Tiebreaker configuration or other third-party applications (for example, ClusterLion) that can initiate a switchover, you must remove the MetroCluster configuration from the Tiebreaker or other software prior to replacing the old controller.

Steps

  1. Remove the existing MetroCluster configuration from the Tiebreaker software.

  2. Remove the existing MetroCluster configuration from any third-party application that can initiate switchover.

    Refer to the documentation for the application.

What's next?

Prepare the network configuration of the old controllers.