The node migration feature allows you to manually move a node from one host to another. Typically, both hosts are in the same physical data center.
Node migration allows you to perform physical host maintenance without disrupting grid operations. You simply move all StorageGRID Webscale nodes, one at a time, to another host before taking the physical host offline. Migrating nodes requires only a short downtime for each node and should not affect operation or availability of grid services.
For more information about node migration, see the Recovery and Maintenance Guide.
In order to move a node from one host to another, the StorageGRID Webscale host service needs to have some confidence that the external network connectivity the node has at its current location can be duplicated at the new location. It gets this confidence through the use of consistent network interface names in the hosts.
Suppose, for example, that StorageGRID Webscale NodeA running on Host1 has been configured with the following interface mappings:
The lefthand side of the arrows corresponds to the traditional interfaces as viewed from within a StorageGRID Webscale container (that is, the Grid, Admin, and Client Network interfaces, respectively). The righthand side of the arrows corresponds to the actual host interfaces providing these networks, which are three VLAN interfaces subordinate to the same physical interface bond.
Now, suppose you want to migrate NodeA to Host2. If Host2 also has interfaces named bond0.1001, bond0.1002, and bond0.1003, the system will allow the move, assuming that the like-named interfaces will provide the same connectivity on Host2 as they do on Host1. If Host2 does not have interfaces with the same names, the move will not be allowed.
There are many ways to achieve consistent network interface naming across multiple hosts; see "Configuring the host network" for some examples.
Given this mode of operation, all of the node’s system metadata and object storage volumes must be accessible from both HostA and HostB for the migration to be allowed, and to work. In addition, they must have been mapped into the node using names that are guaranteed to refer to the same LUNs on HostA and HostB.
The following example shows one solution for block device mapping for a StorageGRID Webscale Storage Node, where DM multipathing is in use on the hosts, and the alias field has been used in /etc/multipath.conf to provide consistent, friendly block device names available on all hosts.