Considerations for decommissioning grid nodes
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.
Do not remove a grid node's virtual machine or other resources until instructed to do so in decommission procedures. |