rmnodecanister

Use the rmnodecanister command to delete a node canister from the clustered system (system). Enter this command at any time after a system has been created.

Syntax

rmnodecanister [ -force ] { object_id | object_name }

Parameters

-force
(Optional) Overrides the checks that this command runs. The parameter overrides the following two checks:
  • If the command results in volumes going offline, the command fails unless the force parameter is used.
  • If the command results in a loss of data because there is unwritten data in the write cache that is contained only within the node canister to be removed, the command fails unless the force parameter is used.
If you use the force parameter as a result of an error about volume going offline, you force the node canister removal and run the risk of losing data from the write cache. The force parameter should always be used with caution.
object_id | object_name
(Required) Specifies the object name or ID that you want to modify. The variable that follows the parameter is either:
  • The object name that you assigned when you added the node to the clustered system
  • The object ID that is assigned to the node - not the worldwide node name (WWPN)

Description

This command removes a node canister from the system. This makes the node canister a candidate to be added back into this system or into another system. After the node canister is deleted, the other canister in the I/O group enters write-through mode until another canister is added back into the I/O group.

Attention: When you run the rmnodecanister command to remove the configured hardware for a node canister:
  • Small Computer System Interface-3 (SCSI-3) reservations (through that node canister) are removed
  • Small Computer System Interface-3 (SCSI-3) registrations (through that node canister) are removed

By default, the rmnodecanister command flushes the cache on the specified canister before the canister is taken offline. In some circumstances, such as when the system is already degraded (for example, when both canisters in the I/O group are online and the volumes within the I/O group are degraded), the system ensures that data loss does not occur as a result of deleting the only canister with the cache data.

The cache is flushed before the canister is deleted to prevent data loss if a failure occurs on the other canister in the I/O group.

Run the rmnodecanister command with the force parameter to take the specified node canister offline immediately without flushing the cache (while ensuring that there is no data loss).

Attention: These prerequisites should be considered:

Before you issue the rmnodecanister command, perform the following tasks and read the following Attention notices to avoid losing access to data:

  1. Determine which volumes are still assigned to this I/O group by issuing the following command. The command requests a filtered view of the volume, where the filter attribute is the I/O group. 
    lsvdisk -filtervalue IO_group_name=name
    where name is the name of the I/O group.
    Note: Any volumes that are assigned to the I/O group that this node canister belongs to are assigned to the other canister in the I/O group; the preferred canister is changed. You cannot change this setting back.
  2. Determine the hosts that the volumes are mapped to by issuing the lsvdiskhostmap command.
  3. Determine if any of the volumesthat are assigned to this I/O group contain data that you need to access:
    • If you do not want to maintain access to these volumes, go to step 5.
    • If you do want to maintain access to some or all of the volumes, back up the data or migrate the data to a different (online) I/O group.
  4. Determine if you need to turn the power off to the node:
    • If this is the last node canister in the system, you do not need to turn the power off to the node. Go to step 5.
    • If this is not the last node canister in the system, turn the power off to the canister that you intend to remove. This step ensures that the Subsystem Device Driver (SDD) does not rediscover the paths that are manually removed before you issue the delete canister request.
  5. Update the SDD configuration for each virtual path (vpath) that is presented by the volumes that you intend to remove. Updating the SDD configuration removes the vpaths from the volumes. Failure to update the configuration can result in data corruption. See the Multipath Subsystem Device Driver: User's Guide for details about how to dynamically reconfigure SDD for the given host operating system.
  6. Quiesce all I/O operations that are destined for the node canister that you are deleting. Failure to quiesce the operations can result in failed I/O operations being reported to your host operating systems.
Attention:
  1. Removing the last node canister in the system destroys the system. Before you delete the last node canister in the system, ensure that you want to destroy the system.
  2. If you are removing a single node canister and the remaining canister in the I/O group is online, the data can be exposed to a single point of failure if the remaining canister fails.
  3. This command might take some time to complete since the cache in the I/O group for that node canister is flushed before the canister is removed. If the force parameter is used, the cache is not flushed and the command completes more quickly. However, if the deleted canister is the last canister in the I/O group, using the force option results in the write cache for that canister being discarded rather than flushed, and data loss can occur. Use the force option with caution.
  4. If both nodes in the I/O group are online and the volumes are already degraded before deleting the node, redundancy to the volumes is already degraded and loss of access to data and loss of data might occur if the force option is used.
Notes:
  1. If you are removing the configuration node, the rmnodecanister command causes the configuration node canister to move to a different canister within the system. This process might take a short time: typically less than a minute. The system IP address remains unchanged, but any SSH client attached to the configuration node canister might need to reestablish a connection. The management GUI reattaches to the new configuration node canister transparently.
  2. If this is the last node canister in the system or if it is currently assigned as the configuration node, all connections to the cluster are lost. The user interface and any open CLI sessions are lost if the last canister in the system is deleted. A time-out might occur if a command cannot be completed before the node canister is deleted.

An invocation example for rmnodecanister

rmnodecanister 1

The resulting output 

No feedback
Parent topic: Clustered system commands