Skip to main content
A newer release of this product is available.

Considerations for decommissioning grid nodes

Contributors netapp-lhalbert

Before you start this procedure to decommission one or more nodes, you must understand the implications of removing each type of node. Upon the successful decommissioning of a node, its services will be disabled and the node will be automatically shut down.

You cannot decommission a node if doing so will leave the StorageGRID in an invalid state. The following rules are enforced:

  • You cannot decommission the primary Admin Node.

  • You cannot decommission Archive Nodes.

  • You cannot decommission an Admin Node or a Gateway Node if one of its network interfaces is part of a high availability (HA) group.

  • You cannot decommission a Storage Node if its removal would affect the ADC quorum.

  • You cannot decommission a Storage Node if it is required for the active ILM policy.

  • You should not decommission more than 10 Storage Nodes in a single Decommission Node procedure.

  • You cannot decommission a connected node if your grid includes any disconnected nodes (nodes whose health is Unknown or Administratively Down). You must decommission or recover the disconnected nodes first.

  • If your grid contains multiple disconnected nodes, the software requires you to decommission them at all the same time, which increases the potential for unexpected results.

  • If a disconnected node cannot be removed (for example, a Storage Node that is required for the ADC quorum), no other disconnected node can be removed.

  • If you want to replace an older appliance with a newer appliance, consider using the appliance node cloning procedure instead of decommissioning the old node and adding the new node in an expansion.

Important Do not remove a grid node's virtual machine or other resources until instructed to do so in decommission procedures.