Skip to main content

Remove nodes from an ONTAP cluster

Contributors netapp-bhouser netapp-pcarriga netapp-sumathi netapp-dbagwell netapp-aherbin netapp-aaron-holt

You can remove unwanted nodes from a cluster, one node at a time. After you remove a node, you must also remove its failover partner. If you are removing a node, then its data becomes inaccessible or erased.

Before you begin

You must satisfy the following conditions before you remove nodes from the cluster:

  • More than half of the nodes in the cluster must be healthy.

  • All data, volumes, and non-root aggregates must be relocated or removed from the node.

    • All of the data on the node that you want to remove must have been evacuated. This might include purging data from an encrypted volume.

    • All non-root volumes have been moved from aggregates owned by the node.

    • All non-root aggregates have been deleted from the node.

  • All LIFs and VLANs have been relocated or removed from the node.

    • Data LIFs have been deleted or relocated from the node.

    • Cluster management LIFs have been relocated from the node and the home ports changed.

    • All intercluster LIFs have been removed. When you remove intercluster LIFs a warning is displayed that can be ignored.

    • All VLANs on the node have been deleted.

  • The node is not participating in any failover relationships.

    • Storage failover has been disabled for the node.

    • All LIF failover rules have been modified to remove ports on the node.

  • If the node owns Federal Information Processing Standards (FIPS) disks or self-encrypting disks (SEDs), disk encryption has been removed by returning the disks to unprotected mode.

  • If you have LUNs on the node to be removed, you should modify the Selective LUN Map (SLM) reporting-nodes list before you remove the node.

    If you do not remove the node and its HA partner from the SLM reporting-nodes list, access to the LUNs previously on the node can be lost even though the volumes containing the LUNs were moved to another node.

It is recommended that you issue an AutoSupport message to notify NetApp technical support that node removal is underway.

Important Do not perform operations such as cluster remove-node, cluster unjoin, and node rename when an automated ONTAP upgrade is in progress.
About this task
  • If you are running a mixed-version cluster, you can remove the last low-version node by using one of the advanced privilege commands beginning with ONTAP 9.3:

    • ONTAP 9.3: cluster unjoin -skip-last-low-version-node-check

    • ONTAP 9.4 and later: cluster remove-node -skip-last-low-version-node-check

  • If you remove two nodes from a four-node cluster, cluster HA is automatically enabled on the two remaining nodes.

Note

All system and user data, from all disks that are connected to the node, must be made inaccessible to users before removing a node from the cluster.

If a node was incorrectly removed from a cluster, contact NetApp Support for assistance with options for recovery.

Steps
  1. Change the privilege level to advanced:

    set -privilege advanced
  2. Identify the node in the cluster that has epsilon:

    cluster show

    In the following example, "node0" currently holds epsilon:

    cluster::*>
    Node                 Health  Eligibility  Epsilon
    -------------------- ------- ------------ ------------
    node0                true    true         true
    node1                true    true         false
    node2                true    true         false
    node3                true    true         false
  3. If the node that you are removing holds epsilon:

    1. Move epsilon from the node you are removing:

      cluster modify -node <name_of_node_to_be_removed> -epsilon false
    2. Move epsilon to a node that you are not removing:

      cluster modify -node <node_name> -epsilon true
  4. Identify the current master node:

    cluster ring show

    The master node is the node that holds processes such as mgmt, vldb, vifmgr, bcomd, and crs.

  5. If the node you are removing is the current master node, enable another node in the cluster to be elected as the master node:

    1. Make the current master node ineligible to participate in the cluster:

      cluster modify -node <node_name> -eligibility false

      The node is marked unhealthy until eligibility is restored. When the master node becomes ineligible, one of the remaining nodes is elected by the cluster quorum as the new master.

      Note

      If you are performing this step on the first node in an HA pair, you should mark only that node as ineligible. Do not modify the status of the HA partner.

      If the partner node is selected as the new master, you need to verify if it holds epsilon before making it ineligible. If the partner node holds epsilon, you need to move epsilon to a different node that is remaining in the cluster before making it ineligible. You do this when you repeat these steps to remove the partner node.

    2. Make the previous master node eligible to participate in the cluster again:

      cluster modify -node <node_name> -eligibility true
  6. Log into the remote node management LIF or the cluster-management LIF on a node that you are not removing from the cluster.

  7. Remove the nodes from the cluster:

    For this ONTAP version…​ Use this command…​

    ONTAP 9.3

    cluster unjoin

    ONTAP 9.4 and later

    With node name:

    cluster remove-node -node <node_name>

    With node IP:

    cluster remove-node -cluster_ip <node_ip>

    If you have a mixed version cluster and you are removing the last lower version node, use the -skip-last-low-version-node-check parameter with these commands.

    The system informs you of the following:

    • You must also remove the node's failover partner from the cluster.

    • After the node is removed and before it can rejoin a cluster, you must use boot menu option (4) Clean configuration and initialize all disks or option (9) Configure Advanced Drive Partitioning to erase the node's configuration and initialize all disks.

      A failure message is generated if you have conditions that you must address before removing the node. For example, the message might indicate that the node has shared resources that you must remove or that the node is in a cluster HA configuration or storage failover configuration that you must disable.

      If the node is the quorum master, the cluster will briefly lose and then return to quorum. This quorum loss is temporary and does not affect any data operations.

  8. If a failure message indicates error conditions, address those conditions and rerun the cluster remove-node or cluster unjoin command.

    The node automatically reboots after it is successfully removed from the cluster.

  9. If you are repurposing the node, erase the node configuration and initialize all disks:

    1. During the boot process, press Ctrl-C to display the boot menu when prompted to do so.

    2. Select the boot menu option (4) Clean configuration and initialize all disks.

  10. Return to admin privilege level:

    set -privilege admin
  11. Repeat Steps 1 to 9 to remove the failover partner from the cluster.

Related information