Evicting Data (Technology Preview)

In certain cases, there is a need to evict a server and move data on its nodes to other servers in the cluster. This operation is user-initiated and will migrate all of a server's resources (e.g., volumes, snapshots) to other servers within the cluster. Data on volumes with RF=1 cannot be migrated at this point, and the evict process will fail. The evict functionality enables migration of the volumes associated with this server prior to a disable server maintenance operation, ensuring that the volumes remain fully protected.

The evict server process can be used when there is a need to perform planed maintenance on the server and you do not want the maintenance to impact the data availability in the cluster. It can also be used in cases where a server's nodes become unavailable and you would like to trigger an immediate eviction of data and not wait for the nodes to become permanently failed.

If a server is no longer needed after the evict was completed, make sure to delete and remove the server from the cluster (delete server API).

Additional Considerations and Limitations

1. To successfully evict a server, ensure that there are enough servers/resources/capacity available to evict the data from the server.
2. A cluster should have at least four servers (evicting a cluster with three servers is not supported)
3. Evicting a server that has volumes that are placed with placement affinity (PrimaryFD) will work, but the PrimaryFD rules will be ignored.
4. Evicting a server with RF=1 volumes is not possible. These volumes should be deleted before evicting the server.
5. Only one evict process can run at a time. Calling the evict API when an evict process is not supported could cause unexpected behavior.
6. It is best to run the evict process when all other servers are healthy and nodes are available.
7. Make sure to monitor the evict process and make sure it is completed before doing any other maintenance activities in the cluster (upgrade, restart, etc..).