Skip to main content

Considerations for decommissioning Admin, Gateway, or Archive Nodes

Contributors netapp-madkat netapp-lhalbert
PDFs

Review the considerations for decommissioning an Admin Node, Gateway Node, or Archive Node.

Considerations for Admin Node

  • You can't decommission the primary Admin Node.

  • You can't decommission an Admin Node if one of its network interfaces is part of a high availability (HA) group. You must first remove the network interfaces from the HA group. See the instructions for managing HA groups.

  • As required, you can safely change ILM policies while decommissioning an Admin Node.

  • If you decommission an Admin Node and single sign-on (SSO) is enabled for your StorageGRID system, you must remember to remove the node's relying party trust from Active Directory Federation Services (AD FS).

  • If you use grid federation, ensure that the IP address of the node you are decommissioning was not specified for a grid federation connection.

  • When you decommission a disconnected Admin Node, you will lose the audit logs from that node; however, these logs should also exist on the primary Admin Node.

Considerations for Gateway Node

  • You can't decommission a Gateway Node if one of its network interfaces is part of a high availability (HA) group. You must first remove the network interfaces from the HA group. See the instructions for managing HA groups.

  • As required, you can safely change ILM policies while decommissioning a Gateway Node.

  • If you use grid federation, ensure that the IP address of the node you are decommissioning was not specified for a grid federation connection.

  • You can safely decommission a Gateway Node while it is disconnected.

Considerations for Archive Node

Note Support for Archive Nodes and the Cloud Tiering - Simple Storage Service (S3) option have been deprecated. Archive Node support will be removed completely in a future release.

  • You can't decommission an Archive Node if it is still connected to the grid. To remove an Archive Node, confirm that the node is no longer being used, data has been migrated to a different location, and the node is powered off. Then, use the decommission procedure for disconnected nodes.

  • If the Archive Node is still in use, make sure your schedule includes enough time to move any existing data to Storage Nodes or a Cloud Storage Pool. Moving the data from an Archive Node might take several days or weeks.

Steps

  1. If you are currently using an Archive Node with the Cloud Tiering - Simple Storage Service (S3) option, migrate your objects to a Cloud Storage Pool.

  2. Confirm that the Archive Node is no longer being used by any ILM rules in the active ILM policies.

    1. Go to the ILM > Storage pools page.

    2. From the list of storage pools, select any storage pools that contain only Archive Nodes.

    3. Select the ILM usage tab.

    4. If any ILM rules are listed, look at the Used in active policy column to determine if the Archive Node storage pool is being used in an active policy.

    5. If the storage pool is being used, create a new ILM policy that no longer uses the Archive Node.

    6. Activate the new policy.

    7. Wait for all objects to be moved from the Archive Node storage pool. This might take several days or weeks.

  3. After you are certain all objects have been moved from the Archive Node, power down the node.

  4. Perform the decommission procedure for disconnected nodes.