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:
- 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.
- Determine the hosts that the volumes are
mapped to by issuing the lsvdiskhostmap command.
- Determine if any of the volumes that
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 #rmnodecanister/delete_node_prereq.
- 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.
- 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 #rmnodecanister/delete_node_prereq.
- 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.
- 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.
- 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: - 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.
- 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.
- 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.
- 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: - 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.
- 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
rmnodecanister 1
The resulting output
No feedback