steps are required because the failure is restricted to an HA pair and storage failover commands can be
used to provide nondisruptive operation during the replacement.
• This procedure includes steps for automatically or manually reassigning drives to the replacement
controller, depending on your system’s configuration.
You should perform the drive reassignment as directed in the procedure.
• You must replace the failed component with a replacement FRU component you received from your
provider.
• You must be replacing a controller module with a controller module of the same model type. You cannot
upgrade your system by just replacing the controller module.
• You cannot change any drives or drive shelves as part of this procedure.
• In this procedure, the boot device is moved from the impaired controller to the replacement controller so
that the replacement controller will boot up in the same version of ONTAP as the old controller module.
• It is important that you apply the commands in these steps on the correct systems:
◦ The impaired controller is the controller that is being replaced.
◦ The replacement controller is the new controller that is replacing the impaired controller.
◦ The healthy controller is the surviving controller.
• You must always capture the controller’s console output to a text file.
This provides you a record of the procedure so that you can troubleshoot any issues that you might
encounter during the replacement process.
Shut down the impaired controller - AFF A220 and FAS2700
Shut down or take over the impaired controller using the appropriate procedure for your
configuration.
Option 1: Most systems
To shut down the impaired controller, you must determine the status of the controller and,
if necessary, take over the controller so that the healthy controller continues to serve data
from the impaired controller storage.
If you have a cluster with more than two nodes, it must be in quorum. If the cluster is not in quorum or a healthy
controller shows false for eligibility and health, you must correct the issue before shutting down the impaired
controller; see the
Administration overview with the CLI.
Steps
1. If AutoSupport is enabled, suppress automatic case creation by invoking an AutoSupport message:
system node autosupport invoke -node * -type all -message
MAINT=_number_of_hours_down_h
The following AutoSupport message suppresses automatic case creation for two hours: cluster1:*>
system node autosupport invoke -node * -type all -message MAINT=2h
2. If the impaired controller is part of an HA pair, disable automatic giveback from the console of the healthy
controller: storage failover modify -node local -auto-giveback false
243