ARL upgrade workflow

Contributors Download PDF of this page

Before you upgrade the nodes using ARL, you should understand how the procedure works. In this document, the procedure is broken down into several stages.

During the procedure, you upgrade the original controller hardware with the replacement controller hardware, one controller at a time, taking advantage of the HA pair configuration to relocate the ownership of non-root aggregates. All non-root aggregates must undergo two relocations to reach their final destination, which is the correct upgraded node.

Each aggregate has a home owner and current owner. The home owner is the actual owner of the aggregate, and the current owner is the temporary owner.

The following illustration shows the stages of the procedure. The thick, light gray arrows represent the relocation of aggregates and the movement of LIFs, and the thinner black arrows represent the removal of the original nodes. The smaller controller images represent the original nodes, and the larger controller images represent the new nodes.

Illustration showing the stages of the ARL procedure

The following table describes the high-level tasks you perform during each stage and the state of aggregate ownership at the end of the stage. Detailed steps are provided later in the procedure:

Stage Steps

Stage 1: Prepare for upgrade

  1. Determine whether the controller has aggregates on internal disk drives.

    This step is required only if you are upgrading from a controller with internal disk drive.

  2. Prepare the nodes for upgrade.

  3. Rekey disks for Storage Encryption.

    This task is required only if you are upgrading from a system with self-encrypting drives.

  4. Verify the SnapMirror relationship state on the cluster and quiesce all relationships between the clusters.

  5. Prepare for netboot.

Aggregate ownership at the end of Stage 1:

  • Node1 is the home owner and current owner of the node1 aggregates.

  • Node2 is the home owner and current owner of the node2 aggregates.

Stage 2: Retire node1

  1. Relocate non-root aggregates from node1 to node2.

  2. Move non-SAN data LIFSs owned by node1 to node2.

  3. Record node1 information.

  4. Relocate failed or vetoed aggregates.

  5. Retire node1.

Aggregate ownership at the end of Stage 2:

  • Node1 is the home owner of node1 aggregates.

  • Node2 is the current owner of node1 aggregates.

  • Node2 is the home owner and current owner of node2 aggregates.

Stage 3: Install and boot node3

  1. Install and boot node3.

  2. Set the UTA/UTA2 configuration on node3.

  3. Map ports from node1 to node3.

  4. Move non-SAN data LIFs owned by node 1 from node2 to node3 and verify SNA LIFs on node3.

  5. Relocate non-root aggregates from node2 to node3.

  6. Move non-SAN data LIFs owned by node2 to node3.

Aggregate ownership at the end of Stage 3:

  • Node2 is the home owner of node2 aggregates but not the current owner.

  • Node3 is the home owner and current owner of aggregates originally belonging to node1.

  • Node2 is the home owner and current owner of aggregates belonging to node2 but not the home owner.

Stage 4: Retire node2

  1. Record node2 information.

  2. Retire node2.

No changes occur in aggregate ownership.

Stage 5: Install and boot node4

  1. Install and boot node4.

  2. Set the UTA/UTA2 configuration on node4.

  3. Map ports from node2 to node4.

  4. Move non-SAN data LIFs owned by node2 from node3 to node4 and verify SNA LIFs on node4.

  5. Relocate node2’s non-root aggregates from node3 to node4.

Aggregate ownership at the end of Stage 5:

  • Node3 is the home owner and current owner of the aggregates that originally belonged to node1.

  • Node4 is the home owner and current owner of aggregates that originally belonged to node2.

Stage 6: Complete the upgrade

  1. Ensure the new controllers are set up correctly.

  2. Set up Storage Encryption on the new nodes.

    This task is required only if you are upgrading to a system with self-encrypting drives.

  3. Decommission the old system.

  4. Resume NetApp SnapMirror relationships.

    Note: The storage virtual machine (SVM) disaster recovery updates will not be interrupted as per the schedules assigned.

No changes occur in aggregate ownership.