Considerations for grid node decommission

Contributors netapp-pcelmer netapp-perveilerk

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 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 all at 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 cloning the appliance node 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.