Removing a Shared Volume and Decommissioning a Site
Every add path needs a documented remove path. This chapter covers the supported way to remove a participant site from a share, and what to know about fully decommissioning a site — including what that does and does not do to data, objectives, and replication relationships.
Removing a Participant from a Share
gfs-participant-remove (and the equivalent action in the Management GUI) is the
supported way to remove a site’s participation in a share. This does not delete
data — it stops the site from participating in that share’s replication.
gfs-participant-remove --share-name Home --site-name "SITE B"Useful options:
--force-master-acquisition-
Only needed if a quorum of participants can’t agree which site is master for replication management — typically after a network partition. It is not a normal part of removing a participant, and carries the warning that it "may leave the share replication configuration in an undefined state," so use it only to recover from that specific situation, not routinely.
--ignore-remove-failures-
Proceeds even if a remote site is unreachable or was already removed. The same undefined-state warning applies — use only when you understand why the remote side can’t be reached.
|
|
Decommissioning a Site
Decommissioning means more than removing a participant: it means safely retiring a site altogether, with confidence that none of its data is stranded on a site that’s being taken away.
On 5.2 and 5.3, there is no supported, self-service procedure for this today. Removing every participant a site holds (above) does not, by itself, guarantee its data ownership moved anywhere first. If a site you’re retiring may still own data, contact Hammerspace Support before removing it rather than improvising a sequence — Support’s current process for this is handled case by case and isn’t a single documented procedure this guide can walk you through yet.