When maintaining or decommissioning a group of nodes in a LINSTORⓇ cluster, it’s common to use the linstor node evacuate command to automatically relocate resources from one node to others in the cluster. However, in scenarios where the cluster is split into distinct node groups, or multiple nodes are destined for evacuation, the default evacuation behavior can sometimes lead to undesirable placement decisions. This might be the case if you have implemented a LINSTOR stretched cluster as part of a disaster recovery plan, for example.
LINSTOR version 1.33.0 introduces new options to the linstor node evacuate subcommands to eliminate these inefficiencies. The following example scenario describes the LINSTOR node evacuation options, --target and --do-not-target.
Example scenario
Imagine a cluster with two groups of nodes:
- Group 1:
nodeA,nodeB,nodeC - Group 2:
nodeX,nodeY,nodeZ
The goal is to migrate all resources from Group 1 to Group 2, to decommission the hardware in Group 1. By default, if you run:
linstor node evacuate nodeA
LINSTOR will attempt to find suitable target nodes for the resources on nodeA. In some cases, depending on available storage and placement policies, LINSTOR can select other nodes in Group 1 when relocating the resources replicas on nodeA.
Similarly, if you then run:
linstor node evacuate nodeB
LINSTOR could choose nodeC as a target for some of the evacuated resources from nodeB. This is clearly undesirable when the intent is to vacate all of Group 1. Not only does it compound the number of resource replicas on nodes that will subsequently be evacuated, but it adds unnecessary resynchronization traffic to your replication network.
Using LINSTOR node evacuation targeting options
To address this, LINSTOR developers introduced evacuation targeting options in LINSTOR server version 1.33.0:
linstor node evacuate NODE --do-not-target NODE [NODE...]
linstor node evacuate NODE --target NODE [NODE...]
These options give administrators explicit control over which nodes will or will not be selected as evacuation targets.
Example 1: Using --do-not-target
You can exclude nodes in Group 1 from being selected as evacuation targets:
linstor node evacuate nodeA --do-not-target nodeA nodeB nodeC
linstor node evacuate nodeB --do-not-target nodeA nodeB nodeC
linstor node evacuate nodeC --do-not-target nodeA nodeB nodeC
This ensures that resources are never relocated onto the nodes being decommissioned during evacuation.
📝 NOTE: Specifying a node in the
--do-not-targetlist while evacuating that same node, such aslinstor node evacuate nodeA --do-not-target nodeA [...], doesn’t hurt. It’s redundant but makes scripting and copy-pasting easier.
Example 2: Using --target
Alternatively, you can explicitly list the nodes in Group 2 as targets for evacuated resource replicas:
linstor node evacuate nodeA --target nodeX nodeY nodeZ
linstor node evacuate nodeB --target nodeX nodeY nodeZ
linstor node evacuate nodeC --target nodeX nodeY nodeZ
This approach ensures that only the specified nodes are considered for placement.
Conclusion
Hopefully the simple scenarios in this article illustrated the practical use cases for this feature. By explicitly defining which nodes should or should not be used as evacuation targets, administrators gain fine-grained control over resource placement during planned migrations or prolonged maintenance operations. This helps avoid unnecessary replica movements within the same node set and ensures that replicas are relocated only to the intended target nodes, resulting in more predictable and efficient evacuation workflows.