Considerations for decommissioning Storage Nodes
-
PDF of this doc site
- Install and upgrade software
-
Install and maintain hardware
- SG5700 storage appliances
- SG5600 storage appliances
-
Configure and manage
- Administer StorageGRID
- Use StorageGRID
-
Monitor and troubleshoot
- Monitor a StorageGRID system
Collection of separate PDF docs
Creating your file...
If you plan to decommission a Storage Node, you must understand how StorageGRID manages the object data and metadata on that node.
The following considerations and restrictions apply when decommissioning Storage Nodes:
-
The system must, at all times, include enough Storage Nodes to satisfy operational requirements, including the ADC quorum and the active ILM policy. To satisfy this restriction, you might need to add a new Storage Node in an expansion operation before you can decommission an existing Storage Node.
-
If the Storage Node is disconnected when you decommission it, the system must reconstruct the data using data from the connected Storage Nodes, which can result in data loss.
-
When you remove a Storage Node, large volumes of object data must be transferred over the network. Although these transfers should not affect normal system operations, they can have an impact on the total amount of network bandwidth consumed by the StorageGRID system.
-
Tasks associated with Storage Node decommissioning are given a lower priority than tasks associated with normal system operations. This means that decommissioning does not interfere with normal StorageGRID system operations, and does not need to be scheduled for a period of system inactivity. Because decommissioning is performed in the background, it is difficult to estimate how long the process will take to complete. In general, decommissioning finishes more quickly when the system is quiet, or if only one Storage Node is being removed at a time.
-
It might take days or weeks to decommission a Storage Node. Plan this procedure accordingly. While the decommission process is designed to not impact system operations, it can limit other procedures. In general, you should perform any planned system upgrades or expansions before you remove grid nodes.
-
Decommission procedures that involve Storage Nodes can be paused during certain stages to allow other maintenance procedures to run if needed, and resumed once they are complete.
-
You cannot run data repair operations on any grid nodes when a decommission task is running.
-
You should not make any changes to the ILM policy while a Storage Node is being decommissioned.
-
When you remove a Storage Node, data on the node is migrated to other grid nodes; however, this data is not completely removed from the decommissioned grid node. To permanently and securely remove data, you must wipe the decommissioned grid node's drives after the decommission procedure is complete.
-
When you decommission a Storage Node, the following alerts and alarms might be raised and you might receive related email and SNMP notifications:
-
Unable to communicate with node alert. This alert is triggered when you decommission a Storage Node that includes the ADC service. The alert is resolved when the decommission operation completes.
-
VSTU (Object Verification Status) alarm. This notice-level alarm indicates that the Storage Node is going into maintenance mode during the decommission process.
-
CASA (Data Store Status) alarm. This major-level alarm indicates that the Cassandra database is going down because services have stopped.
-