Decommission a Volume

Applies to: Hammerspace 5.2 and later.

Decommissioning evacuates a volume’s data onto the remaining volumes, then removes it. The evacuation uses contention mobilities, which take priority over background mobilities, so it can put significant load on a cluster.

Before you start:

Consider changing the share objectives first, so the data moves in the background, and decommission the volume once most or all of it has already moved.
If you would rather not change objectives and a large amount of data has to move, start the decommission during a quiet period.
Check that the remaining volumes have room for the data.
If the remaining volumes hit their thresholds and object storage volumes are available, data is evacuated to object storage.
The oldest files move first, measured by last-used age.

Contact Hammerspace Support if you would like guidance before decommissioning a volume.

The process has two parts: decommission and delete the Hammerspace volume, then delete the logical volume underneath it.

Decommission and Delete the Volume

In the GUI, go to Infrastructure Volumes.
In the Actions column for the volume, click the decommission (trash can) icon.
Answer Yes and click Decommission. Remove volume after decommission is selected by default, which removes the volume automatically once the evacuation finishes.

Data is now placed on other volumes without interrupting access. If there is not enough capacity for all of it, the decommission does not finish until you add capacity or add a cloud or object volume.

When the volume disappears from the Volumes page, the evacuation is complete.

Delete the Logical Volume

This step is only needed if you intend to remove or replace the underlying device. It is CLI-only.

Confirm the volume was decommissioned and deleted. You cannot delete the logical volume if the decommission did not finish.
Sign in to the CLI with an administrative account and delete the logical volume, checking the device path against drive-list or node-list --name <NODE NAME> first.

Command:
```
logical-volume-delete
```

The backing device can now be removed. How you do that depends on whether the node is physical, virtual, or cloud-based. Whichever it is, Hammerspace recommends powering the node down before removing a physical device.

Run any CLI command with --help for its full syntax.

Objectives and Volume Groups

Objectives that name the volume you are decommissioning need attention, and it is much easier to handle if you are already using volume groups.

Identify every objective that references the volume and change it to point somewhere else — preferably a volume group rather than another individual volume. If you decommission the volume before changing those objectives, they stop applying and default objectives are used to place the data instead.

Hammerspace recommends volume groups over individual volumes generally. With volume groups, adding, removing, or changing a storage volume does not require editing tiers and objectives, and changes take effect immediately. If you are not using them yet, create them before decommissioning anything.

Recommendations for volume groups:

Use them as an abstraction layer, so tiers and objectives never reference a storage volume directly.
Use them to express custom capabilities such as geographic or failure domains.
Do not mix volumes of very different capabilities in one group — flash with spinning disk, or large volumes with small ones.
Do not put more than one object storage bucket in a group used by a tier, unless the bucket has multiple endpoints presenting the same namespace. More than one bucket means worse deduplication, more upload bandwidth, and extra garbage collection as files move between buckets.