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

General considerations for grid node decommission

Contributors netapp-madkat netapp-perveilerk ssantho3 netapp-lhalbert
PDFs

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 can't decommission a node if doing so will leave StorageGRID in an invalid state. The following rules are enforced:

  • You can't decommission the primary Admin Node.

  • You can't decommission Archive Nodes.

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

  • You can't decommission a Storage Node if its removal would affect the ADC quorum.

  • You can't 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 can't 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 all at the same time, which increases the potential for unexpected results.

  • If a disconnected node can't 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 cloning the appliance node instead of decommissioning the old node and adding the new node in an expansion.

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